
Hiring Is Broken? - rspivak
https://software.rajivprab.com/2019/07/27/hiring-is-broken-and-yours-is-too/
======
dahart
> Anyone can glamorize and exaggerate the work they have done, and make it
> sound a lot more impressive than it actually was

My personal experience interviewing is that people cannot easily glamorize
their past projects when pressed for details. It might be easy to make it look
good on a resume, but hard in person during a discussion with follow up
questions.

I think asking about past projects is a fantastic interview question, and it’s
very easy to get a good sense of what they did, what they were trying to do,
how much was their leadership versus others, how successful it was, how much
effort it took. All you have to do is ask questions about it, and not take the
resume item at face value.

Personally, I find the open ended nature of the past projects question to be a
better predictor of future performance than almost everything else on that
list.

~~~
username90
Or they could just lie and tell you from the perspective of another dev on
their team, or even combining the achievements from several of them at once.
Of course most people wont lie a lot but this style heavily favors those who
do so you will get a disproportionate amount of liars on your team.

~~~
wslh
You can discover the lie asking very technical questions on how the solved
some issue. They will answer at the greatest level of detail if they did it
themselves.

~~~
marktangotango
Provided you or the arbitrary interviewer have the technical background to
evaluate the answers! I once had reason to view the resume of a former
colleague who took all credit for a major project I implemented. This project
involved parsing and a particular parser generator. He worked on it after I
implemented it, but he claimed it all. And he was knowledgeable enough to back
that claim up!

~~~
smsm42
> And he was knowledgeable enough to back that claim up!

If he worked on it and could convincingly fake it, I - as a recruiter -
wouldn't care too much if he embellishes a bit and claims he also did it from
the start. Maybe he factually didn't, but if he's good enough to make me think
he did, there's a decent chance he would be good enough to actually do it for
me. Not a certainty, there's never certainty, but a good chance. Of course,
given the choice, I'd prefer the one who actually created it, but one who
worked on it and knows it well enough is not bad either.

~~~
palerdot
The point is the hiring method attracts people who are both not genuine , to
admit that they just jumped in on an impressive project and insecure enough ,
that they think they should claim everything as their own ... It doesn't
matter if they actually possess the technical skill as there might be
behavioural issues between this person and the rest of the team.

------
esotericn
This article appears to be an extremely long-winded way of stating that you
don't have to pick from the top-end.

Which is true. Companies know this.

Most of the stuff I read here is basically made up of people who aren't quite
the best moaning that they couldn't get a job at Google or whatever. Life goes
on. It is impractical and not a good thing for every software developer, even
the very good ones, to pile into the same companies.

Not everything is set up as a perfect procedure for you.

And even if it was - OK, so you get the job and the Stanford grad doesn't. You
swap places. Does that make a better world?

I encourage new developers reading these sort of posts to just ignore the
fluff and plug on. You'll get there.

And if not? In five years you might want something else entirely.

I wanted desperately to work at an investment bank as a new grad.

I'm very happy with the path my life has taken instead.

~~~
Retric
I have generally been rather disappointed with Google/FANG software
developers. These companies generally though not always avoid the bottom 1/3
of the talent pool, but that’s about it.

Effectively they simply select for people willing to hack their hiring
process, which also excludes most actually talented developers. Resulting in a
few very talented people, and an overall average workforce.

This is also why most internal projects at these companies are about average
for the industry and these companies focus so heavily on acquisitions.
Consider the differences between iOS, Android, and Windows phones was not so
much about software quality as much as business models.

~~~
esotericn
Wouldn't surprise me at all.

Fundamentally, companies do not hire for raw technical ability.

Would you hire Linus for your bog standard dev role? Of course not. He'd be
bored in days.

You probably wouldn't want a supermodel as a life partner.

The whole thing is about selecting model employees. People who will rock the
boat in the correct ways; need money, but are neither impoverished nor
independent; are reliable; and so on and so forth.

It's not "hiring is broken". It's "you misunderstand what employment is".

~~~
0x445442
> Would you hire Linus for your bog standard dev role? Of course not. He'd be
> bored in days.

I've often wondered if Rob Pike or Guido Van Rossum went through the same
interview process at Google that we all hear stories about. I'd be very
surprised if they did and my guess is, for them, it was much more of a
negotiation of what they were going to work on and what their compensation was
going to be.

~~~
neilv
I asked a recruiter there whether someone like that (like the creator of a
popular programming language) would have to go through the normal new-grad-
style whiteboard coding hazing gauntlet (phrased diplomatically) interview
process that they were expecting me to. The recruiter said no. I decided not
to interview, because it turns out the hazing wasn't something "everyone" had
to do, and I just didn't rate decent treatment.

