A framework for grading your performance on programming interview problems
I think it is focusing on the wrong parts.<p>My framework for the coding part of the interview is following:<p>* Does the candidate tackle the problem analytically? Being able to think analytically is critical to scaling from solving small problems to solving large problems.<p>* Can the candidate predict what his code is going to do before he executes it? Repetitively executing code to see if it works may seem innocuous, but really is a huge defect in candidate&#x27;s process which makes it really difficult or impossible for them to write anything non trivial to be reliable.<p>* Can the candidate recognize and make use of an advice? Surprisingly, a lot of people can&#x27;t recognize when they are given advice even when I directly give them solution to their problem. It is really disheartening to have a candidate dismiss your advice even when repeated multiple times. I frequently give advice to unstuck the candidate because seeing him&#x2F;her work on the problem is more important to me than seeing if they can solve any particular part of the problem.<p>* Can the candidate recognize choices&#x2F;tradeoffs that impact performance and&#x2F;or simplicity of the solution?<p>* Can I have productive discussion with the candidate about designing his solution? Can the candidate converse in a clear and precise language?<p>* Is he&#x2F;she caring that the resulting code is readable?<p>* Can they diagnose faults in their code effectively? Assuming they executed their solution and it is not doing what it was expected to do, I like to see the candidate follow some kind of analytical process to find out what is causing the problem. I even design the task specifically so that it is very likely they are going to make one particular mistake to give me that opportunity.<p>**<p>What I specifically ignore in the coding task:<p>* Whether the candidate knows the standard library. I don&#x27;t care. During normal work they can look it up on google. On the interview I tell them that if they can describe the function I can tell them the name and how to use it.<p>* Whether the candidate can have flashes of insight. I don&#x27;t get so many candidates to waste them on that kind high false negative signal. I have identified parts of the task that require a flash of insight. I give the candidate a minute or two when they reach it and if I don&#x27;t see progress I give them a progressively less subtle nudges.<p>* Whether the candidate can do TDD&#x2F;DDD&#x2F;etc. It all depends on their experience. If they worked for non-TDD or non-DDD shop for a long time it is going to take some time to adjust.<p>* Whether the candidate can solve a very complex problem. The interview is already stressful enough experience for the candidate. I can learn what I need on a simple problem and I care much more to see the candidate&#x27;s process rather than results. The problem is just hard enough to be out of grasp of most people at the very beginning and require some actual thinking. Some people get it instantly and then I am disappointed a little bit because I can&#x27;t see them working on it.