B) for sure. i haven't had that used as an interview technique on me, but i've been on the interviewing end of that, and the feedback from the candidates was great. additionally, we felt it gave a great sense of what it'd be like to work with them, and based on the people we've hired so far using pairing as a component of the interview, it's a better predictor than anything else i've ever seen.

we also ask for a presentation on prior work or a prior project, we do some architecture whiteboarding, and we have talkier personnel type parts. but currently, the hour and change pairing exercise is the only programming exercise, and we were happy enough with the results last summer that we're doing it again for an upcoming round of interviews. our setup was a PM, a tech lead, and a "driver" (the person at the keyboard, which is what i was in the exercise). interviewee is the "navigator" (and by not having to type, we get rid of some of the stage fright for syntax errors and such, and just get to see their thought process since it's a pretty compressed timeframe). best microcosm of real work i've seen. one important thing is to give the same exercise each time (one possible risk in our case was that we gave the candidate 3 possible things to choose from, but settling on what we thought was the best choice was part of the test, and all the candidates ended up passing that part, so we never had to compare WIP from two different coding exercises).

apologies for rambling or repetition, dashing this off before i go to bed. but i'm a big fan of this interview approach, and i think it's probably the best thing we've hit on so far in this field, for positions where that would be a reasonable microcosm of what day-to-day work is like. i think it's much better than making someone code on a whiteboard, or giving them a take home or solo exercise, because you get so much more info about other things besides how well they can bang out a single well spec'ed piece of code.

If you're asking for C with 4.5 hours of work (as per example above) that's fine if you're paying for their time.

Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".

We used to do C for open source stuff that we contributed to at our organization. Seemed like a good comprise because it isn't a completely futile exercise for the person going for the job.

> Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".

Does it? If I have a developer job then I'm paid well and don't really care about the money which I have enough of, I care about the time which I have very little of.

If you're in the top 0.01% of companies to work for (and the applicant knows that) then it's probably a worthwhile time investment, but for the other 99.99% it's a waste.

If you are interviewing with a company, asking you to spend time in exchange for money is reasonable. If you feel you are above that exchange, personally, that is an effective filter for a potential problem employee.

> If you are interviewing with a company, asking you to spend time in exchange for money is reasonable.

These tests are typically a pre-interview step and they don't really work well for much apart from that. So at this point I'm not interviewing with the company and all I know is that they have an interesting job ad. Considering how far from reality job ads can be I'm not going to waste hours based on one.

If C should be paid for, then should A be paid for as well? If not, why not?

In A both the interviewer and the interviewee are giving a similar amount of time. In C, only one is giving time. To compensate, the other should give money.

In C the interviewer is also spending time reviewing the assignment. Maybe not the same amount, but if you also have a handful of your current devs review it and give their feedback, the company time spent on it might not be trivial.

Also there is usually more than one person sitting with the interviewee when they come in, so the company time spent is multiplied at that stage.

100% I prefer B. I'm happy to walk through code with someone, open source preferred, and show them how I'd go about changing it.

The idea of using a whiteboard to do software engineering is like asking a cellist to use writing to play Bach.

I would go for pair programming.

The danger with pair programming is you easily get a partner who sees the activity as a competitive exercise / dick measuring activity* , and some engineers find enjoyment in proving to everyone else (including new hires) their superiority.

*excuse my language, but it is the most accurate description I could come up with.

i'd posit that if an employer can't find a decent pool of current employees to potentially pair program with an interviewee, they have deeper problems than getting that upcoming interview right, and need to correct for some past hiring mistakes ASAP.

i would definitely be looking for employment elsewhere if i my co-workers were so unpleasant that i thought they'd turn every pairing session into a pissing contest (and i say that as someone who generally prefers solo programming as far as immediate enjoyment goes, but who finds that pairing is often useful and/or necessary).

And then you know that employer has issues and to avoid them.

Yep. Exactly. Pairing is a two way street.

That's actually another reason why pair programming is good: The interview is just as much a signal to the candidate as it is to the employer. If the developer he's pair-programming with is a douche, it's a good sign for the candidate to run and not look back.

Idiots have a negative impact on any type of job search. I have been in interviews where I showed a valid solution for a problem but failed because it wasn't exactly the one the interviewer wanted. On the other hand if I did pair programming with somebody and it worked well this would be a strong indicator for a healthy comonay culture.