Hiring Processes Are Also Engineering Processes | Hacker News Reader

Hiring Processes Are Also Engineering Processes

ramblinjan.com

98 pointsramblinjan69 comments

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 writing these blog-anecdotes even quantifies what that cost is.

At the end of the day, programming interviews seem more like hazing than anything. No other profession hires with a full day oral examination. It's fucking ridiculous.

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 they aren't just expensive. On a good team, almost every new hire lowers everyone else's productivity initially.

Hiring more people because of loss aversion also falls prey to the trap of "more people = more productive" that's been pretty thoroughly debunked in the software industry (http://a.co/3ierKnl)

> Hiring more people because of loss aversion also falls prey to the trap of "more people = more productive"

Although perhaps true, I don't really see how this is relevant to what CoolGuySteve said.

CoolGuySteve isn't recommending anything about the number of people that are hired for a particular role, or the rationale for picking that number. Rather, he's just observing something about the cost of being overly picky about the previously fixed number of people that are hired for a particular previously fixed set of openings.

You don't always have a fixed number of positions.

Often it's "we could really use more people, but only if they're better than [some level]".

I'll have to think some on this. I really was not trying to take the brutal "we only hire the best" nonsense that a lot of companies do.

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

Isn't my original blog post at least a little bit of evidence that I've put a good bit of time into thinking about that?

I mean, a "bad hire" with the consulting/open source shop where I did a lot of interviewing & hiring was something pretty specific. A bad hire where I am right now is something pretty specific.

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 practises or advise out there. Yet I'm confident that this is a process that has a low risk of accepting bad hires and a low risk of filtering good hires. =)

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 organizational development. I'd love to chat with you about actionable ideas for your specific need.

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

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.

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 outside of interviews, just to collaborate with coworkers, in my first and second jobs (but not recently). I did it in Google interviews. (No, they didn't ask any puzzlers about manhole covers or blenders.) It was fun, I'd do it anytime.

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

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?

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?

Not much, maybe once a month. One thing I vaguely recall is the sequence and error handling of some service caching, writing to a database, and putting a message on a queue. Obviously it wasn't about "curlies in the right place". And as mentioned, it wasn't recently, it was about 3 years ago now - the most recent team I work with is very small and half remote.

I still think there are things that are good to be able to do, even if you don't use them regularly. As a bad metaphor, swimmers do some dry-land training...

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.

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

A phenomenal candidate can leave pretty easily, too.

But when I'm taking about not being afraid to make a "no hire" call, I'm not talking about the incredibly strong candidates. They tend to shine pretty well if you don't have a hiring process that is difficult for the sake of being difficult (e.g. brain teasers and whiteboarding). When I talk about not being afraid to dismiss someone, I'm talking about the (perhaps admirable) human urge to give an underwhelming candidate another shot.

>No other profession hires with a full day oral examination

When I was looking into pharmaceutical jobs, before I got into the tech industry, many of my inteeviews were all day affairs. Sometimes 5 or so interviewers would all come into one room and start bombarding you with questions, putting your answers down, play good cop bad cop, etc.

Resume writer and ~20 year tech recruiter here. Just a comment to readers about the author's estimate that your resume is being reviewed for 5 minutes. It's not, so be sure not to write your resume as if it is going to get that much attention.

Don't save the good stuff for the ending, thinking "the reader will get to that." Interview or delete decisions are often made in under thirty seconds, at least for things like a quick phone screen. If you start out the resume too slow, many readers are not getting to page two.

Good point. I tried to be pretty conservative so it didn't feel like I was fudging numbers to make a point about speed in earlier rounds, but I wonder if I should clarify.

I'll definitely include this when I write more for an audience of applicants. Resumes are soooooo boring, so anything to stick out is a big deal.

I was hoping not to seem pedantic on this, but it's potentially a key detail to a reader and I wouldn't want anyone to think they have 5 minutes to make an impression when the reality is much closer to 5 seconds to make an immediate positive impression. Then you likely get some more review time once the initial gut reaction is over.

Nicely written article BTW.

Thanks!

Definitely didn't take it as pedantic. Thanks for the reminder about the impact this could have on an audience I didn't think about. I added a small disclaimer.

Elevator pitch that resume.

Seconded. I always write a summary even though many writers don't, and my emphasis on summaries is also to define my client before a junior recruiter or inexperienced screener does it incorrectly on their own.

I hate the "objective statement" (since it is almost always just filler nonsense), but a good personal statement can go a long way. It's like a good thesis statement: make a bold claim that is backed up by the evidence in the resume. But it helps to tell people what unique stuff they should look for.

As a recruiter, I second this!

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 thanks that night, or got the offer out.

Anec-data to your point: The two best companies I've worked for made their offers at the end of the interview day.

How did they go about doing that? It seems like it would be very difficult to avoid pressuring someone to decide on the spot. When that's not the intent (i.e. when the company respects a person's right to think about the offer), it seems like that risks becoming an uncomfortable situation.

The offer was made: they didn't require an immediate response. They had refined their decision process, they didn't constrain my decision process beyond what's customary.

