
Resumes suck for hiring engineers - slyall
http://blog.alinelerner.com/resumes-suck-heres-the-data/?hn=1
======
codingdave
Resumes are just a tool to decide whether or not to start a conversation.

When hiring, you are not really concerned about letting a good candidate go.
There will always be others. It is far more dangerous to let a poor candidate
in. And poor candidates tend to be poor due to cultural and subject matter
issues more than basic technical chops.

I'm not making any hiring decisions at this point - just weeding a huge list
of names down to a reasonable number to actually call. So I'm not judging
people's skill levels yet -- I'm looking for something in their history that
tells me they are bringing more to the table than knowing how to code. I don't
even have preconceived notions of what that might be - just something that
sparks me to think their experience has something in common with what we do.
We'll weed out the weak technical candidates in an initial call, then continue
with the people who are both strong technically and a good fit for the work
and the culture.

So the whole premise that I am not getting it "right" when judging a person
skill based on their resume is missing the point. It isn't that I don't
care... but I know reading a resume won't give me an accurate answer, so it
isn't even a piece of the decision making criteria yet.

~~~
vonmoltke
> When hiring, you are not really concerned about letting a good candidate go.

With that attitude, I hope you aren't complaining about how hard it is to find
talent.

> It is far more dangerous to let a poor candidate in.

This gets parroted a lot around here, but with no supporting evidence other
than highly improbable hypotheticals or black swan events. On the other hand,
I know plenty of companies that have had to deal with poor candidates, from a
Fortune 500 with 70000+ worldwide employees down to a small 12-person shop,
and none have suffered serious consequences from these poor choices.
Considering the lack of hard evidence supporting your statement, I believe
these companies I am familiar with are the typical case and not "lucky".

~~~
Bahamut
I've seen many negative consequences from poor software engineers being
brought into companies first hand.

I saw a junior engineer try to add a patchwork of libraries just because he
was not confident in his ability to do something correctly, leading to a lot
of maintenance overhead that grew very quickly.

Many of the previous frontend engineers got fired from my current company
because they did not produce at all - a direct result is a polluted codebase
that needs to be scrapped asap because it has led directly to poor perception
of product. It also is extremely difficult to iterate upon.

One company I was at had some very terrible legacy code from full stack
engineers. The person who wrote the code was fired as well, but not before
leaving damage that persisted for years - some triply JSON.stringified JS
object, along with some other extra parentheses, was stored right into the
database as a string! This meant every time the data had to be fetched, it had
to be parsed by the server to fill certain other data, but the core answer
object was still sent as it was due to the difficulty associated with sending
a parsed form (the backend was Java), which meant that the frontend also had
to parse it! Thankfully we were able to silo the damage to an easy to adapt
modular service, but it was the cause of much sadness, especially when it was
a core piece of data for our product.

~~~
vonmoltke
First off, thanks for providing some concrete examples.

That said, those all fundamentally sound like process problems to me. They
would not have been allowed to happen at either of the companies I have worked
for or any of the companies I have worked with, at least not to a degree that
they would harm products. Sure, we have shit code down in the bowels of our
libraries, and some of it was put there by people who didn't know what they
were doing. I would not characterize any of it as serious problems, though.
Those tend to either not live long or not make it into the codebase in the
first place.

I understand there is a tradeoff here, and that "process" is a dirty word to
many people. A little process can go a long way, though. It can make problems
like those you describe minor or non-existent. To me this seems like a small
price to pay for opening up your hiring process and dealing with the poor
choices.

On a slight tangent and speaking of costs, I get the impression that many
people discount the cost of a false negative. You are trying to hire people
for a reason. Your company is incurring costs from not having this person, be
it the lost revenue from expanding or the actual costs of working your current
engineers harder to meet deadlines. That needs to enter into the equation,
along with the costs of false positives and the costs of mitigating same.

~~~
tokenrove
Even though process is intended to mitigate the damage an individual can
cause, in practice it's hard to have a good process without good people.
Everywhere I've felt that a poor hire had serious negative effects on a
company, those employees were also obstacles to bringing in a better process.

I agree with you that the cost of a false negative must be considered. The
kind of bad hire I'm thinking of here is a net negative producer that actively
costs the company money (or even causes good employees to leave), even after
they're gone (if you can manage to get rid of them).

