Seems like the standard 2 phone screens + 5 onsite interviews.
My story was - getting interviewed by progressively more senior folks with positive feedback on the spot from whoever I was talking to. So then finally after 4 rounds of technical interview calls I get to talk to the hiring manager who is telling me something along the lines of "the feedback has been awesome BUT we didn't expect to find someone this fast and now need to wait till the next hiring cycle".
1. look at resume
2. recruiter phone screen, just basic are you a human who knows how to answer the phone, usually 15-30 minutes
3. tech phone screen, 45 minutes
4. half-day in-person set of interviews, some tech and some not
And then make a decision, although we'll filter out at each step.
It's been forever since I was involved in on-site interviewing but it used to be pretty standard to have more than one (but usually not more than two) rounds of in-person interactions.
The point being:
A) avoid "having a bad day" bias on both sides
B) not decide too quickly on the "maybe" candidates
C) get more senior people in to convince the outstanding ones
Any strong "don't hire" reactions could cut this short of course but it seems like a good idea to give it a little more time for a serious candidate.
Is that not done anymore, or are you trying to make your hiring decisions faster than other companies?
(And in either case, do you have any insight as to why?)
Since it's a buyer's market for developers (supposedly, I haven't always seen evidence of that out here in the midwest), a developer that's already employed (and thus, signalling that they're good enough to keep their job, which makes them more desirable to other corporations) isn't going to want to take a bunch of time off for interviews with a single company (especially if they're actively looking for work with other companies too - going through the process with 4 or 5 companies could easily eat up most of my PTO time for the year).
I know I hate to take a PTO day for an interview, and if you made me take two you better be willing to pay me an ass load of money and be doing something I really want to do.
Besides, the interview process is exhausting enough. Since so many companies have intense coding exercises or quizzes you have to practice for (especially since they rarely warn you what you're going to be asked you pretty much have to refresh your entire computer science degree), I may have spent 20-30 hours in my spare time refreshing my knowledge ahead of the interview already. I had a five hour intense onsite interview at Google and I needed a couple days just to recover from the mental exhaustion of it. If I know you're going to do that to me twice, for maybe a 25% chance of getting the job (assuming a handful of other good candidates), I might just not bother altogether.
My girlfriend is going in for her second onsite interview in a couple days, but she's in corporate real estate, and all she had to do to prepare is get dressed and make sure she had her portfolio. The first interview they asked her a bunch of personality questions, some questions about her job history, and looked at her portfolio. If that was as intense as a developer interview was, it wouldn't be AS big of a deal to have two onsites.
Flying someone in twice probably only makes sense for higher-level positions, though you could always schedule two days of interviews on the same trip. Having already paid for the flight and expenses, you could make an argument for it that most flown-in candidates would I think accept.
(For local candidates, AFAICT the "doctor's appointment" or similar excuse seems pretty easy to manage.)
As to the exhausting Google-style interviews, I guess they're designed as a one-pass filter. Which seems unfortunate -- many people are more compelling on the second pass -- but apparently works pretty well for giant ad brokerages that also happen to do lots of computer-science-y stuff.
My favorite interview, in fact, was one were a grizzled veteran (he was the Lead Programmer on NBA Jam), asked me a couple questions on the code sample I brought in, showed me an example (uncommented) class from their actual code base (I verified later) and asked me to interpret what it's doing, asked me a couple more questions, then said "Okay, I know you can handle the job, now let's see what you really know."
And he proceeded to ask me deep questions about memory and graphics, which I could only partially answer most of them, and then he proceeded to teach me about the details.
It felt more like a mini-lecture at that point than a pop quiz ("Do you know this? No? Well tough! Better look it up later. Next question!"). I legitimately learned things from that interview that I can still recall today.
Then I had a friendly chat with the president of the company afterwards, who used to work for Midway and designed many classic arcade games, most notably Rampage, about what they do at the company. I played that game a ton when I was a kid, so I was happy just to be chatting to him like we happened to run into each other at a family BBQ.
I was in and out of there in about an hour, and there wasn't even a weed-out phone screen.
Then I got a job offer a few days later, which I ended up accepting.