Ask HN: Would you accept an easier hiring process for an easier firing process?

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.

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.

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.

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

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.

Testing general coding ability is not demonstrated by asking to whiteboard very specific algorithms...a customized variant to fizz buzz applied to the coding field the company needs (frontend, backend, etc) can test that

Those are often too easy. Whiteboard coding is stupid, but does show effort. That's valuable from junior employees.

Also, I got in an argument, I think on this site, with someone who claimed that the modulus operator was not widely known. Not knowing that makes fizzbuzz classic much more complex. :shrug: Not every employee will work at every company.

I was interviewed a couple weeks back and given a FizzBuzz test. It started out normal, like the traditional FizzBuzz test, but then progressed past the "too easy" stage. They asked to design the program in a way that the rules were custom and the only rule that was always defined is that if all other rules don't match then the current number is printed. It wasn't difficult but it allowed for conversation as well as indicating deeper knowledge.

> 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.

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.

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.

> A candidate willing to put in the effort to game them is generally a good signal.

That's not necessarily true. In my experience, the most competent people aren't inclined to waste valuable time on frivolous bullshit. Via this system, you may be selecting for drones that only know how to do what they're told, at the expense of selecting for leadership qualities.

I've been spending my time unemployed to build an online store for a friend and a Raspberry Pi based sensor/control system for a non-profit organization.

Everything I've learned doing this is far more demonstrative of the applicable skills, motivation, etc. a company should be looking for than if I had spent the time memorizing algorithms. I've been sending the source code for these projects to companies in my applications, although I'm not sure if anybody is even looking at it let alone using it to evaluate my skills.

Serious question: would you suggest I just "play the game" and work on practicing the types of questions some companies use in their process?

Related, would you prefer to hire a candidate who spends their spare time "playing the game", or one who works on real applications like I do? I think the correct answer is obviously the latter, and hiring managers should take responsibility for developing a process that rewards genuine productivity and hands-on-learning over ultimately frivolous game-playing.

I recognize this is much easier said than done and respect that your job is difficult. But it is a problem and problems get solved by those who recognize them as such and purposefully try to engineer a solution...

> 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.

This is undoubtedly true. I completed a "code bootcamp" and can personally attest to the fact that some people are qualified for junior level roles, and some should choose another career path. No coding school is selective enough in their admissions to build a brand around quality.

None of this is communicated by having me implement binary search

I'm curious how you're so sure of this as a not-yet-junior Dev.

How does implementing a binary search show any of the qualitative attributes that were mentioned?

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.

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.

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.

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.

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,

What about people that must relocate for the new work?

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

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

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

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

Yes, that's why I worked at Netflix

worked as in got hired and fired from?

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