
Ask HN: Why are hiring processes flawed and testing random standards? - wolco
I started looking at remote positions two months ago.  I&#x27;ve had the chance to be part of a number of different hiring processes.  I had a lot of take home projects, crazy math tests, some coding tests, interviews over various video platforms.  I&#x27;ve had rejections, rejections that turned into further interviews.<p>In the end I found what I was looking for.  It just seems the hiring processes overall is flawed in many ways.<p>Most were looking for exactly one type with one set of experiences.  Anything outside of that and you are filtered out.<p>Companies seem afraid to hire thinking there is a slightly better&#x2F;cheaper option around the corner.<p>There is a fear to pull the trigger compared to local companies.  Afraid to take a chance on obvious candidates.  Someone with x amount of years in a language but not with a specific framework version.  It&#x27;s like the ability to learn 
even the smallest thing isn&#x27;t considered.<p>Multiple unnecessary rounds of interviews&#x2F;tests&#x2F;assignments&#x2F;group hiring.  The long the process ensures the best candidates go elsewhere or are filtered out.<p>The random unrelated tests.<p>The take home assignments with random marking standards.  Tests can matter, ui could matter, api structure could matter, documentation&#x2F;choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.<p>Why are the processes so bad?
======
steventhedev
In a nutshell: they aren't.

