6 ms·

Dear software professional: if you have been rejected because of a coding interview, don't feel bad or discouraged. It has little to do with how smart you are.

Dear software professional: if you have been rejected because of a coding interview, don't feel bad or discouraged. It has little to do with how smart you are. Unfortunately, this style of interviews is likely ineffective and leads to hiring people who look alike and have similar skills. Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world. I'm sure new grads spend a lot of time in classes training for this. Many great people don't function like this and still they may come up with brilliant ideas after a day or a week. Some people have breath of knowledge and study specific topics as needed. Some people can write very well and may not be super fast in tests. I know many brilliant engineers who have been rejected and are doing just fine, building amazing products, and leading teams. If corporations really wanted a cookie cutter method to evaluate CS knowledge, then they should require a scientifically validated standardized test conducted by a third party. It would be cheaper than using engineers' time. So why don't they do that? The reality is that they think they are doing more than that but there is no scientific proof that the interview method works. They don't want false positives but they cannot measure efficacy. If you are one of the guys who know how to perform, then you can get hired faster. In some cases if you are an outsider (older, female, different), then your chances of knowing the "secret interview code" is much lower.

akanet 12y ago
"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking" is actually how problems are generally solved in most fields. Software engineering is perhaps one of the lone exceptions, and I think the pair programming movement has a bone or two to pick with your premise.
- onislandtime 12y ago
  People are very diverse, some are fast and chatty, others are quiet and slow. Usually I perceive the fast and chatty types a bit arrogant. Personality and cultural background is probably an influence. Best teams have a great mix. Often caring about the work is more important than having a genius. (Of course people should be competent).
  - mahyarm 12y ago
    I do coding interviews exclusively since I find whiteboard interviews even more artificial. I try to match the interview to a persons skill set and ask them to implement things they should know or know how to look up if their resume isn't a lie. I don't care if they talk or not while doing the interview and I take the role of a product designer who doesn't know how to code. If they get interview anxiety I give them the space they need. If they want a keyboard & mouse I would give it to them. What else can you do that would be an accurate simulation of their job that only takes 1hr?
    - onislandtime 12y ago
      I think that what you do makes sense if you take the time to read the resume, code samples, articles, and ask relevant questions. Asking to write some code is perfectly fine to see how the person works. References are also very important for more experienced candidates with a track record.
    - dreamweapon 12y ago
      What else can you do that would be an accurate simulation of their job that only takes 1hr? First 1/2 hour: Discuss their code samples in detail -- asking pertinent questions about each as to what they do, and why they did things they way they did. Drill down for detail, ask how they might have done things differently for different use cases, etc. Second 1/2 hour: Bring out some of your own production code and do the same (allowing them space to ask questions this time). Works best if you let them see something that's a bit "raw", i.e. quick and dirty, which you know you could have done a lot better if you had more time or knew better about the requirements (or perhaps you're simply older and wiser now). In both sessions, nuance (both in what they can observe, and how they chose to express themselves) is key. And it'll come out a lot more freely than in in a whiteboard interrogation precisely because they interaction will be natural, uncontrived and unforced. Simple, non-confrontational and 100% reflective of what engineering work is like. That's what we do during the day, 99% of the time -- digging up (sometimes woefully) less-than-perfect components of production systems, and trying to make them a little bit better. But as to how often we drag someone to a conference room, throw them at a smudgey whiteboard with creaky pens and no eraser, and force them to solve some abstract problems while we boredly look at our watch, and interrupt them with hints? Basically never. Except, that is, in coding interviews.
