I think the problem was really that the author was doing two a week when others were doing one a quarter -- for something that was supposed to be a shared responsibility. I agree that your people are your product, but it is bad management to overburden someone with a task they dislike (though they excel at it.)
Interview loading at Google is very strange. I've been interview-trained for 2 years now, I'm in the interviewer database, my skills are updated, and I set my constraints to 2/week. I've been assigned a total of 3 interviews in those 2 years. Meanwhile I have friends that're in the 2/week club.
I suspect that recruiters are going off name-recognition: there're some interviewers that they know & like, and so they assign candidates preferentially to those interviewers with digging into the database to see if there'd be another equally-qualified engineer.
Many other things work like that too. If you do code reviews quickly, you'll get a reputation as a good reviewer, which means...more code reviews. If you always know the answers to people's questions, it means you'll get more people asking you questions. If you're a UI wizard, it means you'll always be assigned UI work, even if you want to do something else.
The usual way out of this is to learn to say "No". That's how I escaped the UI trap, and I've done it to get out of code review & question overload as well. I suspect Rachel's problem could've been solved by setting her interview constraints to 0/week, which (if done by enough people) would've also forced the recruiters to look further down the interviewer database and find untapped engineers for interviews.
Yea I feel for the OP, basically what I'm saying is about all the other people in her story. The people in recruiting should have been doing a better job on quality. The other team members should realize how important it is to do the screening instead of pretending working on code was more important.
My gut tells me that most likely the lack of quality coming out of the recruiting team was burning people out on teams. If an engineer thinks there is a 1:100 chance the person will get hired and they have to invest 2 hours in each person they'll never bother. If the recruiting focuses on quality and gets it down to less time and higher acceptance rates the engineers might (reluctantly) be more comfortable "spending 2 hours" on a screen rather then "wasting 2 hours".
I'm not sure how it is done in other companies, but I really appreciate the close relationship we have with our recruiting team in Production Engineering at Facebook.
Observing the process sourcers and recruiters go through to improve their quality has been very interesting to me. It takes time for them to calibrate to the role (just like interviewers), and while my Silicon Valley experience amounts to one company, my general impression is that many engineers at other companies just don't appreciate the effort they go through to calibrate to the role, and many engineering departments don't put in the effort to help them get to being great.
While there are occasional dips in quality as sourcers and recruiters try new strategies (maybe going deep on release engineering talent in the games industry in Alabama), I'm willing to accept this because I understand that they're trying to get better at what they're doing - it's just like they don't (seem to) get angry with me when I fail to get good signal on whether a candidate is good or not, possibly because I was trying out a new question.
Assuming that the problem was a lack of quality AND that this is the recruiting team's fault sounds unjustified - I assume that Google takes recruiting seriously and puts at least as much effort into calibrating their recruiting team as they do on calibrating their engineers for interviewing.
The people in recruiting should have been doing a better job on quality.
I see no evidence that they were doing a bad job on quality. They do as good a job as they can. But recruiters are fundamentally unable to evaluate technical skills. The OP would be the first person that interviewee talked to who actually could judge technical skills, and her job was to be a rigorous filter, to remove the egregious candidates.
The other team members should realize how important it is to do the screening instead of pretending working on code was more important.
That part of the process was not being criticized here, but I would agree with it.
If an engineer thinks there is a 1:100 chance the person will get hired and they have to invest 2 hours in each person they'll never bother.
Trust me, engineers are made aware of the statistics. But it is one thing to see them in abstract, and another to look through all of the candidates that you, personally, have talked to.
