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.
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.
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.
I've also talked to people with terrible resumes who turn out to be great. They are just bad at resumes.
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.
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."
If they failed your test -- you just know they failed your test. That doesn't mean you now that they're incompetent.
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).
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".
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.
The standard library is to sort, not take the median
min(x)
max(x)
statistics.mean(x)
statistics.median(x)