How to conduct a good programming interview

A commonly mentioned number for application success rates are on the order of 1:100. Even if this process is 10x better, a team will have to welcome a new "apprentice" every month (and fire most of them again) to get a single new hire a year.

This is not obviously an improvement for either employer or employee.

The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose from, and the main priority is avoiding expensive bad hires. The cost of failing to hire a good engineer is small - they can just take the next guy. The cost of hiring a bad engineer is large.

With this in mind, the process makes a lot of business sense. Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire.

This filter does limit your applicant pool a little, but if you're Facebook, the largest chunk of your applicant pool are recent comp. sci. graduates. If they can't solve an algorithms problem reasonably gracefully then that's a bit of a red flag. For non-recent-comp-sci-graduates, a competent candidate really should be able to prepare pretty well in a month or two of spare time.

Facebook might miss out on hires like you who would likely be quite good at the job but aren't willing to put in the effort to prep for the interview, but that's a trade off they'll make happily if they minimize bad hires.

Smaller companies with lower pay and access to fewer qualified candidates would probably be ill advised to copy the Facebooks and Googles of the world though. I'll grant that.

If someone can talk about what approach they took, what other approaches they considered, what made it hard, what made it easy, how often the requirements changed, etc, then I'd rather ask them questions about that then spend the whole time in code. Just do some small spot checks to make sure they aren't taking credit for the work of others.

This was perfect from my perspective, and after I signed the NDA I told them all of those sounded fine. I mentioned that fixing a bug is one of the best ways to get familiar with a new codebase, so I'd probably focus on those, but that I'd like to hear about the rest too. I can probably throw in some of the feature requests or UI tweaks.

That's a bit more candidate-driven than might be expected, but it's really wonderful so far. I feel like I have autonomy, while at the same time they'll get the data about whether I'm effective in the field.

The bias question is important, and I'm not quite sure the best way for us to collectively deal with it. All I know is that there seems to be far more bias in a traditional interview pipeline. One of my recent rejections came after being asked "A hammer and a nail cost $1.10, and the hammer costs a dollar more than the nail. How much does the nail cost?"

Obviously the point of that is to see how you think through a problem. But such problems are useless. They're abstracted from what we as engineers do in the field, and the candidate knows that their entire fate rests on how well they answer that question. Yet those are the kind of metrics real companies are currently using.