Hacker News Reader

I like your ideas, particularly collaborating on problems and giving candidates the ability to control their environment while problem-solving (such as giving them a week-long assignment). We've had good luck with the latter, and it's provided several valuable employees who, frankly, would probably not have passed a "live" interview.

Another tactic we employ is to keep the technical interviews very conversational. Rather than asking a very difficult question and putting the candidate on the spot, we try to talk through problems and do an over-the-phone "white board" session. We like to choose problems with many answers; some of these answers are easy to arrive on, while other explanations may be trickier. The candidate gains confidence getting the first part of the question correct, and seems to be more at-ease while completing the more difficult tasks.

There's no way that we can completely cut out the stress of a technical interview--no matter what, it's nerve-wracking to put your technical capabilities on the line--but it doesn't need to be a belittling, terrifying experience like the ones we so often hear described.

I agree wholeheartedly. To put it another way:

My first few gigs during/after school, the interview was one of the hardest, most stressful parts - the actual work tended to pale in comparison. The interview rarely seemed to have any tangible connection to the actual work being done, either; it was essentially like some sort of bizarre hazing ritual where I proved that I had what it took to be an employed professional, or something.

At this point I've done thousands of phone screens and hundreds of in-person interviews over my career, so that stuff doesn't get to me like it used to. It's much easier to disengage and ignore all the high pressure tactics and shitty interview questions and bad interviewers and just write it off. Given that, I could probably easily end up doing the same thing to candidates when I'm interviewing them.

But I shouldn't! Because oh my god, those first few dozen interviews were emotionally and physically exhausting. Every single one left me a nervous wreck regardless of whether it went well or not. That shit simply isn't healthy; why would I ever inflict it on someone else?

'High pressure' tactics are probably the worst in this regard, out of all the things that go on in interviews. I've dealt with a few places that went with tactics like verbally abusing candidates during interviews, or making a subpar offer and giving the candidate 24 hours (or less!) to decide, in the hopes of getting them to panic and take it. One place had their recruiter call me up at 7am and verbally berate me for turning them down! Fucked up shit.

One thing I consistently hear people complain about is whiteboard coding. Nobody likes it, everyone finds it stressful. Note that the actual task of coding in an interview isn't something I hear everyone complain about - just doing it on a whiteboard, specifically, vs doing it as a take-home 'programming test' or in a shared etherpad or something. Maybe at some point in the future, eventually our industry can phase out the whiteboard.

Aren't the high stakes the fact it is for a job?

The problem with interviews is that you have to make a decision and the candidate may not be themselves regardless of what you do. They may freeze up in a collab. Or collapse on a take home or be overly stiff doing a 2 month contract knowing the job is on the line.

I personally think technical questions are useful. Not hard ones, but softballs. It is never used to say someone is a hire, but is a requirement.

Who cares why the stakes are as high as they are? They're confounding the results of the interview process, which means they're the employer's problem, whether we like it or not, think it's fair or not, or whatever. The fact is that "we", as an industry, have a counterproductive habit of screening candidates for "ability to gracefully metabolize semihostile job interview experiences", which turns out to be not all that valuable an employee attribute down the road.

That's not an industry problem, it is a society problem where people need jobs to eat. Until you fix that problem, everything else is just dancing around the problem.

I interviewed a guy at a movie theatre 20+ years ago when I asked if he liked movies. He started sweating... And eventually said he had to cover medical expenses for his son and he was running out of time. He needed to work and would do what it took.

Until you fix the stakes, all you're doing is changing to another interview form that someone else will freeze up on.

I'd love more ideas

I'm not hiring any programmers at the moment but if I were, I'd probably hire high-level people by sitting down with them to discuss some piece of open-source code they've written. I'd take a few hours before the interview -- again, assuming the position is important enough to justify it -- and familiarize myself with their publicly-visible work. At that point the 'interview' can just be a casual conversation over lunch -- a two-way one, at that.

Lower-level people with less experience? I don't really know how I'd evaluate these candidates. I might have to fall back on grades/employment history and the dreaded Fizzbuzz-on-the-Whiteboard routine.

But that's probably OK, because the higher-level people are the ones where you really need to get the selection process right the first time. One fresh-faced college grad is just like another, presumably, unless s/he has taken steps to stand out from the crowd by contributing code to the community. At which point I'll treat them like a higher-level interviewee, and we can skip the Fizzbuzz stuff.

> You can take deliberate steps to lower the stakes in your interview process by changing the kinds of transactions that happen in the interview (for instance, by constructing interviews that involve collaborating on a problem instead of challenging the candidate).

If you want to evaluate all candidates on a level playing field, this can be really hard to pull off.

I work in the defense sector. We have some pretty strict guidelines on how we're supposed to evaluate people. Because of those guidelines, we often try to give each batch of candidates the same general set of questions/challenges, etc. We do try to be collaborative during our interviews, but it's really tough to collaborate without leading when you've worked a particular problem 1,000 times.

Further, even when you do this well, the candidate often interprets your help as their failure. "Oh crap, he pointed me in a different direction, he must think I'm an idiot."

> You can push more of the recruiting process into situations where the candidate controls their environment (for instance, by doing stuff at home, and on a fixed but flexible time scale) and less on in-person timeboxed interviews.

I think this is really key to our success. Our interview focuses on two programming problems which require you to interpret imperfect requirements, ask questions if you deem it necessary, provide an estimate of when you think you'll complete your work, code/document/test two full applications (one per problem). We ask the candidate to do this well before the interview, on their own time. Typically we don't discount for how long it takes a candidate to complete their work. I've had awful submissions which took someone 40 hours, and excellent submissions which took someone 4 hours, and vice versa.

The problem is real. For many jobs that don't require working with strangers, it is unrealistic to the work required to be able to perform under stress in front of a stranger. I think this may be an introvert/extrovert issue.

There are many solutions, but a couple that come to mind are also imperfect:

- Exams: They seem fair, but reflect the bias of the exam writer, have legal (discrimination) implications, and don't show what's relevant to the job.

- Take-home work: This is closer to real work experience, but can be fudged too. I know someone who landed two jobs based on take home work that he paid someone else to do. It's also someone who visibly cheated in school, so it's a pattern of behavior. Despite being the OP's favorite method, it's still imperfect.

The only things that I've seen work even decently (but still closer to 50% than 100%) are word of mouth recommendations from trusted advisors, and internships. But how to judge potential interns makes this sound like a recursive problem...

Totally agree. One more thing I'd add is: tell your candidates up front what to expect of the process. An overview after first contact is nice, but interview-day schedules specifically seem to help alleviate the jitters. We've started giving candidates a schedule with names and rough content before they arrive: 10a-11a - pair programming on a TI Launchpad with Jerry; 11a-12p - planning and organization exercise with Sam; 12p - group lunch; etc.

I'd also humbly request that employers hurry up and tell a candidate that they're no longer in consideration for a position as soon as that's decided. It doesn't have to be a involved production — a minimally polite two sentence e-mail is all that I ask.

As a job-seeker, getting strung along or getting the silent treatment after interviews is the worst thing in the world, especially if the candidate really wanted the job and/or has other opportunities on the table.

One thing that helps is to think of yourself as the interviewee while you interview the candidate. While you would have a better picture of the open position, still imagine the candidate asking you questions backwards within your mind. This helps in making sure you are not testing the candidate just on your own experience.