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.
> 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)
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.
Often it's "we could really use more people, but only if they're better than [some level]".
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 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!
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.
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. =)
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.
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
Of course this is often an organizational issue more than a hiring one, but we seem to have given up on fixing those.
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.
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.
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.
How many FTEs worth of time is spent on interview hunger games?
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...
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."
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.
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.
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.
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.
Nicely written article BTW.
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.
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.
We just requite an immediate answer thought. We just tell the result and we send an offer letter the next day.
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 :)
> 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.
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.
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.
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'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?"
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.
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.
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
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.
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.
engineering processes are business processes
there is the common "base class"