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].<p>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.<p>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.<p>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.<p>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.<p>[1] This assumes that you have a solid background in CS fundamentals. If not, interview prep has a very high payoff.
How about we collectively protest these kinds of interview questions. I vote that instead of answering questions, we ask difficult ones to our interviewers. When they protest, we explain "Just making sure I won't be working with idiots".<p>Remember folks, these companies are getting more from you then you are from them.
And if you want to see if you could literally, truly derive a working solution to any of these puzzles in a realtime interview environment, I make a tool for that: <a href="https://coderpad.io" rel="nofollow">https://coderpad.io</a><p>It also works for administering the interview!
All of these examples are in C , is it common for interviews to be conducted in C for major tech companies (assuming the job is not a C programming role)?