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.
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.
But wouldn't you say a driving test is to driving as a technical interview is to a development role?
- 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.
Best interview process ever, and that company had excellent programmers and the lowest employee turnover I've ever seen.
I hope I don't get yelled at, but damn that was funny. That stated it so perfectly.
The only "stress" in software development that I see on the job is trying to meet deadlines that either aren't realistic, or now moot due to (substantial) changes in requirements.
Bugs are normal. Prod issues are normal. Code that won't work as you envisioned or intended is normal. Problems that are hard to solve are normal. Any or all of the above sometimes require extra hours to resolve but that's not even in the same ballpark as "will I be homeless soon".
Phrased another way: being without money is not that stressful. Being without a way to make money is extremely stressful.
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.
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 ("An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate.")
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.
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.
> cost of time they're not producing but drawing a salary
How many false positives do you know of who didn't produce anything? What is the actual chance that someone is going to be a net drag if they don't work out? Of course it can happen, but I get the impression from the more paranoid that it is likely or expected. I don't see that.
> eating dev time for training, etc.
This, I feel, is highly dependent on company and codebase. At my previous employer, I worked on real-time radar signal processing code which was very complicated and math-heavy. Someone who did not know what they were doing in that code could have easily cratered the productivity of one or more software or systems engineers. Simpler codebases would not be as bad.
> + cost of firing
Depending on your local laws and corporate structure, I can understand this issue. It takes an act of Congress to get fired from a defense contractor, though they have enough small layoffs to prune the dead wood once in awhile without a full-blown firing. I would like to know what the issues are for a smaller company though, since I really don't know the process. I get mixed signals as well. It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.
> 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).
If your company is finding the people it needs more or less when it needs them, then I understand this view. However, if your company is also one of those that complains about how hard it is to find "qualified" people and how understaffed you are, then your false positives are costing your business far more than that, though the true cost is very difficult to quantify (as is the true cost of a false positive).
Well, none. We haven't had any false positives since I started (and this is my first full-time job).
Depending on how quickly you catch the mistake, I would stand by my statement or call it an exaggeration. If they're still in training when you catch it, they've probably produced nothing. If it takes longer than that, then they've probably produced something (although if they're contributing enough bugs, it is entirely possible for them to have negative net productivity). But even at best, they're producing less than their salary (why else are you firing them?), so you've lost something.
> This, I feel, is highly dependent on company and codebase.
No arguments here.
> I would like to know what the issues are for a smaller company
From a US perspective, most of the cost is lawyers. It is very easy to say something wrong and end up with a wrongful termination suit, so you end up being very careful, which is expensive in both money and time.
> It seems like the employers and managers here speak of the difficulty in actually getting rid of people, while most of the individual contributors I know are worried about losing their jobs at the drop of a hat.
My experience is that people are worried about being laid off, not fired. Maybe I'm out of the loop, in which case I don't really have an answer to this one.
> if your company is also one of those that complains about how hard it is to find "qualified" people
We're not. We're pretty happy with our current growth rate (recently it's a bit high, if anything).
Maybe this reverses if you're having trouble finding as many people as you want to hire. I would understand accepting more false positives if that's your situation.
To avoid false positives you should ask, "Have you hired people who did interview well and weren't great at the work?"
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.
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...