6 ms·

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

21 points by docker_up 7y ago

I'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've worked on, maybe a single onsite coding project with follow up questions just to see how she codes and her thought process. 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. If she meets the bar post hire, then everything is fine but if she doesn'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. Is this more acceptable than the current industry hiring practice?

gus_massa 7y ago
What about people that must relocate for the new work?
- mrfusion 7y ago
  As long as you let them know upfront it shouldn’t be an issue.
  - ljw1001 7y ago
    lol. It won't be an issue because no one will relocate for a two month job.
diehunde 7y ago
Totally. And it's called "hire fast, fire fast".
was_boring 7y ago
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.
- shmooth 7y ago
  i've heard of probationary periods, and prob have been on more than one, but i've mostly worked at startups and none had them.
hahahaha23 7y ago
Yes, I think it makes sense. I even think internship shouldn’t be a student only program.
el_dev_hell 7y ago
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.
siquick 7y ago
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,
ljw1001 7y ago
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 7y ago
  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.
- shmooth 7y ago
  i think this has to be wrong, else companies wouldn't try to hard to get you to quit instead of firing you. the primary reason they want you to quit is so they don't have to pay unemployment insurance. that is the real deterrent to firing someone. i'd say it's like 99:1 in terms of percentage. maybe throw in a new 5% somewhere that is afraid of someone going postal, hitting your glassdoor reviews, etc.
ibeckermayer 7y ago
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 7y ago
  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.
  - gcatalfamo 7y ago
    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
    - x0x0 7y ago
      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.
      - jetti 7y ago
        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.
lemony_fresh 7y ago
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.
drstewart 7y ago
Yes, that's why I worked at Netflix
- muzani 7y ago
  worked as in got hired and fired from?
  - drstewart 7y ago
    Didn't get fired, left voluntarily (leaving the bay area)
nullwasamistake 7y ago
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.
EnderMB 7y ago
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.
shmooth 7y ago
Yes

ibeckermayer 7y ago

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