How to conduct a good programming interview

Is the candidate someone we would enjoy working with?

All of these can be solved directly by asking the candidate if they'd be comfortable doing an actual task on the actual codebase, having them sign an NDA, and then giving them a bugfix to perform. They're compensated for their time, of course.

I'm doing it right now as a candidate and it's by far the best interview experience I've had. The others were all artificial.

A lot of people have a problem with this model for one reason or another, but in terms of effectiveness it's probably at the top 1%.

However I'm shipping scaleable API's used by web and native apps, using Continuous Integration and Deployment on an AWS infrastructure that I set up myself. Furthermore I'm responsible for hiring developers that I work with on agency projects and most important of all getting projects delivered within time, scope and budget AND getting paid for it. Yet I would fail most technical interviews.

I've been doing this for about 10 years and never ran into any major problems. I've worked both as a freelancer and in-house permanent dev and never had any complaints about my work. (Feedback and improvements yes, big failures never). Yet I would fail most technical interviews.

I talk directly to clients and vendors, I sell projects, I take over projects, I end projects and I've created 2 startups, one of which I sold but I would definitely fail a purely technical interview.

I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense.

At a previous company I worked for the team almost crashed & burned because of the TL's focus purely on technical skills. No code was being shipped but hours of meetings and Slack conversations and discussions on PR's for no good reason about 0.01% improvement gains.

I know I'm not the best developer out there and never will be. Often I'm in awe of the technical skills of people out there but I rather have a less skilled dev with great "people & shipping" skills as I call it than some of the people that would pass all these tests but that I couldn't put in front of a client or even let them email a vendor.

My personal experience with this style of interview was that it really helped me to personally demonstrate my abilities. I was interviewing at a startup in San Francisco in 2012 who wanted me to do a quick version of "battleship" as part of their hiring exercise. I proposed, mid interview, "how about I help you solve a performance problem with your current system. What's your biggest issue right now?" My interviewer actually showed me, and we ended up solving the problem together and then deploying out the change.

The funny thing about that experience was that when we were done improving their platform, the VP of engineering was told what I did, and then had the interviewer go back and do the battleship exercise anyway. They needed to "benchmark" me against other candidates, and the only way to do that was with a consistent "test". I did far more poorly with the battleship exercise than I did helping them on their platform.

However one thing I'd point out is that this guide still falls far short of being a good guide for finding engineers. Particularly noteworthy, in my opinion, is that the measurement criteria are still applicable only to the coding question itself. For example, "how well the candidate manages time" still applies only to this limited 40-60 minute question. It doesn't really help evaluate how the candidate might consider prioritization of tasks (implementation or otherwise) in a broader, bigger sense.