4 ms·

Just replying to state my shock at how many people are defending poor interview performance. If you freeze up during interviews because it's "high stress" then

by maxk42 13y ago

Just replying to state my shock at how many people are defending poor interview performance. If you freeze up during interviews because it's "high stress" then maybe you need to practice going on more interviews until it doesn't bug you any more. When you're a developer -- especially at a senior level -- you need to be able to work well under stress. Hell -- you need to be able to do that for nearly any job in the world.

j_baker 13y ago
True. Sr developers need to be able to handle stress. However, I don't think an interview accurately measures a person's ability to handle under stress.
justincormack 13y ago
Why? Interviews are an unnatural situation. I have hired people who did not interview well but were great at the work.
- thedufer 13y ago
  But have you also hired people who did not interview well and weren't great at the work? The goal of interviewing is to avoid false positives, not to avoid false negatives.
  - justincormack 13y ago
    "The goal of interviewing is to avoid false positives, not to avoid false negatives" - why is it? I can rectify a false positive, but if I miss greatness I might fail. If you hire people that others do not look at you can get people who are very loyal too.
    - thedufer 13y ago
      Rectifying a false positive is very expensive (cost of time they're not producing but drawing a salary, eating dev time for training, etc. + cost of firing), and firing people is a morale issue as well. Maybe this is from the perspective of a company that has no shortage of applications, but rejecting an applicant that would've been good costs basically nothing (dev time + travel if they got through phone screens). I didn't realize there was dissent on this topic. Care to elaborate? I initially picked this up from http://www.joelonsoftware.com/articles/fog0000000073.html http://www.joelonsoftware.com/articles/fog0000000073.html ("An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate.")
      - geebee 13y ago
        I think part of the problem is that the technical grilling isn't necessarily reducing false positives after a certain point. You may simply be selecting people who have front-loaded data structures in an "exam ready" way and rejecting candidates who have a fine background in this area but aren't exam ready. Do you really reduce false negatives by doing this? I almost have to wonder if you increase them, since you may simply be selecting for people who know how to prepare for an interview (and who aren't so busy with important work that they can afford to drop everything to front load the information). Think of it like this - you have two candidates. The first is exam ready for data structures and algorithms. You want merge sort? He whips out mergesort. You want red-black trees? You got it. A second candidate is clearly aware of what run time is, and what trade-offs happen in different sorting algorithms. He's clearly aware of what can happen when a binary tree gets out of balance, and is aware of the types of more balanced trees. However, his knowledge is not exam ready. He can clearly code, but he starts to fade on the edge cases and in the implementation details. He mentions the chapter in a well respected data structures and algorithms book he'd read should this issue come up. My question is, do you really protect yourself against false negatives with a no-hire on candidate #2? Candidate #1 may simply be someone who has figured out how to hack the programming interview. He might not be an especially good developer, not especially good at working with clients, with teams, with pushing through and getting it done. Or he might be very good at this. I'm just saying that I doubt that being "exam ready" is much of an indicator beyond the obvious coding ability and awareness of candidate #2. However, this process clearly creates a huge number of false negatives - by bouncing #2, there's an excellent chance that you're passing on a superb candidate, and for what? A reduction in false positives that may be close to zero? One thing - I think part of the disagreement on this board may come from the different definition people have for intensely technical interviews. Some would consider #2 to have passed. My own experience is that interviewers often do expect an "exam ready" preparation on data structures and algorithms, in addition to a few other branches of computing, which is probably I take a more cynical view of these interviews.
        thedufer 13y ago
        I don't see the relevance. The fact that you're asking someone to code a mergesort or a red-black tree tells me that you don't know how to interview, not that interviewing doesn't give you useful information. Candidate #2 sounds like they passed the interview - what did I say that made you think I'd reject them? Yeah, if you're really bad at interviewing, it's not going to give you good information. I'm not disputing that. Interviewing, as it's done where I work (and everywhere I've interviewed, which admittedly isn't very many places), has been very effective at reducing false positives.
  - phaemon 13y ago
    Then you're asking the wrong question. If you want to test a theory, you try to disprove it, not look for evidence to support it. To avoid false positives you should ask, "Have you hired people who did interview well and weren't great at the work?"
potatolicious 13y ago
This seems false to me. Interview stress isn't deadline stress isn't code review stress. This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important. I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselves on being better at interviews, as an employer it is a negative to wash someone out simply because they don't interview well. Personally I rock at interviews, I've done easily 100+ interviews in my life at this point and I actually relax when I get into the room. This doesn't make me a better coder and it doesn't make me more qualified than the next guy who comes in with sweaty palms, and an employer whose heuristic uses interview-skill as a proxy for engineering-skill would be very misguided. The entire problem with tech recruiting comes down to stupid proxies. We went through a phase where the top tech companies replaced real questions with logic brain teasers, as if that was a suitable proxy for real engineering ability. Now some startups are doing stupid shit like requiring extensive side projects, as if that is a suitable proxy for real engineering ability. I'm not sure how many more years it will take for tech as an industry to realize that the best way to know someone is good at X, is to get them to do X.
- Cakez0r 13y ago
  all drivers need to be able to drive well under stress But wouldn't you say a driving test is to driving as a technical interview is to a development role?
  - potatolicious 13y ago
    Absolutely. And if we conducted driving tests like we conduct technical interviews, it would be something like: - Please sketch out a diagram of a typical family sedan, be sure to mark and explain all major components. - Do you drive stick? No? Well, please draw out the full mechanical diagram of a manual transmission. - You are going down the street and an old lady steps suddenly off the sidewalk. Please sketch on this whiteboard what you would do. - Please play 5 rounds of Need For Speed: Underground. You are required to come in 2nd or 1st in all rounds. etc, etc. It definitely won't entail actual driving.
lfuller 13y ago
Many people, me included, experience something called "interview anxiety". It is only ever present during interviews. It may not be rational, but it's how our minds work. It's easier to understand if you think of it like a phobia - someone may be irrationally scared of spiders, but that doesn't mean that they are going to be scared of heights, clowns, dogs, and snakes too.
YZF 13y ago
The main issue is that a lot of those interviews are poorly correlated with actual job performance. (People should familiarize themselves with Daniel Kahneman's related work there). Even the outcome of the interview may have more to do with the mood the interviewers are in and various social factors and signals then some objective measures. Most of my experience is interviewing others but it is certainly a reality check, which everyone should go through occasionally, to go interview somewhere else. Personally I have no issue with stress. It actually brings out the best in me. I do realize however this whole thing is a game. When I interview others I try to be aware of these factors and get at what I really need but I'm not 100% immune to being in a bad mood etc. One day I should blog about how to interview. That's a fun subject to write about...
adeaver 13y ago
You aren't looking at the entire picture. Some have trouble in interviews because of learning disabilities and social anxiety but do well in the workplace once they are comfortable with the people. Add to that the fact that most tech interviews are held in non-real world situations and it's easy to see why some people have problems. Putting a person in a room with a piece of paper with a chunk of code that has a 'hidden' flaw with no access to any other resources isn't real-world. All of us have access to books, manuals, the code, google, any number of places we can use to help. And usually these interviews focus on nuances of a language or a programming trick that you only know if you've seen it before or encounter it regularly. The codebase I'm working on now targets the iPad. If I were to interview with a company and the tech reviewer asked me about an IE specific hack chances are it would take me a while to come up with it. Assuming I've encountered it before.
nollidge 13y ago
I'm shocked that you're shocked. An interview is a contrived situation whose social stressors do not at all match those of programming a computer.

by maxk42 13y ago

j_baker 13y ago

True. Sr developers need to be able to handle stress. However, I don't think an interview accurately measures a person's ability to handle under stress.

justincormack 13y ago

Why? Interviews are an unnatural situation. I have hired people who did not interview well but were great at the work.

thedufer 13y ago
But have you also hired people who did not interview well and weren't great at the work? The goal of interviewing is to avoid false positives, not to avoid false negatives.
- justincormack 13y ago
  "The goal of interviewing is to avoid false positives, not to avoid false negatives" - why is it? I can rectify a false positive, but if I miss greatness I might fail. If you hire people that others do not look at you can get people who are very loyal too.
  - thedufer 13y ago
    Rectifying a false positive is very expensive (cost of time they're not producing but drawing a salary, eating dev time for training, etc. + cost of firing), and firing people is a morale issue as well. Maybe this is from the perspective of a company that has no shortage of applications, but rejecting an applicant that would've been good costs basically nothing (dev time + travel if they got through phone screens). I didn't realize there was dissent on this topic. Care to elaborate? I initially picked this up from http://www.joelonsoftware.com/articles/fog0000000073.html http://www.joelonsoftware.com/articles/fog0000000073.html ("An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate.")
    - geebee 13y ago
      I think part of the problem is that the technical grilling isn't necessarily reducing false positives after a certain point. You may simply be selecting people who have front-loaded data structures in an "exam ready" way and rejecting candidates who have a fine background in this area but aren't exam ready. Do you really reduce false negatives by doing this? I almost have to wonder if you increase them, since you may simply be selecting for people who know how to prepare for an interview (and who aren't so busy with important work that they can afford to drop everything to front load the information). Think of it like this - you have two candidates. The first is exam ready for data structures and algorithms. You want merge sort? He whips out mergesort. You want red-black trees? You got it. A second candidate is clearly aware of what run time is, and what trade-offs happen in different sorting algorithms. He's clearly aware of what can happen when a binary tree gets out of balance, and is aware of the types of more balanced trees. However, his knowledge is not exam ready. He can clearly code, but he starts to fade on the edge cases and in the implementation details. He mentions the chapter in a well respected data structures and algorithms book he'd read should this issue come up. My question is, do you really protect yourself against false negatives with a no-hire on candidate #2? Candidate #1 may simply be someone who has figured out how to hack the programming interview. He might not be an especially good developer, not especially good at working with clients, with teams, with pushing through and getting it done. Or he might be very good at this. I'm just saying that I doubt that being "exam ready" is much of an indicator beyond the obvious coding ability and awareness of candidate #2. However, this process clearly creates a huge number of false negatives - by bouncing #2, there's an excellent chance that you're passing on a superb candidate, and for what? A reduction in false positives that may be close to zero? One thing - I think part of the disagreement on this board may come from the different definition people have for intensely technical interviews. Some would consider #2 to have passed. My own experience is that interviewers often do expect an "exam ready" preparation on data structures and algorithms, in addition to a few other branches of computing, which is probably I take a more cynical view of these interviews.
      - thedufer 13y ago
        I don't see the relevance. The fact that you're asking someone to code a mergesort or a red-black tree tells me that you don't know how to interview, not that interviewing doesn't give you useful information. Candidate #2 sounds like they passed the interview - what did I say that made you think I'd reject them? Yeah, if you're really bad at interviewing, it's not going to give you good information. I'm not disputing that. Interviewing, as it's done where I work (and everywhere I've interviewed, which admittedly isn't very many places), has been very effective at reducing false positives.
- phaemon 13y ago
  Then you're asking the wrong question. If you want to test a theory, you try to disprove it, not look for evidence to support it. To avoid false positives you should ask, "Have you hired people who did interview well and weren't great at the work?"

potatolicious 13y ago

This seems false to me. Interview stress isn't deadline stress isn't code review stress. This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important. I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselves on being better at interviews, as an employer it is a negative to wash someone out simply because they don't interview well. Personally I rock at interviews, I've done easily 100+ interviews in my life at this point and I actually relax when I get into the room. This doesn't make me a better coder and it doesn't make me more qualified than the next guy who comes in with sweaty palms, and an employer whose heuristic uses interview-skill as a proxy for engineering-skill would be very misguided. The entire problem with tech recruiting comes down to stupid proxies. We went through a phase where the top tech companies replaced real questions with logic brain teasers, as if that was a suitable proxy for real engineering ability. Now some startups are doing stupid shit like requiring extensive side projects, as if that is a suitable proxy for real engineering ability. I'm not sure how many more years it will take for tech as an industry to realize that the best way to know someone is good at X, is to get them to do X.

Cakez0r 13y ago
all drivers need to be able to drive well under stress But wouldn't you say a driving test is to driving as a technical interview is to a development role?
- potatolicious 13y ago
  Absolutely. And if we conducted driving tests like we conduct technical interviews, it would be something like: - Please sketch out a diagram of a typical family sedan, be sure to mark and explain all major components. - Do you drive stick? No? Well, please draw out the full mechanical diagram of a manual transmission. - You are going down the street and an old lady steps suddenly off the sidewalk. Please sketch on this whiteboard what you would do. - Please play 5 rounds of Need For Speed: Underground. You are required to come in 2nd or 1st in all rounds. etc, etc. It definitely won't entail actual driving.

lfuller 13y ago

Many people, me included, experience something called "interview anxiety". It is only ever present during interviews. It may not be rational, but it's how our minds work. It's easier to understand if you think of it like a phobia - someone may be irrationally scared of spiders, but that doesn't mean that they are going to be scared of heights, clowns, dogs, and snakes too.

YZF 13y ago

The main issue is that a lot of those interviews are poorly correlated with actual job performance. (People should familiarize themselves with Daniel Kahneman's related work there). Even the outcome of the interview may have more to do with the mood the interviewers are in and various social factors and signals then some objective measures. Most of my experience is interviewing others but it is certainly a reality check, which everyone should go through occasionally, to go interview somewhere else. Personally I have no issue with stress. It actually brings out the best in me. I do realize however this whole thing is a game. When I interview others I try to be aware of these factors and get at what I really need but I'm not 100% immune to being in a bad mood etc. One day I should blog about how to interview. That's a fun subject to write about...

adeaver 13y ago

You aren't looking at the entire picture. Some have trouble in interviews because of learning disabilities and social anxiety but do well in the workplace once they are comfortable with the people. Add to that the fact that most tech interviews are held in non-real world situations and it's easy to see why some people have problems. Putting a person in a room with a piece of paper with a chunk of code that has a 'hidden' flaw with no access to any other resources isn't real-world. All of us have access to books, manuals, the code, google, any number of places we can use to help. And usually these interviews focus on nuances of a language or a programming trick that you only know if you've seen it before or encounter it regularly. The codebase I'm working on now targets the iPad. If I were to interview with a company and the tech reviewer asked me about an IE specific hack chances are it would take me a while to come up with it. Assuming I've encountered it before.

nollidge 13y ago

I'm shocked that you're shocked. An interview is a contrived situation whose social stressors do not at all match those of programming a computer.