4 ms·

”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.” I

by irq11 8y ago

”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.” I haven’t seen this. I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons, and then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass (or because they think TopCoder medium questions are “fizzbuzz”. Equally stupid.) Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.

dunpeal 8y ago
> I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity? > then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it. They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did. > I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.
- irq11 8y ago
  ”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”. If you wait for the senior people to interview everyone, you’re going to be waiting a while. ”Coding questions are among the most quantifiable and objective questions there are.” Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.
  - dunpeal 8y ago
    OK, I suppose lack of seniors is a legitimate constraint. Still, interviewing is so important, that I typically give it a high priority. Even when I had only one other senior engineer, I made sure each candidate spent a long time with each of us. Typically, I'd go in with a junior developer, and he'd go in with some other junior developer. I'd even see the same candidate twice rather than have two juniors interview him. I've been on the other side of that kind of interview and I know how badly it can get messed up. > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. I don't see a reason to swear, as this is a friendly discussion. Either way, we'll have to agree to disagree. Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.
    - shady-lady 8y ago
      > Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets. Except for coding style (incl. naming convention), code organisation, test coverage, arch style, level of abstraction..plus a myriad of other things. I don't know anybody who treat the code in a coding question as a black box. It gets about as subjective as you can get when reviewing, with the (objectively) correct answer weighted the least. Shit code that gets the right answer rates worse than code which ticks all the above subjective boxes but gets the answer wrong.
  - bradleyjg 8y ago
    > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. > Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not. It seems as though there are a fair number of things like this, where people sort-of play act science but don’t bother with the rigor. I guess it’s a type of cargo culting.
  - 0xfeba 8y ago
- btilly 8y ago
  Note that "junior interviewers" are not necessarily junior, just junior as interviewers. They may be good coders, but they don't know what is reasonable to expect for the role, or how to test for it. Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" Two interviewers asking the same question of equivalent candidates can get very different results based on how stressed they make the candidate, what hints they offer, what followup questions they ask, how well they telegraph whether the candidate is on the right path, and so on.
  - dunpeal 8y ago
    > Note that "junior interviewers" are not necessarily junior, just junior as interviewers. Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders. Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees. > Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" I would moderate that statement as "become less quantifiable and objective". They're still more objective than "tell me about the project you are most proud of" or (worst) "what is your biggest weakness?" (perfectionism, duh!). You can also control many of these factors by standardizing interviewer behavior. For example, "no feedback of any kind until the candidate writes a working solution", or working off a predefined set of hints.
    - btilly 8y ago
      Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders. Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees. I would put it the other way around. My experience is that most startups just put you in front of people and tell you to figure it out. People who have done that for a bit wind up with really bad interview habits because they never get corrected. My experience with large companies (Google and Amazon) has them giving interview training. I learned a lot more about interviewing from that than the informal practice that I got in startups.
- sidlls 8y ago
  > Coding questions are among the most quantifiable and objective questions there are. Only in the most trivial cases (for statements, not necessarily solution). If you want to assess engineering ability, specific coding questions are a small, tiny sample of the space, and generally the more difficult the problem the less useful it is.
DoofusOfDeath 8y ago
> Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Not sure how common this is, but I've been one of those flame-outs. It was during a Google phone-screen. I was given a very simple programming problem, and something in my brain just broke (figuratively). In retrospect it was probably from being too tense because I was star-struck about the employer. But on that one particular interview, I could barely have written printf("fizbuzz\n");
- dunpeal 8y ago
  If it's any comfort: everyone performs worse under the stress of an interview. This is widely recognized by hiring employers, and accounted for in the interview evaluation. For example, if I test-run a new question, and it takes my engineers 20 minutes to solve it, I will add 30-50% handicap for stress. I.E. if a candidate manages to solve it within 30 minutes, that's roughly equivalent. Unfortunately, there's no way to account for someone having a complete blackout such as you describe.
  - PhasmaFelis 8y ago
    Don't ask people to do something they've maybe never done before and will never have to do on the job (write code with a marker on a whiteboard as seconds tick down). If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). But literal whiteboard tests are a recipe for complete blackouts.
    - dunpeal 8y ago
      > If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). I am doing just that. > But literal whiteboard tests are a recipe for complete blackouts. Not always. I've done a lot of whiteboard interviews too. It's a different way to discuss a problem, and one that people do use at work. Most design sessions happen with a colleague or two in front of a whiteboard, not sitting at a workstation. I disagree that blacking out is so common, though I understand it does happen occasionally. Also, we typically do at least 5 interviews in every onsite, one blackout wouldn't destroy the chances of an otherwise strong candidate.