The economics of it are that in many places in the world, it is extremely
difficult to fire an employee. Getting rid of an underperformer can take time,
effort, and exposes the company to liability if the termination can be
construed as relating to the employee being in a protected class (e.g. can't
fire someone because she's a woman). Let's assume that it's a SF startup
willing to play a little fast and loose and they aren't concerned with
severance packages or the legal issues. They still put time and effort into
training a new engineer. That's months of work that is potentially wasted.

All of that means that companies are incredibly risk-averse when it comes to
hiring, and will pass on someone who looks even slightly wrong to them. It
also means that the process is inherently random as a company will pass on
someone they aren't sure of _even if they would have been a good hire_ just
because they aren't certain. However, this also means that a lot of companies
rely on self-selection in their hiring pool. Look for people they already
know, from the same backgrounds, or are willing to pass through a series of
arbitrary tests.

In short, it's like democracy. It's the worst form of government, except for
all the others we've tried.

~~~
ChuckNorris89
Don't know where you live but in most of Europe firing someone is pretty
trivial.

For a newly hired, you have a probation period, before your contract becomes
permanent, usually between a month and a year, where you can be fired on the
spot. After that, your contract becomes permanent and you can get fired, no
questions asked, with a notice period of usually between one and 3 months.

In theory, before letting you go, the company has to set up a performance
improvement plan for you but companies never bother as it's considered wasted
effort to invest in under performers so they just warn you at your performance
review that your performance is lacking and that this is strike one. After 3
months of performance monitoring you are let go because your performance
hasn't improved so that was strike two and you're out.

Sure, you can sue them if you know you've been wronged, and win a few thousand
euros, but nobody's gonna hire you knowing you're in a lawsuit with your ex-
employer so nobody bothers to sue and prefers to just find another job
instead.

So unless you're a protected category, usually over 50 years old, woman or
not, doesn't matter or part of some big-corp with strong unions, the hard-to-
fire is not an argument that holds water here.

~~~
anotheryou
In the under-performing scenario, wouldn't the company have to pay part of the
unemployment benefits (up to ~50% of the salary) for a year or so?

~~~
ChuckNorris89
No, you and your employer pay monthly contributions to the social security
system, as part of your income taxes, and in case you get laid off, your
unemployment benefits come from that pool.

------
tathagatadg
What I find funny is how little time and effort is put in writing the job
description. The interview process is mostly very generic and the questions
hardly in alignment to the role. As a profession we try hard to be correct
about creating clear specs that can be translated to unambiguous steps for a
machine to execute, but when it comes to hiring - we write ambiguous specs,
toss it over to recruiters who are poorly equipped.

Here are some thoughts: \- When the new position opens, the team (say the
scrum team) collaboratively writes a job description based on the current
backlog. Let's not leave it to a manager or recruiter who is writing the job
description. Use the company/team's mission and values as guidance to see who
an ideal candidate would be. This is like writing your stories.

\- Then write the filtering criteria based on the typical day to day skills -
what are must haves, what are good to have, what is ok to not have. This is
like write your test cases.

\- What are the areas where the team is lacking. Try to get skills/qualities
that will, for lack of a better expression, raise the bar of the team. This is
like your retrospectives - and if you have notes from your recent
retrospectives, they should help you identify what you are looking for.

\- This better spec should help the recruiters, and also give the candidates
an honest look into the team.

\- For the interview, go back to your previous sprints etc. and build
questions that are simplified models of what a typical story would look like.
Instead of asking to invert a tree, may be it would be better to talk about
how a particular problem you solved and see the approach the candidate would
take. Give the candidate all the tools - their favorite editor/ide or
whiteboard, whatever they prefer.

~~~
RicStrong
I'm actually assisting with a startup in building a solution for things like
this, so your comment really struck home!

And as somebody with a past in technical recruiting, I really like your
thinking. Indeed you're right: many recruiters are poorly equipped to actually
understand the roles. We have non-coders as the first or second tier
gatekeepers for development roles, which does not seem ideal.

Sometimes I'd get different signals from the job descriptions than the senior
recruiters or hiring managers, which was frustrating. Other times, the
requirements in descriptions were way too broad: like the team had an idea of
what they wanted, but couldn't get it down on paper in a concise way.

Resumes can be a challenge, too: many engineers don't always give full details
of their work. Perhaps because they're tired of getting recruiters reaching
out for irrelevant roles (that happen to have a keyword match somewhere).
Perhaps they don't have the time to always be updating and polishing.

A two-front solution could be really great. We need developers to write their
best resumes, and we need employers to write their best job descriptions.
Having them 'speak the same language' on concise accomplishments, metrics,
technologies will make more automated matching a lot (a lot) easier.

And then, of course - build the interview process around the shared skills /
technologies / etc.

Hopefully I'll have something to share here soon, or perhaps do an ask HN to
chat more about making hiring developers easier for everyone

~~~
tathagatadg
That is just great to hear.

"A two-front solution could be really great. We need developers to write their
best resumes, and we need employers to write their best job descriptions.
Having them 'speak the same language' on concise accomplishments, metrics,
technologies will make more automated matching a lot (a lot) easier." \- 100%!
This is the market place that Linkedin has been trying to create - but hasn't
worked very well, right? They have largely solved the problem of structuring
the resume data - which is definitely useful, but I don't see much of that on
the job description side. The matching algorithms can only rise up to the
level of quality of the input data - the resume data, and the job description.

There are similar problems in the dating industry, but mostly you can be sure
both parties are putting their best efforts for creating better input.

I think honesty is also a critical part of the equation. And if the Linkedin
or indeed could encourage both sides to reveal what they value deeply - that
would things more useful. May be a few why questions rather than just
checkboxes and drop downs that can be filled quickly. Candidate: Why is remote
working important for you? Job poster: Why is a self-starter important for
you? That would help bring out the uniqueness for the candidates and helped
the matching algorithms.

Will look forward to seeing your product on Show HN - best wishes!

~~~
RicStrong
Thank you so much - and we can't wait to share!

For anyone who may be interested,
[https://www.rocketship.jobs/](https://www.rocketship.jobs/)

If it can help even one person land a job, we'll be happy with having built
something new and different!

------
mastry
I have no answer to your question, but I can at least offer some sympathy and
confirmation. I've been looking for a remote position for months and have been
eliminated from consideration many times because I didn't have "X" months
experience with specific technology "Y" \- which could be easily learned by
_any_ experienced developer. It's baffling ... and deflating.

~~~
mharroun
To defend some of this:

1) Why pay someone to learn? In both terms of money and other devs time being
sunk into helping you learn.

2) If you do know "tool X" and its a primary tool then its a lot easier to
quickly evaluate whether or not standards will align.

Personally I don't mind hiring Jr Developers that cost less, are mold-able,
and are willing to put in extra effort. Could any experienced dev lean it?
Sure... but its more costly and often ends up in a "I have now studied X for Y
weeks, we do X wrong I refuse to do X your way."

~~~
reallydontask
Do you work with such an extremely static stack that it requires no further
learning?

I would say that one of the most important qualities a developer can have is
the ability to learn.

