
Ask HN: Would you accept an easier hiring process for an easier firing process? - docker_up
I&#x27;m trying to come up with a suggestion for the company where we relax our ridiculous coding and systems design requirements for a more lax, faster hiring process. Instead of hiring for algorithms, we would hire after talking with the team for a couple of hours, going in depth on the projects they&#x27;ve worked on, maybe a single onsite coding project with follow up questions just to see how she codes and her thought process.<p>In exchange, we would have a high bar post-hiring, and give them 2 months to come up to our expectations. The expectations for each level would be well-defined, and would be very concretely communicated so that the candidate would know exactly what we are expecting.<p>If she meets the bar post hire, then everything is fine but if she doesn&#x27;t, we would give her a 2 month severance package and fire her within 2 months. This quick firing would only be applicable within the first 2 months, and afterwards it would be a normal process of performance feedbacks, pips, etc.<p>Is this more acceptable than the current industry hiring practice?
======
ljw1001
In the US (I should say in MA, which is what I know best) the firing process
is already trivial. The only real deterrent for firing someone is that it is
an emotionally difficult task. I've been on both sides of that table, fwiw.

I absolutely love what you're after, though. I'm sick of companies that hire
people to create trivial web or phone apps based on their skill at solving
deep graph or search problems. (This, frankly, is part blind emulation of
Google (& its peers), and part an effort by recent CS grads to ensure that
they only have to work with people exactly like themselves. That is to say,
it's a form of standardized prejudice.)

For nearly every dev positions, craft, tenacity, and people skills are vastly
more important than algorithm chops.

I have yet to come across a company where the interviewers are better at
interviewing than all but the most abysmal programming candidates are at
programming. This kind of questioning of the status quo is much needed.

~~~
slow_donkey
I hate such problems as a job seeker but you can't deny their effectiveness in
finding viable candidates. We typically don't whiteboard and it's easy to find
candidates who can pass the basic build/consume an API test. But once you
throw a different type of problem, they fall apart. I hope someone can counter
that whiteboarding also has the same fallacy.

------
nullwasamistake
Something that's worked for me. Relax the hiring process but ratchet up the
referral bonus and let teams hire their own devs.

People work better when they work with people they like. And they hire people
like themselves. And they generally won't refer shitty devs if they are the
ones that have to work with them down the road. Even with a 3 day gauntlet
interview you won't have enough information to determine if somebody is any
good. Compare that to a referral that one of your team members has known for
years.

With this strategy getting good devs is easy but maintaining non
discrimination is harder due to human nature so it's best to find a middle
ground. Blinding name/sex/age/ethnicity until as far as possible in the
process is a good start.

And have a coding challenge early in the process. Make sure your most skilled
engineers are the ones reviewing submissions. Most teams will flatly tell you
who that person is if you ask individually. If your best and most productive
programmers are reviewing submissions they will select for the same.

The biggest hiring danger for small companies is regression to the mean.
Eventually, once you get big enough, the law of large numbers nearly promises
you will have average engineers. Since you have so much control over hiring
I'll assume you're a smaller player.

This is a good place to be when looking for talent. You can have your best
engineers hire more great engineers by interviewing them personally.

Firing is usually stupidly easy in the US at least so I wouldn't even worry
about that.

------
ibeckermayer
As someone going through the shit gauntlet of coding interviews for junior dev
positions, I would love this. I’m hardworking, tenacious, self motivated, etc.
None of this is communicated by having me implement binary search

~~~
x0x0
Yes it is.

I'm a hiring manager. It's not like we don't know that interviews are game-
able. A candidate willing to put in the effort to game them is generally a
good signal.

We hire people out of code schools: 4 last year, and one of them is about to
be promoted basically because she's good at everything. And for the record, we
ask zero algorithms questions.

Unfortunately, some graduates of code schools you've hard of _can not code_.
Like at all. Hence I understand companies that resort to algo questions.

~~~
protonimitate
> Unfortunately, some graduates of code schools you've hard of can not code.
> Like at all. Hence I understand companies that resort to algo questions.

I'll agree with this. The issue, I think, is that too much emphasis is placed
on the algo questions in relation to the other portions of an interview. I
think the root cause of this is bad/lazy hiring practices.

There's a difference between using an algo question to see if a person can
code, versus using an algo question to stroke the interviewers ego and/or
confirm biases.

It's also an issue of companies not truly wanting to invest in junior talent.
A lot of companies want to pay junior wages for experienced talent, and don't
encourage a mentor/mentee/learning environment.

Yes, I understand the fear that companies will invest time and money in junior
talent just to have them jump ship for a pay raise in 8 months, but that cuts
both ways. I'm willing to bet that companies that are willing to spend more on
training/mentoring/yearly compensation bumps would retain talent for longer.

To answer the OP question - I personally would not accept an easier hiring
process for an easier firing process. I believe that would just exaggerate the
problem above.

At the end of the day, it comes down to ROI for both parties. Job seekers
don't want to spend countless hours cramming for algo questions and being
subjected to multiple-round interviews. Companies don't want to spend the time
and money on hiring + onboarding to get to a point where a new hire produces
value.

You could argue that an apprenticeship model would help circumvent the
problem, but that could mean significantly lowered entry-level salaries, and
probably less interest from "top talent" in the junior market.

Software is a strange case though. It's becoming just as ingrained in society
as say, plumping or electricity, but the potential for revenue is much greater
than traditional trade skills.

~~~
x0x0
the reason not to hire junior employees isn't the money. It's they're net
negative productivity for at least 6 months if you include the senior eng time
spent helping them. It's a hard calculus, and I 100% understand why a company
would choose never to do that.

~~~
protonimitate
I'd argue that if a junior is net negative productivity for 6 months, either
the onboarding process is not well enough defined and too drawn out, or the
junior position being filled should really be for a senior.

------
was_boring
I believe a probationary period is fairly standard in the U.S., even if the
candidate doesn't know it. Generally it's a 30/60/90 day plan, feedback from
managers, etc. If they don't live up then you start reevaluating fit.

If I got a 2 month severance package after being fired for working for 2
months then I would be ecstatic.

Now does reframing it solve your problem? I'm not sure -- that's a question of
how to influence.

------
EnderMB
First of all, it depends on the company and the role itself. If the company is
using an algorithms interview to hire someone to maintain a shitty CRUD app, I
would nope out of that interview almost immediately. Hiring is a reflection of
a companies values as a whole, and if an algorithms interview isn't reflective
of the work I'd actually be doing, it's a poor impression.

To answer the actual question - have you considered offering people the
choice?

Different people have different needs. Some people would rather have a quick
interview process and feel their way through a role in its first few months
for either side to bail. These people usually have more experience, and value
both their ability and their time. Others would accept a tougher interview
process as a prerequisite for job security at a good company.

------
el_dev_hell
This is similar to how my current position started.

I was initially given a contract for 3 months. Not a probation period -- a
contract that could be cancelled at any time by my employer.

I left a very stable job to take this new role (cite: much more money and 100%
remote).

After 3 months, I was given a full-time role. I rolled the dice. I would do
this again.

------
lemony_fresh
What? You think having strangers in your own home commanding you to do what
they tell you over video conference is unacceptable!? Sarcasm aside, gig-to-
hire arrangements would go to the top of the heap when it comes to
prioritizing opportunities.

------
siquick
In Australia where I am, it's becoming normal for a 6 month probation period
and you can terminate or be terminated with 1 weeks notice. Outside of this
the notice period is usually 1 or 3 months - the former being more common,

------
gus_massa
What about people that must relocate for the new work?

~~~
mrfusion
As long as you let them know upfront it shouldn’t be an issue.

~~~
ljw1001
lol. It won't be an issue because no one will relocate for a two month job.

------
hahahaha23
Yes, I think it makes sense. I even think internship shouldn’t be a student
only program.

------
diehunde
Totally. And it's called "hire fast, fire fast".

------
drstewart
Yes, that's why I worked at Netflix

~~~
muzani
work _ed_ as in got hired _and_ fired from?

~~~
drstewart
Didn't get fired, left voluntarily (leaving the bay area)

