I do worry about that as well, but that's a much more difficult problem as people's opinions can be damaged by so many things along the way. What works for some people[0] is a disaster for other people. The 'disaster' nature of it can come down to not liking to be on the phone, needing answers more quickly than Google can provide them[1], or just ending up with a bad interviewer on their loop[2].
Those are much bigger issues, and there are people here trying to tackle them! I feel my effort can be best dedicated to making sure I conduct the best interviews possible. I start from by assuming my goal is to get the candidate to demonstrate the competencies we're looking for in whatever way possible. Yes, there's usually some coding. If the coding turns out to be a bit rough but the candidate can do a fantastic job of walking me through a previous project, it's design, what went well, what they would change about it now, that speaks very well of them. I can't claim they demonstrated fantastic coding, but I can claim that I think we should hire them anyway and justify that recommendation.
It's hard. I would like our process to be lighter weight (or at least, better weighted to individual candidates), but I recognize the importance of maintaining a small false positive rate. I work with really rock solid engineers, and that's one of the best things about my job. I can trust everyone around me to at least make good decisions (even if they're sometimes wrong, or they're sometimes not the decision I would have made, I can usually understand how a smart capable engineer would have made it).
[0]: My process was roughly as follows: phone screen (all technical, coding in a Google doc), on site ~3 days later (five interviews coding on a Chromebook, lunch; the usual mix of interview questions you've come to expect), offer ~5 days after that, mutual acceptance after negotiation ~3 days after that. So we're talking about two weeks end-to-end. Also, I actually really enjoy interviewing. I come out of a day of solving interview questions feeling invigorated. Like I said, we do a really good job of hiring the sort of people who already work here.
[1]: Some of the things that I think are very good about Google's process (particularly in terms of providing fairness across candidates in a way that my previous employer did not) also cause delays. A lot of effort goes into considering all of the data that's available on a candidate. The amount of discussion that goes into every candidate, even after all of the feedback is in, is staggering.
[2]: Remember that interviewers are people. We've all been told that we're representing Google, but some people take that responsibility more seriously than others. Given that interviews are typically conducted 1:1, nobody knows what happened in the room except for the interviewer and the candidate. When candidates have bad experiences, they don't necessarily report it to their recruiter, so if it's a systematic problem with a particular interviewer, unless it shows up in the feedback they're submitting, it's very difficult to detect and correct. This is really unfortunate, but of course putting two people in the room makes some candidates nervous as they feel they're being doubly judged!
Those are much bigger issues, and there are people here trying to tackle them! I feel my effort can be best dedicated to making sure I conduct the best interviews possible. I start from by assuming my goal is to get the candidate to demonstrate the competencies we're looking for in whatever way possible. Yes, there's usually some coding. If the coding turns out to be a bit rough but the candidate can do a fantastic job of walking me through a previous project, it's design, what went well, what they would change about it now, that speaks very well of them. I can't claim they demonstrated fantastic coding, but I can claim that I think we should hire them anyway and justify that recommendation.
It's hard. I would like our process to be lighter weight (or at least, better weighted to individual candidates), but I recognize the importance of maintaining a small false positive rate. I work with really rock solid engineers, and that's one of the best things about my job. I can trust everyone around me to at least make good decisions (even if they're sometimes wrong, or they're sometimes not the decision I would have made, I can usually understand how a smart capable engineer would have made it).
[0]: My process was roughly as follows: phone screen (all technical, coding in a Google doc), on site ~3 days later (five interviews coding on a Chromebook, lunch; the usual mix of interview questions you've come to expect), offer ~5 days after that, mutual acceptance after negotiation ~3 days after that. So we're talking about two weeks end-to-end. Also, I actually really enjoy interviewing. I come out of a day of solving interview questions feeling invigorated. Like I said, we do a really good job of hiring the sort of people who already work here.
[1]: Some of the things that I think are very good about Google's process (particularly in terms of providing fairness across candidates in a way that my previous employer did not) also cause delays. A lot of effort goes into considering all of the data that's available on a candidate. The amount of discussion that goes into every candidate, even after all of the feedback is in, is staggering.
[2]: Remember that interviewers are people. We've all been told that we're representing Google, but some people take that responsibility more seriously than others. Given that interviews are typically conducted 1:1, nobody knows what happened in the room except for the interviewer and the candidate. When candidates have bad experiences, they don't necessarily report it to their recruiter, so if it's a systematic problem with a particular interviewer, unless it shows up in the feedback they're submitting, it's very difficult to detect and correct. This is really unfortunate, but of course putting two people in the room makes some candidates nervous as they feel they're being doubly judged!