Perhaps, you expect all the learning to be done outside of work?

~~~
mharroun
I lead product and engineering orgs in startups, so yes I make sure our -core-
tools remain static as possible.

I never claimed learning is not important, if anything I supported that in my
comment in hiring eager jr's.

My point being is if I am hiring someone "experienced" I need someone who can
mentor others, own projects, and help drive our current products forward. If
that person will need to come in and learn the job... I might as well hire a
JR and train them up instead or hold our the X months the "experienced" person
will need to learn to bypass that whole ordeal.

~~~
mooreds
I hear you. There are so many kinds of senior developers. Wrote a blog post
about it:

[http://www.mooreds.com/wordpress/archives/2812](http://www.mooreds.com/wordpress/archives/2812)

------
thow_leet
I asked an HR rep about this and she told me there is a massive influx of new
grads demanding very high salaries. You and I might be from a generation where
a CS degree was not an obvious choice and the supply was not as high for
organizations. Unfortunately years of experience don’t count for much in this
industry, especially with how fast technologies change.

~~~
thow_leet
Also, startup hiring usually means joining an already close knit team. If you
have to interview with 5 people, have a fifty-fifty chance with each and
anyone can veto your hire that gives you a 3% chance of getting an offer.
Competency will get your foot in the door, but ultimately it comes down to the
social psychology of social comparison and propinquity.

If you are a senior/staff with some success at previous startups, you are
likely to get vetoed by developers who see you as a threat in the promotions
tournament.

------
codingdave
The process is aimed at fulfilling a business need that they are experiencing.
Unless you know everything going on internally, it is difficult to judge
whether the hiring process is bad, or simply not matched to your expectations.
As to why it seems fearful, there is a huge price to pay if you make a bad
hire in any company, but it is exaggerated when you make a bad remote hire,
even more so if they have never worked remote before, and you need to bring
them up to speed on how it works. There may be fear, but again, it is
business-driven.

~~~
maxaf
Your comment is chock full of flawed and patently false ideas. Firstly, I have
yet to encounter a company with a hiring process that is actually, provably,
repeatedly tied to any of that company’s business needs. Designing a working
hiring process is harder than the software work that the hiring is for. It’s
no surprise that results usually seem arbitrary and ineffective.

Secondly, and following up on my first critique, an ineffective hiring process
usually leads to the hiring of candidates who are good at interviewing, not at
the actual work. These are the literal “bad hires” that should have been
sifted out by the hiring process.

~~~
dahart
> Your comment is chock full of flawed and patently false ideas.

Whoa, what triggered and justified that response? I don’t know if the parent
was edited, but it seems pretty reasonable to me.

> Firstly, I have yet to encounter a company with a hiring process that is
> actually, provably, repeatedly tied to any of that company’s business needs.

What do you mean? Why do companies hire then?

> an ineffective hiring process usually leads to the hiring of candidates who
> are good at interviewing, not at the actual work. These are the literal “bad
> hires”

This hasn’t been true in my experience. Why would someone who’s good at the
work not tend to be good at interviews?

I’ve interviewed hundreds of people and hired dozens. The number one reason
for a candidate not getting a position is that there was another better
candidate. More often than not, it has nothing to do with how good the
candidate is, nor does it have anything to do with how good the company’s
interview process is. After that, there is usually a large number of
candidates that are young and shooting above their weight, hoping to get in
somewhere with almost enough qualification. Occasionally, that works. I
haven’t bumped into anyone yet that was great at interviewing but not good at
the work, but like many companies, I’m using the interviews to try and find
out if they’ll fit it, and if they’re truly interested, and if they’re good at
work.

~~~
TuringNYC
>> > Firstly, I have yet to encounter a company with a hiring process that is
actually, provably, repeatedly tied to any of that company’s business needs.

>> What do you mean? Why do companies hire then?

Sadly this is _very common_ \-- the bigger and more profitable the company the
more common it is. Companies often hire for non-business related reasons for
several major reasons:

1\. Bench strength -- Hire top talent before you need it so you are ready to
fire when you have a strategic project. Ideally, hire away talent your
competitors might hire. In many ways, this is a good thing.

2\. "Burn the Budget" \- Divisions will often lose budget if they dont spend
it, and they may lose it in future years when they need it ("well you got it
last year and you didnt use it, so this year you dont get it...") -- so many
divisions will hire to burn the budget and use it just so they dont lose
budget when they really really need it.

3\. HR - It is common for HR to institute Crazy-8s policies or some variant of
it -- where you only get promoted if you have 8 (or _N_ ) people working for
you. Naturally all sorts of non business related tasks suddenly pop up and
people hire just enough to get promoted. This is very common in organizations
where promotion and pay is linked to non business metrics (how much budget you
control, how many people report to you) rather than business metrics (revenue
delivered, revenue enabled, churn reduced, traffic increased, etc.) Often your
boss themselves wants to be promoted and needs 8 middle-managers 8 under them
to get promoted. And so on up the chain. Almost half the HR departments in my
~20yr career institute such a policy, whether it is internally known or not.
It is of course more common in organizations which are not metrics driven.

~~~
dahart
Aren’t those all “business needs” in a general sense?

~~~
TuringNYC
#1 is a business need.

#2 is a gray area.

#3 is business burn -- when an organization "needs" to hire loads of people to
work on useless projects just to align to rigid HR rules, the business has
stopped to drive operations and instead operations are driving the business.

------
jchallis
Two thoughts.

First, most companies will look for a remote person only after exhausting
their local labor pool. If someone remote has to devote their initial months
to learning with no advantage over someone local learning the same content,
why not go with the added benefit of hiring someone local.

Second, many companies have a fallback person in place who can almost meet the
need - maybe they have x amount of years in a language, right attitude, etc.
This process is only to see if you are better than their fallback option. The
distressing answer sounds to be rarely.

------
jamestimmins
A few (incomplete) thoughts:

1\. We haven't yet figured out a way to get enough signal from two hours or so
of work.

2\. There are multiple ways to be a good programmer, but companies need a
standardized way to assess skill. There's an inherent mismatch.

3\. Most teams don't even know how to gauge their own employees' skill/value.

4\. Teams rarely have their own employees retake their hiring tests to
calibrate effectively.

5\. Unpopular opinion: they aren't. Skills like algorithms are vital, and
people who argue that they don't matter simply don't want to do the work.

~~~
ravenstine
> 4\. Teams rarely have their own employees retake their hiring tests to
> calibrate effectively

I can't imagine that would end well in most cases.

------
lrem
Hiring is an inherently hard problem. I imagine the additional hard to test
requirements of remote work (autonomy, discipline, ability to do your own it,
...) doesn't make it easier.

------
jarsin
I have come to see trying to find a job is a lot like dating. You see the
company for the first time "oh look how pretty. We would be perfect together!"

Then you start talking and they ask you a bunch of really stupid questions.
The voice in your head starts telling you something is off.

Then they start testing you and giving you the run around. In dating this is
known as playing games.

Just like in dating it's time to wake up and realize they are showing you who
they truly are. Ignore at your own peril!

------
hsuresh
I am building a product/startup [1] to address some of the problems you
mention, and as a result, I've been talking to hiring teams at several
companies, so I can give you some reasons why the processes are bad.

* Hiring is a marketplace, and supply/demand is not always balanced, so most issues related to job search/hiring is due to this.

* When a company posts an ad for a job, they usually receive about 150-200 applicants within 2 weeks, thanks to job boards, LinkedIn etc. Unless it is for specific high-skilled jobs, in which case, they receive hardly any applicants at all.

* Most of the applicants are usually not a match for the job, but given the number of applicants, recruiters rely on resumes, social profiles etc to shortlist about 20 applicants.

* Tests and assignments are quick means to filter, hence their popularity.

* Not much of an incentive to keep applicants posted at every step, plus, managing communication with a few hundred applicants for multiple positions is hard - so you're most likely to receive only automated communication from the hiring team.

I believe that having a clear specification of the job, that can be
checked/validated with applicants is critical to ensuring a smooth, fast
interviewing process.

[1] - Shameless plug to my startup (in beta) -
[https://www.interviewpass.co](https://www.interviewpass.co). If any of you
are interested in using InterviewPass in your hiring, drop me an email at
suresh@interviewpass.co - happy to help set it up for you.

~~~
marcinzm
The problem as I see it is that good applicants don't bother with job boards.
When you have recruiters banging on your door and begging to handle all the
details for you (and provide proper communication) it's no wonder candidates
don't bother applying. That, however, means the expectation is that job board
candidates are bad and desperate. So companies will filter them more
aggressively than recruiter candidates. So candidates now have even more
incentive to go with recruiters since it actually gives them a better chance
to get hired.

~~~
hsuresh
That's true. Recruiters provide the initial screening, which is lacking in a
job board.

But the hiring process is broken beyond the initial screening as well, biggest
reason being lack of incentives for the involved parties to close a position
quickly.

~~~
marcinzm
>That's true. Recruiters provide the initial screening, which is lacking in a
job board.

It's not just the initial screening. They actively go out and find candidates
who otherwise wouldn't be looking for jobs directly. And as I said before,
those tend to be prime candidates since they get so many recruiters they have
little need to apply directly.

>But the hiring process is broken beyond the initial screening as well,
biggest reason being lack of incentives for the involved parties to close a
position quickly.

Again, recruiters are a solution to this because their paycheck is based on
closing the deal. They will hound the company and the candidate to get the
process finalized.

------
jcadam
All of my previous job searches started with me seeking remote work and ended
with me giving up and taking a local job. There clearly is a surplus of great
engineers looking for remote gigs.

I've recently landed an on-site job (I had to relocate) that pays pretty well
in an R&D type environment that's actually all right -- in fact, this is one
of the few jobs I've had that I've not hated -- so I may stay here more than
my usual 1-2 years :)

~~~
RicStrong
I really hope there's a big push for remote roles. If that's where the talent
wants to be, companies should be able to stay competitive.

Plus, it's much better for the environment. If you can do you work from home,
why not?

------
davtbaum
_Most were looking for exactly one type with one set of experiences. Anything
outside of that and you are filtered out._

In my experience this rings true for senior roles and less so for new college
grads.

 _Companies seem afraid to hire thinking there is a slightly better /cheaper
option around the corner._

I can see why perhaps a candidate receiving a rejection may think this, but in
the companies I’ve worked at this has never been the case. It’s always been
“it’s really tough finding talent, not paying talent”.

 _The take home assignments with random marking standards. Tests can matter,
ui could matter, api structure could matter, documentation /choice of
framework, speed, style all could matter but you rarely know which matters to
whom and rarely have time to do it all and even if you did everything
perfectly a lot of the time no one even looks or the reviewer expects the code
to look like how they might write it._

A fair reviewer recognizes the limitations of these take home exercises. While
there are many ways to perform a take-home successfully, there are more ways
to show that you aren’t qualified for the role. Not all that pass will be
right for the job, but most who fail aren’t.

~~~
hysan
> _Most were looking for exactly one type with one set of experiences.
> Anything outside of that and you are filtered out._

> In my experience this rings true for senior roles and less so for new
> college grads.

I agree that I've seen this to be true for senior roles, but what I've noticed
on many job descriptions is the reluctance to say they are looking for a
senior engineer. I've gone through quite a few phone screens where it becomes
immediately apparent that the company is looking _only_ for a senior but the
job title and sometimes description looks like it was written for a mid or
even junior position. So I can completely understand where OP's view of the
hiring process comes from - you go through the initial test round, get to
speak to them, then find out that they have extremely specific requirements.
If you happen to be unlucky enough to go through many of these, it can really
mess with your perspective on the hiring process.

------
kentrado
They only get as picky as their options. Remote companies get exponentially
more candidates so they can make them jump like monkeys with impunity.

[https://www.youtube.com/watch?v=v1WiCGq-
PcY](https://www.youtube.com/watch?v=v1WiCGq-PcY)

------
leerob
My opinion - Why is the process so bad? Hiring technical talent is flat out
difficult. Even for the best companies. Thus, attempt after attempt has been
made to figure out "the right way" to screen candidates to prevent bad hires.

It started with algorithmic interviews. Then, we tried take home assignments.
Now, lots of companies are doing pair programming type scenarios including a
code review for a more accurate representation of a day on the job. Still,
there hasn't been this silver bullet companies are looking for to solve their
hiring woes.

I don't know the solve. There's also a large problem with those doing the
interviewing being either untrained or unempathetic to the candidates.

------
specialist
Hiring processes are terrible for lack of accountability, transparency,
feedback.

I ran for political office. Endorsement interviews can be either awesome or
brutal. One key difference is whether the interview is recorded, and then
shared publicly.

It will surprise no one that my worst interviews (in both politics and tech)
were behind closed doors.

Worst of all are the 1:1 interviews with inexperienced interviewers. Zero
accountability, zero transparency, no feedback loops. They just report
whatever they want, are not even expected to explain themselves.

I've since decided that any future job interviews will be recorded and posted.
I will definitely embarrass myself. But until someone starts, no improvement
can occur.

------
anotheryou
At least I can weed out companies with bad hiring practices. They team can't
be much better than how they hire.

Having a remote interview with really bad audio, no word on their product, no
small talk, just questions without discourse or feedback on my answers? - No
thanks.

I'm a bit torn on assignments and trial days. I think they should simply be
paid.

~~~
mooreds
At the company for which I work, we definitely pay something for the take home
assignment. Not a ton. It's less a "this is what you'd get paid as a
contractor" and more "this is a recognition that you are spending some free
time on this and we appreciate it".

------
lazyant
Hiring process in our industry has lots of problems and discussing them is one
of HN's favourite topics. For remote the bar is higher, simply because not
everybody is able to be effective working remotely, so companies are more
weary about remote workers.

For ex my company does hire remote but only senior and more exceptional
candidates.

------
mattdeboard
People giving remote-specific response as if that is the only problem. It is
probably a contributor as well but frankly I have had very similar experiences
interviewing for non-remote jobs.

------
exabrial
Unpopular answer: Interviewer Ego

------
lr4444lr
Let's first establish: how are you measuring hiring success?

------
gtsteve
My company is 100% remote so I have quite a bit of experience with being on
the recruitment side.

I think if there was a standard for recruiting that the industry followed,
then people would just be thinking of ways to "hack" the standard, so I don't
think that would be helpful.

Remote working is desirable and rare but also a lot of companies that recruit
for remote workers are very new ones and they often have no clue what they're
doing. I think they feel that so long as they make it really hard and
unpleasant, they'll be like the other massive internet companies.

To be honest, I also have no real clue what I'm doing but I am trying. Perhaps
you could give me some feedback on our process while we're here:

1\. A written test where we ask a few questions around the candidate's
experience - what's the most interesting thing they've worked on, what recent
tech are they most interested in, and we ask them to do a code review of a
poorly written method. We have a strong culture of documentation so if the
candidate can't write well then it's not going to be a good fit.

2\. An online interview where we talk about the company, discuss the test,
answer questions and write some code together via screen sharing. This latter
part takes the longest part - firstly we write a simple string reverse method,
write some unit tests for it, debug another method and design a history API
for a browser (which has more edge cases than you'd think). What we're looking
for: confidence in programming, code, design and communication.

3\. An online or in-person (depending on where the candidate lives) interview
with me and our CEO. This part has about a 95% success rate for the candidate,
our CEO's just a people person and likes to get to know people.

4\. The candidate is hired, and we start assigning work in increasing levels
of difficulty. This is a probation period of 3 months.

Stage 4 is still part of the interview, we're able to take advantage of UK
labour laws that allow us to let someone go inside 2 years without having too
much trouble.

This way we can see them working for real and even if they aren't that good,
get some sort of benefit from it. Of course, we might waste some money but
it's an opportunity to learn what we need to do better during the interview
phase.

For better or worse, capitalism rewards those who take risks. I think the
companies with their multi-month long recruitment cycles are putting too much
effort into risk minimisation. I'm happy when I hear about my competitors'
"brutal" interview processes. It means they're moving slower than me.

~~~
wolco
As long as there are clear expectations at each step I think that goes a long
way.

------
dlphn___xyz
why would you choose to work remote - are you retired? no jobs available in
your immediate area?

~~~
kaoD
Why do you ask that?

I work partial remote and every day I go to the office I wish I was fully
remote... not because I hate the office (I love it, and really enjoy my co-
workers) but because I hate commuting.

~~~
dlphn___xyz
Partial remote or designated telework days make more sense than being fully
remote.

However, it seems like you're exchanging any future/potential at a company for
the convenience of working remote which why i was asking if he was retired.