- lazerwalker 12y ago
  There's a big difference between someone looking over your shoulder and forcing you to explain what you're thinking, and someone working with you to collaboratively solve problems. In the latter case, you can ask lots of questions and throw out lots of dumb half-baked ideas, and actually get a meaningful, useful response from your partner/pair in response. If you're whiteboard interviewing, good luck getting your interviewer to meaningfully engage with you, since they don't want to "give away the answer". The best interviews I've had were legitimate pairing interviews, where the two of us were tasked with solving a problem in a real codebase that the interviewer hadn't solved before. (The best best interviews made it an issue in an open source project, so it can be a not-canned interview without you writing potentially production-ready code for a for-profit company without being paid)
  - cnp 12y ago
    THIS right here is the dream interviewing scenario and in my opinion the singularly best way to test a candidates competence, aptitude and personality. Solving problems together exercises all of these key things in harmony.
  - re_todd 12y ago
    There's also the fact that some people, like me, freeze up in these interview scenarios. I didn't get past my first interview a few weeks ago because I couldn't think straight knowing I was being judged going through this process. As soon as the interview was over and I was more relaxed, I thought of several good answers, like I normally do when employed.
robbyking 12y ago
The analogy I use is a coding interview is like asking a musician to play a specific song; chances are, a classically trained pianist won't know the chords to a specific pop song, but that isn't any indication of their skill as a musician. The interviews I had with the company I work for now were amazing; they asked me some basic questions to verify my resume wasn't completely BS, then asked me to discuss previous projects I'd worked on, asking questions about technical details on the way. ("Why did you use collection type X in stead of collection type Y?") This allowed them to learn about my real world experience without the risk of asking me about one specific type of problem I may not be familiar with.
- deleted 12y ago
  [deleted]
- smm2000 12y ago
  Better analogy is that classical musician is given sheet music to pop song and is told to play it on his favorite instrument. If he is good musician, he should be able to play it reasonably well even without practicing. There are musician who play extremely well but only after practicing one song for a long time - this type of interview sucks for them but they are minority. Most musicians suck with or without practicing so this type of interview is a good filter. Not ideal but no one came up with better one that scales up to thousands of applicants.
  - sgustard 12y ago
    Agreed; the idea of hiring a musician without hearing them play would be madness. Not handing me a recording, not discussing intricacies of music theory, but actually playing live. And yet, a talented studio musician may suffer from performance anxiety in this situation. What to do?
    - kilbasa 12y ago
      I think the best thing is to ask them to warm up with something basic like a scale, and let them work their way up as their comfort level increases. I knew some people who were particularly pleasant and easy going, so they were able to relax people suffering from performance anxiety. There are interviewers who treat coding interviews as a high pressure, adversarial exercise, though. On the other hand, those sorts of people are rarely a joy to work with.
benihana 12y ago
>forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone? These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer. But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.
- personZ 12y ago
  Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it. Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough. I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices. I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at.
leothekim 12y ago
"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world." I'm often in the position to have to explain my reasoning while developing software. Code reviews and pair-programming come to mind. It's about being able to communicate complexity and being more rigorous about the software development process. That said, this style of coding interview brings up a level of stress that I'm rarely under at work. It's an unfortunate condition of interviewing, but I don't think it's completely avoidable no matter how comfortable you make the interviewee.
justinpaulson 12y ago
The point of these type of interview questions is to see how well you can reason and communicate. It is not to see if you know how to solve that specific problem, and if an interviewer is using it like that then they are not a very good interviewer. A standardized test does not substitute for actually talking to someone while they solve a problem and seeing that they can think logically and communicate those thoughts. It is more about the communication aspect of the question, not about getting to the answer. Because communication is a lot more important in business...even tech business...than you seem to think it is.
- maroonblazer 12y ago
  Right. While I wasn't interviewing for a technical position, the interviewer asked me to 'vote off' one of the 50 U.S. states, and to describe my reasoning why (perhaps this is a common question but I hadn't encountered it before). It was basically an exercise in thinking out loud, with a lot of "well, I'd probably want to first consider x, but actually before doing that I'd want to take into account y...". There wasn't any undue pressure, since there was clearly no right answer, so it allowed me to just riff out loud on the problem, exposing to the interviewer how I approach problems. I use this same technique now when interviewing others.
  - thecage411 12y ago
    The answer is florida, right?
    - maroonblazer 12y ago
      Idaho.
