The Indian Tech Interview!

Disclaimer: Much of this is only going to be applicable to tech interviews in India

I have had the (un)fortunate privilege of interviewing for my previous company over several years. During this period I personally interviewed more than 700 people (mostly for developer/lead roles but at various levels). I have also given interviews at many places, both big and small.

I started out my company just some time back and I have been taking advice from lot of fellow entrepreneurs. To pay back the community, I wanted to write about something many others may benefit from. Preferably something they cannot self-learn without real-world experience. This is probably a good bet.

Many bloggers have talked about interviews, unfortunately they are either focused on the generalities of the west, or are rather idealistic. Here are my learnings, hopefully someone somewhere will benefit from it.

This entire article is about getting to the right people earlier, with least investment.

How is Indian Situation Different?

India suffers from a problem of excess, you have a load of candidates that just apply for the sake of it. About 50% of these are carbon copies, hence filtering is not an easy job.

This excess of candidates causes companies to do “formula” hiring. The formula is a numb assembly-line process replacing the rigor needed to hire a teammate. This formula encourages candidates to feign a “personality” that will get them most number of callbacks and interviews.

If you think the right candidates will not do this, stop kidding yourself! Smart candidates know they have to get past the exact same process of “keyword based selection” before they meet the real panel. The only way around for them, is to brave it and let it pass.

Soliciting/inviting candidates

A bad data set will never yield an optimum selection, you must diversify your inviting/soliciting methods. In short, never rely on only one channel.

The varying attenuation levels of each channel ensure that you avoid homogeneity of candidates. This is important since your ideal candidate is not necessarily a perfect match of your written requirements. Ideally you need a Gaussian Bell Curve kind of distribution around your “target profile”.

Popular options are head-hunters, self search via social networks (like LinkedIN) and internal referrals. There is also an often overlooked (but surprisingly powerful) option; re-invite a small selection of people from older interviews (perhaps for other teams) who were worthy but did not make the cut for minor reasons. This also means that if you come across a sharp individual in your hiring cycle, but cannot hire him/her for some minor reason, you must keep this name in your database.

The least effective option (in my opinion) is newspaper ads. They are just a migraine waiting to happen, you will get hundreds of poor responses each hour. The ROI of this is low enough to warrant complete omission. Of course, if you are looking to fill a lot of seats with average to above-average engineers, go for it.

Short Listing

If you have a pile of 500 resumes on your desk, not an easy thing to do. Here too, you should try to maintain some diversity. The idea here is got this done as fast as possible and ensure that you begin with the real interviews quickly.

There is no statistical advantage to spending 15 minutes on one resume as opposed to just 1 minute. Select based on weak criteria, be flexible. At this stage give the benefit-of-doubt to the candidate. This is to ensure that the bloaters don’t overshadow the genuine resumes just because they have a fancier skill-set.

Phone Interview

If feasible, please spend 5 minutes on the phone with each selected candidate. You will instantly be able to drop the “definitely-not” people. The things to note here are communication skills, the reason to switch company (yes its important, even if you know you’ll get a textbook answer) and the capability to explain themselves. Other defining criteria being gross mismatch of CTC expectation, relocation constraints and time to join (in India, some insane companies have 2 months mandatory notice period).

Written Test

Keep one if you are charming enough to convince your candidates without offending them :-) The ROI of this exercise is shockingly high. I try to keep the questions with the following split; 30% very easy, 40% not too easy, 10% tough, 20% simple logic (like simple puzzles or simple math). Also, all questions were multiple choice. The advantage of having multiple choice questions is that anyone can evaluate the answers and hence this can be done even without involving the tech team.


Don’t be casual about it.

Usually companies will request someone with less interviewing experience as the first filter, nothing wrong with that. BUT, avoid sending out your “preliminary interviewer” to invite the candidate inside. First person sets the tone for the interviewee’s expectations from the company. It is as much an interview of your company as it is of the candidate. In India, the right candidate will get offers from many places, your professionalism may be the deciding factor when it comes to choosing between you and Google (for instance).

Interviews must be staged, in favor of your time constraints, please be prepared to cut short an interview process politely if it is leading nowhere. Just like you, the candidate also does not want to waste their time. Also, you might be setting incorrect expectations if you extend a dead end interview.

Types of questions

Never ask questions from a text book, or some website. If you are the kind who likes people who can do just that, you are probably not reading this blog anyway.

Never ask questions about subtle programming syntax or API (surprisingly a lot of people make that mistake). Ask questions that are about logic and something they could not have learned from a book/blog. Try to keep it to algorithms and reasoning. Multithreading related extensions to known problems often work well. I often ask about thread safety when it comes to deletions in various data structures.

Ask them to write pseudo code for some well known but subtle problem (perhaps BFS).

Pick up one or two of the tough questions from the written test (that they got right) and expect a full explanation of how the answer was derived, don’t go easy here.

In the advanced stages, I sometimes ask about unrelated tech that they can talk neutrally about, it should be something they may know about. One of the things I was talking about recently, was amount of RAM on the new iPhone 4S. There is no right or wrong answer for why apple thinks 512MB enough while most competition seems to have 1GB.

Smart people can learn your tech

Face it, you are not looking to hire people because you don’t know how to spawn “pthreads”. You are hiring people who solve problems skillfully. Pthreads are a “man page” away, IQ is a lot harder to acquire.

That’s the bird’s eye view. If you want to know more about my reasoning, please contact me.

UPDATE: Slighly off the Indian context but a good read