3 ms·

> It is condescending. Asking people to do FizzBuzz indicates that you expect a large portion of your candidates to be completely clueless. That's not a good me

by dsacco 9y ago

> It is condescending. Asking people to do FizzBuzz indicates that you expect a large portion of your candidates to be completely clueless. That's not a good message to send. I think it's a fairly honest message. Regardless of how you feel about demanding data structure implementation and asymptotic analysis on a whiteboard in an interview, there are many people interviewing who literally cannot code. I don't believe you can find a heuristic to filter them out that won't come across as condescending. The problem is that interviewers cannot usefully distinguish between people who are protesting FizzBuzz because they can't do it and people who are protesting it because it's actually beneath them. On the other hand, candidates can reframe their attitude. I don't think they should put up with all the nonsense hazing of whiteboard interviews, but FizzBuzz can literally be done in the time it's taken me to write this comment. If a candidate pushed back against doing it, I'd actually point that out. I've interviewed people who were "senior" engineers, yet couldn't actually complete FizzBuzz problems in their areas of expertise. It's not a trick question or testing for something abstract and far removed from the job - it's testing for, "Have you flipped through a book, compiled a program, and ran it before?" I'm sure some of the people I asked found it condescending as well, in particular the ones who couldn't complete it. But it saved me an hour of second-hand embarrassment. > Think about the following. FizzBuzz filters out some extreme cases of incompetence, but tells you nothing of value about the people who passed. You can use the same chunk of interview time to ask a more challenging question that will still filter out the extremely incompetent, but also give you some level of confidence in the people who passed. So why would you prefer to ask a question that gives you less useful information? You are talking about 5 - 10 minutes of interviewing time here. If I weed out some nontrivial percentage of applicants using a benchmark that doesn't rely on trickery and actually tests for facility with the domain, I'm happy! That's a great result - I don't want to be condescending, so if you have a better suggestion, I'd love to hear it. But like I said, sooner or later you're going to insult people with these mundane questions. You can spend the rest of the entire interview on whatever sexy signaling material you'd like, it's not like the FizzBuzz problem really ate into your time budget (unless, of course, they actually cannot code). To give you a concrete comparison: I'm very competent in cryptography (up to and including research and protocol cryptanalysis). If someone were to ask me in an interview, "Hey, what's the difference between symmetric cryptography and asymmetric cryptography", I wouldn't respond with, "Haven't you read my resume? Ask me something real." If they asked me to, I don't know, draw a diagram of a Feistel network, I wouldn't roll my eyes and take offense. I'd just do it. I might have a lesser view of their recruiting pipeline after the fact, but I'd sympathize with the necessity of the question overall and hope the interview picks up in the next ten minutes.

alexbeloi 9y ago
>I don't want to be condescending, so if you have a better suggestion, I'd love to hear it. Almost every interviewee has a git(hub/lab) account with code they're written, that should suffice to determine if they can FizzBuzz. You could also ask them for a coding sample prior to the interview if they have no public code. The solution is simple, nobody does it because it asks the interviewer to do more than skim the resume before walking into the room. I think this comes from the perception that the interviewee's time is cheap compared to that of the interviewer's.
- dmoy 9y ago
  This doesn't work, because candidates can (and apparently do) lie. I've interviewed people who have a pointer to a github account that has reasonable code, who then cannot code something basically as easy as fizzbuzz. I assume it's because they lie about that being their github account, though maybe it's because they need an IDE to code a single stateless loop. Edit: or maybe they just haven't coded in >years, and have forgotten how? I don't know.
  - alexbeloi 9y ago
    >This doesn't work, because candidates can (and apparently do) lie. I have not found this to be the case. I ask people about specific projects they have posted and sometimes look through the code together and ask them about the time-space complexity of function they've written. Maybe you're just encountering test-anxiety.
