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.
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.
> "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
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.
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.
"I see it says here you're an [particular platform] programmer? Ok, have you ever worked with [particular SDK]? Oh, you have, ok what are the parameters to [arbitrary method in said SDK with over 6 parameters]"
This is an actual question I got. I don't consider it weeding out people to keep them honest. I had worked with that SDK, I might have even used that particular API (though it was not a common one in the area I was working with that SDK).
Here's the error I think. These problems do not ask the candidate to demonstrate their problem solving capability. They ask the candidate for a solution, and they are often presented in such a way as to imply that's all the interviewer wants to hear: He expects you to just rattle off a solution.
I don't think "seeing how the candidate thinks about problems" is very useful. Either someone can reason about the problem, or they can't. When you ask them a trick question like this ("find loops in a linked list" was one I used back before I learned how to interview people) they either can solve it fairly easily or they can't.
If they are constantly stuck, you have no information about their programming ability.
I think that's the error. People think that "getting stuck" means they are poor at problem solving. (and rarely, possibly never, has an interviewer asked me questions relevant to understanding how I solve problems.)
The pressure of an interview session, combined with the fact that most interviewers are not really all that competent at problem solving in the first place (about %50 of the time they ask the problem wrong and then have to change it while I'm solving what they actually asked, or what they asked is nonsensical) means that you get a lot of false negatives.
I'm self employed now so I write software all day long. I am constantly solving my own problems. I've been doing this for decades. Still you put me in an interview and ask me to sort a linked list, and I'll be spending %50 of my energy trying to get over the fact that the interviewer seems to expect me to just blurt out an answer. (even though I know they want to see me solve the problem).
If you get an interviewer who is using you as material to feel smug, I take that as a solid sign that the company is not a good one to work for.
I've had a long enough career that I can draw some conclusions about my work experiences. The trick questions designed to be extremely difficult to answer correctly under pressure are negatively correlated with a good working environment.
One of the best, most challenging jobs I had, and with the best set of engineers is one where I got interviewed by the president of the (small) company, he asked me no technical questions and told me I had the job at the end of the interview (I guess you can be fast when you're the president). I don't mean to say he didn't ask me about programming, he did, he asked me quite a lot about it, but no "how do you solve this problem" or "write code that does this" type questions. More, "how do you feel about language X and why?" type stuff.
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
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)?
"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.
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.
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.
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.
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.)
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.
> 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.
22 comments
[ 9.5 ms ] story [ 42.2 ms ] thread80% 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.
Interviewing is a social event at least much as it is a technical one.
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
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.
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.
This is an actual question I got. I don't consider it weeding out people to keep them honest. I had worked with that SDK, I might have even used that particular API (though it was not a common one in the area I was working with that SDK).
Here's the error I think. These problems do not ask the candidate to demonstrate their problem solving capability. They ask the candidate for a solution, and they are often presented in such a way as to imply that's all the interviewer wants to hear: He expects you to just rattle off a solution.
I don't think "seeing how the candidate thinks about problems" is very useful. Either someone can reason about the problem, or they can't. When you ask them a trick question like this ("find loops in a linked list" was one I used back before I learned how to interview people) they either can solve it fairly easily or they can't.
If they are constantly stuck, you have no information about their programming ability.
I think that's the error. People think that "getting stuck" means they are poor at problem solving. (and rarely, possibly never, has an interviewer asked me questions relevant to understanding how I solve problems.)
The pressure of an interview session, combined with the fact that most interviewers are not really all that competent at problem solving in the first place (about %50 of the time they ask the problem wrong and then have to change it while I'm solving what they actually asked, or what they asked is nonsensical) means that you get a lot of false negatives.
I'm self employed now so I write software all day long. I am constantly solving my own problems. I've been doing this for decades. Still you put me in an interview and ask me to sort a linked list, and I'll be spending %50 of my energy trying to get over the fact that the interviewer seems to expect me to just blurt out an answer. (even though I know they want to see me solve the problem).
I've had a long enough career that I can draw some conclusions about my work experiences. The trick questions designed to be extremely difficult to answer correctly under pressure are negatively correlated with a good working environment.
One of the best, most challenging jobs I had, and with the best set of engineers is one where I got interviewed by the president of the (small) company, he asked me no technical questions and told me I had the job at the end of the interview (I guess you can be fast when you're the president). I don't mean to say he didn't ask me about programming, he did, he asked me quite a lot about it, but no "how do you solve this problem" or "write code that does this" type questions. More, "how do you feel about language X and why?" type stuff.
It also works for administering the interview!
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.
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.
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.)
Remember folks, these companies are getting more from you then you are from them.
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.
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.