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.<p>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.<p>These costs can easily outweigh the cost of a bad hire. Nobody writing these blog-anecdotes even quantifies what that cost is.<p>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.
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. <i>It's not,</i> so be sure not to write your resume as if it is going to get that much attention.<p>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.
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.<p>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.
I especially liked this part:<p>> 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.<p>Edit: Except for deliberately frustrating candidates.
Andy Groove "High Output Management" covers this topic and more. Highly recommend! <a href="https://www.amazon.com/dp/B015VACHOK" rel="nofollow">https://www.amazon.com/dp/B015VACHOK</a>
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.
<i>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><p>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.<p>Engineering is one piece of the pie. The success of the company is everyone's success. Consequently, the team's hiring process <i>can and should</i> be influenced by people outside of Engineering, to some extent. One has to take the comapany's culture in account.