The next time a recruiter from there cold-contacted me, I asked again. IIRC,
that one said a person could skip at most only the first part of the
whiteboard coding hazing (phrased differently), if someone at Google could
vouch for them, but that _everyone_ had to do the second part of the hazing,
before they could advance to the interviewing phase of professionals with
mutual respect (phrased differently). I decided not to interview.

So long as their process comes off as one-sided, arrogant, and negging, the
company doesn't seem like a place I'd want to work.

It's like you're meeting a first date in the line at a cafe, and they're
physically attractive and rich, but they're rude to the barista -- bullet
dodged, we're not together, and I'd like my coffee to-go, please.

~~~
0x445442
At this point in my career I won’t do coding tests or problems at home or over
the phone. I’ve done my fair share of hiring and I’ve never needed to resort
to such things.

Being asked to perform these tasks is actually a pretty good litmus test to
filter out companies. Also, I expect a certain degree of deference given my
resume shows a 25 year history of implementing and delivering systems.

~~~
thoman23
How much hiring and interviewing have you done? I've seen countless resumes
with 25 years of stated glorious achievements, and they couldn't write a for
loop.

~~~
0x445442
I've done quite a bit and have never had any difficulty sniffing out "gloss"
with just a few minutes of questions over the phone using the applicant's
resume as a starting point for the conversation.

When you're focused on system implementation, delivery and maintenance you can
pick one of the past projects listed and start probing. It's not hard to
quickly get a picture of what the candidate did and didn't do on the project
and whether or not they're blowing smoke.

~~~
neilv
Exactly. Of course, we do have to be a bit careful how we ask about past
projects, to avoid the appearance of being exposed to IP, but it's doable. We
can also just talk about hypothetical design problems (and they can learn
about us based on the questions we ask, even if we're not doing a
collaborative exercise). But no whiteboard CS101 coding negging.

------
ebiester
This goes back to the idea that there is a "fungible" programmer that is
universally substitutable between companies. In some companies, I am a highly
valuable addition. In others, I am mediocre at best. I think of this like a
sports team - a highly performing sports team both needs people of the highest
skill and complementary role players that are the best at a valuable skill
even if they aren't the best at every skill. It would be great if every team
member was excellent at code craft, debugging, collaborating between teams,
researching new third party solutions, and whipping up prototypes, but your
team may not need all of those.

I don't like the term "culture fit" because it is a proxy for people who are
already on the team, and often gets confused for "white, male, and likes to
drink with coworkers." That said, I highly value "work style fit" and "team
need." Are you running into code quality problems? Find someone who thinks
about code quality. Do you need someone who can get a prototype to sales
quickly to close a deal? That's a skill, and it's not a generalized skill.

All of the cases above _can_ be valuable, but only contextually. Figure out
what your team needs first, then craft your interview process around that.

