You may not need a live coding session to hire a good programmer

Introduction:

I have never liked live coding in the recruitment process. Just a few years ago, it was obvious that a candidate, in addition to the theoretical part or other stages of the recruitment process, had to face at least a few minutes of potential embarrassment. This often involved coding an algorithm or a piece of a component in a framework with several people watching closely as each keystroke echoed through the room.

Neither candidates nor recruiters particularly enjoyed this process, but if you asked anyone whether it could be bypassed or organized differently, they would probably respond, ‘After all, how else can you better assess someone’s programming skills than by actually looking at their work and thinking process while performing a task?’

In this article, which is part of my series of reflections as a technical recruiter, I will share my insights into why I have decided to abandon live coding in the recruitment processes I conduct. While this perspective is that from the standpoint of frontend development, it seems to me that a significant portion of my observations seems to be rather universal.

My experiences with live coding as a candidate and initial observations:

In addition to the most basic form involving screen sharing and writing (and, of course, optimizing) an algorithm, live coding can take various forms. As a candidate, I have participated in pair programming (no idea why we call it that since it is basically you writing and explaining everything) and I have fixed a working code prepared on a specific platform, which involves getting familiar with multiple files and their interactions. I even encountered a scenario where I had to build a complete CRUD in React with TypeScript, and style within an hour on a laptop not connected to the Internet with IDE I don’t usually use. Although I must admit that the recruiter, in that instance, wasn’t directly observing my hands and was rather busy with other tasks nearby.

Despite completing most of these sessions with great success, I started to realize that my skills were not necessarily thoroughly assessed. Furthermore, I imagined that someone with an extensive knowledge but a different organizational approach, a slightly slower pace, or someone in need of a syntax refreshment in a specific technology could be dismissed — to the detriment of both parties — the company and the candidate.

Basic issue with live coding:

How often do we, as programmers, experience real stress when we have to deliver some code within ten or fifteen minutes with a manager looking over our shoulder? This rarely happens to anyone. In most cases, a programmer is not a surgeon, and it doesn’t matter whether they spend 10 minutes or an above-average 20 minutes on a specific problem. Creating pressure just to see how someone will perform in these conditions can be avoided. If it’s a complicated algorithm, it is usually better to take your time, analyze all the options and then start implementing it — rushing through the process is certainly not recommended.

It’s completely baffling to me how FAANG companies, probably for prestige reasons, put candidates through multiple timed live coding sessions just so their employees can later film videos like — ‘A day as a programmer where I constantly play foosball with the team or go to the buffet, and review code with a coffee in hand during breaks’. Why make people anxious if it does not matter after all?

Optimize that algorithm:

The next problem, more specific to frontend development, is that there isn’t much to test. Certainly, there are always the classics such as the Fibonacci sequence and FizzBuzz, but questions about algorithm optimization seem to be constantly coming up in job interviews. Frontend rarely deals with very large datasets where shaving off milliseconds could matter. Of course, there are exceptions, such as the number of frames per second in the implementation of interactions between elements on a canvas (e.g., d3.js), but most of the time, computational complexity doesn’t make much difference — whether it’s O(n²) instead of O(n log n) when sorting a hundred elements. Most optimizations are not something humanity encounters for the first time, so ready-made implementations are verified and available immediately after a quick search or AI copilot assistance. Same with tree traversal algorithms — I have never implemented them after leaving university.

What about the frontend application part? Well, it doesn’t test anything either. I felt extremely awkward asking mid or senior developers to create a basic React or Angular component that displays names from an array as paragraphs because this is something they should know at the trainee level. What about more significant tasks? There is no time, and to be honest, I lack the patience of going through the process of explaining more complex scenarios. From my experience, it is better to discuss these issues rather than watch a candidate struggle to declare every function and find syntax errors on the platform or code playground provided by the company.

If I had to choose one thing that I would ask and which is defendable in terms of content, it is a question about some operations on objects and arrays, such as sorting, mapping, and reversing — that is actually what is needed on an everyday basis.

Conclusion:

In summary, live coding, although it seems to be an attractive tool in the IT recruitment process, comes with certain risks — some candidates simply fear it and believe that it undermines their comfort, leading them to opt out of the process. As a recruiter, it is crucial for me that the recruitment process is as candidate-friendly as possible, since this can influence their decision to choose one company over another. I constantly wonder whether this recruitment method truly reflects a programmer’s daily work in any way. Of course, there are cases where live coding may be the only possible and appropriate solution, one of them being when the candidate is entirely inexperienced, and we genuinely want to assess if they can write a “hello world” program.

Regrettably, I have frequently observed experienced developers (assuming from their CV) struggle to create a simple frontend code, like sorting and filtering an array. I can’t justify it as anything other than a high-stress scenario for someone. So, I wasn’t entirely sure if I could mark an ‘X’ on the candidate, especially if the tech discussion went well — perhaps it’s just not their day.

Certainly, there are candidates who meticulously set up their IDE for every live coding scenario and dedicate hours to exploring all possible exercises on the LeetCode platform. Undoubtedly, they will excel in these assessments and will likely secure their jobs most of the time — but does it mean they are really better programers with bigger perspective or just ‘practice makes perfect’ algorithm excercises resolvers?

Talking to many other recruiters and candidates, I know that we are moving away from live coding, and we are using this method less and less in recruitment. In the upcoming articles, I will describe what to do instead in order to make the recruitment process more relaxed while providing us with greater insights into the candidate, especially in limited time conditions.

I am curious what you think about this, from the perspective of a candidate as well as a technical recruiter.