The Terrible Technical Interview

For what it's worth, I think these are great interview questions. You can quickly pick up how much experience a candidate has in a particular area by how in-depth their thoughts on the topic are. Asking a candidate to compare two languages, data structures or technologies in general usually yields good results too.

I think what some of the replies to your post are forgetting is there are no right or wrong answers to these questions. The questions are about gauging the experience of the candidate so you can make an appropriate offer if you wanted to hire them. It's probably not a huge deal if you couldn't describe MVC but you gave an in-depth answer to the OOP question for example. It is a problem however if several questions reveal there are major holes in your knowledge and experience though.

Maybe we should just offer a choice of what kind of interview candidates want.

The problem is that programming skill is not normally distributed. There are some big outliers at the brilliant end, and some big outliers at the toxic end.

So "average" is not really a meaningful term. I mean "average programmer" as "can be trusted with routine tasks".

Behind every successful startup, there was one 10x or 100x outlier who did the hard work, even if he was not the person who got public credit for the startup's success.

If you're at a large corporation and trying to minimize risk, hiring a large number of average people is the most stable path. You'll get something that sort of mostly works. If you're at a startup and trying to succeed, you need that 10x or 100x person.

To me, that sounds like a convincing argument that your specialty is not worth learning. I'd rather work someplace that wants to invest in their employees, rather than expecting them to already be experts in some obscure techniques.

Are you hiring people who are brilliant, or people who are so desperate that they'll spend a couple months preparing for one interview?

The guy who wrote this is not even a real professional software developer[1] but it seems that he has strong opinions on technical interviews anyway. In fact I looked up few people he mentioned in article and none of them seem to be real full time software developers either. Nevertheless whoever has microphone gets to get heard, I guess.

I have seen a lot of PMish/weak programmers make cries about technical interviews. Yes, whiteboarding interviews are not perfect and false negatives rate is typically high but the companies who want nothing but the best would care less about false negatives and rather more about false positives. Anyone who has worked long enough in software engineering professionally knows the enormous cost of false positives [2]. These sort of companies also typically care less about which language and frameworks candidate knows at the moment. They rather put huge weight on evidence whether a candidate can analyze a challenging problem, apply computer science and obtain a solution. Why? Because these companies are actually working on problems that does requires deep hard computer science.

Most - perhaps 80% - of software development houses are not like that. Programmers in those companies have never bothered to think about collisions in hash tables and they often wonder why anyone would care when libraries take care of everything. They never need to create data structure for trees or graph or even linked lists because simple things have always got job done. They wonder why they are being asked questions on those "arcane" things when nobody really uses computer science stuff that they were taught at school.

That's the culture problem. Those 80% of companies tend to copy interview process at other 20% even though it is meaningless for what they do. Interviewers typically chose their questions from algorithms text books or even internet searches. Then they get stuck on it for a decade and proudly mention it as their "favorite question". That's completely wrong. I almost always tend to ask CS questions that I myself needed to solve to get my job done. I typically retire my questions in month because I probably would have found another problem where applying right algorithms and data structures was the key. When I ask these questions to candidates, (1) it's rare chance that it would have been covered in books like Cracking the Coding Interview (2) no risk because candidate decides to do interview brain dump (3) I know candidate is smarter than me if s/he can solve within hour under pressure (4) If they fail miserably I know this guy could have screwed up our project just last month had he been hired.

Bottom line: Ask questions from your actual day job. It takes a lot of skill and effort to abstract away other complexity and form a good interview questions and that's why being an interviewer is hard. Whiteboarding works if you do that. It doesn't work if you are trying to copy companies which are doing different kind of work than you do. It most certainly doesn't work if you never actually needed to solve the problem you are asking to get your actual job done.

1. http://rezendi.com/aboutauthor.htm

2. http://www.joelonsoftware.com/items/2007/06/05.html