Hacker News Reader

Comment by nogabebop23 | Hacker News Reader

We use a coding challenge as well but I like your addition of "auditing" the coding part and using existing open source or side project work. Bonus points if it uses some of the target technologies too!

The author doesn't appear to understand the economics of the hiring company; it's about time & effort to filter and the cost of making a bad hire. I cannot give every application 1-2 hours of review if I get 100+ resumes. I can't give every interviewee a half-day assessment to get the very poor signal/noise ratio answers to questioning methods suggested. I can't hire easy and then fire easy. I can't invest weeks of work from myself and other mentors on non-ideal potentials. I know this means I pass over great candidates and that really sucks and is totally unfair. I'm sure that's happended to me as well. The problem is nothing presented here is a better alternative.

View on HN

> I cannot give every application 1-2 hours of review if I get 100+ resumes.

This is perhaps the biggest misconception of hiring, that out of some misguided notion of "fairness" or "objectivity" you have to treat every candidate exactly the same. In theory it seems like a good principle, but the road to hell is paved in good intentions. In practice, this results in arbitrarily designed standard tests which are only superficially fair, and systematically weed out people who aren't good at test taking or auditions.

Go through all the resumes quickly, pick out the top candidates, and start from the top! Focus most of your time on researching your few top candidates, and if one of them seems good, then hire them, and end your hiring process. You may only have to interview 1, 2, maybe 3 people at most. This saves everyone time: your own time, and the time of the 100+ people who would otherwise be interviewed and rejected, because there's only 1 job opening.

Obviously if you interview your top candidates, and you find them lacking, then keep working your way down the stack. But going through the entire stack of candidates is a huge waste of time, a pointless exercise, totally counterproductive.

Don't do "screening" interviews. Only do "hiring" interviews.

Generally you don’t get all the resumes at once, this is literally the secretary problem. Unfortunately you need some objective standard of measurement across candidates that is static over at least months, and ideally takes a minimum of you and your candidates’ time. Though imperfect, real-time technical questions are a pretty good solution to this problem, especially since a lot of the best engineers prefer them to take-homes.

Also, anecdotally after interviewing hundreds of candidates, I’ve found resumes to have a relatively high false positive rate. Surprising numbers of engineers look great on paper but can’t write working code for semi-complex problems when tested, even accounting for interview anxiety.

> Surprising numbers of engineers look great on paper but can’t write working code when tested, even accounting for interview anxiety.

How have you accounted for interview anxiety?

It’s definitely not an exact science.

1. I try to make the parameters of the interview as friendly as possible — language of their choice, don’t have to worry about code style or computational complexity, or talk while they’re coding, just write working code that solves the problem. They can use google freely. I’m there as a resource to talk through their solution, answer questions, and help them get unstuck if needed.

2. The algorithm to solve the question doesn’t require a trick and there are many viable solutions so most candidates can verbally explain to me a working algorithm quickly, +- a couple edge cases.

3. Candidates often get visibly flustered or hung up on irrelevant details, or unsure what exactly I want for them, and I focus on noticing this. I try to guide them down a correct path if they’re close and tell them not to over-architect if they start doing that.

Despite all this, too manly candidates do not have a dependable metaprocess for writing working code - a common scenario is they write code, it gives the wrong result, they drop some print statements to debug, but can’t effectively trace the program to figure out why they’re getting the debug output and so they guess and try to fix the wrong thing, causing further problems. I know that some of this is nerves but it can’t account for all of it.

> I know that some of this is nerves but it can’t account for all of it.

Why not?

If you've never experienced severe situational anxiety, you may not know how debilitating it can be.

And then, maddeningly, perhaps just minutes after the interview is over, you return to your "normal" self, and start to think about what you would have done in that situation if you weren't nervous.

It's basically stage fright, which can be terrifying if you're not used to the stage.

I guess I'm generally going off of an interviewee's body language, which isn't entirely fair since I'm not a mind reader. And I'm sure I'm missing some cases of stage fright, which is why again I mentioned all the techniques above that I try to mitigate this, but I agree is a really unfortunate side-effect of the interview process that I don't have a fool-proof solution for.

Still, I do have some EQ. A lot of candidates exhibit visible anxiety and then get into a rhythm and calm down when they start coding. Or they visibly calm down once I start asking them questions about how they're thinking and coax them towards viable implementation. On the flip side, a lot of candidates actually exhibit overconfidence running in the wrong direction, which I try to lightly mitigate but can't prevent in all cases without giving an unfair advantage.

Are you sure? I mean the 10 years of success spent over various companies projects on resumes have a high false rate because after they took your coding test they didn't do as well as you thought they should? Did you hire any of them and did they out perform your initial assessment.

If you didn't hire them and compare them to new hires who have bad resumes but did well on your test how would you know?

You can't objectivity judge a candidate by your test results only. Otherwise your test is just randomly filtering people. Until you do that you don't know how effective your test is. You could be flipping a coin and getting the same results.

