[hagmonk]

So I tried a new approach inspired by this kind of interview question. In a nutshell: it aims to simulate the interactions you'll have with the candidate when they receive their first project, without the time burn of a full pair programming day.

1) determine the system the candidate will design. It should be an internal system or an internal oriented problem, not an external thing like Monopoly or URL shortening services.

2) stack your interview team with a mixture of people who can contribute different thoughts to this problem. Engineering, UI, marketing, management, etc.

3) first interviewer of the day introduces the topic and helps the candidate understand some of the internal lingo and bootstrapping questions they'll have right off the bat. The first interviewer is pretty crucial because the candidate has to be prepared to write things down and carry information across each interview.

4) all subsequent interviewers come in and ask two questions:

* What problem were you given to solve?

* I'm an expert in technology / business area X. How can I help?

By the end of the day when they're having their likely optional interviews with more senior people, they should look disheveled but pretty happy, because now they're pitching to senior management an idea they collaborated on with a wide variety of team members.

They should have a whiteboard full of stuff, stacks of paper, whatever. You should get a good idea of how they organize themselves under pressure.

The interview team should have a good feel for how the candidate leveraged them for answers. The interviewers should have done a lot of talking! There should also be clear evidence of the candidate getting better towards the end.

At the conclusion they're tasked with taking a step back to the higher level to explain the idea to management - regardless as to whether management is technical or not, they should be expected to walk away understanding the big picture. Having non-technical "business" people contribute to the interview is critical, since they help the candidate understand some of the human requirements.

I could go on and on, I'm pretty excited about how this technique has worked so far. The key element is deliberately having the candidate carry knowledge between interview teams. I'm sure I'm not the first person to think of this :)

EDIT: styling

[Stratoscope]

Thank you, that sounds like a brilliant technique!

One question: Do you let candidates know ahead of time what the interview process will consist of? That sounds like an important step that many companies leave out - whatever interview process they use.

I think if I knew before arriving that this how it would work, I'd be a lot more excited about the interview and better prepared too.

[hagmonk]

Yes, the candidate should know in advance if there is a particularly structured interview technique being used, for sure.

Because it also requires a lot of mental commitment from the interview team as we'll as the candidate, I'd recommend using this technique as the final hurdle. I don't think you want to phone screen someone, then just toss them into this process. You need to have them cross some basic technical gate (like FizzBuzz, a take-home coding project, whatever), and have them meet a handful of people first, just to make sure they pass those early smoke tests.

In fact I think this technique works best when you want to seal the deal with a very strong candidate who is entertaining several options. Interviews should always be a two-way process, and if a candidate walks away from your interviews thinking "I had real trouble getting my point across to those people, I would never work there" then that represents success for the interview process.

The strongest candidates tend to be the ones least influenced by money and more interested in the problems, the people they will be working with, the culture and the environment of the organization. So having your interview process structured around revealing that gives you the best possible chance of matching your team with people excited to be there.

Conversely if you're a candidate, even if the company you're applying with doesn't seem to have thought too deeply about this stuff, don't despair. Hiring is one of the hardest things to do and also tends to be done by the seat of the pants (Amazon seems like a notable exception) You can impose your own structure by asking the right questions and making special requests of the recruiter. Tell them you want a chance to write code with someone! Or that you want to mock up a UI that solves a problem they have. Or you want to see what their strongest engineer thinks of your design for this service you've put together.

It doesn't matter if you're desperate for the job, or whether you wish they'd stop calling you ... this kind of stuff makes you stand out in the crowd as proactive and motivated by the right reasons.

[Nocturnographer]

What company do you work for, out of curiosity? I absolutely love this idea; I would be extremely impressed if I showed up for an interview and this happened.

[hagmonk]

Were you to do some spelunking you'd probably find http://goo.gl/vZdTyh (sorry for being oblique about it :)

[discardorama]

This is probably doable if you're interviewing 1 candidate a week (or one in 2 weeks). Most tech companies run through several candidates a week; and finding engineers/designers/managers who will play along with your question will be very difficult. I've been to interviews where they didn't know I was coming that day; where interviewers failed to turn up; where wrong interviewers showed up; etc. etc.

Basically, interviewing is a clusterfuck. :-)

[hagmonk]

I know where you're coming from there. It depends on the company. I think hiring is the most important thing a company does, so it's really critical to get everyone wanting to participate. I'd suggest that most push back folks get is because people generally dislike having to interview - they are tired of meeting lots of B grade candidates and even a few hours a week feels like a drag.

Having said that, there are ways to offload. There's a biotech startup (I'd have to dig for their name, I remember they did all their coding in mathematica) that described their hiring process to me. Hopefully I'm not messing up the details too badly.

I recall one guy who went through it said it was way more stressful than his final year university exams. They tested candidates, all candidates, on physics, math, chemistry, biology, computer science, and more. Candidates were given projects in each area, and a week to complete all of them.

It was deliberately structured so that there was no possible way that anyone could humanly complete the entire set of tests, much less while also working a full time job. This was deliberate, so that they could observe how candidates chose to prioritize. They also wanted to give people more than they could do to stimulate a "by any means necessary" approach they knew would be required in the actual job.

Finally, it also caused a lot of people to say "erm, no thanks. That's a ridiculous amount of work", which they rationalized as being a good test for candidates who saw a mountain of work and then baulked.

Not sure if I'd use a technique like this myself, but I found the idea interesting!