1) Resume screen
2) 30-minute coderpad/codeshare exercise on a problem/pattern you actually use/encounter during the course of your work over phone. (No inverting binary trees). Expect a 20% pass rate here.
3) Reasonable take-home problem that you've timed 2 of your own staff completing well in 50 minutes. This is where you will get the most complaints from applicants, but that's OK. Let them select themselves out of the process. Expect a 30-40% pass rate here.
4) In-person interview. At this point, you should be mostly committed to hiring the candidate. Do a couple livecoding deals, but be extremely lenient in how you interpret results. Other week, we had a candidate fail the problem, but they kept their composure and showed they knew what they were doing on the way to bombing the problem. Candidate seemed sad at the end of the interview and happily surprised when we extended an offer.
IMHO this process works fairly well and does a good job of being economical with people's time.
I'm curious about the codepad/codeshare approach right at the first touch point. I fully agree that screening actual tech skill early on is important. Do you not find that you commit a lot of engineer time to codeshare interviews that don't work out further down the line?
Codeshare portion is 1 (typically senior) engineer for 30 minutes. Not that bad on a large enough team with everyone taking turns. I should add that we have 3-4 "canned" questions that the HR rep writes down the answer to, so even in the "resume screen" there are a few super-lightweight technical questions.
Interesting. I've got a feeling early stages of tech hiring pipelines are very poorly optimized at the minute; it's something I'm working on. Individual experiences help; thank you.
Another idea I've heard about but never got motivated enough to set up is a system wherein the applicant submits their resume via an api with some kind of trivial challenge... like "here is an id and an integer, multiply it by 2 and submit it with the id and your resume as a json with these fields or whatever." Might try it some day, but that's another idea to get some of the technical probe out early.
There's a company, I think it's Mythic Beasts in the UK, that has or had a job application that had something along the lines of (before you got to the form) 'first prove you're not a robot do this simple maths blah...' but every time you submitted your answer, by typing in and clicking on the page, you got an error page saying 'too slow'. I wasn't looking for a job at the time but that has to easily be my favourite application process ever!
IMHO this process works fairly well and does a good job of being economical with people's time.