Cool. So they just said, "Hey, we would like to offer you the job. Here are the details. Please take your time and let us know when you've made a decision"?

That's right, although they said something like 'Please decide within the week' or something to that effect. I'd have to dig up old, old paperwork to get the exact phrasing, but it wasn't 'Hey dude, it's chill, whenever you make up your mind'

Ha! Right, right. Good on them, and thanks for indulging me.

Sounds super-professional.

you successfully censored the story about that giant censorship engine.

I just want to add. We provide instant feedback at my company too.

We just requite an immediate answer thought. We just tell the result and we send an offer letter the next day.

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.

While admirable, doesn't that strongly bias Voxy to local candidates?

I especially liked this part:

> If you need someone who can hit the ground running right away, test them with the exact tools they’ll be using on the job. If you need someone flexible who can learn anything, test them on something new and unique. If you need someone with a level head, try to frustrate your candidates and ditch the ones with short tempers.

Edit: Except for deliberately frustrating candidates.

If you need someone with a level head, try to frustrate your candidates and ditch the ones with short tempers.

My head's so level, I'd outright ask the interviewer if she's intentionally being an asshole as part of the "negative feedback" portion of our interview, or if she's actually that bad to work with. Regardless of the answer, as I was walking toward the door I'd ask if negativity is such a problem at their company that they feel a need to test for it.

> If you need someone with a level head, try to frustrate your candidates and ditch the ones with short tempers.

Interviews are a two-way street. If as a candidate I'm given an unrealistic expectation that's intended to frustrate me, I'll get the impression that's how the company normally operates and choose to look elsewhere.

This is a great point.

When I talk about intentionally frustrating candidates, it's mostly based on a technical interview we would do that a lot of people would struggle with. It hit the critical thinking itch, I think, and some people can't handle that. Y'all have me thinking that this section could use a little revision, though.

There could be reasonable ways to accomplish that. Knowing how well a candidate handles frustrating situations is definitely worthwhile, I just think there should be a lot of caution about how the situation is presented so that the candidate doesn't get the wrong impression.

> try to frustrate your candidates and ditch the ones with short tempers

There's a Mitchell & Webb sketch which seems almost obligatory here: https://www.youtube.com/watch?v=iRtBvo9grLw

"Derek is here to provide what we call 'extreme negative feedback', so that we can assess your ability to cope with stressful situations. Is that okay with you?"

I would caution against purposefully frustrating your candidates. Interviews where the interviewer is frustrating definitely have not made me looks more favorably on the company.

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 say as much as their approach.

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 remaining calm in crisis work situations where people (customers, co-workers, owners) are dependent upon me, but I can bomb interviews just as easily as the next person. Some approaches might consistently filter people who get stressed during interviews, rather than select people who maintain poise.

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

What I liked was the philosophy of deciding what personal traits are relevant for this job, and then specifically interviewing for those traits. The edit was because people seemed to be keying off the "frustrated" part, and that wasn't what I was trying to call attention to.

Made a slight edit. Thanks for the feedback.

Andy Groove "High Output Management" covers this topic and more. Highly recommend! https://www.amazon.com/dp/B015VACHOK

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.

It's not an issue of time, but expectation. If it is clearly known that it will take 5 days to respond then the developer won't be peeved. The most important part of the process is to be transparent.

Made a small edit based on your comment. Thanks!

Fair point.

I want to say this again: a technical recruiter should not define hiring policy or hiring process. Their value is in their relatively low cost per candidate.

I look at this a little differently. OP seems to treat Engineering as a totally independent organization within a company. In bigger companies, I understand. But I don't think it makes as much sense in a smaller company, where, often, the tight-knit culture is what's keeping the ship afloat.

Engineering is one piece of the pie. The success of the company is everyone's success. Consequently, the team's hiring process can and should be influenced by people outside of Engineering, to some extent. One has to take the comapany's culture in account.

You've got me looking back at what I've written, because I actually agree with you on company culture (if the company's culture is a positive force). My point about technical recruiters is because they're very often totally separated from the engineering culture. Oddly enough, I'm speaking about smaller companies more so than bigger ones because a large company is less likely to give their engineering teams enough autonomy to really do anything with what I've written.

The main thing I wanted to get at here is that a hiring process can not be thought of as separate from your engineering process. I'm not trying to argue that hiring should be insulated from reality. I'm arguing that there are a lot of companies who are ignoring the fact that it isn't.

Most hiring processes are engineering processes in the same sense that throwing a sheet over two chairs to make a cubby house is civil engineering...

The title got updated by HN, I think. I'm not trying to call everything engineering (I don't actually think everything should be approached as an engineering process). My argument is that the decisions you make about culture and process in hiring inevitably affect your actual team's process.

hiring processes are business processes

engineering processes are business processes

there is the common "base class"

Was there ever a time in the tech industry where employers would provide actual training to new hires? Besides Facebook's boot camp.

Every new hire takes training.

Old school IBM/HP/DEC

Reply on news.ycombinator.com