5 ms·

A Strategy For The Dreaded Interview Coding Question

39 points by tysont 14y ago

Shoomz 14y ago
I like the framework you layout. It's always good to have a method for walking through problems because it conveys a cogent thought process (reminds me of SAT multiple choice problems or Spelling Bee questions about word origins).
msluyter 14y ago
Yes. Having been on both sides of the process a lot recently, I'd agree that restating / asking questions / talking through the problem as you do it is helpful. But beyond that, I think that simply practicing typical whiteboard questions is the best preparation. You can find a lot of these simply by googling, or, by looking at a typical CS algorithms or data structures textbook. Re-familiarize yourself with lists, trees, etc... and basic searching/sorting algorithms. Steve Yegge offers similar advice here: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
- tysont 14y ago
  Love the Yegge posts on interviewing, and I completely agree. There are all kinds of things on the technical side that would be interviewers should brush up on, I'm just preaching having a strategy to run thru when actually answering the question instead of haphazardly diving into code.
- cdr 14y ago
  Yegge's post is a classic but getting a bit old. I highly recommend "Cracking the Coding Inteview" [http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/1466208686 http://www.amazon.com/Cracking-Coding-Interview-Programming-...] for serious prepping. Edit: It looks like the author of the above has a newer book out called "The Google Resume", probably worth taking a look at too.
gwillen 14y ago
I don't know about you, but I don't dread interview coding questions at all -- I love them. What I dread are the squishy / soft questions. "Where do you see your career going in 5 years?" "What do you want to get out of this job?" "What is your greatest weakness?" Coding I can handle.
- asparagui 14y ago
  Here's a good cheat sheet of answers to memorize. http://www.gowrikumar.com/interview/index.html http://www.gowrikumar.com/interview/index.html
  - jmillikin 14y ago
    Rather than memorizing the answers to bad questions, technical interviewers should memorize the questions themselves. Then if any of those show up in an interview, walk out -- one doesn't want to work at those sorts of companies.
    - jmduke 14y ago
      This is an admiral ideal but when you have $50K in student debt, abandoning a potential job because you didn't like the HR screener is not the best idea.
    - Retric 14y ago
      As an interviewer I often ask questions not because I care what the answers are, but rather to change the tone of the conversation. There is little point in grilling people for an hour vs mixing in a few probing questions and keeping the interview light. AKA, I see you got a CS degree and 5 years of development experience. Looking back what do you think your most (useful, fun, memorable) class was? What's language that you don't know are you most interested in learning / using?
    - cdr 14y ago
      That's a bit much - it's rare that a company doesn't have something broken about its hiring process, even good/great companies. If you want to work there otherwise, what does it hurt to learn the expected answer for fluff questions and recite it when asked?
jimmyhwang 14y ago
This framework is very similar to case interview questions management consultants use during their interviews. The bit about repeating the question not only buys you some time to think about the problem some more, but also allows you to confirm your assumptions (as the write notes). As another comment pointed out, the best way to become better at this process is to practice. I know when I was preparing for my consulting interviews, I practiced the framework with a friend for weeks at a fast food joint so that I had the process down. Once you can perform the process instinctively, you can focus your brain cells on actually solving the problem.
Kroem3r 14y ago
I think the world could have done without this post. The reason being that while the interview question might be anywhere in 2hr-solution space, the answer is always: Make sure you understand the problem, the edge cases and present a viable structure for a solution. Now we're going to have to find a new question.
- wtracy 14y ago
  "present a viable structure for a solution" is easier said than done. This post elaborated a bit on that point and offered some suggestions that I found useful.
  - Kroem3r 14y ago
    I think you missed my point, and that's ok. Maybe also the OP. Well, and also that I was being a little tongue-in-cheek.
deleted 14y ago
[deleted]
- bethling 14y ago
  Wow... that's the exact opposite of what I like to see. I want to see a thought process -- not someone throwing together code to get something there. When I've seen people like that get hired dealing with their code long term is painful. You tend to get "mostly working" code with a bunch of band-aids. For an entry level position, getting an answer is important, but for more experience developers knowing how to figure out what actually is important (in my experience) is a better indicator (and yes, they actually need to be able to code). Experiences vary though :)
