David Hansson, the creator of Ruby on Rails, admitted in a tweet that he wouldn’t be able to write bubble sort on a whiteboard. David looks up code on the internet all the time:
He was supported by multiple colleagues:
This topic, which periodically comes up on different sites, fell right into my own experience: this week and a couple of past ones I went through several technical interviews with various companies, and the question about how to prepare is now of the utmost importance to me.
So, two difficulties occur:
1) Frequently in an interview, you’ll have in front of you a sheet of paper and a pencil, or a whiteboard and a marker. In real world development, we use numerous tools that remove some routine tasks: for example, code auto-completion. And so, also taking into account the somewhat stressful situation of an interview, it’s not always possible to write accurate, syntactically correct code on the fly.
2) The second difficulty is a consequence of the fundamental feature of the digital era. I will explain with a small example.
For the past couple of years I have been studying Chinese. The main difficulty in learning Chinese is remembering the spelling of words expressed in hieroglyphs. Unlike European, familiar to us alphabetic languages, in Chinese, even if you remember the pronunciation of a word, it is unlikely to be helpful in remembering its exact spelling. Modern electronic assistants — phone applications — ease this by having you enter into them phonetic words in Latin (Pinyin), helping you quickly find the characters you are looking for.
From time to time, I think about how people dealt with this in the past. And at best, it was necessary to look into a thick dictionary each time to find out the correct spelling of the desired word. This posed completely different demands on the ability to memorize hieroglyphs, the time for their repetition during study, and so on.
In short, to put it crudely, part of the functions of our brain is involuntarily taken out to external interfaces. No, not the memory itself, but, let’s say, a hash table for it, from which we can quickly restore all the numerous knowledge that we gain in the ever-accelerating stream of professional life.
In other words, a successfully programmer who knows where and how to quickly restore knowledge on the current topic, writing code every day and even capable of solving very non-trivial problems (for example, creating RoR), suddenly fails miserably at an interview, mumbling something not very intelligible, looking at what would seem like a “childish” task. Then the question arises – what does such an interview really define?
By the way, western companies have some research on this subject.
Conclusion: “It’s not all that clear.” Of course, any normal employer first of all wants to see a person in front of him who has basic knowledge. Since our whole culture is primarily a written culture, the employer has the right to demand that the candidate put his knowledge on paper. However, with programming (and probably in some other areas of intense mental work), a simple fact is becoming very obvious: a person is no longer able to reproduce all his knowledge without special keys, hints. Rather, in an interview, it would be more productive to offer that the applicant solve a practical problem, integrally assessing his abilities and skill to find a solution, and not just testing their abilities to remember individual pieces of code.
The material for this article can be found here