Why couldn't a potential hire be given 5 minutes to think about a solution and then be asked what their plan is? What benefit is added by 36x-ing the time allowed that justifies putting the candidate through such pain?
I have seen people who can talk very nicely, but are lost once they actually have to touch the code. I have also seen people who are really bad at articulating their plans, but are OK with coding them.
Because there are people who are very, very good at bluffing their way through that first 5 minutes. If that's all it takes to pass the interview, your company is about to make a mistake, potentially a big one.
This would be a totally unsuitable format for this task. When doing this task, most of the time is spent looking at the code and reading what is already there. The actual changes needed are very minimal. It is explicitly not about complicated logic flow or algorithms like most interviews, but rather about a software engineering process and the ability to discover things yourself.
Also, the actual time limit (the real author of the question showed up in this thread) was 1 hour. I'd say in actuality it's roughly a 30 minute process.
If I were running this as an interview question I would do exactly that -- give them 5 minutes to think then 5-10 minutes to describe their plan.
But THEN, I'd let them actually try to DO it. Because there is a huge swatch of people out there who can describe (and sound smooth about it) but can't DO. And there are also some who can do but don't sound very competent when they are asked to describe.
Many interview techniques never assess the ability to DO coding, presumably because it is more difficult and time consuming to evaluate.
This is the right way to handle this problem. Everything after 5-10 minutes waste both your time and the interviewer’s time. There’s nothing you can discover that’s important after walking through their plan other than to figure out if they are familiar with code bases like the one you’re using.
Couldn't disagree stronger with this. In fact, I love this problem, in that it gets rid of most of the complaints about engineering tech interviews: (1) it's "real world" (for the job in question), (2) can be reasonably done in the time alotted, (3) involves a task that is most common for developers (modifying existing code), (4) shouldn't require extra preparation.
I have seen many times where a user can actually explain the solution to a problem, but the translation from algorithm-to-code is extremely slow, or not done correctly at all. There is real skill in being able to output code quickly, even if you already know the English-language description.
I disagree with that. If you’re hiring a programmer, surely you want to seem them write some code.
This question has the added benefit that they don’t have to write a whole program from scratch, they have to deal with a real–world program instead of a toy program created specifically for interview purposes, and they have to demonstrate that they can read and understand other people’s code. The latter seems really important to me, as apparently it was to the author of the question, because we spend so much of our time improving code that has already been written instead of writing completely new programs. Of course, I am especially good at these software–archaeology skills, so I suppose I could be biased.
There’s many many people, far more than not, who can make a plan, even write the code but can never actually get it to run. They can’t compile things without someone helping, and they sure as hell can’t debug to save their lives. This is a good test to weed them out.
I have seen people who can talk very nicely, but are lost once they actually have to touch the code. I have also seen people who are really bad at articulating their plans, but are OK with coding them.