- EricDeb 14y ago
  Full dev computer with internet access I approve of, whiteboard coding I don't.

39 points by tysont 14y ago

I like the framework you layout. It's always good to have a method for walking through problems because it conveys a cogent thought process (reminds me of SAT multiple choice problems or Spelling Bee questions about word origins).

msluyter 14y ago

Yes. Having been on both sides of the process a lot recently, I'd agree that restating / asking questions / talking through the problem as you do it is helpful. But beyond that, I think that simply practicing typical whiteboard questions is the best preparation. You can find a lot of these simply by googling, or, by looking at a typical CS algorithms or data structures textbook. Re-familiarize yourself with lists, trees, etc... and basic searching/sorting algorithms. Steve Yegge offers similar advice here: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

tysont 14y ago
Love the Yegge posts on interviewing, and I completely agree. There are all kinds of things on the technical side that would be interviewers should brush up on, I'm just preaching having a strategy to run thru when actually answering the question instead of haphazardly diving into code.
cdr 14y ago
Yegge's post is a classic but getting a bit old. I highly recommend "Cracking the Coding Inteview" [http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/1466208686 http://www.amazon.com/Cracking-Coding-Interview-Programming-...] for serious prepping. Edit: It looks like the author of the above has a newer book out called "The Google Resume", probably worth taking a look at too.

gwillen 14y ago

I don't know about you, but I don't dread interview coding questions at all -- I love them. What I dread are the squishy / soft questions. "Where do you see your career going in 5 years?" "What do you want to get out of this job?" "What is your greatest weakness?" Coding I can handle.

asparagui 14y ago
Here's a good cheat sheet of answers to memorize. http://www.gowrikumar.com/interview/index.html http://www.gowrikumar.com/interview/index.html
- jmillikin 14y ago
  Rather than memorizing the answers to bad questions, technical interviewers should memorize the questions themselves. Then if any of those show up in an interview, walk out -- one doesn't want to work at those sorts of companies.
  - jmduke 14y ago
    This is an admiral ideal but when you have $50K in student debt, abandoning a potential job because you didn't like the HR screener is not the best idea.
  - Retric 14y ago
    As an interviewer I often ask questions not because I care what the answers are, but rather to change the tone of the conversation. There is little point in grilling people for an hour vs mixing in a few probing questions and keeping the interview light. AKA, I see you got a CS degree and 5 years of development experience. Looking back what do you think your most (useful, fun, memorable) class was? What's language that you don't know are you most interested in learning / using?
  - cdr 14y ago
    That's a bit much - it's rare that a company doesn't have something broken about its hiring process, even good/great companies. If you want to work there otherwise, what does it hurt to learn the expected answer for fluff questions and recite it when asked?

jimmyhwang 14y ago

This framework is very similar to case interview questions management consultants use during their interviews. The bit about repeating the question not only buys you some time to think about the problem some more, but also allows you to confirm your assumptions (as the write notes). As another comment pointed out, the best way to become better at this process is to practice. I know when I was preparing for my consulting interviews, I practiced the framework with a friend for weeks at a fast food joint so that I had the process down. Once you can perform the process instinctively, you can focus your brain cells on actually solving the problem.

Kroem3r 14y ago

I think the world could have done without this post. The reason being that while the interview question might be anywhere in 2hr-solution space, the answer is always: Make sure you understand the problem, the edge cases and present a viable structure for a solution. Now we're going to have to find a new question.

wtracy 14y ago
"present a viable structure for a solution" is easier said than done. This post elaborated a bit on that point and offered some suggestions that I found useful.
- Kroem3r 14y ago
  I think you missed my point, and that's ok. Maybe also the OP. Well, and also that I was being a little tongue-in-cheek.

deleted 14y ago

[deleted]

bethling 14y ago
Wow... that's the exact opposite of what I like to see. I want to see a thought process -- not someone throwing together code to get something there. When I've seen people like that get hired dealing with their code long term is painful. You tend to get "mostly working" code with a bunch of band-aids. For an entry level position, getting an answer is important, but for more experience developers knowing how to figure out what actually is important (in my experience) is a better indicator (and yes, they actually need to be able to code). Experiences vary though :)
EricDeb 14y ago
Full dev computer with internet access I approve of, whiteboard coding I don't.