Live data from Hacker News

Hiring Processes Are Also Engineering Processes

ramblinjan.com

61–70 of 71 posts

Re: Hiring Processes Are Also Engineering Processes

#61

Earlier quoted context omitted.

It depends on your definition of "perfectly acceptable." Almost every job in every industry with a hiring cycle rejects "a majority of candidates," especially when there's limited space. > These costs can easily outweigh the cost of a bad hire. How so? You're right that I've relied a good bit on the anecdotal, but aren't you doing so a bit here? Bad hires are ridiculously costly--especially on a small team--because t…

> Bad hires are ridiculously costly Here's a serious question. Please make an effort to think about it and come with an answer for your company: What is a "bad hire"?

We suffered one, he was on a two man team. Reviewing his pull requests took at least a day, which were effectively rewrites by the more experienced dev.

We eventually had to let him go, but the technical debt remains. For example, tests that mock everything so that they didn't actually exercise any of the code!

Re: Hiring Processes Are Also Engineering Processes

#62
post #39

Earlier quoted context omitted.

Other professions hire based on pedigree and looking+sounding the part. I personally prefer a hard skills test. But of course I would, the latter scenario favored me much more than the former when I was not-yet done with college, and also when I was looking for my second job in a new city. There's always some complaint in these kinds of threads about whiteboard coding. I love whiteboard coding! I did it a fair bit ou…

How much whiteboard coding do you do once you are hired? I'm not talking design but actually writing a sort algo with all the curlies in the right place, on a whitebaord?

Do interviewers actually really care about the curlies being in the right place? I've never interviewed in the US, but certainly every interview I've had in Europe that required whiteboard coding only required essentially pseudo-code that looked more or less like the target language.

Re: Hiring Processes Are Also Engineering Processes

#63
Not communicating clearly and on time definitely leads to terrible candidate experience. I was on the receiving end of this when a recruiter from a famous hosting company told me over the phone that they are going to make an offer by the end of the month. When that time came, he told me that they would need to conduct another interview with the CTO who is out till the end of that month. By this time, it had already been 3 months in the pipeline. I hung on to it because I liked talking to the team and loved the product. But this is surely not worth my time.

Re: Hiring Processes Are Also Engineering Processes

#64

Where does this assumption come from that rejecting the majority of candidates leads to better results? At some point you're just cutting into the bone and rejecting candidates that are perfectly acceptable. The more candidates you reject, the more time you waste and the more people come out of your interview with a negative experience of the company. These costs can easily outweigh the cost of a bad hire. Nobody wri…

It's not just those costs. The real cost is the phenomenal candidate you do miss. If engineering talent follows a power distribution, as I believe it does, then a single mistaken "no hire" can mean more productivity than the all the rest of your engineering hiring for the quarter.

Perhaps this is why Ben Horrowitz made such a strong case that for key roles you should, "Hire on strength, not on a lack of weaknesses."

Re: Hiring Processes Are Also Engineering Processes

#65

Hiring fast is actually really important. It sets a really good tone with candidates and forces you to have a hiring process with good decision points and processes. At Voxy we had a 1 week turn around goal from receiving a resume to having on offer on the table. Didn't always work out like that because of candidates, and vacations and what not, but that was the goal. The day of last interviews we either said no than…

Very good point, it's very off putting this 3 month or longer hiring process. Definitely screws with your expectations of the company. The weird thing is most of my applications lately seem to be going that slowly. It's especially frustrating from my end as I could be delivering and providing value instead of waiting for an offer. I've actually started working on my own products just because people are too slow :)

A 3-month hiring process would make me think there's a lot of bureaucracy that would interfere with things like getting work done and making a good product.

Re: Hiring Processes Are Also Engineering Processes

#66
post #60

Earlier quoted context omitted.

> Bad hires are ridiculously costly Here's a serious question. Please make an effort to think about it and come with an answer for your company: What is a "bad hire"?

Someone who writes code bad enough that the maintenance costs of the code outweigh the cost of employing them to write it. Of course this is often an organizational issue more than a hiring one, but we seem to have given up on fixing those.

There's also the cost of impact on a team, etc.

Shameless self-plug, though, for another post I wrote about organizational process: http://ramblinjan.com/development/2016/07/05/Going-Agile-Whe...

I definitely haven't given up on fixing those. I just, uh...I have a lot of feelings.

Re: Hiring Processes Are Also Engineering Processes

#67
post #60

Earlier quoted context omitted.

> Bad hires are ridiculously costly Here's a serious question. Please make an effort to think about it and come with an answer for your company: What is a "bad hire"?

Someone who writes code bad enough that the maintenance costs of the code outweigh the cost of employing them to write it. Of course this is often an organizational issue more than a hiring one, but we seem to have given up on fixing those.

[deleted]

Re: Hiring Processes Are Also Engineering Processes

#68

Earlier quoted context omitted.

Hum. Didn't read the usernames. Too much theory and not enough actionable advice. You know what. I'm just gonna talk candidates 30 minutes about them, us, me, the company (just talk, not any sort of test). Then I'll ask it to write a program to print number from 1 to 10 (that will be the test). And finally flip a coin before I take a decision (that's the randomness). I'm pretty sure it follows none of the good practi…

It's really really hard to come up with explicit actionable advice when a core part of your argument is that you need to do what is right for your team/company. To extend my TDD analogy, it would be like trying to write tests for someone else's codebase without any context. If you want some specific feedback for your team, please reach out to me on Twitter. I'm always thrilled to talk to people about process and orga…

I agree to that. The hard part of hiring is that it is a lot of customization for the specific environment of a company.

Hence my message. Talking about his past and future career, mine and the company's plan is the best thing for me to do, because I'm pretty that the other interviewers have not talked much about that, if at all.

And I'm confident that the hardcore technical interviews have been done. They don't need me to make it harder, except for a few select senior candidates. A for loop in a few languages written on the resume is enough (and it's fun for candidates who have "assembly") :D

Re: Hiring Processes Are Also Engineering Processes

#69

Earlier quoted context omitted.

Thanks for the feedback. I'll have to give it some thought because it seems like I failed to explain this well enough (though I may just straight up be wrong about it altogether). The candidates who ended up frustrated weren't feeling that way because we were jerks to them (I don't think). Maybe what I'm getting at is don't be afraid to push people to the limit a little bit in a task, because their reactions to it sa…

Most jobs don't require people who can endure getting "pushed to the limit" every week, hour, day, etc. Especially while under close observation and scrutiny. That would strain most any person. If it is that demanding, then be upfront about that instead of surprising candidates during a stressful interview. People should be aware of what they accidentally select for in candidates. I feel like I am skilled at remainin…

> then be upfront about that instead of surprising candidates during a stressful interview

People are rarely humble enough to actually reflect on this if they're excited about a job.

> People should be aware of what they accidentally select for in candidates

Absolutely.

Re: Hiring Processes Are Also Engineering Processes

#70

Earlier quoted context omitted.

I don't understand why everyone is ridiculously tough on interviews but wimps with firing. Just do a 1 year probation, and payout a couple of months severance with an NDA/non-disparagement clause. If the guy sucks, send him off. When I read these threads I'm always blown away by the time wasted on the hunger games hiring process. One guy on another thread was talking about 5 interviews with homework. What a waste of…

It costs a company a lot more to hire someone and then fire them, than it does to never hire them at all. Especially if you give them a few months' severance. That's the most generous probation program I've ever heard of.

Only if you demonstrate that this torturous process produces better candidates.

How many FTEs worth of time is spent on interview hunger games?

Post reply on HN