------
nnnnni
You know what's frustrating? When you don't even make it to the interview
stage because hiring managers think that "Red Hat" and "Linux" are two
different things.

I was recently passed over because my 15 years' of experience with Linux has
been with multiple distributions (including RPM-based ones) and my resume
didn't have a line that just said "Red Hat" on it.

Them: "Oh, I'm sorry, we can't hire you because you don't have any JavaScript
experience..."

Candidate: "What do you think all of this stuff with JS in the name on my
resume means?!"

~~~
CmonDev
Treat CV writing as a SEO task: "JavaScripted the JavaScript scripts using the
JavaScript MVC framework Angular.js (JavaScript)." instead of "Implemented
using Angular.js".

~~~
mangrish
I've recently written a resolution engine for keywords when matching cv's to
job descriptions. it also helps finding patterns in other skills that may be
transferrable. i hope to show HN as soon as i finish some performance
improvements (which includes writing a brand new db driver :'()

~~~
civilian
Add me to the list of people to notify when your project is done, plz.

------
TTPrograms
I would think that the other interpretation of this result is just that many
engineers suck at writing resumes, which is totally plausible. In fact, one
could analyze this in the current data set by looking at the total number of
correct predictions versus the different resumes in the set. A well-written
resume would then be one which results in correct predictions most frequently.
You'd then have two dimensions for each resume - quality as judged by the
author and signaling accuracy in the resume itself.

I've seen resumes in all corners of that plot, so I can't say that I'd throw
out the resume straight away, but it does indicate that there is some large
gap between what hirers want and what candidates think they want.

~~~
kabouseng
Since technical writing is part of an engineers job requirements, I would
argue that an engineer incapable of writing a decent resume is already at a
disadvantage.

~~~
eigenvector
Resumes are inherently hard to prepare because the requirements are often
deliberately withheld. Granted, if a resume has basic formatting, spelling or
grammar problems that's a big red flag, but other than basic linguistic
elements it's not really a fair way to evaluate someone's technical
communication skills. Some companies treat the job posting itself as a type of
puzzle you're expected to guess at with your cover letter and resume.

Also, a lot of job postings are terribly written, extremely vague or otherwise
problematic, so it's not a one-sided problem. It's hard to know if you're
meeting the employer's needs when their posting is asking for someone who
could engineer a mission to Mars on their lunch break and will work for
$50,000 and 1 week of vacation.

~~~
kabouseng
"Granted, if a resume has basic formatting, spelling or grammar problems
that's a big red flag"

I agree. The same could also be said about a companies job posting. If the job
posting is "vague or problematic", it also indicates the company has no idea
of what skill set they need.

This has many parallels with a client not properly being able to specify his
requirements. Usually if a client cannot properly specify his requirements, he
also underestimate the amount of work / cost it will require to develop.

The same with a job posting, if they cant properly specify a job posting, an
employer also might think the job is easy or he can pay someone peanuts to do
it.

------
joshyeager
I took the survey, and would have done a 20-minute phone screen with five out
of the six resumes I got. All six were basically qualified for their roles.

That is vastly different from reality. When I post job ads, at least 25% of
the resumes I get are completely unlike the job requirements, and another 50%
superficially match but are obviously unqualified. The remaining 25% look like
the resumes I saw in the survey.

When I get resumes from recruiters, I generally don't get any of the "didn't
even read the ad" resumes, but I still get about 1/3 obviously unqualified
candidates.

So overall, a resume filter lets me skip hundreds of useless phone screens or
face-to-face interviews. I may lose a few good candidates in that process, but
not many.

I'm really not sure why this author is trying to use resumes to decide whether
to interview these candidates. Once you have them filtered to this level, a
quick phone screen gives you much better information than a resume, and
doesn't take too much time.

------
stared
The experiment looks flawed. It seems that ALL (or almost all) resumes are, at
least, OK.

Resumes can work for weeding out bad fits, or people doing things clearly out
of the scope of interest. They are not, and cannot, be a tool for choosing the
best. (Unless success is so spectacular, that you know the person by name
anyway.)

It's HR's delusion that previous -perceived- presented achievements written on
one's resume can serve well for predicting future achievements in our company.
So, don't overoptimize it an do technical interviews with people actually
working on a given technical problem.

~~~
hessenwolf
But can we have technical interviews instead of brain-teasers?

Maybe it is just me, but I don't do puzzles. I solve big problems, and I have
a track record of being very successful at it. I juggle people, and tools, and
objectives, and timelines, and get things done.

I like projects, and I am not afraid of hard work. If I like the objective of
a project, I will wade through human vomit to get it done.

Brain teasers are none of that for me. They are some kind of parlor-trick
brain-test. I am not necessarily bad at them... but I am just a bit better
than okay. I do not want to have to practice them just to get past an
interview.

~~~
wallflower
[https://signalvnoise.com/posts/3660-the-person-theyll-
become](https://signalvnoise.com/posts/3660-the-person-theyll-become)

~~~
hessenwolf
Interesting, and a point I agree with, but I don't see how it relates to the
above?

------
vonnik
The startup where I serve as in-house recruiter, FutureAdvisor, recently ran
an experiment in hiring without resumes. It was called StaffupWeekend. The
Chronicle's careers blogger wrote about it here:

[http://blog.sfgate.com/gettowork/2014/10/31/staffup-
offers-a...](http://blog.sfgate.com/gettowork/2014/10/31/staffup-offers-a-new-
way-to-network-interview/)

We recognized that resumes were poor indicators of performance. In fact, we
believe that the only thing that correlates with performance -- is
performance. A study that Google released last year supports that.

The solution we came up with was to invite people to work on projects for a
weekend at no cost other than their time. They chose what they wanted to work
on together.

In a sense, we were batch processing applicants while gathering much richer
information than resumes provide. Strong candidates we didn't hire, we shared
in the Sequoia network.

We ended up making eight interview offers (several candidates decided to work
elsewhere), and we hired one engineer.

The whole event was inspired by this essay:
[http://brookeallen.com/pages/archives/1234](http://brookeallen.com/pages/archives/1234)

~~~
ddebernardy
> The solution we came up with was to invite people to work on projects for a
> weekend at no cost other than their time.

As in working for you for free, and on a WE to boot?

For a student or someone who is unemployed, that might work.

For someone with a job and a family life, I don't think so. Especially if that
person can command a $120k+ salary.

~~~
danielweber
Dude, they get to contribute to the company _for free_.

~~~
hnnewguy
I almost spit out my coffee when the OP stated " _for free_ ", as if not
having to pay anything but time, my most valuable asset, was some perk.

I'm sure the OP means well, and it may have been a success for them, but I
don't know anyone in my circle who would participate in something like this,
unless they were utterly desperate for a job. I thought there was a serious
talent crunch? Who is courting whom?

I wonder what sort of engineers self-select in a process like this?

~~~
vonnik
One reason why engineers and companies have trouble discussing the job market
is that talented people who know how to craft their resumes don't imagine that
any other kind of candidate exists.

Unemployed people have lots of time. Understand that and you'll understand why
a weekend like this makes sense.

One reason they're unemployed is that they don't know how to demonstrate their
value. A lot of engineers are actually poor at communicating, and not that
great at resumes.

This weekend was for them.

------
tehwalrus
I'm in the process of going through technical interviews with a bunch of
companies (some I approached, some approached me.) The coolest thing has been
some peoples' reaction to the little details on my CV (Resume.)

Compared to the other very unsuccessful interview, where the MD just listened
to me talk for a few minutes and said "you're not what we're looking for" (no
programmer in the interview), getting engineers to ask me end-of-interview
questions with a smile on their face was really fun (whether or not I get the
jobs in the end.)

The OP says that engineers were quite good if the CV contained enough detail
about what the candidate had been _doing_ , the substance of the projects. In
both cases, the little question was where I had included a bullet thinking
"noone in HR will know what this means, but I think it's cool" were the ones
that got the smile question.

For the record, all my CVs are skills-based (that is, a set of bullets around
"programming", "teamwork", "communication" etc) followed by a brief chronology
of work and education, rather than having to list every position (student
volunteering included) in order to say what I did there that was relevant.
Customising which bullets (and even sections) you include on a per-application
basis is extremely important, of course, so that the HR person can see "skill
that we asked for: 5 bullets" right there on the first page.

~~~
_dark_matter_
This may be off-topic, but it sure sounds to me like what you're submitting is
not a CV but a resume. Those are two different items. CVs are a comprehensive
history of yourself and your accomplishments, resumes are short, tailored
briefs of why you are fit for the job.

~~~
cben
Interesting, certainly makes etymological sense. I never realized that, in
Israel the two terms are used pretty interchangably. Wikipedia says CVs are
much more comprehensive in some countries, esp. North America.

------
Zenst
Sadly one of the biggest problems I have found regarding Resumes/CV's in the
IT industry and companies is the rise of HR departments who will just word
filter the candidates and even remove people they deem not suitable. Even the
classic case of filtering out people they deem `overqualified`, which sadly
means the IT manager most often does not get to even see or known about the
better candidates and ends up with a selection picked by HR people who know
nothing of the work involved.

I for one welcome phone interaction and tests, though not all tests perfect
and found many flawed tests and errors in tests in the past. Some companies
appreciate when you tell them of mistakes and others will hold it against you,
though again, found HR departments if you point out a mistake will not take it
onboard and take it as criticism and in a negative way and hold that against
you.

So for me, I do feel HR departments play too large a part in recruitment in IT
than their skillsets entail.

Not saying a golden solution, but I do feel that many recruitment processes
have gone down hill with HR wedging themselves into the process more and more
and filtering out candidates that the manager doing the recruiting, never even
knows about.

Though this is all based upon my experience and I'm sure others had different
views. But for me, having been turned down for a job for being overqualified
and case of you actually knowing the manager and he never even got to see your
CV, well, sadly I know it is very true and happens.

~~~
freshflowers
It this really a problem?

Because most of us wouldn't want to work for a company with such a broken
hiring process, it's a big red flag for a lot of other things being wrong in
they way they treat their tech people.

And those who do want to get in should be smart enough to play the game and
cater their resumes to those HR practices. If you can't or won't, you probably
wouldn't happy or successful working for such a company.

As far as I'm concerned, any recruitment process is essentially self-
selecting: it will attract and pass the candidates that are a good fit for the
company. If a company finds it can't get the right candidates, they should
take a step back and look at their entire company culture.

Broken HR processes are a symptom, not the root cause. And it's a filter that
works both ways, preventing naive candidates form inadvertently getting hired
for jobs that will make them miserable.

~~~
Zenst
I agree, though for many companies recruiting those fields of work have long
established institutions and recognised exams, be those lawyers or
accountants. now IT has its own institutions and exams but the difference is,
those change so frequently or that anything with credibility has changed or
indeed expired due to technology changes at a frequency higher than the
educational process too learn those skills fully.

Accountant exams and lawyers as the best examples have not changed. So for HR
to see filter is not only easy but obvious process in such stable measures. In
IT those change so much that it is mostly recruitment agency input that has
those factored into requirements and as for agencies. Well some good at
filtering and know the trades and others mostly work upon (1) get CV's (2) get
companies (3) push CV's and effort done by wine and dine approach with HR.

So not only is it the HR department but the agency factor and in the web based
direction the added level of filtering does get down to keywords still and
little if not mostly none at all human sanity by somebody who knows the role
and can see the signs of somebody who knows the skills.

Then keywords do not bestow what level of competence and that varies greatly
as we all know.

This all said sometimes the gains outway the broken HR if you get an offer and
not every time do you have the luxury of saying no.

Though as a personal anecdote I once had a job interview with a company and
got there on time, left waiting and eventually HR bod came down and said fill
this in (form which was all details upon my CV), so I ask can I just attach my
CV you already have and told no. So I had to fill out in pen on a form that
you just know somebody will have to type into a system, details already upon
my CV. Did that, still waiting for HR bod to return. They return then have
interview with HR. Was very belittling with much attitude of thats a lot for
money for somebody your age and in short really off putting attitude. I then
saw the boss of the IT department, was interview with him and IT contractor,
not only aced the interview and blew them away but taught them things as well
like undocumented debug modes in software they used (dataease so talking 90's
here). Given the contractor was a `specialist` in this product he was mind
blown. Also the small bonus skills I totally aced, in short a perfect
interview at every level.

Not only was I offered the job before I got home from the interview but they
had offered 20% more than the agency had put me forward for and that HR person
had been so much attitude towards me (I was early 20's). It just totally put
me off, and turned it down, just due to that HR experience. Though have many
other HR anecdotes, some good and some bad, as we all do and shall not mention
the posture nazi's for want of a better term.

------
jnaour
What I feel right now is that the hiring process is more and more based on
personnal branding. If you want to have a job interview in top startup you
have to have a good github, smart blog posts, a good stackoverflow, a good
kaggle, some certificats from coursera, some conf etc.

It's a good thing for hiring process, you could judge a candidat more easely
if you could read some of his code or thoughts. You could have more
interesting job offers from people that actually understand what you do. The
problem is that you have to spend lot of time in improving these things. Some
are easy because it's natural to do some work on a open source project that
you're interested in, the personnal branding thing it's just a bonus, but some
other need works...

I believe that in all automatic job applying process that I tried recently
there were fields for linkedin, github, personnal blogs, websites etc.

~~~
ryandrake
A company that relies on GitHub and blog posts will miss tons of highly-
qualified candidates who don't (or cannot due to their employment agreement)
work on open source and who don't spend their weekends blogging and posting to
StackOverflow. Sure, I can see interesting programming side projects being a
nice bonus, but it's not a replacement for a resume + technical interview.

------
mbesto
> _As it turned out, people were pretty bad at filtering resumes across the
> board, and after running the numbers, it began to look like resumes might
> not be a particularly effective filtering tool in the first place._

Her theory - people suck at filtering because the tool they use is poor.

> _it may not be a matter of being good or bad at judging resumes but rather a
> matter of the task itself being flawed — at the end of the day, the resume
> is a low-signal document._

Resumes suck for hiring _all_ people. But that's not the purpose of a resume
-- it's a low-signal filter to weed out the initial batch of candidates. If
you treat hiring like a sales funnel (and you should), then a resume is a
great way to eliminate unnecessary time for your team to assess someone's
cultural fit. Expecting the resume to be high signal filter is pretty naive.

~~~
dragonwriter
> If you treat hiring like a sales funnel (and you should), then a resume is a
> great way to eliminate unnecessary time for your team to assess someone's
> cultural fit.

Where's the evidence that it is great at this? Certainly, its _a_ basis for
narrowing the set of candidates that get further review, but is it a _good_
basis?

~~~
mbesto
Where's the evidence that there is a better alternative?

I was slightly perturbed by the original author as she offered no real
solution.

~~~
itsdrewmiller
She did suggest an idea - asking for a clear explanation of a project, as a
sort of writing sample.

~~~
itsdrewmiller
It's definitely not a solution for an employer who is just like scraping
resumes off of Monster or something, but it's not much different from the
uncontroversial practice of asking for a cover letter.

------
hacknat
>For each resume, I had a pretty good idea of how strong the engineer in
question was, and I split resumes into two strength-based groups. To make this
judgment call, I drew on my personal experience — most of the resumes came
from candidates I placed (or tried to place) at top-tier startups. In these
cases, I knew exactly how the engineer had done in technical interviews, and,
more often than not, I had visibility into how they performed on the job
afterwards. The remainder of resumes came from engineers I had worked with
directly.

Does anyone else think this is a huge caveat getting thrown into a blender of
numbers? Why does this person's opinion even matter? Why should I take this at
face value? I'm not trying to say resumes are a good indicator of anything,
but neither is this "study".

~~~
apolretom
Thank you. This entire 'study' is nonsense because this recruiter has no idea
how 'strong' these candidates really are. She only thinks she knows, just like
every arrogant jerk who's ever conducted a technical interview.

~~~
cowls
Yep, nonsense in = nonsense out. This "study" is pointless.

------
JimboOmega
As someone trying to hire, I find myself going through resumes for the firs
ttime...

And honestly, my primary metric is if the word "rails" appears anywhere (It's
a ruby on rails job). I might even let that go if I saw a cover letter
explaining why they liked rails (but maybe don't have professional experience
in it).

Honestly this is a pretty low bar. And the way I've been doing it, the phone
screen that follows is pretty softball. But after that, I give out the coding
exercise...

If you complete it, you get an in person interview for the most part. But all
the rest of it - looking at resumes, the phone screen - sort of seems like a
waist of time. I don't care how big a game you can talk, if you can't do the
coding exercise (which, btw, is the most common outcome - they beg a couple
extensions and then give up), then... oh well.

~~~
ownagefool
Honestly, if hiring permenant staff for long term occupation, I probably
wouldn't even require that much. If they have php, perl or python on their CV,
then they'll have had the opportunity to know everything else you'll want them
to know.

------
hw
It's hard to gauge a person's qualities from a resume. Things like culture fit
(extremely important IMO), fast thinker, quick learner - are all aspects that
can't be garnered from a resume. IMO, resumes are only a decent filter for
experience, and provides a baseline for the interview.

There are many I've interviewed that padded their resumes and said they are
experienced in something they really aren't, and there are some who dont have
much experience but are smart and quick learners.

Without a resume, what else can we go with when it comes to hiring? In my
career, the best hires have always been from two sources:

\- someone i've worked with and trust before

\- someone who was recommended by someone i worked with and trust before

~~~
terranstyler
Are you hiring right now?

I wrote exactly these two tags "fast thinker" / "quick learner" in my CV /
cover letter / LinkedIn profile and I removed them a few months later because
from my experience it looks like they drive recruiters away or scare them.

~~~
ghaff
I can only speak for myself but terms like that set off my BS meter and
probably make me think at least marginally less of whoever sticks them on
their resume. They're vague and unquantifiable. They're of a class with words
like acclaimed, industry-leading, and so forth in copy describing products.

~~~
terranstyler
Yes, for that reason I took it off, still the question is how can one
communicate that one is? Should you write "constantly programmed faster and
leaner and with less errors that his colleagues?". I don't think there is a
way to communicate this but I still think it matters.

You can easily determine if some one is a BS guy in a technical interview
anyway, so I don't think, BSers are very frequent in IT and much less so in
programming.

~~~
ghaff
Results, achievements, accomplishments. Frankly I don't really care if you
were better than the guy in the next cube. He might be an idiot or a complete
slacker.

And I'm not sure I wouldn't get negative vibes from someone who felt they had
to position themselves by de-positioning the people they worked with.

>You can easily determine if some one is a BS guy in a technical interview
anyway, so I don't think, BSers are very frequent in IT and much less so in
programming.

Of course they're frequent. They are everywhere.

------
jayhuang
I feel like this data is a small piece of the age long debate about hiring
methods and competence/success indicators.

There's been a lot of data about how even people who think they are experts at
finding good candidates are really no better than someone flipping a coin.

How then, if the line between "strong/less strong" candidates are so blurred,
does Aline draw the line between "strong/less strong" herself? Isn't the way
she splits the candidates' resumes also part of the exact thing she's trying
to measure?

 _> "...then even if my criteria for whether each resume belonged to a strong
candidate wasn’t perfect, the results would still be compelling"_

~~~
itsdrewmiller
I don't think you actually demonstrate this statement:

> if the line between "strong/less strong" candidates are so blurred

It is hard to tell prospectively whether someone will be a good programmer. It
is not too difficult to tell retrospectively. (Any research that tries to
measure competence/success indicators must be using something as its dependent
variable, right?) The line you quote is specifically about the fact that
resumes could be meaningful even if her competence assignments were not.
Resumes seem to fail at that test as well.

The biggest threat to validity would probably be that different people will be
good/bad developers in different environments, and that this effect is very
strong. Then each reviewer could be good at selecting for success in their own
company, but they would only agree with each or with aline to the extent that
their environment was similar to that of other companies or the ones that
aline placed those engineers at. I am pretty comfortable rejecting this theory
out of hand myself.

------
3am
A resume is a list of qualifications, and to see how a candidate frames
themselves. They also set expectations for me, the interviewer for the
questions I would like to ask (they say they're a Node and Clojure expert? I
will tailor my questions to verify that).

It's also a way (in addition to the cover letter) to quickly judge their
communication skills.

I wouldn't hire someone without 1) a cover letter 2) a resume 3) a phone
screen 4) review of their projects (ie github) 5) a team interview 6)
references. Granted, I don't have to do it at scale.

It's time consuming, but not as much as a bad hire.

~~~
ghaff
I tend to agree that a lot of the hate on resumes seems to be missing the
point. Sure, if I know or know of someone, maybe a resume doesn't add a whole
lot. But they provide: \- A first pass at there being some match between
experience/background and those needed for the position. \- Some guidance for
the interview process. Frankly, a lot of the details on the resume don't
really matter all that much to me but, overall, it usually gives me a sense of
which avenues are worth probing in more detail and which ones I can skip over
fairly quickly. Sure, I could draw a lot of this out during the interview but
it's easier to read over a couple of pages in advance and spend a few minutes
thinking about how to spend the interview slot.

------
iN7h33nD
The real questions are: What would be better than sending a resume? Should the
job ask for a resume as well as have every applicant submit a project
somewhere, one which will be "unit tested" automatically to filter candidates?
Should they just ask for the project?

Should there be something other than a resume like a timed coding test or
something (where the applicant needs to take half an hour and write a program
to do X in the language that they will need to work in, probably something
really simple)?

~~~
wallflower
A friend of mine made it through the initial interview stages at SoundCloud.
He was then given three days to build an iOS app using the SoundCloud API that
showed off his experience and skill. I like that approach because three days
is a nice length of time to build something you can be proud of. He was
interviewing for the iOS team, of course.

~~~
Iftheshoefits
Was he paid for his work? If he wasn't, he's part of the problem in hiring
processes in our industry.

~~~
marktangotango
Agreed, I did a coding exercise for the Nerdery once, I epended about 8 hours
on it, no one even reviewed it. Total waste of time. Yes I am naming them
intentionally, I felt that behavior was antagonistic and exploitative.

~~~
Iftheshoefits
This industry is filled with what I've come to call the "Naive Narcissist".
There is a very large percentage of developers who are so eager for "kudos,"
renown, and other intangibles that they will happily subvert their own
livelihoods and contribute to the culture of relegating programmers to second-
class commodity labor in the pursuit of overcoming a (usually arbitrary,
artificial) challenge.

I come from academia. I know what its like to work toward a goal for the sheer
pleasure the challenge brings without expecting (much) compensation. But
that's academia. This is (typically) private, for-profit industry. There is no
_good_ reason to not demand fair compensation and respectful treatment that
includes not being given unpaid monkey-work to "show off" for some ass with a
superiority complex.

------
aercolino
Many recruiters don't read resumes and many of those that do, don't understand
them, be they from HR or IT depts.

Arrogance, disrespect and plain unpreparedness.

~~~
raverbashing
Actually, from my last experience, winning the recruiters was easy, it was the
company RH/Engineers was tough

They're the first step in the funnel, if you can't get through them your
resume usually needs fixing.

And of course the interviewing flaws that are discusses several times on HN
play a part as well.

------
learnstats2
If you exclude a single outlier (a candidate rated poorly by the experimenter
scores 100% in the resume test), the resume test doesn't look too bad.

Apart from that one, the consistently well-rated CVs are all from the strong
side.

So it could be argued that CVs work pretty well for recruiters - hiring from
the best CVs makes it unlikely you'll hire a weak candidate.

~~~
jschwartzi
This also gives us concrete data on what makes a good CV, provided anyone has
access to the ratings and can also come up with a good classification metric
to extract attributes.

------
iuguy
Funnily enough I've been working on this a lot lately for a book I've been
writing[1].

It seems there are several audiences for a CV (recruiter, hiring manager,
supporting interviewer) and a fundamental error that people make is writing a
CV for more or less than these three types of people.

The fundamental truth is that no-one wants to read a CV. They're at best an
advert, but people tend to overstuff them or fill them with things irrelevant
to the position they're applying for, so they get ditched by people who have
tons of them to read through.

I have a free email course about career hacking for anyone that subscribes to
my book's mailing list. It's focused on people who want to become penetration
testers but the career material is applicable to anyone wanting to get into a
discipline that they're not already in.

[1] - [https://www.rawhex.com/](https://www.rawhex.com/)

------
fredophile
I'm not very surprised that resumes aren't a good indicator of performance.
They're real only useful as an indicator of experience. In other words they
tell you about quantity and not quality. I'd say if they seem reasonable for
the role then move them on to the next step of the hiring process. Every
interview process that I've been involved with has had a series of increasing
expensive steps designed to find specific information and weed people out as
early as possible.

It's also worth noting that several of the criteria people used to reject
candidates in the article aren't good predictors. For example, lack of
pedigree doesn't tell you much. People from a variety of backgrounds can be
good or bad as coders. A good or bad pedigree can be a useful indicator.

------
rurban
They remind me of these folks: [http://www.commitstrip.com/en/2014/11/05/when-
a-project-mana...](http://www.commitstrip.com/en/2014/11/05/when-a-project-
manager-speaks-to-another-project-manager/)

------
photoJ
I am not sure how I would feel if my resume was posted here. I've already
found someone I was able to quickly identify by looking at the resumes. I
would have expected more discretion on the recruiters part.

~~~
leeny
Aline here. I got permission from everyone whose resume I used in this
experiment.

~~~
photoJ
Fair enough....

------
ddoss
Totally agree! KeepSafe is taking this exact approach to hiring right now.
[https://www.getkeepsafe.com/noresume.html](https://www.getkeepsafe.com/noresume.html)

------
freshflowers
As a hiring manager, I want those resumes as an initial filter. No, they don't
say much about engineering skills, but they tell me quite a lot about a number
of other things.

Things like communication skills, priorities, attention to detail and
motivation are strongly reflected by someones resume.

The only people who can afford to not put serious effort into their resumes
are people that have an online (Github etc) or offline (network) footprint
that speaks for itself. But those also tend to be the people that don't get
recruited via the formal application process.

------
hdennis
In the part of the article that lists "Rejection Reasons" one rejection type
is "Too Enterprisey". Could someone please clear up what that means for me?

~~~
ghaff
This blog post discusses it a bit.
[http://jobtipsforgeeks.com/2013/03/07/enterprisey/](http://jobtipsforgeeks.com/2013/03/07/enterprisey/)

It wouldn't shock me if it also gets used as code for things like "hasn't
worked at a startup before" or, frankly, "too old."

~~~
fecak
I wrote the piece you linked, and I do see still see that feedback on some
candidates almost two years later. I think your interpretation of this as code
for other things is fairly accurate, although not as much for the 'too old'
piece. I've heard it for even the 7-10 years of experience range (though
perhaps that could be construed as too old for some).

------
Fede_V
Interestingly, why didn't she do some kind of text mining/classification to
try to show what features gave the highest discrimination between the two
classes?

------
joelgrus
I don't see anywhere the Ockham's Razor explanation that bad candidates fudge
their resumes in order to make themselves look like good candidates.

~~~
pekk
I think it's even simpler just to observe that the way someone chooses to
write and target a resume has no particular relationship to how well they
would do the job.

------
Moto7451
Resumes are just a broad filter for skills and a way to find useful questions
to later flesh out a candidate and their competence/experience level. It
shouldn't be shocking that code samples and/or a short programming test and a
phone call will tell you more about the candidate, and if they should come in
for a full interview, than blind keyword bingo.

------
cpach
Keep in mind that sending out resumes is not the only way to get a good job.
Some relevant previous discussions:

[https://news.ycombinator.com/item?id=8338859](https://news.ycombinator.com/item?id=8338859)
[https://news.ycombinator.com/item?id=8532886](https://news.ycombinator.com/item?id=8532886)

------
moron4hire
My own experiences with interviewing HR pre-filtered resumes bears this out,
so I can't imagine what the entire firehose is like.

------
mkremer90
I can tell you that I got interviews at 6 "startups" (ranging from garage to
multi-million dollars) in San Francisco without giving any of them resumes.
And I live in Milwaukee, so they even had to fly me out.

Seems like SF is on top of it, Milwaukee on the other hand, only cares about
how many years of experience you have. Nothing else.

------
lowglow
Some of the worst people I know also have the best resumes. I think they've
learned to optimize where they can.

~~~
eo3x0
It also works the other way around. Some of the best people I know have
horrible resumes or no resume at all. Resumes are probably subject to the
Dunning-Kruger effect that tends to plague software development.

------
vishalzone2002
I like the article but really if resumes suck then what doesn't. Companies
look at resumes for 1-2 minutes on top will they ever have time to browse
through hundreds of lines of code, projects, portfolios, etc. I don't think
so.

------
rezashirazian
for anyone relating with every "engineers suck at writing resumes" comment;
I've been using my stackoverflow profile as a resume and it's been working out
great.

------
rumcajz
The interesting part is that recruiters seem more in agreement when
identifying low performers. When faced with a high performer their scores
differ wildly.

~~~
ghaff
It wouldn't especially surprise me if that were the case. It's a lot easier to
identify people who don't meet the requirements of a position than to intuit
how good a job they'll do based on paper qualifications. You'll make mistakes
in both cases, but more in the latter.

Testing like SATs are similar. A low score is probably a much better predictor
of (lack of) success at an elite school than a high score is a predictor of
success.

------
fiatjaf
Resumes suck for hiring anyone.

