These are the prescreen questions that were used for senior SRE. It's not a hiring test- this person didn't even get to the actual hiring interviews (which would have asked you, for example, to implement quicksort in code on a whiteboard).
The recruiter-screeners in this case don't know anything, they're just looking for you to answer some questions against a table of "right answers", and they wouldn't know it if you answered in a way that was technically correct, but not in the answer key.
The reasoning behind this, sadly, is that Google thinks it tuned its hiring questions to reduce the rate of false positives- hiring an unqualified person into a role- at the expense of false negatives (not hiring a qualified person).
Eventually, I stopped referring people to Google as the process was quite capricious. I told anybody who wanted to apply to read everything online about the process, memorize CLR and leetcode, and then tell the interviewers what they wanted to hear.
This is also what I tell people, including students, unfortunately. Interviewing at Google seems to do a reasonable job of preventing them from hiring anyone hopeless, but not a good job hiring people who aren't hopeless.
Most Googlers I know are not at all confident that they would get their job back if they had to reinterview for it, including those with top performance review ratings.
I once helped author the hiring guidelines and questions used for recruiting and interviewing. After months of effort, the committee proudly, euphorically called the effort good.
I then asked the committee "Who here could pass the high bar we just set?"
There’s also the story of one hiring committee that was proud of its high bar. It got pranked by someone feeding them their own packets, which they denied. It was in a tech talk somewhere, don’t recall where.
This is a valuable experiment to run for any hiring process.
Generally, you want to select for successful employees in your company, which hirers normally are. If they can't get selected, something is very very wrong with your process.
As a former SRE with over 25 years experience at companies small and large, I’ve never understood why an SRE would need to implement quicksort, or how the skills needed by a competent SRE - specifically, to guide developers in making their applications adhere to well-known reliability and scalability tenets, and capture and evaluate the data to show where problems may lie — are evidenced by such rituals. And those rituals tell you nothing about your ability to influence developers through your social skills to adapt the business and its processes to have successful outcomes.
Obviously Google has had some success in this space as their opinions are highly influential, but sometimes I can’t help but wonder if they were successful in spite of their interview practices—especially in the early days—because jobs at Google were much-coveted: talent from all over the world sought out a job there because the money and the prestige was just so damned good.
Afaik this prescreen questionnaire is there bc it was statistically determined it fairs better than a resume screen at selecting candidates that would pass subsequent interviews
The recruiter-screeners in this case don't know anything, they're just looking for you to answer some questions against a table of "right answers", and they wouldn't know it if you answered in a way that was technically correct, but not in the answer key.
The reasoning behind this, sadly, is that Google thinks it tuned its hiring questions to reduce the rate of false positives- hiring an unqualified person into a role- at the expense of false negatives (not hiring a qualified person). Eventually, I stopped referring people to Google as the process was quite capricious. I told anybody who wanted to apply to read everything online about the process, memorize CLR and leetcode, and then tell the interviewers what they wanted to hear.