Hacker News new | ask | show | jobs
by lokar 1627 days ago
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.

3 comments

> 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've read many resumes that seem solid. Then the candidate knows almost nothing. They just lie on the resumes.

I've also talked to people with terrible resumes who turn out to be great. They are just bad at resumes.

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.
I would reckon (based on my own observation, combined with some research that has come out recently -- see below) that "a good percentage of this good percentage" probably failed due to nervousness, rather than than truly lacking basic coding skills.

If they failed your test -- you just know they failed your test. That doesn't mean you now that they're incompetent.

https://dl.acm.org/doi/abs/10.1145/3368089.3409712

Indeed, the point was that resume screening can have >50% accuracy when done right. Unfortunately I’ve seen 5% as the accepted norm in the industry.
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.
Finding the median with or without sorting first?

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".

They are free to use the standard library, and use whatever language they like (eg python). It's not about how to sort
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.

The site has a detailed spec and test input/output, you can build and run the tests

The standard library is to sort, not take the median

"No [one] is saying ..."