I’ve hired people who have not passed the coding screen (but did pass subsequent interviews) and they’ve been some of my best hires. But the type of failure really matters. Did they write generally correct code but ran out of time because the algorithm they came up with under time pressure was too complicated? Or did they fail to debug a list indexing off-by-one error, even after printing the list repeatedly? It’s sometimes a judgement call but I believe there’s a lot of signal in watching people write code in real-time

Agree with this for most companies. When at an airport we were government and had to be 'fair' it was about ten solid days of work to hire for one position.

This only makes sense if they want top talent. Usually they want cheap/easy to push around talent and for that you need a screener that filters out the best and whoever remains will have the strength to deal with bully managers or lack of requirements

> Don't do "screening" interviews. Only do "hiring" interviews.

Good way to put it. Exactly.

How do you "quickly go through" a stack of 100 resumes and choose a handful of top candidates in a way that is not subject to personal (conscious or unconscious) bias?

I remember an interview training exercise, which also covered resume screening. Each person got the same stack of resumes, and the instructor said, "You have 60 seconds to pick out the top 3 you'd like to bring in for an interview. Find them." At the end of the exercise we found that we all basically picked out people who were a lot like us. White people picked out "whiter-sounding" names, women picked more women, etc. Also, Ken Thompson's resume was one of them (with a different name) and nobody picked him.

I think the point was that human eyeballs and brains are terrible at objectively or fairly pre-filtering.

> How do you "quickly go through" a stack of 100 resumes

Well, by quickly I didn't mean only 60 seconds. :-)

> in a way that is not subject to personal (conscious or unconscious) bias?

In my opinion, a common conceit is that it's possible to design a process that is not subject to bias. It's not possible. There will be bias, no matter what process you choose. It's thought that "quiz show" style interviews are "objective", but if you look at the results, they're clearly not helping. They're not increasing diversity. The poor results speak for themselves. So then some people look at the results of this so-called "fair" process and conclude that minorities are just worse at coding, because that's what the tests say. To me, that approach and attitude is even worse than just acknowledging personal bias.

The only way to try to counteract unconscious bias is to be conscious of it. Admit it, and keep it in mind while you're going through your hiring process. Keep it in mind while you're filtering the résumés. Keep it in mind while you're interviewing. But don't try to pretend like you can eliminate it entirely from the process, because then you're just deluding yourself and everyone else.

This is an entirely self-created problem, not for you personally, I mean for the industry. We are against "credentialling" so signals like personal recommendations, alma mater, or work history at prestigious firms are overlooked.

My employer tried Hackerrank for a while, we abandoned it when we realised that the candidates we really wanted (e.g. based on personal recommendations from existing employees) were dropping out of the pipeline as soon as the Hackerrank link was sent to them. And the ones we were getting were good at Hackerrank and not much else.

> I cannot give every application 1-2 hours of review if I get 100+ resumes.

Your process has already failed if you're considering 100+ people!

First, you should never be getting 100+ resumes for a role. If you are, you need to write better job descriptions and/or get a better recruiter who knows how to match to the job description.

With that in place, you (I) are getting about 10-20 resumes at most. Then what I do is read them and rank them. Takes less than two hours.

I'll only interview the top five from this stack. I'm happy to give each of these five people however many hours of attention it takes, they and I deserve it.

This way the people who didn't get to the interview round have not wasted any of their time which is the most respectful way to handle it.

> you need to write better job descriptions

Tech job postings are the absolute worst. Anyone who's having trouble with hiring in any way needs to start there. Everyone in tech knows that job postings are a joke, which is why you're told to apply to jobs even if you're not qualified, and then companies complain about the applicant pool. It's their own fault!

The "excuse" is almost always "HR". But this just tells the applicant your company is a bureaucratic nightmare that few sane applicants would want to join.

There's a lot of worry in tech hiring about the "faker", the engineer who lies or exaggerates on their résumé.

The irony is that the tech hiring process, especially the job postings, encourage the fakers to apply. You're practically beginning fakers to apply.

The most honest, scrupulous people tend to only apply for jobs where they're 100% qualified according to the job posting. So the system, which hires people who don't actually meet the listed qualifications, is systematically selecting against the honest applicants. Honest people can even be driven out of tech in virtue of being honest.

> Your process has already failed if you're considering 100+ people!

Remote roles get a _lot_ more applications than on site. In my experience getting 100 applications is quite common for such a role.

The commenter doesn't appear to understand the economics of the job-seeking candidate; it's about time & effort to keep your current job and the cost of getting hired at a bad company. I cannot give every company I apply at hours of coding if I apply to dozens of jobs. I can't give every company a half-day assessment. I can't get hired easily and then get fired easily. I can't invest weeks of work from myself on non-ideal potentials. I know this means I pass on great jobs and that really sucks and is totally unfair. I'm sure that's happened to me as well. The problem is that nothing presented here is a better alternative.

This is a snarky parody, but put together you are both just saying that you can only afford to spend any time on job matches likely to be especially good, but that you’ll spend a lot of time on the good ones. Which just means you both are in an illiquid or conservative hiring market that is out of your control and their control to change.

>I can't hire easy and then fire easy.

Why not? Maybe you should address that problem. It would certainly make things a lot easier.

Reply on news.ycombinator.com