4 ms·

Hrm, I don't like this. I consider myself a pretty competent programmer, and I like doing programming puzzles for fun. I've spent a decent amount of time on 4cl

Hrm, I don't like this. I consider myself a pretty competent programmer, and I like doing programming puzzles for fun. I've spent a decent amount of time on 4clojure, project euler, and similar sites, and I can generally come up with solutions I'm happy with (elegant enough for my own liking). That said, from the stress free environment of my couch, some of these puzzles take me quite a while. I'm fairly confident that if asked to hash out a solution to this on a whiteboard in an interview situation, the stress of being put on the spot would impede my ability to perform up to par, and I'd probably come across as inept. Ironically, I'm one of the principal interviewers at the medium-sized company I work at. Many of the interviews I conduct delve into fairly technical discussions of previous projects the candidate has worked on, and I can generally walk away with a fairly firm gut feeling of how competent someone is. Candidates that give a solid initial impression are always asked to submit additional code samples (sometimes several rounds thereof), and occasionally asked back for one additional followup interview if we need any additional details. Through this gradual feeling out process, I feel like we've acquired some very excellent hires that we may have otherwise looked over if we based our process strictly on brain teaser type screenings.

gcp 15y ago
I'm fairly confident that if asked to hash out a solution to this on a whiteboard in an interview situation, the stress of being put on the spot would impede my ability to perform up to par, and I'd probably come across as inept. There's a mistaken assumption here that because you're a competent programmer you're expected to solve these exercises with ease [1]. If you're interviewing with that expectation, you'll have a huge false negative rate and only hire people with nerves of stainless steel. Even experienced programmers can make very silly mistakes when coding under pressure in front of an audience. What you're expecting to see is that the person can reason, knows the basic syntax of the language he claims to be familiar with, and doesn't make any mistakes that show a total misunderstanding or unfamiliarity of how it works. (Put differently, have they read a book/website of examples of the language, or have they actually coded in it?) If you point the experienced programmer that's very nervous a few of his mistakes, you're expecting him to show sheer terror and panic as he realizes what he's done [2]. If the candidate is showing you a blank stare instead, you might have a problem. If you're only verbally interviewing and asking for code samples, you can get fooled easily. Some candidates think that if they can bullshit their way through the interview, they'll stay hired. And sometimes, they're even right, because most people don't like to fire. At some point, we were having serious problems filling positions and started de-emphasizing doing bad/mediocre on the coding part of the interview, and focus more on the experience and verbal interview, on the assumption radiated in many posts here that serious coders might not necessarily be able to show their ability in a coding interview. All of those hires turned out to bad. You'll have a hard time convincing me now that coding interviews aren't effective. [1] The example here is FizzBuzz. Why is it so trivial that many people can't believe it works? Because even good coders will fuck up more complicated questions in interviews. [2] Just as an observation and nothing more: experienced coders tend to also not being able to bear the sight of those mistakes and insist on being allowed to correct them even if told it really doesn't matter.
- gldalmaso 15y ago
  I agree. I do think is valid to show code produced just-in-time, but I don't it's okay to observe the candidate, for the reasons already pointed out. If you must ask for code, give the candidate a computer and leave the room, or have the candidate leave the room with a computer and leave him to it. You should be at least partially trying to emulate real working conditions. Otherwise it's just torture.

gcp 15y ago

I'm fairly confident that if asked to hash out a solution to this on a whiteboard in an interview situation, the stress of being put on the spot would impede my ability to perform up to par, and I'd probably come across as inept. There's a mistaken assumption here that because you're a competent programmer you're expected to solve these exercises with ease [1]. If you're interviewing with that expectation, you'll have a huge false negative rate and only hire people with nerves of stainless steel. Even experienced programmers can make very silly mistakes when coding under pressure in front of an audience. What you're expecting to see is that the person can reason, knows the basic syntax of the language he claims to be familiar with, and doesn't make any mistakes that show a total misunderstanding or unfamiliarity of how it works. (Put differently, have they read a book/website of examples of the language, or have they actually coded in it?) If you point the experienced programmer that's very nervous a few of his mistakes, you're expecting him to show sheer terror and panic as he realizes what he's done [2]. If the candidate is showing you a blank stare instead, you might have a problem. If you're only verbally interviewing and asking for code samples, you can get fooled easily. Some candidates think that if they can bullshit their way through the interview, they'll stay hired. And sometimes, they're even right, because most people don't like to fire. At some point, we were having serious problems filling positions and started de-emphasizing doing bad/mediocre on the coding part of the interview, and focus more on the experience and verbal interview, on the assumption radiated in many posts here that serious coders might not necessarily be able to show their ability in a coding interview. All of those hires turned out to bad. You'll have a hard time convincing me now that coding interviews aren't effective. [1] The example here is FizzBuzz. Why is it so trivial that many people can't believe it works? Because even good coders will fuck up more complicated questions in interviews. [2] Just as an observation and nothing more: experienced coders tend to also not being able to bear the sight of those mistakes and insist on being allowed to correct them even if told it really doesn't matter.

gldalmaso 15y ago
I agree. I do think is valid to show code produced just-in-time, but I don't it's okay to observe the candidate, for the reasons already pointed out. If you must ask for code, give the candidate a computer and leave the room, or have the candidate leave the room with a computer and leave him to it. You should be at least partially trying to emulate real working conditions. Otherwise it's just torture.