I also was in charge of hiring programmers at some point in my career. I made it a point to give programmers a simple project to take home and get back when they where ready (at most a week). The project was very close to what the hired candidate would be doing if we chose them.

I told the candidates that they did not necessarily needed to show me a working application (although that would have been great!), but simply to document what architecture, language and approaches they would use to implement the task.

Also the task could be documented in a few hours, and those that got close to coding a few classes might have spent a day at it. Now the argument could be made that I did not remunerate this people, but keep in mind the work they did was not expected to be more than a few hours.

For me, this is an ideal technical interview. Also, I ended hiring a candidate though this method, and he is by far the most productive and creative force in our team.

And how do you know that they did not farm it out to rentacoder.com?

Remember, I did not ask for an implementation. Only a document with their thought process on implementing it. Also, they can use whatever means they like, if we hire them we will quickly find out if they are incompetent. No interview system is fool proof, of course.

How fast could you then fire them? How much money wasted on that and onboarding? Compared to the risk of missing out on that one person who cannot whiteboard but is otherwise brilliant? Quite a gamble.

"Tell me about that one time you solved an interesting problem?"

I agree if that was the only thing you asked, you wouldn't get a good answer. However, if you then dug into their answer you can probably tell if it is BS or not.

I remember having this exact experience with a junior dev who claimed to worked on some interesting projects at Uni, but when you dug deeper, you realised he knew very little about the technology he supposedly used.

That said, my company isn't really interested in hiring people who can code an algorithm to balance b-trees. My company just need people who know how to ask questions, write maintainable code, and use a profiler.

Worked with a guy once who was a pro at this. Every day he did nothing, but when higher ups asked the team what was done and how, he managed to take credit and explain how things worked well enough to convince them that he had done it all. The rest of the team was not amused. Just listening in on a team (while adding nothing to the code or discussion) might be enough to go into great depth in such a discussion.

What makes you think a bullshit artist that good a) doesn't actually know his shit well enough and is just lazy and b) won't pass your technical interview by either actually knowing enough or absorbing enough test prep material?

Also, how common do you think these people are? IMO, not common enough to design an interview process around. Then again, I don't subscribe to the "one bad apple will torch the orchard" paranoia popular in this industry.

Give each team member a different assignment - this should avoid the mentioned problem.

> "Turns out that the only sure way to tell if you can do X, is to make you do X and watch you yourself actually do it, in person"

I don't write code on whiteboards for a living, nor am I applying for a job that will have me coding on whiteboards, so watching me do that will tell you almost nothing about the job you're actually hiring me for.

I agree it is not ideal, but the counterexamples I provided do explain why other suggested methods are too simple to fool.