[cramey]

I can tell you what's worked for me when hiring experienced programmers:

Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview.

Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job.

The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.

[Shaanie]

The problem with talking about previous projects is that it can be hard to tell whether the candidate was an important contributor to the project or just a subpar developer making the changes (s)he's told to do by more knowledgeable teammates. A candidate which is charismatic and good at talking can be quite convincing.

Provided code samples is good, but only if the candidate has written all the code themselves and isn't just passing off other's code on a project as their own.

When I was conducting interviews I was frequently surprised by just how bad some candidates with fancy titles and a decade of experience were at actually coding. And I mean things like a understanding a simple recursive function, integer division, inheritance and other core concepts. I would never hire someone without at least a brief code comprehension check nowadays.

[mixmastamyk]

The problem is you’d probably do just as poorly under the gun and away from your subject of expertise.

[2rsf]

> Ideally the candidate offers code samples

Code samples are not like blood or urine samples, you should have serious and public projects to sample from.

Many great programmers are not coding outside of the work environment, what should they provide according to your method ?

And for those who do, they can explain things but you can never be sure they actually wrote it or will be able to write at a similar level (well, that's partially true for take home tests as well)

[_throwawayyyyyy]

People lie about their credentials in every profession, why do you think in tech you're going to somehow be able to stop that?

[_throwawayyyyyy]

Your process sounds awesome. It's definitely the exception to the rule. It would be great to drill down and speak about the parts that are interesting in projects I've done. Maybe a paid project makes sense for your example of someone without an available codebase to share. Good luck!