Programmers can’t write algorithms without help: once more about the interview

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.

It’s no secret, quite often interviewers ask the so-called Basics of the language (in my case, it’s JavaScript), which includes algorithms. And here any normal (discussion centered around this definition can happen, but I insist on normality, without quotes) engineer faces two difficulties. But first, here’s a small explanation to “normality”: an ordinary developer is obligated to use up-to-date technical solutions adopted in his field in commercial development. For example, the best algorithms. However, whether an ordinary, normal programmer is required to remember specific implementations of the best algorithms in code remains in question.

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.

Exactly the same thing can be said about programming knowledge. With hand to heart, everyone can confess: sooner or later he forgets some things that are accepted as being related to the fundamentals. For example, any good JavaScript course includes the concept of OOP, exploring the topic of inheritance, creating “classes”, and so on. However, in modern projects, especially those based on frameworks, the programmer doesn’t directly use OOP paradigms that frequently. Not as often as OOP is asked about at interviews (and it is almost always asked). Naturally, there is collision between what is actual and what you, as it seems to you, firmly remembered (and successfully forgot).

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

---

Written by Maksim, translated from here