How to conduct well measured programming interviews and importance of interviewer humility

There are always a few hard problems that has me scratching my head over for multiple days with no solution in sight. How I wish I could solve such problems in 30 minutes in an interview like in the cartoon above :-). Jokes apart, above is an example of what I think should not be happening in an interview.

Programming interviews are hard, for both the interviewee and the interviewer. Many interviewers think that their job is over after they have selected a question. But they need to cover a lot of additional ground work to take care of these points as well:

• Even before the programming interview begins, has the hiring manager defined the Job Description (JD) with performance-based expectations to be successful on the job? If you want the top performers in the industry to get excited about your job, just mentioning the laundry list of traditional skills and competencies is not enough.
• Is coding/design question selection realistic and evaluation of candidate response rightly measured? You can find more about this in Are the interview programming questions appropriately selected? The gist is that we want to test the candidate's ability to perform in something similar to the environment they'd be working in if they got hired. The challenges of the interview should be challenges that are likely to appear in their day-to-day work environment.
• Are we giving enough weightage to candidate's original thought process, reasoning and her solution, or we want candidate to produce solution from our cheat sheet (which in my mind is very bookish and limiting)? While you usually give the candidate a programming task to work on during the interview, it is the process through which a candidate finds a solution that reveals the most about whether they can write code. Are we having a conversation with the candidate before the solution is written down to evaluate her thought process and approach, or we are giving a question and passively waiting for the candidate to code it? If it's the latter, what's the difference between an online assessment and an onsite interview with human interaction? As an interviewer, you should end up with a much more holistic view of the candidate than "finished task X in Y minutes".

The thought process that the candidate brings on the table while making a journey to the final solution is more important than the final solution itself.

• Are we nitpicking over minor details when there is less than 30 minutes on a task she has never seen before, often on a whiteboard or paper without editors or tools the candidate is comfortable with? An example of this could be nulls have not been handled or these edge cases have been missed. We definitely should expect her to do this if there is enough time remaining and she actually missed them even after we had set that expectation (no mind reading please :-)). But if there is very little spare time left to do this after having spent most of the time on the core logic of the problem, its probably ok if these got missed.

In a real work setting, she may have days or weeks to design and code the same task and we should not nitpick about this and make this a deal breaker

• Are we setting up the candidate for success during the interview? She should not need to deal with vague instructions, unclear expectations, or the mind-games of trying to guess "what does the interviewer actually want". Having a conversation and exchanging ideas does not mean we are "giving a hint" to her.

Onus is on the interviewer to let creativity flow and genuinely make an effort to understand her thought process and challenge her on her approach - if what the candidate is saying seems reasonable to you and she is able to defend the darts thrown at her, let her continue on her path to her solution, and not your solution in the cheatsheet.

Let her calculate the time and space complexity of her solution. Her solution need not be the most efficient one but if it's better than brute force one, then it's great! In my view, if she is smart enough to come up with her own solution, then she will be smart enough to figure out most efficient solution when working on a real project which certainly has more time than 30 minutes on the interview :-) This simulates the real life situations well and I have seen such candidates do well on the job.

An environment should be created to help the candidate succeed

• Last but not the least, does the interview realistically measure whether candidate would exceed the expectations of the JD that we are hiring for? It ties back to one of the points raised above but its very easy to lose sight of this. I was reading this article about why Google stopped asking crazy hard interview questions and it highlights how easy it is to lose sight of this and fall into the trap of making the interviewer feel smart in front of the candidate, his peer interviewers or boss.

Doing a well measured programming interview requires the interviewer to be humble and mature. A situation should not arise where the interviewer is feeling smart grilling the candidate, while she is feeling miserable. Even if you don't want to hire her, she probably has friends you would want to hire! Word spreads, and during an interview, she is interviewing your company as well.

We need to ensure that candidates are getting a fair opportunity as outlined in 5 well-balanced tips Hiring Manager should follow for hiring top engineers. Onus is on the interviewers to provide a good long term candidate experience while doing full justice to both the candidate and the company, which is the one that stands to gain most if it were to hire such a top performer.

What do you think? Please share your valuable thoughts in the comments section below.

Disclaimer: All the postings and views on this site are my own and has no bearing whatsoever on my employer's position.

Keywords: #hiring, #attitude, #PassionateEngineers, #interview, #interviewing, #ProgrammingInterview, #skills