How to Crack the Toughest Coding Interviews

“Describe how you would implement the tinyurl.com website.” preferably without realising you have the technical skills to do far better on your own than wage-slaving yourself for us.

Actually, it was invite-only when I was there. But that's sort of besides the point. It's irrelevant whether or not it's an "honor" to be on the hiring committee. The point is that being on the hiring committee does give you some insight as to why people tend to get rejected. Without being on the hiring committee, you really only see why you're rejecting people -- smaller sample size, biased, less diversity of questions, etc. But, for hiring committee members, you see the results of many people's interviews.

I've interviewed a lot of people (at Microsoft). I don't claim to be good at it, I think that I do OK, but that's why one interviewers opinion should never be the be all.

I've definitely encountered people who were clearly good, and equally clearly sucked at interviewing, as an interviewer I had to ask myself the question "why?"

I encountered the following cases (among others)...

The ill-prepared - This may come down to background, some candidates didn't seem to know that they should prepare for an interview - this can be excusable, but in a world where advice about this is one web-search away is increasingly tough. Usually (but not always) this is a barrier to recommending hire.

The chronically nervous - This is always at least 50% my fault. I believe in asymmetric responsibility, as the person with more "power" in the situation, I feel part of my job is to help a candidate past their nerves; if this means my interview is entirely spent putting them at their ease to (potentially) do better with the next person in line, so be it. This has rarely been a barrier to recommending a hire.

The arrogant - "I can't believe you asked me such a demeaning coding question when I'm applying for a senior role, clearly my resume tells you all you need to know about my coding chops" - sorry, if I can't pierce this, no hire.

The inarticulate - often in this case the code speaks, even if the candidate can't, I usually associate this with nerves, sometimes it is language issues, sometimes stress sensitive speech impediments. I'm pretty sympathetic to this if the code speaks, but communication is part of the role so this is always a judgement call.

Can't code on a whiteboard - I'm inclined to call this ill-prepared, you should expect to have to do this coming into the interview, but I do get that this is equivalent and opposite from "inarticulate" - I will take a coherent and detailed description of a solution as being nearly as good as the whiteboard code, but there is a bottom line, you have to be able to show me your ability - sometimes one really insightful question or observation is all that it takes...

I got that book. While the questions and answers are useful, in my experience this book alone is nowhere near enough to get prepared for a Google interview (not that the author claims that).

I studied CLRS's Introduction to Algorithms and a couple of other books for about 2 months. Even then I could not answer the hardest questions during the onsite interview. And if you cannot come up with an optimal algorithm for a given problem, all of the items mentioned in the article (communication, clear coding, testing) don't really matter.

Now ticketing, that reminds me of the ITIL standards and reamedy fun (slang for nightmares). If a company has ITIL I always ask them what proactive support measures do you have in place, always a good question that as ITIL is in essence more reactionary/event driven and as such does not lend itself well by design for catering for proactivity. I was in a server room once, smelt burned solder type smell, traced to a server that smelt like something had blown. All services/diagnostics/monitoring checked out fine and indeed it was working fine. I wanted to plan a changing of the server/have a hot standby ready for it being proactive as literly something smelt wrong. Alas the ticketing system did not alow such a ticket to be rasied as the server was not faulty and there was no issue showing. Two days later that very server failed, turned out PSU had died and taken out the raid controller on the motherboard in the process. The impact of this was more work than had it not been proactivly addressed. That is why when they say ITIL, then I fear how it is implemented and as such ask how do they proactivly deal issues. At the very least they should have root cause analysis mentioned, idealy they will sing all about there great Q&A processes and how that is all catered though open to suggestions.

Your right about the canned marketing responses, most of those forget the interview is a two-way process sadly and deem any question you ask as a waste of there time, that is a sign you should take note of.