eli_gottlieb 12y ago
Of course it's total bullshit. You still have to pass it. You can't demand that everyone else be at least as wise as you, especially since you could well still be wrong.
yarou 12y ago
They don't want to do this because the secret to making money in IT is creating a glut in the supply of labor for IT workers. When you add licensing (i.e. requiring a license as a doctor or a lawyer does), this creates a barrier to entry, which will cause an upward pressure on wages for IT workers.
- onislandtime 12y ago
  Good point. Perhaps we need to work through professional organization to look into hiring practices and propose practical solutions.

akanet 12y ago

"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking" is actually how problems are generally solved in most fields. Software engineering is perhaps one of the lone exceptions, and I think the pair programming movement has a bone or two to pick with your premise.

onislandtime 12y ago
People are very diverse, some are fast and chatty, others are quiet and slow. Usually I perceive the fast and chatty types a bit arrogant. Personality and cultural background is probably an influence. Best teams have a great mix. Often caring about the work is more important than having a genius. (Of course people should be competent).
- mahyarm 12y ago
  I do coding interviews exclusively since I find whiteboard interviews even more artificial. I try to match the interview to a persons skill set and ask them to implement things they should know or know how to look up if their resume isn't a lie. I don't care if they talk or not while doing the interview and I take the role of a product designer who doesn't know how to code. If they get interview anxiety I give them the space they need. If they want a keyboard & mouse I would give it to them. What else can you do that would be an accurate simulation of their job that only takes 1hr?
  - onislandtime 12y ago
    I think that what you do makes sense if you take the time to read the resume, code samples, articles, and ask relevant questions. Asking to write some code is perfectly fine to see how the person works. References are also very important for more experienced candidates with a track record.
  - dreamweapon 12y ago
    What else can you do that would be an accurate simulation of their job that only takes 1hr? First 1/2 hour: Discuss their code samples in detail -- asking pertinent questions about each as to what they do, and why they did things they way they did. Drill down for detail, ask how they might have done things differently for different use cases, etc. Second 1/2 hour: Bring out some of your own production code and do the same (allowing them space to ask questions this time). Works best if you let them see something that's a bit "raw", i.e. quick and dirty, which you know you could have done a lot better if you had more time or knew better about the requirements (or perhaps you're simply older and wiser now). In both sessions, nuance (both in what they can observe, and how they chose to express themselves) is key. And it'll come out a lot more freely than in in a whiteboard interrogation precisely because they interaction will be natural, uncontrived and unforced. Simple, non-confrontational and 100% reflective of what engineering work is like. That's what we do during the day, 99% of the time -- digging up (sometimes woefully) less-than-perfect components of production systems, and trying to make them a little bit better. But as to how often we drag someone to a conference room, throw them at a smudgey whiteboard with creaky pens and no eraser, and force them to solve some abstract problems while we boredly look at our watch, and interrupt them with hints? Basically never. Except, that is, in coding interviews.
lazerwalker 12y ago
There's a big difference between someone looking over your shoulder and forcing you to explain what you're thinking, and someone working with you to collaboratively solve problems. In the latter case, you can ask lots of questions and throw out lots of dumb half-baked ideas, and actually get a meaningful, useful response from your partner/pair in response. If you're whiteboard interviewing, good luck getting your interviewer to meaningfully engage with you, since they don't want to "give away the answer". The best interviews I've had were legitimate pairing interviews, where the two of us were tasked with solving a problem in a real codebase that the interviewer hadn't solved before. (The best best interviews made it an issue in an open source project, so it can be a not-canned interview without you writing potentially production-ready code for a for-profit company without being paid)
- cnp 12y ago
  THIS right here is the dream interviewing scenario and in my opinion the singularly best way to test a candidates competence, aptitude and personality. Solving problems together exercises all of these key things in harmony.
