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).
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-goog...
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.
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?"
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.
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.
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?
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?
I like this one: Where do you see yourself five years from now?
The problem is that my answer is always something involving writing code and solving problems. I have no desire to be a manager of any kind - companies don't like people who aren't interested in moving on to management.
If someone can devise a job where they slide a problem description with some guidelines under the door, I'd be perfectly happy.
There are a lot of companies that see the value in someone who loves writing code and solving problems. If I asked that question (which I wouldn't, I hate it) I would be happy to hear the following as an answer:
"I love coding, so I hope that whatever I'm doing in five years, I'll still have my hands dirty solving real problems. I also love learning and sharing my knowledge with others. While I'm not interested in being a technical manager, I would like to be a technical leader."
It isn't coding, in the sense of actual real world production coding, that the AOTOA[1] appears to be dreading.
But rather being buttonholed in the hopelessly awkward and incredibly claustrophobic "code this completely contrived (and like as not[2], poorly articulated and presented) search problem that I got from some blogpost somewhere, and which BTW bears virtually no resemblance to the day-to-day gruntwork you'll actually be asked to do here, RIGHT NOW, bitch!" routine -- that passes for a filtering process in far too many companies, these days.
[2] in my experience, about 33% of the time the "top" in the interviewing process either bungles some important detail, or makes some other kind of brain fart in stating the problem that makes it take far longer -- and in some rather embarrassing cases, outright impossible -- for the "bottom" to solve.
I actually agree with you, if done well I think that coding questions are fun too. At the same time, I also happen to know a lot of very strong developers who hate them. I think the reasons vary, but some are called out in the article (lack of a familiar environment/IDE, the contrived nature of questions). The answer to a coding question is also impossible to "fake", at the end of the day you get it or you don't (whereas some situational/behavior questions have more of a fudge factor).
Whether you hate 'em or love 'em, the main point of the post is to advocate approaching coding questions with a strategy that you've practiced and can repeat over and over again.
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.
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.
"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.
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).
24 comments
[ 3.4 ms ] story [ 75.0 ms ] threadEdit: It looks like the author of the above has a newer book out called "The Google Resume", probably worth taking a look at too.
Coding I can handle.
http://www.gowrikumar.com/interview/index.html
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?
The problem is that my answer is always something involving writing code and solving problems. I have no desire to be a manager of any kind - companies don't like people who aren't interested in moving on to management.
If someone can devise a job where they slide a problem description with some guidelines under the door, I'd be perfectly happy.
"I love coding, so I hope that whatever I'm doing in five years, I'll still have my hands dirty solving real problems. I also love learning and sharing my knowledge with others. While I'm not interested in being a technical manager, I would like to be a technical leader."
But rather being buttonholed in the hopelessly awkward and incredibly claustrophobic "code this completely contrived (and like as not[2], poorly articulated and presented) search problem that I got from some blogpost somewhere, and which BTW bears virtually no resemblance to the day-to-day gruntwork you'll actually be asked to do here, RIGHT NOW, bitch!" routine -- that passes for a filtering process in far too many companies, these days.
See also:
https://en.wikipedia.org/wiki/Stanford_prison_experiment
[1] AOTOA = author of the original article
[2] in my experience, about 33% of the time the "top" in the interviewing process either bungles some important detail, or makes some other kind of brain fart in stating the problem that makes it take far longer -- and in some rather embarrassing cases, outright impossible -- for the "bottom" to solve.
Whether you hate 'em or love 'em, the main point of the post is to advocate approaching coding questions with a strategy that you've practiced and can repeat over and over again.
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.
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 :)