5 ms·

Emphasis on point #2. You're hiring a programmer not a clutch outside shooter for your basketball team. Unless your code consistently has a lot of fires that ne

Emphasis on point #2. You're hiring a programmer not a clutch outside shooter for your basketball team. Unless your code consistently has a lot of fires that need to be put out in short order there's no reason to filter people based on clutch performance.

meritt 14y ago
Obviously interviews are stressful but this is FizzBuzz we're talking about. If someone cannot figure it out during a moderately-stressful interview, they quite simply aren't a very good programmer.
- rasur 14y ago
  Never under-estimate the ability of a stressful situation to completely decimate your ability to perform as hoped, regardless of programming ability.
  - Nursie 14y ago
    If you're so stressed you can't write fizzbuzz in an interview then how are you going to deal with any workplace stress?
    - rasur 14y ago
      Interview stress and normal workday stress are completely different beasts, in my experience. Coping with one is not always an indicator of the ability to deal with the other.
      - jlgreco 14y ago
        How are we supposed to interview candidates at all, if their interview specific stress is so crippling? What sort of things can they answer, if not at least FizzBuzz?
        UnoriginalGuy 14y ago
        Give them a unique programming problem before hand and ask them to bring their solution to the interview, and then discuss the solution with them. Unless they "cheat" this should give you a good idea of what they're capable of. The cheating should also show up if they cannot explain it or why they wrote it the way they did.
        jlgreco 14y ago
        How far beforehand would you suggest? Would walking into the interview, handing them the problem, and then telling them that you'll come back in 10/15 minutes to "start" the interview be acceptable?
        davorak 14y ago
        Asking someone to solve a problem in the waiting rooms is considerably different then letting them solve the problem in their chosen environment. Probably not as stressful as durring an interview with people watching however.
        rasur 14y ago
        As noted in another reply to this question, get them to bring in a project and explain it. Additionally, they could spend some time with the team they'd be working in, pairing (or whatever) with other members and really demonstrating their abilities. It's not really that difficult to get away from the whole "technical question at the interview" problem, and I'd wager that in the long-term it'd be better for all concerned.
        jlgreco 14y ago
        Eh, maybe. Those are fine interviewing techniques, but I am unconvinced that explaining something technical you've done in the past would really be that different (from a stress-induced difficulty standpoint) than FizzBuzz.
        14y ago
  - bmj 14y ago
    So, when production is down, and clients are calling, and revenue is lost, it's okay to say "I'm too stressed to fix this bug?" I'm sympathetic to complaints about overly technical interviews (I've bombed a few in my day because of stress and/or ignorance), but as others have pointed out, this is FizzBuzz. I'm generally very bad at interview/algorithm puzzles, but I could even figure this one out pretty quickly.
    - ssebro 14y ago
      A better metaphor would be those things happening and your boss saying "solve fizzbuzz in 10 minutes or we'll fire you". (or we'll fire you == not getting the job/failing the interview). The big difference between the two metaphors is that mine has direct impact on your personal life and negative consequences are gonna be seen as your fault, while yours is a company threat - fixing it will get you seen as a hero, not a disgraced villain.
  - danielweber 14y ago
    Fortunately there are plenty of employers. Even Google lets you try again in a year.
- UnoriginalGuy 14y ago
  FizzBuzz seems to get a lot of people simply because they aren't familiar with the remainder (Modulo) operator. I have to admit that I myself rarely need to use it. When I first read about FizzBuzz I tried to solve it by division and then comparing the floating point result to a rounded int result (i.e. circular way to get the remainder). I'd be interested to see how many people pass if you simply remove the remainder operator part of it entirely. My guess is that near 100%. FizzBuzz is still less "unfair" than a lot of the trick programming questions, riddles, or random CompSci trivia that many companies (Google, Microsoft, etc) do. This is one of the reasons I would never even apply at a Google. I don't perform well programming wise under that level of pressure and my "random trivia" reserves are low.
  - jstelly 14y ago
    It really depends on the type of programming job you are interviewing for, but for all of the jobs I've had I'd expect a candidate to be able to do this with or without using a mod operator. I've asked people similarly simple programming problems; I like the approach. I don't like requiring leaps of intuition or analysis as a filter like this though. So problems should be straightforward. You are checking for fundamental coding and problem solving in an interview like this.
ssebro 14y ago
I have to agree with this one. It sounds absolutely crazy that the average engineer can't write fizzbuzz during an interview. But if you take a second and think about it, how the hell could these same people who fail fizzbuzz write production code in previous companies? Are you really saying that you believe that fizzbuzz is more complicated/difficult than their previous work? As someone who's run lab experiments and who's seen a bunch of surprising results, trust me when I say that shocking results usually mean that you're running a test that you don't understand. In this case, you're probably testing for a host of things that have nothing to do with day-to-day engineer performance.
- Nursie 14y ago
  "how the hell could these same people who fail fizzbuzz write production code in previous companies?" Maybe they had a lot of supervision, or were someone that could talk a good game to management but didn't deliver, or maybe they just fiddled around with minor stuff in other folks' code. While experience is obviously a really good thing and a useful thing, if they can't write fizzbuzz you'd have to re-evaluate that experience in the light of new knowledge.
  - ssebro 14y ago
    I think you missed my point. I'm saying that fizzbuzz is very, very unlikely to be something you should use for evaluating someone's experience. What I'm pointing out is a fundamental problem with coding problems. FizzBuzz is a relatively simple problem to solve, so if fizzbuzz fails as a test for coding ability, then it's fairly likely that all coding problems fail. There's are probably better metrics (faster, more uniform, etc) that you could use to figure out how good a coder is. For example, one thing I've noticed is that I'm fairly aware of the skill levels of everyone I've ever worked with. I think it might be interesting to see how peers rate each other (A players can tell A players, and so on)- maybe that would be the metric that's most useful. All I know is that FizzBuzz probably isn't it. One last thing I need to add: the people who are dramatically more productive coders are not always dramatically more productive because they code faster or better. It's often because they enact/enable processes that amplify the other developers. (e.g. the developer who pushes the company to have a hackathon, or the dev who creates machine images preconfigured for deploying test and dev builds).

meritt 14y ago

Obviously interviews are stressful but this is FizzBuzz we're talking about. If someone cannot figure it out during a moderately-stressful interview, they quite simply aren't a very good programmer.

rasur 14y ago
Never under-estimate the ability of a stressful situation to completely decimate your ability to perform as hoped, regardless of programming ability.
- Nursie 14y ago
  If you're so stressed you can't write fizzbuzz in an interview then how are you going to deal with any workplace stress?
  - rasur 14y ago
    Interview stress and normal workday stress are completely different beasts, in my experience. Coping with one is not always an indicator of the ability to deal with the other.
    - jlgreco 14y ago
      How are we supposed to interview candidates at all, if their interview specific stress is so crippling? What sort of things can they answer, if not at least FizzBuzz?
      - UnoriginalGuy 14y ago
        Give them a unique programming problem before hand and ask them to bring their solution to the interview, and then discuss the solution with them. Unless they "cheat" this should give you a good idea of what they're capable of. The cheating should also show up if they cannot explain it or why they wrote it the way they did.
        jlgreco 14y ago
        How far beforehand would you suggest? Would walking into the interview, handing them the problem, and then telling them that you'll come back in 10/15 minutes to "start" the interview be acceptable?
        davorak 14y ago
        Asking someone to solve a problem in the waiting rooms is considerably different then letting them solve the problem in their chosen environment. Probably not as stressful as durring an interview with people watching however.
      - rasur 14y ago
        As noted in another reply to this question, get them to bring in a project and explain it. Additionally, they could spend some time with the team they'd be working in, pairing (or whatever) with other members and really demonstrating their abilities. It's not really that difficult to get away from the whole "technical question at the interview" problem, and I'd wager that in the long-term it'd be better for all concerned.
        jlgreco 14y ago
        Eh, maybe. Those are fine interviewing techniques, but I am unconvinced that explaining something technical you've done in the past would really be that different (from a stress-induced difficulty standpoint) than FizzBuzz.
        14y ago
- bmj 14y ago
  So, when production is down, and clients are calling, and revenue is lost, it's okay to say "I'm too stressed to fix this bug?" I'm sympathetic to complaints about overly technical interviews (I've bombed a few in my day because of stress and/or ignorance), but as others have pointed out, this is FizzBuzz. I'm generally very bad at interview/algorithm puzzles, but I could even figure this one out pretty quickly.
  - ssebro 14y ago
    A better metaphor would be those things happening and your boss saying "solve fizzbuzz in 10 minutes or we'll fire you". (or we'll fire you == not getting the job/failing the interview). The big difference between the two metaphors is that mine has direct impact on your personal life and negative consequences are gonna be seen as your fault, while yours is a company threat - fixing it will get you seen as a hero, not a disgraced villain.
- danielweber 14y ago
  Fortunately there are plenty of employers. Even Google lets you try again in a year.
UnoriginalGuy 14y ago
FizzBuzz seems to get a lot of people simply because they aren't familiar with the remainder (Modulo) operator. I have to admit that I myself rarely need to use it. When I first read about FizzBuzz I tried to solve it by division and then comparing the floating point result to a rounded int result (i.e. circular way to get the remainder). I'd be interested to see how many people pass if you simply remove the remainder operator part of it entirely. My guess is that near 100%. FizzBuzz is still less "unfair" than a lot of the trick programming questions, riddles, or random CompSci trivia that many companies (Google, Microsoft, etc) do. This is one of the reasons I would never even apply at a Google. I don't perform well programming wise under that level of pressure and my "random trivia" reserves are low.
- jstelly 14y ago
  It really depends on the type of programming job you are interviewing for, but for all of the jobs I've had I'd expect a candidate to be able to do this with or without using a mod operator. I've asked people similarly simple programming problems; I like the approach. I don't like requiring leaps of intuition or analysis as a filter like this though. So problems should be straightforward. You are checking for fundamental coding and problem solving in an interview like this.

ssebro 14y ago

I have to agree with this one. It sounds absolutely crazy that the average engineer can't write fizzbuzz during an interview. But if you take a second and think about it, how the hell could these same people who fail fizzbuzz write production code in previous companies? Are you really saying that you believe that fizzbuzz is more complicated/difficult than their previous work? As someone who's run lab experiments and who's seen a bunch of surprising results, trust me when I say that shocking results usually mean that you're running a test that you don't understand. In this case, you're probably testing for a host of things that have nothing to do with day-to-day engineer performance.

Nursie 14y ago
"how the hell could these same people who fail fizzbuzz write production code in previous companies?" Maybe they had a lot of supervision, or were someone that could talk a good game to management but didn't deliver, or maybe they just fiddled around with minor stuff in other folks' code. While experience is obviously a really good thing and a useful thing, if they can't write fizzbuzz you'd have to re-evaluate that experience in the light of new knowledge.
- ssebro 14y ago
  I think you missed my point. I'm saying that fizzbuzz is very, very unlikely to be something you should use for evaluating someone's experience. What I'm pointing out is a fundamental problem with coding problems. FizzBuzz is a relatively simple problem to solve, so if fizzbuzz fails as a test for coding ability, then it's fairly likely that all coding problems fail. There's are probably better metrics (faster, more uniform, etc) that you could use to figure out how good a coder is. For example, one thing I've noticed is that I'm fairly aware of the skill levels of everyone I've ever worked with. I think it might be interesting to see how peers rate each other (A players can tell A players, and so on)- maybe that would be the metric that's most useful. All I know is that FizzBuzz probably isn't it. One last thing I need to add: the people who are dramatically more productive coders are not always dramatically more productive because they code faster or better. It's often because they enact/enable processes that amplify the other developers. (e.g. the developer who pushes the company to have a hackathon, or the dev who creates machine images preconfigured for deploying test and dev builds).