[luu]

I recently did a batch of interviews at a handful of companies. The advice I got from the best programmers I know was that you shouldn't bother preparing for interviews, other than, perhaps, spending a few hours skimming an algorithms textbook to make sure that stuff is fresh. I wasn't sure about that advice at the time. In retrospect, I agree [1].

80% of the coding questions I got were really simple; things you'd expect any college kid who'd been through a basic CS curriculum to be able to answer cold. Not having just taken an algorithms class, stuff like that took a bit of thought. 20% were things like "implement coroutines in C using setjmp and longjmp" or "implement a regular expression matcher". How can you cram for that? Sure, you can cram for any specific question, but, given the breadth of the question space, your only hope is to understand things well and be able to reason out whatever comes up.

As far as I could tell, being better prepared was negatively correlated with getting an offer. I did well in interviews where I was totally clueless and had to reason things out from first principles. Conversely, I had an interview at Palantir where I heard the question I was being asked, so I said that. My interviewer asked me to quickly sketch the answer. When I did, he asked me another question. After repeating that process a few times he gave up and asked me a simple design question. Apparently, I failed that interview so badly that I got kicked out before lunch (interviews there are normally all day). In general, having heard the question before (and telling my interviewer), or having a flash of insight and being able to write down the answer without thinking about it seem to be taken as negative signals.

I was surprised by that until talking to a friend of mine who said "the interview process is this largely protocol driven song and dance where you're supposed to scratch your head and be wowed by the technical question and then slowly and painfully make incremental progress on a solution while the interviewer can feel smug about knowing it all along and maybe they can help you along the way. If you blurt out a good approximation in the first thirty seconds, that ruins the whole courtship." That's not true everywhere, but it seems to be true at most places.

There are, of course, non-coding questions. Those seem even less useful to cram for. You might be able to impress someone if you happen to know a lg(lg(n)) data structure you can use instead of a red-black tree, but most non-algorithms questions are about thinking on your feet; just having lots of knowledge won't help you there.

[1] This assumes that you have a solid background in CS fundamentals. If not, interview prep has a very high payoff.

[droopyEyelids]

Another way of looking at this:

When I'm interviewing someone, I want to get a sense of how they work through a problem and think about things. That sounds difficult right? It is, and your cooperation is appreciated. By saying you heard everything you gave the interviewer nothing. I guess you expected him to be a perfect authority figure and have an infinite vault of questions to throw at you.

Next time, try walking through one of the problems, explaining all the parts you find interesting, and bullshitting about what context it would be useful in. Try to relate to the problem and the interviewing process, and how it might fit in the job. You can be honest and joke about it if it doesn't fit. Remember, this isn't school and your interviewer is a coworker, not a professor with a hundred tests to grade.

Try and figure out how much he knows about the problem he just asked you.. and I bet 80% of the time the interview will go well if you show them something they're missing, or take them to the limits of their knowledge and show them something new or creative. People's egos tend to get in the way when you assume they will. Assume the best about 'em. Remember, the interviewer isn't a faceless part of The Machine out to dismiss you, but a potential coworker and friend that'll probably be happy learning something new with someone who can broaden their horizons.

[jlarocco]

This has been my strategy for a while, and it's always worked for me. I never study for interviews, and I can usually find jobs.

In my experience, technical questions typically fall into two categories. The first is trivia about a programming language or other tool. The only people who need to "cram" for these are people who lied on their resume. Everybody else will answer these questions pretty easily just from working with the tools and having hands on experience. These are weed out questions to keep people honest.

The second category is to see how the candidate thinks about problems and solving them. It's not helpful to "cram" for these because the problem space is too large, and it would defeat the point anyway. If a company wanted people who've memorized "Coding Interviews For Dummies," they would just put that in the job requirements. In reality, the job they're hiring for doesn't have cookie cutter problems and solutions, and they want to see how the interviewee will work through a problem to find a solution. Knowing the answer to these in advance can actually hurt because it doesn't show them what they're looking for.

[feralmoan]

> "the interview process is this largely protocol driven song and dance where you're supposed to scratch your head and be wowed by the technical question and then slowly and painfully make incremental progress on a solution while the interviewer can feel smug about knowing it all along and maybe they can help you along the way. If you blurt out a good approximation in the first thirty seconds, that ruins the whole courtship."

Your friend is exactly right, and there's plenty of competitive companies out there not demanding you physically take up a whiteboard marker to cock-swing out some algorithm in a political kowtow ritual. Asking for an answer or illustration of deductive process to a non-trivial question is a good litmus test of both talent AND enthusiasm/presence and provides entry points for deeper technical discussion but relying on a '2 line perl implementation of log(log^n-dimension) reimann curvature' as a source of truth rather than understanding the person you're humiliating and how they can augment your team if the Ruby Beard of Magic approves is absolutely absurd. Unless you don't care about the people or culture you're creating and just want the work done of course, because money money or whatever :D

[noloqy]

I agree. It seems better to spend your time investigating the company and to try to obtain information about the interviewers with the purpose to discover some common ground, rather than to learn dozens of algorithms by heart, just to forget the a month later.

Interviewing is a social event at least much as it is a technical one.

[aaronbrethorst]

Then maybe they should stop asking algorithm questions that can be answered by cramming for a week or a Google search.

[zura]

May I ask you in which company you've been asked about implementing coroutines in C?

[hkmurakami]

can't forget those basic string manipulation questions too! :)