(As for me? I have been in management for a while, but I am at my best in
developing high functioning teams, collaborating between teams to solve larger
problems, and crafting high quality solutions. I am not at my best in deep
debugging sessions and quick prototyping. If it isn't my own startup, I might
not be the ideal choice for employee 1-5. I may be the person you bring in
when your team is expanding rapidly and you're running into scaling issues.)

~~~
streetcat1
So if you are not good at coding/recent tech, how do you know if a given
solution is high quality or not?

~~~
ebiester
I am good at coding. I am a good enough debugger to get through most cases. I
am good enough at getting a prototype out. However, if you are looking for
someone to sort out some deep and ugly multithreading issues, there are people
who are better at it than me.

If you are running an agency trying to drum up work, there are people better
than me.

If you have a codebase with no tests and everyone is afraid to touch it, you
want me. If you have three teams that are trying to sort out a problem but
nobody will dig in, talk with everyone, and sort out the technical issue, you
want me. That’s the difference.

Now, as for determining high quality code without having that basis, I would
start with Robert Martin’s book “clean code.” At the very least, it can teach
the basics of understanding a code sample. However, it can be a difficult
problem. I might think about a consultant to judge those and use behavioral
interviews to judge the rest.

------
cbanek
While hiring is inefficient and biased (some would say broken, which I won't
disagree with), I think performance reviews are equally so. Companies don't
really know how to evaluate performance well, and without bias. Many of these
same problems exist in performance reviews:

> Ask them for references, Do back-channel references

Asking people for feedback, peer review, 360 review, etc. This is somewhat
effective, but if people can choose their own reviewers, they will of course
get only the good info, same as for interviews. If anyone can submit feedback,
you're likely to get people who don't like an employee to write stuff about
how terrible that employee is, which might be exaggerated.

> Take home projects, Audition for the role as a contractor, Ask them to
> describe their past projects, Ask for source code from significant projects,
> Pair programming on a “real” problem, Live Coding Exercises

All of these are meant to try to get real signal on how the person would
perform their job. But even when people are employed on a team and you can
observe them at any time, it's hard to quantify their performance. Do you look
at their commit count? Bug count? Lines of code? Any metric has its weakness,
and people game them.

Interviewing is a game of making a decision with incomplete information. I
would say we aren't much better having a whole lot more information about how
someone works, when trying to give an accurate performance review.

If we can't accurately judge performance of the people we should know, I think
that proves we can't accurately judge performance of people we don't know.

------
oneepic
This debate will keep happening for years to come, but everyone's just
repeating the same talking points over and over. I have to sum up my thoughts
like this:

I really don't think we're ever going to find a perfect hiring method. You
will always have a nonzero chance of false positives and false negatives, and
there will always be downsides that piss people off. So, pick a reliable
hiring method(s) (talk about experience, solve whiteboard q's, do take-home
projects, or whatever) and try to make it better over time. If you don't like
it, you can switch to another method and start improving on that. Etc. But
your method will always fail some good hires and pass some bad ones. It sucks,
but we are still able to hire mostly good/trainable people, so we should stop
worrying and move on.

I hypothesize that there are a lot more interviewees than interviewers getting
involved in the debate. I only have to tell the former group to keep trying
and stop complaining. If you're not sure why you're failing interviews, that's
a solved problem -- just do mock interviews with your friends or on
interviewing.io. But stop blaming the process for your own failures.

~~~
ChuckNorris89
_> but we are still able to hire mostly good/trainable people_

Wow, you're actually _training_ people? Kudos to you, I haven't seen that in a
looong time.

In my current area, everyone only looks for seniors or experienced devs. New
grads without connections can suck it basically.

~~~
oneepic
At this point my team mostly hires juniors. We train them on whatever they
don't know that they need to know here.

We hired a mostly self-taught engineer out of college a year ago (I started
~2mos ago). Had almost no idea about webdev, or C#/.Net, or web APIs, but we
taught her on the job. I'm similar, since I had no experience with web APIs
before joining but I had experience with C#.Net, Asp, etc.

------
otras
One thing I’d add is that live coding exercises can vary _widely_ in quality.

> If you solve the problem, you’re scored highly. If you don’t, you’re scored
> poorly.

In my own opinion, this is a terrible way to look at these problems, though
many people do use this metric. This is further emphasized by HackerRank-style
exercises where you have to pass all test cases. This is robotic and not
empathic at all.

A more fluid and dynamic approach that focuses on the candidate’s approach,
ability to clarify, and problem solving, even if the correct answer isn’t
reached, can still give valuable signals

Disclaimer: I work and give interviews at a large tech co that uses exercises.

~~~
jcims
I wonder if there is any value in having a few candidates do a group project.
Would probably be a mess but might be informative, you could at least identify
the bullies and dickheads pretty quickly.

~~~
kvonhorn
I could imagine that this would be the worst way to evaluate candidates I've
ever heard, especially if not everyone got hired. I think this would only be
an appropriate evaluation metric if your end product were actually a reality
TV show focusing on this process.

Maybe do it Survivor style, have 12 candidates/new grads start, give them the
goal of producing an MVP CRUD app, and start voting people out of the scrum
after a couple of days. Winner gets a 6 month contract to hire, 3 people have
their careers ruined, and the rest bump around the valley for a few years
before moving back to wherever the hell they came from. The memes that come
out of this alone could make this show a valuable cultural contribution.

~~~
geggam
Ever work in a startup ? This feels like a startup.

------
ddebernardy
The biggest issue isn't one mentioned in the article. No amount of hiring
tricks and hacks will work around the fact that hardly anyone (including most
managers and HR pros) gets trained on how to review a resume, conduct an
interview, and evaluate a candidate.

~~~
codingdave
This does not ring true based on my experience. Where have you worked where
you found this to be the case?

~~~
tidepod12
I worked at one of the largest global consulting companies (and I have enough
friends in the other major consulting companies to know it's the same in most
of them).

I was a relatively junior person working there in my early-to-mid 20s. It was
common practice for me and my peers to be asked to review resumes and filter
them, as well as be an interviewer every few months. I never once received any
kind of training on interviewing or resume review. Not even the 10-minute-
cheesy-corporate-video kind of training. Hell, not even a quick 1-pager or
chat on tips or things to look for. It was literally just "hey here's a stack
of resumes, please filter them".

------
drchewbacca
Another related question is how would you evaluate the quality of hires? So
you hire for a team of 5 people who complete 83% of the tasks you set for them
that year.

How do you know if you hired well? Is this an excellent result or a terrible
one? How do you know how well each of those 5 did and how well the team would
have done with other people in the roles?

~~~
okaram
What makes this even worse is that you have no info on false negatives ... How
would the people you didn't hire would have done?

------
alexandercrohde
For those of you not reading this article (appears to be most) - this is a
META article:

1\. Main thrust is that all the HN posts on this topic are stupid and
formulaic

2\. Argues that numerous the OTHER posts merely list the negatives for one
method of interviewing A, and the positives for another method B.

3\. Lists every method of interviewing, showing glaring problems and
advantages in each of them. Obviating the need for the discussion ever
happening again.

4\. Asks for something akin to _evidence_ if we are going to drive the
discussion forward.

~~~
necovek
I've read it, and while it starts with a request for a double-blind study, it
immediatelly moves on to listing a subset of interviewing techniques. It is by
no means exhaustive.

If the focus was to be on evidence, it would provide a framework for such a
study. It generally sounds pretty hard to do anything of the sort.

~~~
alexandercrohde
>> I've read it, and while it starts with a request for a double-blind study,
it immediately moves on to listing a subset of interviewing techniques.

Uh, what? It start by saying "I can’t keep track of the number of articles
I’ve read about hiring in the past few years. Inevitably, they all follow the
exact same format"

That point is true.

The question then becomes "Why does the community generate spammy articles
without making any sincere attempt at intellectual progress toward a better
system?"

And the answer is probably that it's not in any individual's self-interest. HN
members want to whine about not getting hired by google, companies want to
promote themselves, people like me want validation.

The only people who have any incentive/interest in objective hiring are
companies that specialize in that purpose (e.g. hired, interviewing.io). But
there's really no reason for them to divulge their secret sauce, and even if
they did, people would probably only upvote it if it let them feel less
insecure about getting rejected by google.

------
coding123
At one (large) company I worked at we hired the guy that basically invented
one of the technologies at Sun behind one of the larger JSRs - like an entire
standard API for one of the Java EE products (not going to say which) for an
architect role. I have no idea why we hired him. He basically sat idle all the
time asking what he was supposed to do. He randomly would make charts and show
people. He was older, out of touch with most of the team, and just kinda
present at every meeting with no specific task or role. He had advice here and
there that most of the people at the table were already thinking through. I
left before I found out what happened to him. Nice guy though.

Hiring might be broken for keeping out the best of the best, but as long as
you work at a company that isn't afraid of firing/laying off, hiring isn't
_fully_ broken.

~~~
eropple
_> as long as you work at a company that isn't afraid of firing/laying off,
hiring isn't fully broken._

Yes, it is--it is just broken in a way that privileges the company over its
employees. Firing somebody (absent flagrant abuse and the like) is a failure
of management and leadership.

------
erikpukinskis
I don’t get how “Look at what University they went to” becomes “Check if they
went to Stanford”.

There are lots of good schools. If you got a BS in Computer Science from UIUC,
that means something to me. That’s a good school and you got through it.

Same with jobs, why does “Look at their job history” mean “Check if they went
to any big name tech companies”?

You look at the companies, look at what the company does, what the applicant
said they did for them, and ask them questions about what that was like. It
doesn’t really matter if it’s Google or it’s Pet Food Express, the important
questions are the role and the work.

------
bentona
I wonder if people describing hiring as "broken" have only experienced the
process from one side. Hiring is a one of my favorite things to work on at my
software engineering jobs, because it's a super-hard problem that is always
available. It hasn't been "solved" and lots of people do it in ways that are
obviously sub-optimal, but I don't think anyone knows how to do it optimally.

I think this is what TFA is getting at.

~~~
projektir
Being on the other side of the process has only convinced me more of how
broken it is. There are lots of baseline errors, biases, and insufficient
attention given to the process that are quite obvious but a lot of people
either fail to see them or refuse to see them because they don't want to admit
that their hiring process is not better than rolling dice.

As a basic example, in a lot of places you get very little advance warning
that you're going to interview someone.

Test problems or assignments are often not tested or even looked at by
existing employees, so often you don't even know that your current team would
do well on them.

Sometimes interviews happen without any intention at all to hire the candidate
(wtf).

------
track_me_now
What about focus on direct referrals who have worked with a current employee?
The highest signaling characteristic I've ever found is someone who was
recommended by a former coworker; there's a transitive relationship that seems
to capture both the technical skills and a comfortable fit.

I realize this doesn't scale to the rapid growth of some companies, but most
of us need a more modest supply of talent vs. giant pools of people.

------
tylerFowler
As most of those bullets point out, nearly all of these are good indicators
for some people and bad for others based on what kind of person they are or
what their environment might be. It seems like the ideal would be to allow
candidates to choose what format they think would best showcase how they work?
Choose-your-own-adventure style?

Assuming you had some way of making comparisons across these different formats
(easier said than done, I'm sure) it seems like you would end up with "truer"
signals. It also seems like you would get an extra signal based on what the
interviewee chooses. For example someone who prefers live coding/pair
programming sessions might be someone who leans on and thrives more in ultra-
collaborative/brainstorm-ish settings. Whereas someone who prefers take home
assignments maybe is more productive being able to sit on a problem and
iterate, then collaborating after being able to articulate the specifics in a
code review type setting. Neither are wrong, nor are they mutually exclusive
within an organization but in terms of team placement or general "culture fit"
(whatever that means) it seems like something that's useful to know ahead of
time.

Of course you might also allow people to choose which route they think they
can hack more but I think that problem is more of an implementation detail of
any given method. Asking for a solution to find the perimeter of a group of
pixels at a video streaming company is better than asking someone to invert a
binary tree at virtually any company. Asking someone to build something real-
ish with a hundred valid solutions is better than asking someone to implement
a trie with a thin search interface on top. And so on.

------
ltbarcly3
The older I get and the longer I do stuff the more I realize that everything
is broken and there's nothing you can do about it but try to do the things you
are doing well, learn from people that you think are doing something well, and
teach people where you have figured out how to do something well. None of
these things are blanket rules you can read in a blog and then follow.

------
clairity
hiring is really simple: you can straightforwardly filter out the obvious
no's, but beyond that, it's a crapshoot.

basketball analogy time! (my favorite =) the NBA employs 450 of the best
basketball players on the planet, and at any given time, the league is
evaluating a few thousand more (out of hundreds of millions of basketball
players, out of ~7.5 billion people worldwide). all the easy filtering is
done. every year, the 60 most promising players are drafted. and because
they're among the most promising, most of these 60 players _should_ become
regular NBA players. in practice, only 5-10 will do so in any given year, and
you have _no idea_ which ones it will be as they all look promising (e.g.,
laker kyle kuzma drafted 27th in 2017).

in short, once you get down to the 10-20 candidates you think will fit a given
job, you might as well just draw a name out of a hat, work with them for 3-6
months, and re-evaluate. there really is no shortcut to this (not even for
google).

~~~
dredmorbius
Pro sports is an interesting comparison, in that it has a very long-chain
training and recruiting system, starting as young as age 5-10, and including
sport leagues and/or school teams to refine talent. Though professional
recruiters may not be looking at younger players, sports leagues and schools
are quite conscious of talent.

Professional lifetimes are also frequently quite short. For gymnasts,
competing life is virtually over by age of majority, for Americna football, a
few years in pros is typical, though some careers last longer. Baseball,
cricket, tennis, and golf are longer-lived exceptions.

I'm not saying this as a rabid sport ethusiast, and the transfers to technical
recruiting may be limited, but it's at least an interesting system to
consider.

Other uneven talent/fame domains are theatrical performance (acting, music),
and, possibly, writing.

~~~
clairity
yes, mainly, i'm using the nba to show that even among folks who are
constantly and publicly evaluated for ~10 years (the time from discovery to
draft), you have ~10-20% chance of hiring the right player at the right time.

so then, why would one expect to be able to evaluate a candidate for a few
hours and do better than that? if anything, professional (office) skills are
harder to evaluate than athletic ones.

reasonable folks should expect only 10-20% of hires to be good fits,
regardless of the skill or integrity of the hire.

------
yellowapple
I recently got thrown into interviewing a bunch of NetSuite developers (so
lots of JS programming), and so far my strategy has boiled down to:

1\. A verbal pop quiz about some reasonably-complex NetSuite-related
programming topic/task (i.e. "on a high level, how would you go about
implementing $FOO, given the constraints $BAR and $BAZ?")

2\. Digging into past projects/experience and gleaning info on how involved
the candidate was with those projects

3\. If available, look at an existing programming portfolio / GitHub account /
etc.

I feel like these three things tend to cover my bases, knowing full well that
they're flawed assessments (but flawed in ways I can control and adjust/tweak
as necessary).

------
CalChris
The article has a lot of good advice. However, hiring doesn't end with the
offer letter. There's also on-boarding which is largely left to the manager
and varies considerably. Perhaps the writer could do a sequel on on-boarding.

------
beeblebr0x
I've interviewed many candidates for cloud native architect positions. None
could tell me what important tools/patterns like TLA+ or CQRS and none could
discuss the concepts once explained. Instead of recreating the binary tree
from an array of in-order, depth-first-traversed nodes, which is an extremely
narrow minded test of someone's skills, I want them to describe how they build
reliable distributed systems. LeetCode, HackerRank and the companies whose
interview process gave rise to these sorts of services misunderstand the idea
of software engineering.

~~~
9nGQluzmnq3M
If you want somebody to describe how they build reliable distributed systems,
then ask them to describe in detail how they would build one for a specific
use case, instead of quizzing them on alphabet soup.

------
awesome_dude
The problem isn't limited to engineering hires, ever bought a house and had to
go look for a builder to check the house is in good nick? What about the
lawyer you use for the conveyancing?

How about an accountant to do your taxes?

Further, how do you define who is the best? Someone who does a so-so job in a
short amount of time? Someone who checks every possible decision branch,
explicit or implicit? Someone who writes code in a clever way.

You're only ever going to see the skills you understand. Anything that you do
not understand you will miss.

------
nafeydev
Whats the general consensus on take home projects? How helpful are they?

~~~
gravypod
I haven't been able to find a better screening method than take home projects.
A major issue that I find when watching hiring take place is people don't
separate learnable/domain specific skills from the "inherent" skills you need
as an engineer. Hiring someone who has a 10 year track record as a software
engineer in systems software for a web-stack backend role should be an easy
"Yes" if they are a skilled software engineer. Because of this I usually
encourage people to make take home problems that are limited in scope and
follow the restrictions:

    
    
      - Should not take longer than 3 hours for an inexperienced developer.
      - No learnable skills tested like tooling, language, and domain experience.
      - Simple to understand problem 
      - Problem should be obviously mappable to a solution
      - Provide sample input and sample output data (only 1 case). 
    

I then score using the following questions

    
    
      - Did the code work on the sample I provided?
      - Were edge cases in the spec accounted for?
      - Has the engineer followed a language standard (PEP/PSR)?
      - Were docs (install, compile, comments) provided?
      - Were unit tests provided?
      - Were sample cases the engineer ran manually provided?
      - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year.
    

I think the actual project should have low bearing on completion and the state
and cleanliness of the code has a higher mapping to quality.

~~~
hysan
Would you be able to give an example of how limited in scope you're talking
about?

Is it just a single "write a method that does this" type problem? I ask
because I did a take home very recently which I know I could knock out
quickly, but it took much long because everything you listed ballooned the
amount of time it took me to complete it. Specifically:

    
    
      - Has the engineer followed a language standard (PEP/PSR)?
    

For JavaScript, it takes some time to setup a new project from scratch with
linting and formatting configurations. Then documenting it in your README.

    
    
       - Were unit tests provided?
       - Were sample cases the engineer ran manually provided?
    

Once you go beyond a few "features" to write, this balloons in time due to
both writing it with good descriptions and documenting it for the reviewer.

    
    
       - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year.
    

If what you ask is of sufficient complexity, it would just be normal to take
time to think about what the interviewer is expecting here. Like what future
features could there be? How might this be used in a larger codebase? etc.
Then once you've decided on this, you'll want to spend time commenting and/or
writing up an explanation in your README about your design choices.

Lastly, this isn't mentioned but I did this on the take home I recently
completed - using version control and properly branching & merging on each
deliverable. Doesn't take time, but if you are making atomic commits with good
comments, that's just another way for you to lose time. Of course, I don't
think the fact that I did this is going to be noticed as it wasn't written out
as a requirement.

If you notice what I'm nitpicking, it's all the setup and writing that becomes
a time sink for most. In isolation, it wouldn't break the bank, but with all
those requirements combined, you've lost much more than 3 hrs. When I'm given
take homes for interviews, this is where I've burnt the most time - taking the
time to document well.

~~~
mburger
What about having a discussion on how the candidate would solve a given take
home?

You could check if she would think of the required parts. For instance, would
she think of unit tests? If she wouldn’t mention tests, you could ask „How
would you ensure that your program works as expected?“

Thus, solving the take home theoretically.

~~~
gravypod
This is a great use of the take home. It's a good interview-starter to get
conversation moving.

------
nabdab
With all the focus on broken hirering, I never quite head the employing side
being like: “we thought this person was the perfect candidate but (s)he turned
out to be rubbish.” So on that side of things it seems ok. Mostly the people
who seem to think the system is broken are people who don’t get the positions
they believe they are perfect fits for. But they have an extreme bias and
don’t actually know the state of the competition that end up getting the
position.

------
jimbob45
While hiring is broken, let's certainly not pretend it was in a workable state
in the past. Let's further appreciate things we have now that we didn't in the
past. Previously, if you wanted a job in another state, you'd have to move
there and hope you got a job before your bank account ran dry. Now, you can
safely apply for jobs while at your current job until you get something.

------
adamredwoods
I'm actively interviewing. I don't think hiring is broken, but I think some
companies get lazy or even abuse it. If we get the abuses down, and require
less of a time commitment (no 8 hour take-homes), I think there'd be less
complaints.

The key takeaway is that rejection hurts emotionally. Programmers who care
about coding, take the rejection personally. Less time commitment, less hurt.

------
eternal_intern
Why not list the pros/cons of each method and let the candidates choose their
poison. Whichever metric they think they would be best at given their
constraints.

Still requires work and a subjective estimation of candidate skill because you
have to make a judgment across metrics instead of within one, but I mean,
everybody wins in this case, right?

~~~
borramakot
I like the idea of multiple tracks a lot, but I think you need to be hiring at
sufficient scale that each track has a fairly high rate of interviews, which
makes it hard to support tracks that aren't commonly chosen.

If you don't had that scale, uncommon tracks will be full of interviewers who
are out of practice for your question, and poorly calibrated to evaluate the
candidate.

Also, some companies might not want to allow any of these methods, since they
each have their own tradeoffs/blind spots.

------
dkhenry
Whenever I see anything about hiring I always think back to this article

[https://techcrunch.com/2015/03/08/on-secretly-terrible-
engin...](https://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/)

------
devxpy
The "cons" part of this list is filled with how a practise doesn't work for X
class of devs.

So, why not randomly pick 5 of these practices and simply tailor your process
so it works well for a majority of candidates?

Something like pick your poison?

------
GoToRO
Well, none of the above. Anytime you try to gauge someone by counting, it's
not going to work well. You need the best developer at your company, to do the
hiring. Filtered by HR for personality and so on.

~~~
gridlockd
Your "best developer" probably doesn't want someone _better than them_ on the
job.

~~~
dymk
What a weirdly insulting straw man of a developer you set up. Many engineers
including myself would be thrilled to have somebody else highly skilled
around, and "selfish/vain" isn't the default in our industry.

~~~
gridlockd
> Many engineers including myself would be thrilled to have somebody else
> highly skilled around, and "selfish/vain" isn't the default in our industry.

What else are you _supposed_ to say about yourself or anyone else?

I'm not talking about the best developers in general, I'm talking about "the
best developer in the team". The "golden child". Do you sincerely believe
they're thrilled about giving up that special status to the new hire?

Yes, people are _that_ petty, they're not necessarily that self-aware though.

~~~
dymk
You can construct any number of hypothetical evils that might plague your
team; I don't really see why you'd let that shape your perception of engineers
when you hardly ever run across people like that though.

Most people are fine, and if you run into a toxicity then go take care of it
like an adult and talk to your manager/HR/whatever.

~~~
gridlockd
I'm not talking about "my team", I'm talking about people. Status preservation
is one of the most basic behaviors in higher animals. It's not "toxic" or
otherwise special in any way.

If you follow the advice of the GP, you are setting up a conflict of interest.
I'm not ruling out that the "best developer" in some teams is of such noble
disposition that they will always hire someone better than themselves. It's
not what you can _expect_ though, so don't set yourself up for failure.

------
hackbinary
Probably. Everything else seems to broken as well, housing, education,
healthcare, justice, and politics. So it seems perfectly rational to think
that hiring is broken as well.

------
bartread
I thought I was going to be completely infuriated by this as I've seen _just
far too many_ articles about hiring recently.

However, it's worth a read because it does a good job of summarising the
trade-offs inherent in most of the techniques I've seen used to hire
engineers. I might have missed it, but it didn't talk about any kind of
software design assessment, which I have used and seen used reasonably
successfully.

There was, however, one observation that ticked me off under cons in the "Live
Coding Exercises" section:

> Very stressful. Many programmers can’t handle the stress of coding under the
> clock, with someone watching them

If this _is_ you I'm going to give you some advice that, if you can swallow
it, will prove very helpful...

Grow up.

Seriously: grow up. You are (or will be) highly paid, and are supposedly a
professional. So _learn_ to toughen up and handle the pressure.

Because I guarantee you this: you will grow in any job that is worth having.
Sometimes that growth will be forced. Even when it's not, it can still be
uncomfortable and stressful.

Why?

Because you're doing things you haven't had the chance to become comfortable
with, or there's some external pressure: deadlines loom; a teammate is off
sick; a horrific security flaw is discovered in your code, or in a library you
use; some terrible bug makes it into production (this happens at even the best
companies) and you need to hustle to fix it; politics happens, and you have to
navigate through it.

In this line of work you cannot avoid stress. You can certainly make every
effort to run an orderly software development process with great teams,
regular releases, great feedback mechanisms, interesting work, and all the
rest, to minimise chaos, but that doesn't get rid of the stress.

We're software developers. Our stock in trade is dealing with really hard
problems. Sometimes those problems are technical, sometimes organisational,
sometimes commercial, more often a blend of all three (along with other
factors).

Guess what? Dealing with hard problems is stressful. Easy problems aren't
stressful (although boredom is for many), but if you wanted easy you chose the
wrong profession.

So buckle up. Because if you cannot handle an hour sitting down and working
either with an interviewer or under their observation/guidance on a problem,
how are you going to handle it on the job when it all kicks off (whatever "it
all" happens to be on the occasion in question)?[1]

 _[1] This presupposes the interviewer isn 't an asshole, and can be depended
upon to behave like a grown-up. I have borne direct witness to, or heard
report of, far too many interviews where the interviewer appears to be on a
mission to prove they're smarter than the candidate. If you are unlucky enough
to be interviewed by somebody who behaves like this you may be better off
looking for a position elsewhere even if you're offered the job._

------
maxyazhbin
awesome, right on!!!

------
brooklyn_ashey
Why is it that no one questions the system in which these —at best,
ridiculously obtuse—at worst, totally corrupt, often nepotistic— “interviews”
reside? The whole “interview/audition” culture comes out of a kind of
gladiator/Olympic ethos that pits "commoners" against one another for the
amusement of the powerful, while solidifying the collective deception that
keeps them in power. It’s a lever workers hand over willingly because the
other mythology—the one in which their genius and hard work “earned” them
their position—is an identity narrative they can’t survive the despair of
corporate culture without. But haven’t the critical thinkers among us agreed
that when the starting bootstraps are of different lengths, we can’t trust our
notions of “merit-based” reward? Celebrities bribing their kids into college
is but one of the more languid manifestations of the bankruptcy of this belief
system. When we play along in this gerrymandered Miss America pagent—what now
passes for job interviews in tech—we legitimize and endorse these so-called
“measurements". We need to collectively refuse to participate, with some
vehemence and volume. We must stop trying to make fairer versions of this
fundamentally dishonest bullshit. There is no fair Three Card Monty; it’s a
trick! Back in the day, the only folks who would play that game around 42nd
St. were tourists or kids who’d just moved to the city. This interview process
is the same; you can only pull it on the green, which is why it selects for
the young and desperate. Hey! Young and Desperate! You are way smarter and
better than this.

For those looking for actual data, like the post’s author who says as much,
one could turn to the classical music “industry”. This audition process where
“the best man wins” was exactly that for many, many years, until someone
thought to put up a screen and down a carpeted walkway, and well, what do you
know?...when the candidates were truly anonymous, women started winning.
Here’s an article [http://gap.hks.harvard.edu/orchestrating-impartiality-
impact...](http://gap.hks.harvard.edu/orchestrating-impartiality-
impact-%E2%80%9Cblind%E2%80%9D-auditions-female-musicians), one of many on
this study. So that trick was revealed, but ultimately, the idea that they
would select the “best” players of orchestral excerpts resulted in them
looking for players who rivaled computers in accuracy. Unfortunately, that
isn’t really what one wants in an art. Anyone there has the accuracy required
in spades. Accuracy beyond that is just meat compiling. It turns out that
classical orchestras populated by this kind of person lack morale, creativity
and vitality and don’t evolve with the culture, so these organizations have
become culturally dead and are going bankrupt all over the country—this after
their members were forced to let go of any real compensation and all dignity.
The problem is that most organizations like these and tech companies are top-
down. They are run like the military; their basic training programs are even
called “boot camps”, and like boot camps, they won’t get you much. We need to
take a look at the whole system, I’m afraid, or it will suffer a fate similar
to music in this country, because that’s what happens here, eventually.

~~~
brooklyn_ashey
The thing is, I’m actually interested in why we, a community of engineers and
tech people, aren’t genuinely interested in evolving the fundamental failures
of our system. We might learn something from classical music’s failures which
led to its musicians being mostly unable to continue to be professionals. They
used this same organization building system we are using now and it led to a
collapse of their entire industry. If we “peer review” our code, why don’t we
“peer review” the way we build our companies and the way we bring new folks
in. We mostly only pretend to care about diversity and we only care about
innovation when we are comfortable. It would be great to hear about why we
look to the individual interview process for faults it can’t really accept
responsibility for. Don’t its fundamental failures lie in the greater system
and by extension, the (even unconscious) intentions of the folks who designed
it? Ibram Kendi (youngest winner of the National Book Award) recently wrote a
book “How to be an Anti-racist”. In it, he details how the SAT was written and
how it was specifically and consciously designed to be eugenicist. I’m not
claiming that’s the case with interviews, but don’t you think we should
consider better ways NOT to redline certain folks out of the hiring process?

------
PaulHoule
Wasn't that headline written by content marketers working for triplebyte? It
is popular for medium articles and if you use it on the programming section of
Reddit you will get downvoted into oblivion.

------
graycat
It's easy for a person in good health, never arrested, never bankrupt, good
credit score, native born US citizen, world class Ph.D. with one of the very
best backgrounds for _analytics_ and _machine learning_ , with peer-reviewed
publications in applied math, mathematical statistics, and artificial
intelligence, having recently written .NET code in 100,000 lines of typing for
an ambitious Web site, code that appears to run as intended and be ready for
production, and who has shipped very high quality code to high end customers
to be 100% completely, utterly, totally, permanently unemployable for anything
beyond minimum wage, literally.

That's just the way it is.

~~~
strikelaserclaw
and you've met such a person?

~~~
lubesGordi
If they're 50+ and live in rural America, yeah good luck.

~~~
opportune
Good luck finding a job creating artisanal fruit preserves at a research
station in Antarctica

