The Art of Interviewing

Had always wanted to know what it is like to sit on the other side of the table. But, ironically, one year and about a hundred interviews later, I realized that it is all about being on the same side of the table. Interviewing, I realized, is about sketching the character of a person; and the simplest way to do it is to make the person feel at home in the interview. Otherwise, you unfortunately have the task of figuring out the "true" from the "superficial".

So that's rule number 1: Make the candidate feel at home.

Call him boss or bhai (as we call any friend in India), just make the candidate feel comfortable; anyway you want it. Sometimes, if possible, sit on the same side of the table as the interviewee to stress the fact that you are just there to support their thinking and not to criticize it. Setting the stage can also depend on the candidate. Some candidates are nervous at the start. In such cases, I have found that a small chat about their hobby or favorite game helps a lot. For a geeky guy, a talk about the algorithm in his project or some interesting recent tool he worked on etc. sets the tempo. We also don't have any dress code for the interviews at our company. We just ask the candidates to dress in any way they are comfortable.


Another important fact about interviewing is that you are there to make a decision.
So never have an analagous answer scale - he was good but ..., he was average but good on some factors etc ...

The answer has to be a definite "Yes" or "No". The simple logic behind this is that you "might" just lose a good candidate by saying a "No" but the fact is that you will always mostly be able to find another good candidate. On the other hand, a misjudged "Yes" can cost the company dearly over a long term.

So rule number 2: Make a clear decision.


Interviewer: What do you do if you want to reverse a linked list?
Candidate: I would just iterate over the linked list editing pointers and go on ....
Interviewer: Hmm ... how do you do it recursively?

Find anything odd in the situation above? Well, the point to make here is that people think differently. So do not try to force your idea or solution onto the candidate. The best interviewers build the interview around the thought process of the candidate. So every interview might be unique inspite of the same questions being asked.

That makes rule number 3: Listen and adapt.


Another thing to have in mind while preparing questions for an interview is to decide carefully around what each question tells you about the candidate. Jot down the various areas you want to evaluate the candidate on. Plan the questions and discussion accordingly. You can wrap up the interview at any time you have collected all the data points you were looking for. This will greatly improve the efficiency of the interviewing process.

Thereby, rule number 4: Have an evaluation plan.


There is generally a false notion that you need to ask really tough questions to pick out the best candidates. In this sense, there is also a dread in many interviewer's minds is that - if the candidate already knew the answer to that question, then they might not have got a clear idea of the candidate's capabilities.

The best way to counter this is to focus on the discussion around the problem rather than on the actual solution. So design your questions in a way that they involve some discussion. Even if candidates know the question, you can easily judge their prowess from the way they describe and validate the solution. Maybe, ask a few variations on the original question to see how they improvize.

So here goes rule number 5: Focus on the discussion; not on the solution.


For industry hires, the best way to recognize a good software engineer is from his code. So, the questions asked are pretty simple. What we need to concentrate on is on the elegance of the solution. This is closely related to my previous article . It is about finding how deep a foundation have the coding practices laid into their daily work.

Rule number 6: Ask the candidate to code!

Guess I did learn some of these stuff personally over experience and also from this link So this post is probably my summarization of Joel's article with a few of my own hints.

Overall, I hope you found this article informative.

Signing off.