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.

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.

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

> 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)

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

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!

It's more like different subsets of HN will complain about each and there's no one size fits all solution. What interviewers should do is take that into account.

Github resumes are great for some people who like working on OSS stuff but horrible for others who can't share comercial work and want to have a non-coding life outside of it.

Take home projects can be terrible if they're too early in the hiring pipeline and also exclude anyone currently working full time.

Whiteboard questions are mostly terrible because of nerves and poor input methods, at least do it on a laptop connected to a projector, then it's acceptable for some people.

The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions.

"The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions."

Right on.

For me the irritating part is, I haven't encountered any other professions where the interviewee has to "prove" themselves with this kind of nonsense (isn't that what the resume and references are for?), especially over and over again in the case of consultants and frequent job hoppers - it gets tiring and I avoid companies that try it now (unless it's a small trivial application/test).

I can understand it to a small degree, given the nature of software development. I wonder how other professions would take it - "Excuse me Sandra, I know your resume says you're an electrician, but I'm going to need you to wire up this house so I can just check". I'm sure some other professions do do this, but none I've heard of.

Sure there are plenty of other professions. Pilots being the first one I can think of, as they require some type of checkride (flight exam) which will include an oral examination by the instructor/interviewer. And they don't get paid for taking that checkride.

Professional musicians have to prove themselves in auditions, CPAs, auto mechanics (good ones at least), etc. The list goes on.

Professions like pilots, doctors and CPAs are bad examples because they have a certifying body that exists outside of the relationship between employee and employer. It's true they're not getting paid for that certification, but once they have it, it's valid and transferable between jobs.

Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition.

I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?

I assume you've never conducted interviews, am I correct? There are so many "developers" out there that simply can't code, regardless of what their CV or education says. 15 years experience with Java development as a senior developer but doesn't know integers have a limited size (never heard of BigInteger), knows a hash map is used for key-value but not what hash means nor what the point of an interface is? Sure, I've seen that candidate. There's just so many terrible developers that you pretty much have to do some extra filtering to weed these out.

A short technical screen to ask those things is reasonable. My post was originally about unpaid projects, although the discussion around interviewing in general has been interesting.

I wouldn't expect to get paid for a 20 minute tech trivia screen.

So much this. I give people options of many interview workflows as I don’t care... I need some way to test and make a discussion about it. I want you to succeed more than you half the time! I’ve still seen failed candidates go on social media and complain that they’d rather do X when it was a freaking option. Entitled little twats

kudos for giving options; too bad the candidates didn't appreciate that. once they spend some more time in the wild, they might!

There's a bit of missing info in the OP: how much time is this project expected to take? If it's literally 2 hours or something, then fine, don't pay me. If you want me to spend 8+ hours developing a polished looking site or a standalone API, then I'm probably not going to do your interview unless passing the test gets me straight to the offer stage.

Roughly speaking, I can get to an offer decision after:

1 recruiter call (20-30 minutes, usually, pretty softball).

1 or 2 phone screens (30-60 minutes apiece, generally).

1 day onsite for 4-6 hours.

If you're going to demand much more than that amount of time from me, you have to offer something compelling. The definition of "compelling" varies depending how much I think I need a new job.

The most recent project I did last week was 3 days. Three unpaid days, and in the prompt no time limit per day. It's for a company that is top 10 most valuable startups in the world. Do you tell them you won't do it..? How long do you work on it? Open ended. I actually like what I made but I would normally charge thousands of dollars for it. It's so frustrating. Haven't heard back yet but regardless it's not a good process

Yes, I tell them no thanks and give them my reasoning. I would rather work for a public company that pays real money (like the company I work for now) than a startup with paper equity, anyway.

Google does it too, I've done projects for them the same way. Good on you for sticking to your principles though. If everyone did maybe it wouldn't be so commonplace. Not everyone is in the situation to refuse. Thanks for the viewpoints.

I have serious ethical issues with working for Google, so that would just make my decision easier.

Just an example of a publicly traded company that I've seen do it (and if the top ones do it, then the other thousands of companies do too).

What's this ethical, publicly traded company you work for that doesn't do BS interviews? I bet they'd get a lot of inbound if they made that known.

I like Basecamp's approach of not having live coding in the interview. They discuss past projects and you walk through some code you're proud of or think is interesting.

1. https://m.signalvnoise.com/hiring-a-programmer-ditch-the-cod...

2. "... you’ll submit some code you’re proud of, review it, and tell its story. Then on to an interview. Our interviews are one hour, all remote, with your future colleagues, on your schedule. We’ll talk through some of your code and some of ours. No gotchas, brainteasers, or whiteboard coding." from https://apply.workable.com/basecamp/j/F2CB808F33/

edit: spacing

Until you run into the guy who literally cannot code. I'm not talking hard algorithms either.

Then you fire them.

This - California is an at-will employment state. Given that, you'd think hiring and firing would both be quicker. Literally any reason that isn't illegal. So why are there so many barriers to being hired if I can be fired at whim?

Currently cargo-cult fashion.

This seems decent, except for the “submit some code you’re proud of“ part. What about applicants whose only jobs have been on proprietary code they can’t share? This is the same problem as using GitHub resumés: it’s kind of unfairly biased against people who either don’t work on open source projects, or like to have a life outside of coding when they’re not on the job.

That sounds like a good case for paying someone to do a project for you (if they're employed, give them an 'hours' budget over a longer 'days' or 'weeks' period). Then you'd have something to look at that they just built, fresh.

It's easy - let the candidate choose what works best for them.