- dsacco 9y ago
  > Almost every interviewee has a git(hub/lab) account with code they're written, that should suffice to determine if they can FizzBuzz. No, almost every interviewee does not have public code, and what's more, that should be irrelevant to your process. Your proposal here selects for people who have a lot of free time or few hobbies outside of work (or a combination thereof). It's not selecting for ability. Ideally each candidate should receive the same interview; having public code shouldn't bypass what candidates without public code have to do. > You could also ask them for a coding sample prior to the interview if they have no public code. I could, and I'm personally a fan of that. But it has its own problems: 1. The assignment can still be perceived as condescending by prospective candidates. Are their feelings about this less valid than if I asked the question directly on a phone interview? Where is the line between reasonable and unreasonable contempt for a mundane task in an interview process? 2. You're still selecting for people who have free time. They either don't currently have a job, or they have free time outside of work to complete your assignment. Unless your assignment takes a trivial amount of time, in which case we're right back where we started. > The solution is simple, nobody does it because it asks the interviewer to do more than skim the resume before walking into the room. I think this comes from the perception that the interviewee's time is cheap compared to that of the interviewer's. The solution is emphatically not simple, or it would have been done in the industry already. Many people want it to be solved on both sides of the table. Your perception appears to be that interviewees' time is so valuable it's reasonable for them to be offended by a programming question so far below their (apparently vast) level of ability. You're asserting a hypothesis that interviewers are not respectful of time and saying they can't be bothered to review a resume, but it's fair if an interviewee can't be bothered to answer a simple programming question in an interview? Moreover, people lie or exaggerate on their resumes, which diminishes their absolute utility - like I said, I've seen senior engineers fail FizzBuzz. Alternatively, both sides can simply acknowledge that there isn't a simple solution and that everyone's time is valuable, then excuse the other for asking questions that are specifically designed to save everyone time. You're free to ask such questions and apply your own filters, too.

by dsacco 9y ago

alexbeloi 9y ago

>I don't want to be condescending, so if you have a better suggestion, I'd love to hear it. Almost every interviewee has a git(hub/lab) account with code they're written, that should suffice to determine if they can FizzBuzz. You could also ask them for a coding sample prior to the interview if they have no public code. The solution is simple, nobody does it because it asks the interviewer to do more than skim the resume before walking into the room. I think this comes from the perception that the interviewee's time is cheap compared to that of the interviewer's.

dmoy 9y ago
This doesn't work, because candidates can (and apparently do) lie. I've interviewed people who have a pointer to a github account that has reasonable code, who then cannot code something basically as easy as fizzbuzz. I assume it's because they lie about that being their github account, though maybe it's because they need an IDE to code a single stateless loop. Edit: or maybe they just haven't coded in >years, and have forgotten how? I don't know.
- alexbeloi 9y ago
  >This doesn't work, because candidates can (and apparently do) lie. I have not found this to be the case. I ask people about specific projects they have posted and sometimes look through the code together and ask them about the time-space complexity of function they've written. Maybe you're just encountering test-anxiety.
dsacco 9y ago
> Almost every interviewee has a git(hub/lab) account with code they're written, that should suffice to determine if they can FizzBuzz. No, almost every interviewee does not have public code, and what's more, that should be irrelevant to your process. Your proposal here selects for people who have a lot of free time or few hobbies outside of work (or a combination thereof). It's not selecting for ability. Ideally each candidate should receive the same interview; having public code shouldn't bypass what candidates without public code have to do. > You could also ask them for a coding sample prior to the interview if they have no public code. I could, and I'm personally a fan of that. But it has its own problems: 1. The assignment can still be perceived as condescending by prospective candidates. Are their feelings about this less valid than if I asked the question directly on a phone interview? Where is the line between reasonable and unreasonable contempt for a mundane task in an interview process? 2. You're still selecting for people who have free time. They either don't currently have a job, or they have free time outside of work to complete your assignment. Unless your assignment takes a trivial amount of time, in which case we're right back where we started. > The solution is simple, nobody does it because it asks the interviewer to do more than skim the resume before walking into the room. I think this comes from the perception that the interviewee's time is cheap compared to that of the interviewer's. The solution is emphatically not simple, or it would have been done in the industry already. Many people want it to be solved on both sides of the table. Your perception appears to be that interviewees' time is so valuable it's reasonable for them to be offended by a programming question so far below their (apparently vast) level of ability. You're asserting a hypothesis that interviewers are not respectful of time and saying they can't be bothered to review a resume, but it's fair if an interviewee can't be bothered to answer a simple programming question in an interview? Moreover, people lie or exaggerate on their resumes, which diminishes their absolute utility - like I said, I've seen senior engineers fail FizzBuzz. Alternatively, both sides can simply acknowledge that there isn't a simple solution and that everyone's time is valuable, then excuse the other for asking questions that are specifically designed to save everyone time. You're free to ask such questions and apply your own filters, too.