Preamble
In my carrier as an applicant to open engineering/tech positions I have done hundreds of interviews, and as an hiring manager I interviewed hundreds of candidates. I then also collect feedbacks from colleagues all around the world about the same topic. Rarely I found someone happy about a live coding challenge during an interview.
This article will try to summarize all the problems I found in this practice and, if possible, propose better alternatives.
I started working in the tech industry in a time, around 20 years ago, when during an interview the candidate was asked to write code on paper, with a pen. No PC, no laptop, no codepen, codesandbox, hackerrank or other tool involved. Naturally it was not a pleasant experience and was reminding exams' practices at University time. Time flies, but still nowadays many companies are proposing a virtual coding challenge for candidates of different seniority: junior/associate, mid-senior, senior and sometimes also to tech lead and engineering manager.
The goal of a live coding challenge should be to proof for the hiring manager or technical interviewer that an applicant can be a good fit for the team from a technical perspective.
The usual motivation behind this is too check how a person can solve a problem understanding the requirements and explaining what is thinking to the interviewer(s). The interviewer(s) could also provide some small hint s to the candidate in order to complete the task.
This procedure is always sugar coated with a premise “the task will be solved in a collaborative way”.
This approach for me starts already with a basic bias: given a problem the interviewer has in mind already one or multiple solution, as in general is expected that the interviewer themselves completed the same task previously in their own way.
If the candidate provide a different approach the interviewer should evaluate if this is better or worse, considering the same expected result. Sometimes even choosing the programming language could be impacting the interviewer’s feedback, because there are no developers that don’t love or hate a specific programming language.
So in most of the case becomes a biased interrogation about hows and whys. Also the candidate doesn’t know what is the favourite approach of the interviewer.
7 other reasons why I am in general against a live coding challenge
- during your normal daily developer’s routine no one is looking at your screen, questioning what you are doing and warning if you are out of time;
- in a live digital coding challenge anything can happen, connection is lost, your pc can have issues, the IDE could not work;
- when the IDE is not your IDE you are feeling less confident;
- a live coding challenge is not a pair programming sessions! Again, someone is looking at what your doing, is not working with you;
- when a big company is involved it could happen that the interviewer will be not even part of your future team, this means that the feedback about you will be assessed but you will not have the same opportunity;
- solving a fancy algorithm or asking to apply a specific pattern is not realistic;
- after the release of tools like https://chat.openai.com/ a live coding challenge could be easily solved by the AI, proposing to the candidate a good solution to the problem.
First alternatives to a live coding challenge: a take home assessment
The first critique to a take home assessment is that it requires more and everyone is busy because of the job, life, hobbies or other interests. I would like to confute this critique as a live coding challenge usually requires at least a dedicated synchronized session (one or more than an hour length) of at least two or more people (the candidate + one or more interviewer) during working hours.
Another point is that a take home assessment requires a bit of effort from the hiring company team side, but let me tell you this secret: if a team has no time to create or update every 3 to 6 months the assessment you found already a red flag.
But this means that the candidate should dedicate PTO while the interviewer are just doing their normal company tasks and they are paid for that.
With a take home assessment the candidate has the time, the space and the opportunity to focus on the given requirements, providing a solution but also already thinking to any possible bug fixing and/or improvement.
A take home challenges should be in general a small project that will last after the particular selection process. It could be reworked and analysed in a second time and could be part of the developers portfolio / cv.
Second alternatives to a live coding challenge: an automated platform
Nowadays there are multiple online platform where the candidate can receive a task to complete in a given amount of time. In the same platform the candidate can train themselves to the tool but also with other tasks in order to be more proficient. It could be less humane as it is a binary evaluation of a non-binary problem, but at the same time is less biased and can completed at any decided time of the applicant.
Also this tests are structured in a TDD way, so that you can try multiple inputs to solve the problem.
Last but not least this kind of platforms are used by many companies, so knowing one could help in a next application.
Conclusion
What I described is the result of collecting feedbacks from personal opinions of different friends and colleagues, and all of them were confirming my same idea. I would be interested into providing more analytical data related to the preferences of candidates around the world.
Recently during an interviewing process I was told that there was the possibility to choose between the live coding challenge and a take home assessment. This is the best scenario for me, the candidate should have the possibility to decide.