Hacker News Reader

I like this comment. At the end you wrote: <<my coworkers don't enjoy doing hiring stuff>> Can you clarify something for me? Are you a hiring manager? If yes, the "ROI" comment makes a lot of sense. And do "co-workers" mean other hiring managers... or non-managers? As a non-manager, putting effort into hiring doesn't have good ROI for me personally.

My CV and LinkedIn profile had links to open source projects for more than 10 years. I am someone who interviews a lot -- I like to move from company to company for diverse experience. Only once in ten years has anyone asked about my open source work. They are generalist libraries (Java and Python) that I "import" at every new job. They give me a real edge over my teammates. My point: Interviewing seems like a total gamble. My best strategy is to figure out what the hiring manager wants and pretend to be that person. In most teams, the hiring manager calls the shots nearly 100%. If they like you, you will be hired. I've had crap tech interviews with the "teammates" and still gotten offers because I transformed (during the interview!) into exactly what the hiring manager wanted. Bizarre.

An alternative explanation: even if they did spend more time on the resumes they wouldn't be selecting better, because they don't know what to look for

Ah, the sheer ego size of hiring managers who go around saying stuff like "understanding how candidates think" or "assessing cultural fit"

The brightest minds of psychology - with far, far more resources and time - can't replicate those results if they run the tests this Monday or this Wednesday... and then comes the hiring manager and they say they can do it with a CV, some technical assignment, and an hour of chat. After having spent less time properly studying the topic than highschoolers spend on their homework each week

It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews."

The "stand out significantly" check doesn't take 10 minutes per resume.

Additionally, doing nothing but reading 100 resumes (no meetings, no development work, no trouble shooting issues, nothing else) is soul crushing.

Going to blogs some HR departments will frown upon as it may introduce biases into the evaluation process that they'll get sued over. "The candidate recently wrote about her experience with pregnancy on her blog that the interviewer had looked at" - and you've got a discrimination suit on your hands.

> It isn't "critically evaluate" but rather "in this stack of 100 resumes, find four that stand out sufficiently to bring in for interviews." The "stand out significantly" check doesn't take 10 minutes per resume.

So it sounds like you're saying that you can do a really fast check with ~no false negatives. That is, you won't skip over the best candidates and fail to interview them.

But are you sure that's really true? Often if you can find any code a candidate wrote, it quickly stands out as "exceptionally bad" (like, you can see bugs at a glance, the formatting is a mess, stuff is copied and pasted everywhere, the project isn't what was advertised) or "exceptionally good" (like, they are making PRs fixing tricky issues with really thoughtful writing and immaculate appearing code.)

There's almost literally nothing on a resume that can stand out that much other than, like, "ICPC winner" or "lead engineer on Chrome" or "famous celebrity I know by name". At first glance, the resume of the guy with the exceptional code will just look like "went to some school, worked at a few companies where they did a few bullet points." How are you so sure you will decide to interview him if you just skim the resumes very fast? What if you have four candidates who went to better schools and companies, and you interview them instead?

I get the "soul crushing" complaint. If I were king I would try to split the labor among engineers as much as possible to mitigate that. Or hire more slowly.

If you're selecting 10% or 5% or 1% that are interesting to bring into an interview, what is a false negative?

I'm not going to claim that the ones selected are the best or that I'm missing ones that I would give a thumbs up to if I had the time to interview every candidate.

Instead I'm looking for "are they applying to this job? Do they have some of the skills that the job is looking for and have claimed to use those particular skills in a past job or project? Do they have a history that demonstrates that they're likely to stay around after becoming a positive contributor?"

I've got an excel spreadsheet where I am to give a 1 to 5 score for each of the skills (1 is "no claim of the skill being used" to 5 of "specifically claimed to use the skill in a current project or role"). The next column is "average tenure in months" and lastly there is a column for red flags or green flags. You will note that nothing in there asks about past company or school. Considering schools can get into trouble for discrimination if the person went overseas or to a HBCU. If you want to call out something (the candidate spelled JavaScript as 'java script', "JavaScript" and "java Script" (with java lower case and bold)) then that can be put in the red flags.

From that list (and multiple people all fill that out for all resumes), HR then selects the ones to move to the next round of interviews.

If I am looking for code the candidate wrote that can cause problems with discrimination suits at this level of the interview. If we look for any blog posts on them or social media they've written, we open ourselves up to lawsuits and claims of biased hiring.

When it comes to code, we have a take home test that is given to those who are selected. Having the take home up front has been met with "but you aren't paying me to do this" or other forms of refusal to do it... and I'm not going to go through and review 100 submissions - I don't have the time for that.

For that code part of the interview, again, there is a rubric that is set down such that anyone reviewing the code should come to the same conclusion.

And while it seems a bit impersonal, the key is that the same criteria is applied to everyone and if someone else was to watch a recording of the interview (this isn't done, but its the hypothetical goal) that they would come to the same conclusions based on that same rubric for evaluating the candidate.

It's a matter of ROI. The initial skim is just the sorting phase. And sure, I may miss a great candidate, but that's the price one pays. It's much better to get a false negative than a false positive.

A false negative costs me very little. A false positive is a massive burden. I'm optimizing to avoid false positives.

Also to be clear, I will read the full resume of a candidate I'm interviewing. And their blog and GitHub and whatever else they tell me about. And I'll take notes so I can ask them about interesting things I find.

The skimming is just for the initial "should we consider this person for an interview" screen.

are you paid on commission? or salary?