by irq11 8y ago

dunpeal 8y ago

> I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity? > then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it. They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did. > I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.

irq11 8y ago
”Why are "juniors" interviewing candidates?” I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”. If you wait for the senior people to interview everyone, you’re going to be waiting a while. ”Coding questions are among the most quantifiable and objective questions there are.” Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.
- dunpeal 8y ago
  OK, I suppose lack of seniors is a legitimate constraint. Still, interviewing is so important, that I typically give it a high priority. Even when I had only one other senior engineer, I made sure each candidate spent a long time with each of us. Typically, I'd go in with a junior developer, and he'd go in with some other junior developer. I'd even see the same candidate twice rather than have two juniors interview him. I've been on the other side of that kind of interview and I know how badly it can get messed up. > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. I don't see a reason to swear, as this is a friendly discussion. Either way, we'll have to agree to disagree. Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.
  - shady-lady 8y ago
    > Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets. Except for coding style (incl. naming convention), code organisation, test coverage, arch style, level of abstraction..plus a myriad of other things. I don't know anybody who treat the code in a coding question as a black box. It gets about as subjective as you can get when reviewing, with the (objectively) correct answer weighted the least. Shit code that gets the right answer rates worse than code which ticks all the above subjective boxes but gets the answer wrong.
- bradleyjg 8y ago
  > Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right. > Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not. It seems as though there are a fair number of things like this, where people sort-of play act science but don’t bother with the rigor. I guess it’s a type of cargo culting.
- 0xfeba 8y ago
btilly 8y ago
Note that "junior interviewers" are not necessarily junior, just junior as interviewers. They may be good coders, but they don't know what is reasonable to expect for the role, or how to test for it. Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" Two interviewers asking the same question of equivalent candidates can get very different results based on how stressed they make the candidate, what hints they offer, what followup questions they ask, how well they telegraph whether the candidate is on the right path, and so on.
- dunpeal 8y ago
  > Note that "junior interviewers" are not necessarily junior, just junior as interviewers. Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders. Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees. > Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" I would moderate that statement as "become less quantifiable and objective". They're still more objective than "tell me about the project you are most proud of" or (worst) "what is your biggest weakness?" (perfectionism, duh!). You can also control many of these factors by standardizing interviewer behavior. For example, "no feedback of any kind until the candidate writes a working solution", or working off a predefined set of hints.
  - btilly 8y ago
    Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders. Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees. I would put it the other way around. My experience is that most startups just put you in front of people and tell you to figure it out. People who have done that for a bit wind up with really bad interview habits because they never get corrected. My experience with large companies (Google and Amazon) has them giving interview training. I learned a lot more about interviewing from that than the informal practice that I got in startups.
sidlls 8y ago
> Coding questions are among the most quantifiable and objective questions there are. Only in the most trivial cases (for statements, not necessarily solution). If you want to assess engineering ability, specific coding questions are a small, tiny sample of the space, and generally the more difficult the problem the less useful it is.

DoofusOfDeath 8y ago

> Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway. Not sure how common this is, but I've been one of those flame-outs. It was during a Google phone-screen. I was given a very simple programming problem, and something in my brain just broke (figuratively). In retrospect it was probably from being too tense because I was star-struck about the employer. But on that one particular interview, I could barely have written printf("fizbuzz\n");

dunpeal 8y ago
If it's any comfort: everyone performs worse under the stress of an interview. This is widely recognized by hiring employers, and accounted for in the interview evaluation. For example, if I test-run a new question, and it takes my engineers 20 minutes to solve it, I will add 30-50% handicap for stress. I.E. if a candidate manages to solve it within 30 minutes, that's roughly equivalent. Unfortunately, there's no way to account for someone having a complete blackout such as you describe.
- PhasmaFelis 8y ago
  Don't ask people to do something they've maybe never done before and will never have to do on the job (write code with a marker on a whiteboard as seconds tick down). If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). But literal whiteboard tests are a recipe for complete blackouts.
  - dunpeal 8y ago
    > If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). I am doing just that. > But literal whiteboard tests are a recipe for complete blackouts. Not always. I've done a lot of whiteboard interviews too. It's a different way to discuss a problem, and one that people do use at work. Most design sessions happen with a colleague or two in front of a whiteboard, not sitting at a workstation. I disagree that blacking out is so common, though I understand it does happen occasionally. Also, we typically do at least 5 interviews in every onsite, one blackout wouldn't destroy the chances of an otherwise strong candidate.