- re_todd 12y ago
  There's also the fact that some people, like me, freeze up in these interview scenarios. I didn't get past my first interview a few weeks ago because I couldn't think straight knowing I was being judged going through this process. As soon as the interview was over and I was more relaxed, I thought of several good answers, like I normally do when employed.

robbyking 12y ago

The analogy I use is a coding interview is like asking a musician to play a specific song; chances are, a classically trained pianist won't know the chords to a specific pop song, but that isn't any indication of their skill as a musician. The interviews I had with the company I work for now were amazing; they asked me some basic questions to verify my resume wasn't completely BS, then asked me to discuss previous projects I'd worked on, asking questions about technical details on the way. ("Why did you use collection type X in stead of collection type Y?") This allowed them to learn about my real world experience without the risk of asking me about one specific type of problem I may not be familiar with.

deleted 12y ago
[deleted]
smm2000 12y ago
Better analogy is that classical musician is given sheet music to pop song and is told to play it on his favorite instrument. If he is good musician, he should be able to play it reasonably well even without practicing. There are musician who play extremely well but only after practicing one song for a long time - this type of interview sucks for them but they are minority. Most musicians suck with or without practicing so this type of interview is a good filter. Not ideal but no one came up with better one that scales up to thousands of applicants.
- sgustard 12y ago
  Agreed; the idea of hiring a musician without hearing them play would be madness. Not handing me a recording, not discussing intricacies of music theory, but actually playing live. And yet, a talented studio musician may suffer from performance anxiety in this situation. What to do?
  - kilbasa 12y ago
    I think the best thing is to ask them to warm up with something basic like a scale, and let them work their way up as their comfort level increases. I knew some people who were particularly pleasant and easy going, so they were able to relax people suffering from performance anxiety. There are interviewers who treat coding interviews as a high pressure, adversarial exercise, though. On the other hand, those sorts of people are rarely a joy to work with.

benihana 12y ago

>forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone? These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer. But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.

personZ 12y ago
Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it. Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough. I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices. I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at.

leothekim 12y ago

"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world." I'm often in the position to have to explain my reasoning while developing software. Code reviews and pair-programming come to mind. It's about being able to communicate complexity and being more rigorous about the software development process. That said, this style of coding interview brings up a level of stress that I'm rarely under at work. It's an unfortunate condition of interviewing, but I don't think it's completely avoidable no matter how comfortable you make the interviewee.

justinpaulson 12y ago

The point of these type of interview questions is to see how well you can reason and communicate. It is not to see if you know how to solve that specific problem, and if an interviewer is using it like that then they are not a very good interviewer. A standardized test does not substitute for actually talking to someone while they solve a problem and seeing that they can think logically and communicate those thoughts. It is more about the communication aspect of the question, not about getting to the answer. Because communication is a lot more important in business...even tech business...than you seem to think it is.

maroonblazer 12y ago
Right. While I wasn't interviewing for a technical position, the interviewer asked me to 'vote off' one of the 50 U.S. states, and to describe my reasoning why (perhaps this is a common question but I hadn't encountered it before). It was basically an exercise in thinking out loud, with a lot of "well, I'd probably want to first consider x, but actually before doing that I'd want to take into account y...". There wasn't any undue pressure, since there was clearly no right answer, so it allowed me to just riff out loud on the problem, exposing to the interviewer how I approach problems. I use this same technique now when interviewing others.
- thecage411 12y ago
  The answer is florida, right?
  - maroonblazer 12y ago
    Idaho.

eli_gottlieb 12y ago

Of course it's total bullshit. You still have to pass it. You can't demand that everyone else be at least as wise as you, especially since you could well still be wrong.

yarou 12y ago

They don't want to do this because the secret to making money in IT is creating a glut in the supply of labor for IT workers. When you add licensing (i.e. requiring a license as a doctor or a lawyer does), this creates a barrier to entry, which will cause an upward pressure on wages for IT workers.

onislandtime 12y ago
Good point. Perhaps we need to work through professional organization to look into hiring practices and propose practical solutions.