5 ms·
When I was first promoted to leading a team and tasked with hiring people, I was really scared because of the prevalence of articles and anecdotes claiming scar
by mlthoughts2018 8y ago
When I was first promoted to leading a team and tasked with hiring people, I was really scared because of the prevalence of articles and anecdotes claiming scary things like “80% of people in software can’t code” or “one bad hire will destroy your team.”
After a few years of doing it, I think those fears are silly and it’s all a lot of overblown scare tactics to pressure us into cargo-cult adoption of what Google has done, usually through consulting firms that advise on the recruiting process or through new businesses like HackerRank, etc., that try to commoditize this fictional hiring fear.
What has worked for me is trusting recommendations from my existing team, employees in a company, or my extended network. I’ve also selectively reached out to specific users of GitHub, Stack Overflow, Kaggle, and other community sites. I will also travel to university recruiting fairs, professional conference recruiting fairs, and sometimes local meetups or technology groups.
I avoid opening up a job ad to the whole internet and accepting an undifferentiated stream of resumes. I avoid it not because it means I have to weed out “bad coders” or some nonsense — in many cases, most applicants are fully skilled enough for the job, and it’s just a big lie in our industry when people whine about inability to pass FizzBuzz. It keeps the incentives aligned towards hiring hyper-competitive 22-year-olds who just spent 10 months on leetcode and end up working for a lot less money, while nobody thinks about the impact on culture, long-term design or other expertise, diversity, etc. They just want the 22-year-old leetcode jockeys to arrange them as a doll collection in open-plan seating for VCs and investors to walk by.
Instead I an internet stream of resumes because it’s not cost effective to put myself in a position where I or especially engineers on my team have to scour huge piles of resumes.
I can’t stress this enough. You should not open yourself up to a firehose of resumes. And adding extra filters, like coldly making candidates complete a code test before they even speak to a human about the nature of the job is just a symptom of the contortions you have to do if you open yourself up to a firehose.
Focus on improving the useful signal of the source of resumes. Keep diversifying and improving this, and take on small batches of higher signal resumes.
If I could summarize what has worked efficiently for me:
- keep job ads short and technically focused on the intended job duties
- don’t open yourself to a firehose of resumes
- use technically probing conversation, recursively digging into really technical details of the candidates past experiences or studies
- code tests, if used at all, should be used lightly, involve no hazing-style algorithm trivia, and candidates should have options regarding their comfort and preferences (e.g. doing it on-site vs take-home, using their editor & programming environment of choice, generous time limit, and absolutelt nothing resembling HackerRank/coderpad/whiteboard hazing nonsense).
- Keep initial interviews short and informative.
- Use the max over a candidate’s performance in early rounds, and min in later rounds, explained below:
- In early rounds, always have more than one interviewer to get multiple impressions, and use the best candidate impression to decide to continue them to the next round.
- in late rounds, have many interviewers and use something closer to the candidate’s worst session to decide on an offer, but perhaps with some careful discussion to mitigate the chance it was unrepresentative.
- And of course always give the candidate a chance to ask questions and see the facilities. I would expect a candidate to absolutely turn me down if they aren’t allowed to ask questions, and why shouldn’t they? Especially if my company comes across like we care more about cramming in one more trivia question than about the candidate’s curiosity and preferences, frankly then we don’t deserve to hire a good candidate.
There really is such a woeful lack of Peopleware-style common sense in modern tech hiring; a lack of basic humanity or empathy to such a degree that it actually hurts business.
- HillaryBriss 8y agoi appreciate your thoughtful comment, especially the part where you describe using recommendations from your existing team or network to avoid the firehose of resumes. but then, further down, i was surprised to see the first tip about writing job ads. i mean, won't job ads pretty much turn on that firehose of resumes?
- mlthoughts2018 8y agoOnly if you post them to an application portal, a third party recruiter, or job aggregation sites. Usually you’ll still need some type of written job description for a candidate to review, and it should be concise & genuinely informative. But you should choose which candidates to share it with (e.g. on community sites, at conference recruiting fair booths, or by email sent from a referral). I didn’t mean to imply writing a job ad for purposes of widely distributing it— but I totally see that my choice of the word “ad” was a mistake. Should just be some type of infrequently shared written job summary.
- logfromblammo 8y agoSo which garden hoses of resumes should I put my resume into--rather than the fire hose--if I want to be hired by a good company that follows your recommendations? If you don't drink from the fire hose, you're accepting the intrinsic biases of the lower-flux feeds that you do use, and missing the candidates that won't necessarily know to stand exactly where you are willing to search for them. But then, if you do disclose your sources, and everyone starts using them, those eventually increase in volume and decrease in quality as well. The problem is still finding a method to match high-quality employee candidates with high-quality employers, without getting swamped by any low-quality parasites inserting themselves into the signal and masquerading as high-quality for individual benefit. Why not have some of the candidates vet each other? Give everyone a random set of N partially anonymized resumes, and ask them to pick the one out of the N that they would most enjoy working with at your company.
- mlthoughts2018 8y agoThis is very true, and if you find that for your use case, you really need that bigger fire hose, then by all means go for it. But you have to agree you're shifting different costs around. If you go with the fire hose, you have to pay the weed-through-tons-of-resumes costs, often including build outs of application systems, standardized portals and application/interview pipelines, third-party recruiter overhead, etc. I would argue that even if the fire hose is allowing you more access to the tail of some candidate distribution, it is not worth that cost, and in all likelihood the best candidates would be reachable through other means anyway. In reality, many of the companies that use these big recruiting platforms designed to wrangle an internet fire hose of resumes fall into two camps (yes, an oversimplification, but often useful): - big corps who want a large pool of resumes solely to put downward pressure on salary -- these are the same companies that will ask you to do a 20 minute song and dance interview with someone from HR right at the start, which is nothing but pretense to ask about your salary requirements, and immediately reject you if you either won't say or say something too high. This kind of place right away communicates that engineering managers don't have the power to hire good people, only people who were cheap enough to pass the initial HR filter. - Places that cargo-cult copy the hiring process of other, uncommonly successful places. When you focus on cultivating a smaller network of places to request resumes, you do pay a cost. You do immediately prevent yourself from good candidates who wouldn't just happen to be in your targeted applicant communities. But this is life. Trade-offs. Do you know that this cost is worse than all the costs associated with the huge big-box applicant pipelines? I mean, people using those pipelines are still often heard griping about how hard it is to find candidates and how long it takes. My experience has been that the benefits of narrow, specialty / community focused requests for applicants work out to be a lot better overall, even if I have to endure some unpleasant costs to do it that way. No method is perfect, so you have to look at the trade-offs. And as always, your mileage may vary. > "The problem is still finding a method to match high-quality employee candidates with high-quality employers, without getting swamped by any low-quality parasites inserting themselves into the signal and masquerading as high-quality for individual benefit." I actually really disagree with this, and I think it just perpetuates the myths about tech hiring. In reality, very few applicants are "masquerading" (and, by the way, all applicants are in it for individual benefit). People seriously overestimate how many applicants are "fakers" -- especially because they will ask some asinine hazing trivia, like some useless question about esoteric data structure internals, and then when someone can't answer it perfectly in 20 minutes, they'll be declared a "faker" and the interviewer will jump on Hacker News and write some comment embellishing the situation, as if the candidate ran away in terms when asked to solve FizzBuzz, despite having 10 Ivy League degrees on their resume. It's nuts. Few people are fakers. It's safe to assume applicants are sincere, and then technically probe them. If they can't speak with you in good technical detail about their experience or studies, it doesn't meant they are a faker, but it might mean they aren't the match for your role. Be nice to them, give them useful feedback, and move on. But I can't even imagine how awful it must be to harbor such a cynical attitude that you need to be significantly worries about people "masquerading" during interviews. It really, truly just isn't true, not even when you do use a fire hose stream of resumes.