There is a reason for the regimented process that you're talking about.

The challenge for any large company is to delay, for as long as possible, the inevitable reversion to hiring the mean. Under normal circumstances, different teams will have different standards, and by the time you realize this you'll have a lot of teams whose standards have slipped, and you will have a lot of marginal employees.

Therefore smart large companies try to create a minimal process that aims to create uniform process across the whole company. The process tries to be lightweight as possible on individual people, but fights the good fight against entropy.

Unfortunately for Rachel, Google's process centers around the idea of having well-calibrated interviewers whose interview characteristics had been so well tested against others that hiring committees know exactly what to make of their interview feedback. (What absolute scale you grade on does not matter much. How your scale compares to everyone else, and how well it predicts everyone else, does.) Once an employee winds up as a well-calibrated interviewer, HR would like to use that person as much as possible (and each use does a better job calibrating the employee, and increases their desirability as an interviewer).

This is inconvenient for the employee to whom it happens. But, on average across all developers, the process is quite light-weight.

Instead, the formal interview processes I've seen are gauntlets of trivia and case studies and successive whiteboarding exercises that exhaust everybody. They don't generate value proportional to their cost. And they're unsustainable, so that whatever marginal effectiveness they have is compromised totally within a year when everyone who participates gets sick of it and starts phoning things in.

Google's process has been sustained company-wide for a number of years now. There is much that is imperfect about it, but evidence suggests that it is sustainable.