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
This exchange happened around 2016 or so, if I remember correctly. Already posted here a couple of times.
And it happened to me also. Those recruiters were hilarious, you cannot make that up. I got 8 of 10 by luck, but refused a 2nd exchange with those bots.
It’s great that they still don’t get how pointless it is to memorize things like protocol numbers for esoteric stuff that is trivial to google and find in a few seconds if the need should ever arise, which it rarely would. IIRC they asked me for the one for GRE.
I also had one (I forget the exact question) where my answer was technically correct but “wasn’t what [they] had”, and my explanation about why it was the same thing went way over the recruiter’s head.
Whoever thought this would be a fun little trivia game to have people play for their careers…yeah, no.
I still got through to the technical interviews wherein the first technical screener told me he doubts he’d be able to get his current position again now if he had to go through the interview for it, and he told me seriously not to feel bad if I don’t pass. I did pass that one.
Second technical screen was with a person with a thick accent and bad VoIP who was getting obviously frustrated due to both of us having to repeat stuff a lot.
This was all after a 6+ month dance of scheduling and waiting and hearing nothing from their recruiters. Got a rejection weeks later and never tried re-applying. They still reach out like every 6 months.
I had similar questions on 2016, although not quite as wrong/bad as presented here. E.g. "why is quicksort the best" wasn't asked. Instead, something more like "What is the average case time complexity of quicksort?"
Thanks for this - now I know what link to reply with for recruiters that keep spamming me as if I’d be interested in working at whatever company they’re spamming me for.
I had a similar experience a few years ago. Although I soon realized what the deal was, and what the expectations of the screener were (so I could adjust and ‘pass’), it discouraged me from moving forward.
It seems nowadays the process is much more reasonable, but Google is still far behind other FAANG companies in regard to their interviewing process, in my opinion.
The reason for this is that resume review is really ineffective as a screen. You end up having engineers wasting time on technical interviews that are clearly a pass in the first 10m (but you keep going for 45 to stay professional)
IMO, a better approach now are basic on line code screens designed to take 15m for a qualified candidate. The goal of which is to show you are serious about the tech stuff and give people a way to bow out gracefully.
> You end up having engineers wasting time on technical interviews that are clearly a pass in the first 10m (but you keep going for 45 to stay professional)
If someone is a pass in the first 10 minutes, the next 35 minutes are me trying to sell the company to the candidate. This is not, even slightly, a waste of time.
I have Allied Mastercomputer levels of HATE for whichever HR drone decided that "interviewing candidates" needed to be a bullet point in the "corporate evaluation process" and thus made the interviewing process even shittier than it needed to be.
I think the post you were replying to was using "pass" to mean "pass on the candidate" i.e. not move forward in the interview/hiring process. The point of such recruiter screens is to avoid an engineer seeing in a coding screen that the candidate has no chance in hell of success.
Hrm. Good point. I didn't catch that might have been the implication.
However, being professional is also important and I don't consider it a waste. I've experienced the reverse. It was clear after one interview that I was not a fit for the position.
I still ran the interview out even after pointing out that I really wasn't a fit because that's what professionals do. I later got a contract out of that company simply because I was professional about things and so many other people aren't.
Resume screening is very effective when done by someone who is intelligent. The tech industry refuses to take hiring seriously and apply such people to the problem.
I second that. It's not necessary about "lying", many candidates may drop a keyword as something they know, when really they have only heard about it instead of mastering it.
Some people also under-rate their skills, because they are very demanding to themselves (the bad ones don't know "sort" and want to re-implement their own sorting method in Python).
I pre-screen using practical problems that I have to solve every day, and when candidates know their UNIX shell commands that's usually a really good sign.
I think the point of GP comment to yours is that by reading resumes skillfully -- that is, between the lines -- and comparing with other factors (e.g. their portfolio) it's pretty easy to tell the "probably solid" from the keyword-stuffers and buzzword droppers.
By "probably solid" I don't mean "immediate hire" but rather "It's a safe bet this person isn't utterly incompetent and I won't be wasting 10 minutes of my time talking to them."
I do not think it is possible to weed out all or even most of the completely incompetent programmers on the basis of resume screening. My reasoning is, I frequently conduct technical interviews, and a good percentage of those are with candidates lacking basic coding skills, and many of those candidates have impressively written resumes.
What is your bar for “terrible”? Resumes are a demonstration of written communication skill — they should at least be competent at expressing certain basic things about the candidate. An underwhelming list of accomplishments or lack of significant prior experience need not be showstoppers, of course.
I frequently administer technical interviews. For candidates who have passed an initial recruiter screen, I have ascertained no correlation between resume quality and code production. Many, many candidates with extremely impressive resumes are unable to produce basic, working code.
The reason for this is that resume review is really ineffective as a screen.
No is saying they should rely solely on resume review as a screen.
What is under question here is the perceived wisdom (on Google's side) of screening for Director positions using badly programmed chatbots (or recruiters, whatever) instead of having them be asked the same questions by an actual human.
IMO, a better approach now are basic on line code screens designed to take 15m for a qualified candidate.
Perhaps, but companies like to screw that up as well -- having people code into a Word doc, for example (try it sometime), or assigning problems that are either brain teasers or essentially willingness-to-cram filters rather than what they should be -- a simple, straightforward test of minimal programming ability (to determine whether further time investment is merited).
I've used (I think) hackerrank, and just done really basic stuff. Like freshman CS basics, starting with working code and extending it (eg a class that calculates the average of its contents, and you add min, max and median). Surprisingly it screens out about half.
If it's the latter (essentially a test of whether they've memorized quickselect) then that sounds like a horrible filter, actually. Unless it's for the position of "Senior Quicksort Engineer".
If some asks me to "calculate" something I assume they mean from scratch (without using a built-in). That's probably what a fair number of these people did.
Also, my sense is that Python is something of an outlier in having a mean and median functions in it standard library. I could be wrong, but AFAIK Go and JS do not, for example -- so people using those languages would surely bomb (at least on the median calculation part -- again, assuming they interpreted your question as "calculate from scratch").
I don't mean to be pedantic or split hairs. The point I'm trying to make is that even simple-seeming problems can have gotchas to them, depending on the context.
Interviewers could do better by either thinking just a bit more about the problems they select, or just communicating better. But many do not, unfortunately -- I have the sense they just pull problems out of the air, and see what sticks. Meanwhile counting the high number of fails as a success signal.
Not surprising, the candidate did fail at acknowledge who the interviewer was to adapt their answers. It was a recruiter reading answers from a sheet, the simpler you keep it the highest the chance of passing the stupid test.
Don't do that. Don't conflate having to dumb yourself down for recruiters that reached out to you for a director of engineering role with communication skills.
Yes sometimes you need to be able to simplify things for non-technical shareholders, but no that's not what this should be.
In an engineering focused organization if recruiters are reaching out for a position this high up they should either be solely acting as a data gatherer while a highly technical person reviews, or they should be technical enough themselves.
We're not talking about screening internships here, the person in the article didn't ask Google for an interview, it was on Google to provide competent points of contact. That doesn't necessarily scale if we're talking about applications they receive, but that's why the article states almost immediately it was an unsolicited interview.
If the person can't tell the difference between "dumbing down" and communicating appropriately for the audience in order to get their message across then I think the process ending in "no hire" is working fine.
There's no level above which this stops being important. If anything, it only increases as you go up.
There are probably thousands of 'director of engineering' or similar roles at Google. If it's anything like other companies, they will be managing something like ~50 people. It's a middle management role, not that high up - except in compensation relative to the median...
> In an engineering focused organization if recruiters are reaching out for a position this high up...
How high up is this? What's a director in FANG-land? In some places, a manager of managers is a director - which isn't very high, and can be closer to the ICs than to the CEO on the org chart.
Yes - after “Recruiter: wrong, not "attributes", it's "metadata".” - it’s clear enough what’s happening. “stat() return an error code, not an inode” - I know this isn’t what’s on the paper, and the author should have also. “stat() let you get the inode number” would have let you stay pedantically correct yet still satisfy the recruiter.
“What is the type of the packets exchanged to establish a TCP connection?” - as soon as I read the question, I knew right away the author would give the exact hex, and the recruiter would want the three letter acronyms.
Perhaps this was a brilliant engineer disguising a personality interview as a technical one. Personally I would want my coworker or boss to be someone with enough awareness to have passed this interview. Compassion, empathy, social awareness, understanding someone else’s role and perspective, setting aside your ego to help a conversation go smoothly - important for a director to have.
It is so typical to interview very senior people who get really arrogant about their skills, but when it comes down to it, they fail at this rapidfire, and in a very non graceful way.
This rapidfire is very coarse and weeds out most incompetent people. It's likely not your answers, but your attitude that failed you.
Unlikely, unless the interviewer was just trolling them.
If it was just their attitude, they’d not tell them they were wrong when they weren’t and tell them to work on x y and z to be qualified in the future. They’d just complete or end the interview and say something like, “Great! You should hear back in x days” and then reject in their ATS.
If not, then the recruiter is an asshole and gaslighting the candidate.
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.