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?"
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.
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."
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.
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?
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?
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.
Comments
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.
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.
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.
Aaand lots of people look forward to those questions -- because they're not bad at programming and the questions are fun.
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.
Here's a good cheat sheet of answers to memorize.
http://www.gowrikumar.com/interview/index.html
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."
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.
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?
It is a bit much. Good managers can be crappy interviewers (and vice-versa). I would take it into account when considering my options, though.
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?
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.
I disagree, a lot of these interview coding sessions border on hazing these days.