Programmers can not write algorithms without help: once again about the interview
David Hensson, the creator of Ruby on Rails, admitted on his Twitter account that he wouldn’t have written a bubble sort on the board. David looks at the code on the Internet all the time:
He was supported by numerous colleagues:
This topic, which periodically rises at different venues, is very helpful to my own experience: this week and a couple of past I have gone through several technical interviews in companies, and the question of how to prepare is now the most important for me.
')
It's not a secret, quite often interviewers ask so-called. The basics of the language (in my case, this is JavaScript), which also include algorithms. And here any normal (around this definition discussion is possible, but I insist on normality, without quotes) the engineer faces two difficulties. Only first, a small explanation of “normality”: an ordinary developer is obliged to use in commercial development advanced technical solutions adopted in his field. For example, the best algorithms. However, whether an ordinary, normal programmer is obliged to remember the specific implementation of the best algorithms in the code is a question.
So, two difficulties:
1) Often in an interview in front of you a piece of paper and a pencil. Either the board and the marker. In actual development, we use numerous tools that remove some routine tasks: for example, performing code code completion. And so, besides, given the somewhat stressful situation at the interview, it is not always possible to write the correct, syntactically correct code with the fly.
2) The second difficulty is a consequence of the fundamental characteristics of the digital era. Let me explain by a small example.
The last couple of years I have been learning Chinese. The main difficulty in learning Chinese is to remember the spelling of words expressed in hieroglyphs. Unlike European, familiar to us alphabetic languages, in Chinese, even if you well remember the pronunciation of the word, it is unlikely to help you remember its exact spelling. Modern electronic assistants help you with your business — applications for your phone; by entering phonetic words in Latin (phin yin) into which you can quickly get the desired hieroglyphs.
Periodically, I think how people were treated before. After all, at best, it was necessary to crawl into a thick dictionary each time in order to peek at the correct spelling of the desired word. This made completely different demands on the ability to memorize hieroglyphs, time to repeat them when studying, and so on.
In short, roughly speaking, some of the functions of our brain are unwittingly carried out to external interfaces. No, not the memory itself, but, let's say, a hash table for it, according to which we can quickly restore all the many knowledge that we gain in the ever-increasing flow of professional life.
Exactly the same thing can be said about knowledge in programming. Hand on heart, everyone can admit: sooner or later he will forget some things, which are accepted to refer to the Basics. For example, any good JavaScript course includes the notion of OOP, disclosing the topic of inheritance, creating “classes”, and so on. However, in modern projects, especially those based on frameworks, the programmer directly uses OOP paradigms in writing his code not so often. Not as often as asking the PLO for an interview when applying for a job (and almost always they like to ask him). Naturally, there are conflicts between what is in reality and what you, as you think, are firmly remembered (and successfully forgotten).
In other words, a successful programmer who knows where and how quickly to restore knowledge on the current topic, issuing a code every day and even capable of solving highly non-trivial tasks (for example, coming up with RoR), suddenly fails to interview in an interview, mumbling something not very intelligible, looking at the seemingly “childish” task. Then the question is - what really determines such an interview?
By the way, the bourgeoisie has research on this topic. For example, here it is .
Conclusion: "there is not so simple." Of course, any normal employer first of all wants to see in front of him a person who knows elementary things. Since our entire culture is primarily a written culture, the employer has the right to demand that the candidate can put his knowledge on paper. However, with programming (and, probably, with some other areas of intense mental labor), a simple fact is becoming more and more obvious: a person is no longer able to reproduce all of his knowledge without special keys and hints. Rather, the interview would be more productive to offer the applicant to solve this or that practical task, integrally evaluating his abilities and skills to find a solution, and not just recall individual pieces of code.
According to the materials of the article , the Russian translation is partially here .
He was supported by numerous colleagues:
This topic, which periodically rises at different venues, is very helpful to my own experience: this week and a couple of past I have gone through several technical interviews in companies, and the question of how to prepare is now the most important for me.
')
It's not a secret, quite often interviewers ask so-called. The basics of the language (in my case, this is JavaScript), which also include algorithms. And here any normal (around this definition discussion is possible, but I insist on normality, without quotes) the engineer faces two difficulties. Only first, a small explanation of “normality”: an ordinary developer is obliged to use in commercial development advanced technical solutions adopted in his field. For example, the best algorithms. However, whether an ordinary, normal programmer is obliged to remember the specific implementation of the best algorithms in the code is a question.
So, two difficulties:
1) Often in an interview in front of you a piece of paper and a pencil. Either the board and the marker. In actual development, we use numerous tools that remove some routine tasks: for example, performing code code completion. And so, besides, given the somewhat stressful situation at the interview, it is not always possible to write the correct, syntactically correct code with the fly.
2) The second difficulty is a consequence of the fundamental characteristics of the digital era. Let me explain by a small example.
The last couple of years I have been learning Chinese. The main difficulty in learning Chinese is to remember the spelling of words expressed in hieroglyphs. Unlike European, familiar to us alphabetic languages, in Chinese, even if you well remember the pronunciation of the word, it is unlikely to help you remember its exact spelling. Modern electronic assistants help you with your business — applications for your phone; by entering phonetic words in Latin (phin yin) into which you can quickly get the desired hieroglyphs.
Periodically, I think how people were treated before. After all, at best, it was necessary to crawl into a thick dictionary each time in order to peek at the correct spelling of the desired word. This made completely different demands on the ability to memorize hieroglyphs, time to repeat them when studying, and so on.
In short, roughly speaking, some of the functions of our brain are unwittingly carried out to external interfaces. No, not the memory itself, but, let's say, a hash table for it, according to which we can quickly restore all the many knowledge that we gain in the ever-increasing flow of professional life.
Exactly the same thing can be said about knowledge in programming. Hand on heart, everyone can admit: sooner or later he will forget some things, which are accepted to refer to the Basics. For example, any good JavaScript course includes the notion of OOP, disclosing the topic of inheritance, creating “classes”, and so on. However, in modern projects, especially those based on frameworks, the programmer directly uses OOP paradigms in writing his code not so often. Not as often as asking the PLO for an interview when applying for a job (and almost always they like to ask him). Naturally, there are conflicts between what is in reality and what you, as you think, are firmly remembered (and successfully forgotten).
In other words, a successful programmer who knows where and how quickly to restore knowledge on the current topic, issuing a code every day and even capable of solving highly non-trivial tasks (for example, coming up with RoR), suddenly fails to interview in an interview, mumbling something not very intelligible, looking at the seemingly “childish” task. Then the question is - what really determines such an interview?
By the way, the bourgeoisie has research on this topic. For example, here it is .
Conclusion: "there is not so simple." Of course, any normal employer first of all wants to see in front of him a person who knows elementary things. Since our entire culture is primarily a written culture, the employer has the right to demand that the candidate can put his knowledge on paper. However, with programming (and, probably, with some other areas of intense mental labor), a simple fact is becoming more and more obvious: a person is no longer able to reproduce all of his knowledge without special keys and hints. Rather, the interview would be more productive to offer the applicant to solve this or that practical task, integrally evaluating his abilities and skills to find a solution, and not just recall individual pieces of code.
According to the materials of the article , the Russian translation is partially here .
Source: https://habr.com/ru/post/323188/
All Articles