Hacker News Reader

Comment by ebiester | Hacker News Reader

The fence is there because the risk of doing something new is hard, especially because testing hypotheses in hiring is expensive.

I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates. However, it comes down to this: I only get 2-3 hires a quarter. Trying to get a meaningful result on changes I make is difficult. If one doesn't work out, did it not work out in a way that my original process would fix?

And so, we get conservative because even though it rejects a lot of qualified candidates, it also gets good candidates.

View on HN

> I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates.

Simple solution: Be very clear what kind of candidate the company actually needs, e.g. do you need

- a genius in algorithm design

- a person who knows the subtle details of a specific language/platform/standard X

- a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)

- how important is it really that the person is also nice to hang up after work

- an allrounder vs an expert for X, Y

- a person who creates solid code that will be good to maintain vs. a person that "simply get things done"

- a person who is is already good at X vs a person who has a high potential to become good at X

> a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)

Maybe it's just a matter of wording, but the implication that people who will go to bat for an important choice can't also be "nice" strikes me as strange and contradicts my experience. Good comment otherwise though.

There are 20 more that you could have named. What is their temperament? What kind of initiative do they have? Are they collaborative or more independent? How do they collaborate between teams and is that something you need? Do you need someone that can go in front of a customer?

So, do you customize your hiring process for each hire? What if multiple teams need different types of people? How big is your organization?

And if you get a discrimination claim, can you prove you have a fair process? The bigger the company, the more standard the process generally is.

My interviews aren’t heavy algorithm interviews, unless I need it. However, those questions you mention and many others are hard to analyze. How do you test that someone is an expert, especially if you don’t have an expert on staff? How do you know if the person writes maintainable code or just talks a good game?

How do you assess work ethic?

Hiring is hard.

> There are 20 more that you could have named.

Of course; these were just examples as the "e.g." tells.

> How do you test that someone is an expert, especially if you don’t have an expert on staff?

I gave some idea on https://news.ycombinator.com/item?id=24841552

That gets to the difference between a generalist and a specialist. Sometimes, I need to hire a specialist because we need someone who can provide high level expertise to a group of generalists. (E.g. a specialist on visual design and interactions with javascript, react, and best practices regarding such.) If we are looking to hire for that skill, trivia isn't going to work but neither do we want to hire someone who can talk a good game but would be quickly exposed by an expert, and will lead us down the wrong path.

Now, I can give you all sorts of answers here. My point is that unless you're going to put a lot of effort into redesigning the interview process from first principles for your company due to some need (like Google), or you are putting your effort into a startup like interviewing.io, you're likely going to take an existing process and tweak it. And that explains why the fence is there.

As one very junior in my career, this comment was really eye opening for me. I am feel a lot of the frustration and stress of the 'broken' hiring process, but was quite comforted by the introspection your comment caused.

thank you for that :)

Also a hiring manager.

If you conceptualize a hire as "this decision costs me $100k to $200k, and six months", you'll understand why folks are conservative. That's my finger in the wind cost of a bad hire, in terms of their salary, the salary and opportunity cost of their first two weeks buddy, plus all the other related efforts to onboard and train. Plus, again, if it's a bad hire, by the time we spend 2 months getting to the termination, and a 2 month search, and a 2 month onboarding, I wait 1/2 a year before I get the employee I need.

>The fence is there because the risk of doing something new is hard

This is the exact wrong lesson to take from the proverb. Instead of considering why something is still in place, you should consider why it was put in place to start with.

Coding tests came about because some developers can talk a good game but are very poor at software development, and it can take months to realize in more complex code bases. Algorithm tests came about because when interviewing CS majors, you can assume they have had an algorithm class. Many of us know why the fence was put up. We don’t tear it down because it is a complex problem. It just takes one successful company to create a better process and the fences will start coming down, just as whiteboarding has become much less prevelent in the last decade as laptops have become common for developers.

Reply on news.ycombinator.com