Interviewing is broken

I have been thinking about it for a long time but I was not sure until I posted Hacking job interviews on Hacker News a day ago. It taught me some invaluable lessons as a young college undergraduate who is, himself, giving interviews to a few companies these days. Simultaneously I have been also wondering why I am giving those interviews!

February 18th was the day I posted or commented on Hacker news for the first time in my life. Nothing has ever excited me more than those 70 points i got on that day, and an array of comments that gave insights into the real thought process going around the world. Here I attempt to examine the interviewing system and raise a few question lying underneath them. Caveat: May be biased towards an undergraduate student who is yet to see the real world!

Till a few months ago, I was heavily opposed to the idea of yet another ‘reverse this linked list’ question. I am also now, but not so much. Here is why. Because projects are not precise reflection of a person’s ability. They don’t show how crappy the code is, how much time it took to actually write it, and what effort it’s going to take to maintain that code base, all without intricate examination. Most of the interviewers don’t have enough time to examine the code base, or even bother to go through them. Many people don’t even feel shame in stealing others’ people code, and showing them as their own. Also whatever the interviewer asks about the project, it has been already crammed in heart and soul. And, some even tell other’s contribution in the project as their own!

Then what is left is to test the person’s IQ and computer science fundamentals. But, that too depends on the type of job. If the job is of a frontend engineer in a web development company, then there is not much point in asking a dynamic programming problem in the interview. The interviewer should directly look for the chops it takes to create an awesome frontend and user interface. Similarly, if the job is of a system programmer, then the interviewee should expect questions related to operating systems, libraries and UNIX programming and not to tell time complexity of a sorting algorithm. However, if a fresh undergraduate is being interviewed, in most of the cases, there is no substantial knowledge in a particular field. But many of them have what it takes to create wonderful products, if given proper initial orientation and guidance in a company. So, it again comes to testing their IQ and computer science fundamentals, as there is no other option left.

Interviewing is not an exact science. And, the factor that affects most is the worldly view of the interviewer. Whether he chooses to ask about github projects or yet another reverse-this-list question, it all depends on him. There is also a very high possibility that he may be worst at interviewing, but writes solid production code which gives tears of joy! So it should not be directly assumed that if the interviewing process is bad, the interviewer, and his code, and his team and his company are all bad. There is always a chance of that, but there is no correlation between them. I have seen some shitty companies pretty good at interviewing, and some good companies very shitty at interviewing! Then, whose fault is this ? The fault is of the ‘good’ company which is not teaching it’s employees how to take ‘good’ interviews. The fault is of the interfacing of HR between the interviewer and of the interviewee, who are unaware of the crappy system and are unwilling to change the so called ‘best practices’. I can only hope that in future there is equal emphasis on interviewing process in good companies, as is on the products they build.

Many amazing, wonderful, and big companies die, and they die because they hired unproductive employees when their interviewing process deteriorated more and more as time progressed. I hope this will all change someday.

P.S. This post was originally written on Feb 22, 2012 atwww.mycareerstack.com/blog/19/interviewing-is-broken .