5 ms·

Study material for tech interviews

109 points by rttlesnke 13y ago

luu 13y ago
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.
- hkmurakami 13y ago
  can't forget those basic string manipulation questions too! :)
- deleted 13y ago
  [deleted]
- noloqy 13y ago
  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 13y ago
    Then maybe they should stop asking algorithm questions that can be answered by cramming for a week or a Google search.
- zura 13y ago
  May I ask you in which company you've been asked about implementing coroutines in C?
- feralmoan 13y ago
  > "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
akanet 13y ago
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: https://coderpad.io https://coderpad.io It also works for administering the interview!
jiggy2011 13y ago
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)?
- spullara 13y ago
  Generally the candidate picks their best language. Personally, I would never pick C because there is too much minutiae and not enough meat.
  - georgemcbay 13y ago
    "I would never pick C because there is too much minutiae and not enough meat" There's really not much minutiae at all when it comes to C. C++, sure, I'd agree, but not C. You do have to be be pretty comfortable with how processors and memory work if you're going to be answering questions in C, but that aside the language's syntax, keyword usage and standard library are all quite small.
    - spullara 13y ago
      You spend half the time allocating memory, deallocating memory and checking error return values. I gave a couple hundred interviews at twitter, people that picked C wasted a ton of time not solving the problem.
- theorique 13y ago
  A lot of higher level languages abstract away the fundamental implementation details and provide a lot more scaffolding than C. So something that might be a couple of lines of Python or Ruby (just remember the library and the method calls), could wind up being a more interesting problem in C.
- coolsunglasses 13y ago
  Easier to write your own answer once you've seen how the C works in a higher level language than to go in the other direction, assuming you need this material to begin with.
privacybuff 13y ago
I think I've become jaded in my old age, but I find questions like this to be a negative indicator of the nature of the company. I once interviewed at Apple for the quicktime team and they asked me a question about how you could make video start playing quickly, instead of waiting for it to download (this was before youtube so it was a reasonable problem to try to solve.) A directly relevant question to the technologies they were working with, and something applicable on the job. I wish I'd come up with HTTP Live Streaming on the spot (a tech they announced years later) which seems so obvious now. When I interview people, I like to ask them business questions (eg: how they might solve a particular business problem with technology) and then from there you can drill down into the issues that it might bring up (technical issues). Interviewing these days seems to be a lot of trick questions and trivia that tells the interviewer more about how similar you are than how competent you are. For instance, I was once asked what a particular keyboard shortcut did. I didn't know because I used the mouse for that function, but I am certain the interviewer assumed I didn't use the IDE much because I didn't know that particular shortcut. He was projecting his preferred method of working onto me, and then reaching the wrong conclusion from it. Every startup wants to "hire the best!" but so often they don't seem to understand what "the best" is. And worse, when you've got a ... marginal person conducting the interview they may pass on candidates who are stronger than them simply because they don't understand what the candidate is describing, or are intimidated. (of course they won't admit this.)
mempko 13y ago
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". Remember folks, these companies are getting more from you then you are from them.
- brianto2010 13y ago
  > Just making sure I won't be working with idiots. I think the the interviewer (or company) would probably take this as an insult. But I do agree with you in that these types of interview questions are pointless. Spitting back an answer verbatim demonstrates nothing. A neat approach that I've seen people use is to take a you-should-know-this concept such as the merging part of merge sort and put a twist in it, so it isn't a simple spit-the-answer-back, but different enough to require some thought.
  - mempko 13y ago
    "probably take this as an insult." Yet isn't it surprising perspective employees don't feel the same? Or maybe we do but we suck it up to get the job.

109 points by rttlesnke 13y ago

luu 13y ago

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.

hkmurakami 13y ago
can't forget those basic string manipulation questions too! :)
deleted 13y ago
[deleted]
noloqy 13y ago
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 13y ago
  Then maybe they should stop asking algorithm questions that can be answered by cramming for a week or a Google search.
zura 13y ago
May I ask you in which company you've been asked about implementing coroutines in C?
feralmoan 13y ago
> "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

akanet 13y ago

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: https://coderpad.io https://coderpad.io It also works for administering the interview!

jiggy2011 13y ago

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)?

spullara 13y ago
Generally the candidate picks their best language. Personally, I would never pick C because there is too much minutiae and not enough meat.
- georgemcbay 13y ago
  "I would never pick C because there is too much minutiae and not enough meat" There's really not much minutiae at all when it comes to C. C++, sure, I'd agree, but not C. You do have to be be pretty comfortable with how processors and memory work if you're going to be answering questions in C, but that aside the language's syntax, keyword usage and standard library are all quite small.
  - spullara 13y ago
    You spend half the time allocating memory, deallocating memory and checking error return values. I gave a couple hundred interviews at twitter, people that picked C wasted a ton of time not solving the problem.
theorique 13y ago
A lot of higher level languages abstract away the fundamental implementation details and provide a lot more scaffolding than C. So something that might be a couple of lines of Python or Ruby (just remember the library and the method calls), could wind up being a more interesting problem in C.
coolsunglasses 13y ago
Easier to write your own answer once you've seen how the C works in a higher level language than to go in the other direction, assuming you need this material to begin with.

privacybuff 13y ago

I think I've become jaded in my old age, but I find questions like this to be a negative indicator of the nature of the company. I once interviewed at Apple for the quicktime team and they asked me a question about how you could make video start playing quickly, instead of waiting for it to download (this was before youtube so it was a reasonable problem to try to solve.) A directly relevant question to the technologies they were working with, and something applicable on the job. I wish I'd come up with HTTP Live Streaming on the spot (a tech they announced years later) which seems so obvious now. When I interview people, I like to ask them business questions (eg: how they might solve a particular business problem with technology) and then from there you can drill down into the issues that it might bring up (technical issues). Interviewing these days seems to be a lot of trick questions and trivia that tells the interviewer more about how similar you are than how competent you are. For instance, I was once asked what a particular keyboard shortcut did. I didn't know because I used the mouse for that function, but I am certain the interviewer assumed I didn't use the IDE much because I didn't know that particular shortcut. He was projecting his preferred method of working onto me, and then reaching the wrong conclusion from it. Every startup wants to "hire the best!" but so often they don't seem to understand what "the best" is. And worse, when you've got a ... marginal person conducting the interview they may pass on candidates who are stronger than them simply because they don't understand what the candidate is describing, or are intimidated. (of course they won't admit this.)

mempko 13y ago

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". Remember folks, these companies are getting more from you then you are from them.

brianto2010 13y ago
> Just making sure I won't be working with idiots. I think the the interviewer (or company) would probably take this as an insult. But I do agree with you in that these types of interview questions are pointless. Spitting back an answer verbatim demonstrates nothing. A neat approach that I've seen people use is to take a you-should-know-this concept such as the merging part of merge sort and put a twist in it, so it isn't a simple spit-the-answer-back, but different enough to require some thought.
- mempko 13y ago
  "probably take this as an insult." Yet isn't it surprising perspective employees don't feel the same? Or maybe we do but we suck it up to get the job.