making technical recruiting suck less

Note: This post is cross-posted from interviewing.io’s blog. interviewing.io is a company I founded that tries to make hiring suck less. I included it here because it seems like there’s a good amount of thematic overlap. And because there are some pretty graphs.

interviewing.io is an anonymous technical interviewing platform. We started it because resumes suck and because we believe that anyone, regardless of how they look on paper, should have the opportunity to prove their mettle. In the past few months, we’ve amassed over 600 technical interviews along with their associated data and metadata. Interview questions tend to fall into the category of what you’d encounter at a phone screen for a back-end software engineering role at a top company, and interviewers typically come from a mix of larger companies like Google, Facebook, and Twitter, as well as engineering-focused startups like Asana, Mattermark, KeepSafe, and more.

Over the course of the next few posts, we’ll be sharing some { unexpected, horrifying, amusing, ultimately encouraging } things we’ve learned. In this blog’s heroic maiden voyage, we’ll be tackling people’s surprising inability to gauge their own interview performance and the very real implications this finding has for hiring.

First, a bit about setup

When an interviewer and an interviewee match on our platform, they meet in a collaborative coding environment with voice, text chat, and a whiteboard and jump right into a technical question. After each interview, people leave one another feedback, and each party can see what the other person said about them once they both submit their reviews. If both people find each other competent and pleasant, they have the option to unmask. Overall, interviewees tend to do quite well on the platform, with just under half of interviews resulting in a “yes” from the interviewer.

If you’re curious, you can see what the feedback forms look like below. As you can see, in addition to one direct yes/no question, we also ask about a few different aspects of interview performance using a 1-4 scale. We also ask interviewees some extra questions that we don’t share with their interviewers, and one of those questions is about how well they think they did. In this post, we’ll be focusing on the technical score an interviewer gives an interviewee and the interviewee’s self-assessment (both are circled below). For context, a technical score of 3 or above seems to be the rough cut-off for hirability.

Feedback form for interviewers

Feedback form for interviewees

Perceived versus actual performance

Below, you can see the distribution of people’s actual technical performance (as rated by their interviewers) and the distribution of their perceived performance (how they rated themselves) for the same set of interviews.1

You might notice right away that there is a little bit of disparity, but things get interesting when you plot perceived vs. actual performance for each interview. Below, is a heatmap of the data where the darker areas represent higher interview concentration. For instance, the darkest square represents interviews where both perceived and actual performance was rated as a 3. You can hover over each square to see the exact interview count (denoted by “z”).

If you run a regression on this data2, you get an R-squared of only 0.24, and once you take away the worst interviews, it drops down even further to a 0.16. For context, R-squared is a measurement of how well you can fit empirical data to some mathematical model. It’s on a scale from 0 to 1 with 0 meaning that everything is noise and 1 meaning that everything fits perfectly. In other words, even though some small positive relationship between actual and perceived performance does exist, it is not a strong, predictable correspondence.

You can also see there’s a non-trivial amount of impostor syndrome going on in the graph above, which probably comes as no surprise to anyone who’s been an engineer.

Gayle Laakmann McDowell of Cracking the Coding Interview fame has written quite a bit about how bad people are at gauging their own interview performance, and it’s something that I had noticed anecdotally when I was doing recruiting, so it was nice to see some empirical data on that front. In her writing, Gayle mentions that it’s the job of a good interviewer to make you feel like you did OK even if you bombed. I was curious about whether that’s what was going on here, but when I ran the numbers, there wasn’t any relationship between how highly an interviewer was rated overall and how off their interviewees’ self-assessments were, in one direction or the other.

Ultimately, this isn’t a big data set, and we will continue to monitor the relationship between perceived and actual performance as we host more interviews, but we did find that this relationship emerged very early on and has continued to persist with more and more interviews — R-squared has never exceeded 0.26 to date.

Why this matters for hiring

Now here’s the actionable and kind of messed up part. As you recall, during the feedback step that happens after each interview, we ask interviewees if they’d want to work with their interviewer. As it turns out, there’s a very statistically significant relationship (p < 0.0008) between whether people think they did well and whether they’d want to work with the interviewer. This means that when people think they did poorly, they may be a lot less likely to want to work with you3. And by extension, it means that in every interview cycle, some portion of interviewees are losing interest in joining your company just because they didn’t think they did well, despite the fact that they actually did.

How can one mitigate these losses? Give positive, actionable feedback immediately (or as soon as possible)! This way people don’t have time to go through the self-flagellation gauntlet that happens after a perceived poor performance, followed by the inevitable rationalization that they totally didn’t want to work there anyway.

Lastly, a quick shout-out to Statwing and Plotly for making terrific data analysis and graphing tools respectively.

1There are only 254 interviews represented here because not all interviews in our data set had comprehensive, mutual feedback. Moreover, we realize that raw scores don’t tell the whole story and will be focusing on standardization of these scores and the resulting rat’s nest in our next post. That said, though interviewer strictness does vary, we gate interviewers pretty heavily based on their background and experience, so the overall bar is high and comparable to what you’d find at a good company in the wild.

2Here we are referring to linear regression, and though we tried fitting a number of different curves to the data, they all sucked.

3In our data, people were 3 times less likely to want to work with their interviewers when they thought they did poorly.

Share this:

If you’re a regular reader of this blog, you know that I’ve come to rely quite heavily on data. I’ve counted typos on resumes, I’ve sifted through a corpus of engineering offers, and I’ve skimmed thousands of recruiting messages to tag them by personalization level. This post, however, is going to be a bit of a departure. Rather than making broad, sweeping conclusions based on a lot of data points, I’m going to narrow in on one story that happened, in part, because of some data I gathered during an experiment. I think it’s a really cool story, and I can only hope that there will be more stories like it that, in time, will enable me to write another post with lots of graphs.

The experiment in question was thus. Last fall, I showed a set of anonymized engineering resumes to about 150 engineers, recruiters, and hiring managers and asked one question: Would you interview this candidate? It turned out that not only did both recruiters and engineers largely fail at predicting who the strong candidates were, but, much more importantly, no one could even agree on what a strong candidate looked like in the first place.

These results were quite startling, and they left me scratching my head about the implications. After all, resumes are such a huge part of how hiring is done. Of course, it wasn’t always this way. From Chinese civil servant exams to Thomas Edison’s somewhat infamous general knowledge tests, filtering for positions requiring specialized knowledge was, up until the last century, accomplished largely through a variety of aptitude tests. Even as the resume rose in prominence and became a ubiquitous arbiter of potential fit, its format has gone through a number of evolutions. Things that were commonly included on resumes at various times (and still are in certain cultures) — a photo, marital status, age, religion, height, weight, blood type, and political affiliation — are no longer en vogue, and it’s certainly not inconceivable that, in the future, asking for a resume will seem just as silly as these now-outdated practices.

So, if resumes aren’t a good signal for hiring engineers, what is? In my blog, I wondered if, instead of a resume, it might be interesting to have people write a bit about something they built that they were excited about. I was excited, in turn, when my friends at KeepSafe actually decided to try this out — for a month, candidates who applied through KeepSafe’s No Resume campaign were evaluated purely on what they wrote about their projects, and this writing sample would be the only thing used to decide whether someone would get an interview. This is the story of what happened.

KeepSafe, in some ways, came to this experiment out of necessity. Like many other small startups, they were feeling the acute pain of hiring engineers in this market. They had a product people loved, a ridiculous user to engineer ratio (39M users for 6 engineers), and the requisite hip South Park office. Along with that, though, they had quite a high hiring bar and consistently found themselves competing for talent with the likes of Google. And more often than not, they’d lose.

To stay in the game, KeepSafe needed to change up the rules and tap into a different pool of people. The hope was that out there were plenty of talented engineers who were getting overlooked because of their lack of resume pedigree but who were passionate and skilled and who would be awesome hires, given the chance to show what they could do.

KeepSafe’s experiment struck a chord, and in the first two days, over 400 people submitted descriptions of stuff they’d built. Awesome stuff like this.

Submissions varied in length. Some were just a sentence. Some were multiple pages and supplemented with links to demos. Not all submissions were awesome. Some were generic, copy-pasted cover letters espousing their interest in the software development life cycle, and some were just disconnected links. Those KeepSafe cut immediately. The rest were a lot tougher to cull.

Though I didn’t participate in the judging, one thing that struck me about the submissions I read was that my normal approach was useless here. Normally, when I look at resumes, I can make a yes/no decision based on proxies like past employers within 10 seconds. With KeepSafe’s submissions, I couldn’t rely on proxies at all. With each person, I had to think about what they built, imagine it, understand it. In addition, I found myself starting to getting a real read on people’s interests and trying to imagine what projects they might want to tackle at KeepSafe, something that’s much harder to gauge with the traditional resume format.

All of this was weird and slow, but it felt really good. And then I realized that unless your achievements fit into a convenient mold, you’ll lose the best parts of you when you try to beat your windy path into a nice clean line. Resumes don’t have an explicit section for building rockets or Minecraft servers, and even if you stick it somewhere in “personal projects”, that’s not where the reader’s eye will go. The sad truth is that if the reader doesn’t like or recognize what they see before they get to the rockets, they will likely never get there at all.

***

By traditional Silicon Valley standards, AJ Alt didn’t look especially good on paper. He hadn’t attended a brand-name school, his GPA wasn’t high enough to stand out, and his only professional programming experience was a multiyear cybersecurity stint at a huge defense contractor, the nature of which he was forbidden from discussing, on a resume or otherwise. His GitHub, full of projects spanning everything from a Python SHA-1 implementation to a tongue-in-cheek “What should I call my bro?” bromanteau generator, hinted at a different story, but most people never got there. While AJ’s government work experience gave him a good amount of cred in the public sector, he found that making the move to industry, and startups especially, was near impossible. It wasn’t that he was blowing interviews. He just couldn’t get through the filter in the first place.

Of the 415 people who applied to KeepSafe through the No Resume campaign, 18 ended up interviewing, and 5 came in for an onsite day of coding. One received an offer. It was AJ, a candidate that Zouhair Belkoura, KeepSafe’s cofounder and CEO, readily admits he would have overlooked, had he come in through traditional channels. Since starting a couple of months ago, AJ has built out an open source Android animation library and was one of the co-creators of a brand new security feature within the app.

When I asked Zouhair if KeepSafe would consider the experiment a success, his answer was a resounding yes. According to Zouhair, “The overall quality of applications seemed to be a lot higher than through our normal resume channels. We also met more people who seemed to genuinely like programming and wanted to talk about it [rather than people just applying because they wanted a job].”

The team has decided that they will continue to hire without resumes for the foreseeable future — the funnel numbers for this process weren’t too different than what you’d see in a more traditional setting, and, with time, as the team gets better at making value judgments based on writing and projects, they will only improve. Resumes work well for companies like Google because their strong brand drives a revolving door of inbound applicants. Copying that process, if you’re a smaller brand, however, can be detrimental. Of course, this experiment had a small sample size, and one hire is more anecdote than gospel, but if replacing the resume with a writing sample is a good way to get at a different, yet highly skilled and engaged talent pool, then it’s worth a shot. As Zouhair told me, “Our culture is that code speaks louder than credentials, and now we have a hiring process that reflects that. [When we made the hire], we had never even seen AJ’s resume. And we don’t need to.”

Share this:

I recently had the utterly terrifying experience of giving a guest lecture to an MIT computer science class on technical communication/public speaking. To my relief, things went quite well, and it was awesome to peel back the curtain a bit and give students a perspective on what actually happens inside companies when they’re hiring.

Before my talk, I sent out a survey to see which job-hunt related topics were most interesting, and in addition to the usual stuff about technical interviewing and negotiation, one of the more sought-after topics was how to vet companies during the interview process.

Doing this well is really hard. There’s not much time, you don’t feel like you have much power, and people tend to respond to your questions with rehearsed platitudes. To make things easier, I’ve compiled a list of very specific questions you can ask, verbatim. The purpose of these questions is to be really specific/situational so you can quickly get past the platitudes and make shit get real.

Note that:

It’s a good idea to ask some subset of your interviewers the same questions to see how their answers differ… because the devil is in the deltas.

Don’t waste precious time talking about benefits/salary/vacations/process during interviews – you can get those answers later from HR or whatever.

Bolded questionsare ones I particularly enjoy or find non-obvious.

Without further ado, the questions, broken up by topic, are below. Please use some subset of them at your leisure, and tell me if they helped you! Oh, and maybe don’t say “fuck” in interviews unless you can own it.

Team caliber/culture

How long have you been here?

When you were last interviewing, what were some of your other options, and what made you choose this company?

What is the most fulfilling/exciting/technically complex project that you’ve worked on here so far?

What is something you wish were different about your job?

How often have you moved teams? What made you join the team you’re on right now? If you wanted to move teams, what would need to happen?

(If the company is a startup) When’s the last time you interacted with a founder? What was it regarding? Generally how involved are the founders in the day-to-day?

Engineering

What does a typical day look like? EDIT: What did your day look like yesterday? Was that pretty typical? If not, what does a typical day look like?

What is your stack?

What is the rationale for/story behind this specific stack?

How often do you add new tools to the mix?

Do you tend to roll your own solutions more often or rely on third party tools? What’s the rationale in a specific case?

What kind of test coverage do you have?

Would you describe your engineering culture as more pragmatic or more theoretical?

What portion of your time is spent working on new stuff rather than iterating on existing stuff?

How long are your release cycles?

What’s been the worst technical fuckup that’s happened in the recent past? How did you guys deal with it? What changes were implemented afterwards to make sure it didn’t happen again?

What is the most costly technical decision made early on that the company is living with now?

If possible, also ask for the opportunity toview the source. This may be tricky, it may involve signing some stuff, and you may not be able to do it, but it doesn’t hurt to ask. The best thing, if you can, is to just spend a few days working onsite as a contractor. It’s hard to make time, but boy does that give you some valuable perspective. I’ve had candidates on the brink of accepting offers rapidly drop out after seeing that the day-to-day/codebase/team dynamic was nothing like they expected. And I’ve had people who weren’t sold at all end up loving a place because they got to spend some time with the team.

Product voice/visibility into business side

What are you working on right now? Why/how did that become the thing that you ended up working on?

If you had an idea for something new to build, what would you have to do to make it happen?

What is some of the more meaty new stuff that got pushed in the last release? Where did the idea for that feature originate? Where do product ideas generally come from?

Who are the other major players in this space? What do we have that they don’t?The answer to this one can be useful for getting some idea of what the space looks like and what traction the company in question might have. Most importantly, though, it’ll give you some insight into whether the people at the company care about the product and the business side of things or not and how much they’ve thought about stuff like this.

Attrition

How long does the average engineer stay at the company?

Why have the last few people left?

Entrepreneurship

How many former employees have gone on to found startups?

Was their leaving to do so was generally looked on favorably?

How does company culture encourage entrepreneurship? Specific examples?

Share this:

Lately, a good number of people have asked me for feedback on their tech recruiting startup ideas, and I’ve noticed that I tend to ask the same questions and give the same advice over and over. Below, I’ve reproduced some of these things. At the end of the day, a lot of my advice is based on the current market climate, where engineering demand severely outstrips supply. I don’t know how long this state of affairs will last, but this state of affairs is precisely why this space is heating up and why it’s so lucrative.

At this point, you might be asking yourself something along the lines of, “Who is this dipshit, and why is she qualified to give advice about starting companies?” I ask myself that every day, and as a disclaimer, I too am working on a product in this space (interviewing.io), so we’ll see if I take my own advice!

Many of the people approaching me are eng hiring managers who are considering leaving their job to build tools that fix the hiring problems they encounter in their day-to-day. As a hiring manager, one of the biggest problems you encounter is filtering, namely going through a bunch of candidates and figuring out who’s good. This is really hard. Resumes are pretty low-signal, and technical interviews are fraught with their own set of challenges. But sometimes hiring managers tend to forget that before candidates even get to their part of the process, they’ve chosen to be in the mix, and they have already passed through at least one or two filters. In other words, you’re taking for granted the fact that the people who are crossing your desk want to work at your company in the first place.

Hiring, like sales, is a funnel. At the top, you have your attempts to get people in the door, either through building the kind of brand where people want to apply or through spamming the world or any number of other things. The middle is filtering, where you try to figure out whether the people in your funnel are worth hiring. Unfortunately, filters don’t make people better, so you are constrained by the quality of your sourcing efforts. And, in this market, where engineering supply is severely out of whack with demand, where good people are rarely actively looking for jobs, and where contingency recruiters get at least $25,000 per hire, the biggest problem isn’t filtering through a bunch of engaged job seekers. The problem is engaging them in the first place.

To drive this point home, let’s do a thought experiment. Given the data available on the internets, you could reach out to every engineer at Facebook and/or Google who went to school at MIT and/or Stanford. That data is already out there, and between LinkedIn, Rapportive, Clearbit, Entelo, other candidate search aggregators, and/or a little bit of quick and dirty scripting, doing this isn’t that hard. What’s hard is finding the ones who want to talk to you. Therefore, any product in this space that focuses on filtering isn’t solving the fundamental problem.

2. If you’re building a two-sided marketplace, create value for great engineers up front.

As you saw above, in this market, great engineers are rarely looking for work. Therefore, if you’re building some variation on the theme of a two-sided marketplace that attempts to pair top talent with great companies, you will quickly realize that getting great engineers to sign up is hard. They simply don’t need it and don’t want to be inundated with more noise.

If you do want to engage with the best people (And you do, right? Because it’s easy to go broad if you start elite but really hard to go the other way… kind of like a hiring law of entropy.), think carefully about what value you’re providing up front to people who don’t need you — if you can get that segment interested, everyone else will follow. Hired did this really well by taking advantage of the fact that salary data is pretty opaque and convoluted. In other words, all of a sudden, great engineers had a reason to sign up because, with very little effort (clicking once to sign in with LinkedIn), they could get a pretty good first-pass approximation of their market value that they could then, at the very least, use as leverage and at best, to find a new job. This is a big deal.

How do you apply this to your idea? If there’s some hard-to-find info you can shine a light on (salary data, team structure, etc.), by all means do it. If you can’t do that, then think about convenience. As it stands, interviewing is a pain point. Great people often have many interview loops going on in parallel, different parts of which are more frustrating than others. If you can streamline part of the process, or let the candidates you work with skip some of the drudgery, you’re going to be in good shape.

3. Are you trying to force people into behaviors that run counter to their incentives?

Regardless of the space you’re in, you should be building something your users want, but I can make the pitfalls really concrete in the tech recruiting space. Specifically, many of the people that come to me asking for my opinion on their business idea oversimplify the incentives at play. They assume that everyone just wants to hire the best people and that’s it. However, the world of incentives is complicated, and you have to be mindful of the misalignment of individual incentives/those of the purchasing decision makers relative to the optimal outcomes for organizations. In other words, though everyone wants to hire the best people, unless your product is an unambiguous, direct line to doing that, shit gets hard. To illustrate these points, I’ll go through 2 examples. Both are drawn from reality. The first one is from my own experience, while the second is my analysis of why someone else’s product in this space didn’t pan out.

Incidentally, although in-house recruiters are not the only ones with complicated incentives, they are generally the gatekeepers for figuring out which hiring products to use, so I’ll focus on them here. If you’re selling to recruiters, you have to be able to put yourself in their shoes, and you have to be careful to not oversimplify what their incentives actually are. “Recruiters want to hire more good people” is often a gross oversimplification that causes you to lose a lot of time building the wrong things because you don’t deeply understand your audience. Your other option is to say that you’re going to go around recruiters and sell to a different org within the company, but that’s its own can of worms with its own set of tradeoffs that I’ll save for a future post.

Example 1 – Why presenting great candidates isn’t enough

So, with in-house recruiters, their whole job is to hire good people, right? However, what does “good” really mean? When I was focusing on running a 3rd party recruiting agency, I consistently ran into the same problem when working with in-house recruiters. I’d present a candidate who looked like shit on paper but that I had reason to believe was good (previous work, having run them through technical screen, etc). Recruiters at these companies, by and large, wouldn’t entertain a conversation with these candidates because it was too risky for them. Engineering time is precious, and if you present someone who looks suspect and they don’t work out, you incur a good amount of vitriol internally. If, however, you keep presenting safe candidates, some of whom make it through and some of whom don’t, no one can blame you.

To put it really concretely, I’d expect that as an in-house recruiter, if you presented 10 candidates from Google/Facebook/MIT/Stanford, 8 of whom didn’t get an offer, and 1 of whom did but was clearly never too interested in your company, and 0 of whom got hired, no one would bat an eye. On the other hand, if you presented 10 candidates, all of whom looked kind of weird on paper, 2 of whom got offers, and 1 of whom got hired, you’d probably going to get a stern talking to.1

It’s a bit silly, but that’s how things work. If you’re building a product that surfaces people for recruiters to talk to, think about whether those people are risky bets and how those risky bets affect recruiters’ metrics — recruiters are bound by all sorts of metrics, and how many people they hire is only a small part. So, getting them to make seemingly unsafe, ambiguous choices with no clear return probably isn’t the best way to go.

Here’s another one. Let’s say you’re building a sourcing tool that involves getting the engineers at a given company to hook in their social networks so that your recruiters can then reach out to the people that engineers at the company already know, as those people are likely to be 1) good at stuff because yay referrals and 2) warm-ish leads. Cool idea, right? And it makes sense because recruiters want to hire more good people, right? Unfortunately, as before, it’s not that simple.

While recruiters do want to hire good people, that’s not the only thing they want. There are tons of products coming at them claiming to make their lives easier all the time. Most of these products end up not doing that. Now, in addition to asking them to spend time on something with questionable return, you’re asking them to evangelize said questionable product to engineers, whose participation is necessary for things to work, before the recruiters even have a chance to confirm that the product is, in fact, useful. Add to that the tension/stratification that already tends to exist between a company’s engineers and its in-house recruiters, and you wind up with a tall order. Having to vouch for something before you know it’s great is uncomfortable and weird.

For the record, this product was a real thing, and it was called YesGraph. When I first heard about it, I thought it was an awesome idea, but then I learned that they ended up pivoting away from hiring. I believe that the misalignment of incentives I described is partially to blame.

Incidentally, if you’re curious to read more about the challenges around driving/productizing referrals, I wrote about it at some length on Quora.

4. If your goal is to scale your two-sided marketplace, don’t turn into a middleman by accident.

In any two-sided marketplace, the path of least resistance often involves sitting between the two sides and playing god to make sure that everything that is supposed to happen is happening. You want to make sure that the right people are talking to the right companies and that companies are interviewing your candidates and so forth. Sure, down the line, you’re going to build an automated system, but for now, you’ve gotta get in there and make some tweaks.

I am a wholehearted believer in doing things that don’t scale. But, you have to be mindful of whether what you’re doing is going to keep you from going in a scalable direction in the future. Matching users with companies by hand? Great, that makes sense while you learn what works and what doesn’t. But, if you aren’t mindful of it, before you know it, you have a recruiting agency on your hands, just one that happens to have a nice startup-y skin. And, by the time you realize it, you’re too vested in the unscalable status quo to change anything because money’s coming in. And then you have to hire a bunch of recruiters, and then you’re committed. And now, you’re growing linearly with the number of recruiters you hire.

So, sure, do things that don’t scale, but keep asking yourself whether what you’re doing will ever be possible to automate and be mindful of whether you’re creating an infrastructure of middlemen with a vested interest in the status quo. And if you realize that what you’re doing is really hard to automate with technology or solve through crowdsourcing/engaging with your users, then ask yourself whether there’s something else you should be trying.

1 As a footnote to this story, one of the first companies I worked with made a deal with me after seeing the nontraditional kinds of candidates I presented. They said that, though they’d be down to talk to the first 3 candidates I threw their way, if most of them didn’t make it to at least onsite, I was going to be fired. Two years later, this company is one of my favorite clients to do business with — I love their team and, even at the time, I completely empathized with their skepticism. Though it ended up working out well, this kind of deal is rare and getting over the hump was likely helped by the fact that I knew one of the founders.

Like many commission-based jobs, technical recruiting has a pretty low barrier to entry, everything you need to know you can probably learn on the job, and the payouts can be huge. On top of that, having an engineering background can give you a significant edge over your non-technical colleagues. However, it is not an easy field to be successful in, in much the same way that consistent, high magnitude successes in sales are difficult. Confound that difficulty with the terror that comes with striking out on your own, and you’re in for a bumpy ride. Below, I’ll share the most salient things I’ve learned in the process of launching my own technical recruiting firm. Some of these things are obvious, and some, at least for me, were entirely unexpected.

Before getting into the list, one thing I want to stress is that, if you’re thinking about doing this, you shouldn’t quit your day job until you know it’s really something you can do. People, engineers especially, tend to think that technical recruiting is easy money. Certainly, it’s not the hardest job, and it uses a very different part of your brain than writing and designing code, but by no means is it a walk in the park. Therefore, before committing to this new course, if it doesn’t create a conflict of interest with your current job, try placing people part-time while you continue to do whatever it is you’re doing now. See if you can make a placement or two before you go all-in. And, even more importantly, see if it’s something you like doing. Because the day-to-day isn’t always awesome… which brings me to the first item in the list.

1. A good chunk of recruiting is wrangling people. And that part sucks.

When I first got into recruiting, I thought that most of the job would be finding talented engineers and presenting them with great opportunities they wouldn’t have had access to otherwise. Sounds great, right? I thought I’d be getting paid to judge people, unearth the good ones, and rack up karma points for making their lives better.

In reality, a good chunk of the job happens after you find great engineers. You have to convince companies to talk to them because unless they fit a very specific, pedigreed mold, most companies won’t touch them with a 10 foot pole. Following up every few days to make sure that everyone who’s supposed to talk to everyone else is actually talking. Checking in to see what everyone thinks and how they’re feeling. Keeping track of your candidates’ timelines. Potentially getting into shit situations where multiple companies are interested in the same person and trying to figure out how to best recuse yourself so no one thinks you’re an asshole who’s instigating a bidding war while still trying to make sure your engineer gets the best offer they can.

It’s a hot mess. A lot of this job is like being stuck between 2 different, mildly adversarial high school cliques and making sure that, at the end of the day, they both still like you.

At the end of the day, the guys from Hacker School (formerly Hackruiter) said it best when they talked about why they pivoted away from being a recruiting org, so I’ll just quote them here.

[Recruiting is “soul-crushingly awful.”] When the idea first came up to become recruiters, pg [Paul Graham of Y Combinator] warned we’d hate it. He said it’d be miserable grunt work, but worthwhile for what it’d teach us. He was right on all counts.
A few of the many reasons recruiting sucks: You spend all your time having meetings (on the order of dozens a week) and writing emails. You never code. Your meetings and emails consist primarily of either rejecting people or being rejected (or watching people you like get rejected, frequently for dumb reasons). Desperate people lie to you, companies ignore you, and even if you’re ethical and upstanding, most people (understandably) initially distrust you because you’re a recruiter.

Last year, I worked with a really great engineer who told me it was his dream to work in the ed-tech space. He also told me that one of his deal-breakers was working in advertising and that he’d never do it. I set him up at Udacity, and he did an onsite interview. Then, while he was in town, for shits and giggles, he interviewed at an advertising startup where one of his friends was working. That’s the place he ended up choosing.

The truth is people will tell you all manners of lies about where they want to work, what they want to work on, and what’s important to them. But, of course, they’re not lying deliberately. It likely means you’re not asking the right questions, but sometimes knowing what to ask is really hard. For many of the questions you can think of, people will have all sorts of rehearsed answers about what they want to do, but those answer are framed to a specific audience and may not reflect reality at all. Or, a lot of the time, people simply don’t know what they want until they see it.

Because of these roadblocks to getting to the heart of what people want, I’d suggest not dwelling too much on what people say. Instead, pick some interesting companies, and get them to talk to someone who works there. Perhaps the most important thing I’ve learned is that, at the end of the day, one of the biggest parts of a recruiter’s job is to get the right two people in a room together. Regardless of industry or domain or stack or money (within reason of course), chemistry is king. Get the right two people to have the right conversation, and everything else goes out the window.

3. You should write down your principles.

This job is ethically gross. You will be tempted to do all sorts of things that you found to be abhorrent before embarking down the agency recruiting path. And the more you see them being done around you, and if you ever do them yourself, it’s a slippery slope. It’s simple really. Humans are frighteningly adaptable creatures. Scared of public speaking? Give 3 talks. The first one will be panty-wringingly horrific. Your voice will crack, you’ll mumble, and the whole time, you’ll want to vomit. The next one will be nerve-wracking. The last one will mostly be OK. And after that, you’re fine. Same thing applies to offer negotiation, approach anxiety, sex, and mathematical proofs.

And of course, it applies to vile business practices as well. When huge amounts of money are at stake, it’s easy to talk yourself into all sorts of things:

If a candidate you’re working with has an opportunity outside of your lineup that’s clearly better for them, it’s very tempting to try to talk them out of it. Don’t do it.

If a candidate is worth more than one of your clients is offering them, but you just want to close the deal to get your paycheck, don’t do it.

If companies are pressuring you to disclose offer details, but your candidate asks you not to, don’t do it.

If you know a candidate is about to accept a position because they really like their new manager, and you know that that manager is going to be leaving the company really soon, it’s going to be tempting to withhold that info. Don’t do it.

Write down what you won’t do and then keep not doing it because once you start, it’s going to be hard to stop. Which brings me to my next point.

4. Play the long game. Treat your candidates well.

In this market, finding companies who want you to help them hire is a lot easier than finding great engineers who want to work with you. Treat every engineer you work with like a precious commodity. Even if they don’t end up finding jobs through you, if you add value, are helpful, give them info they wouldn’t have had otherwise, counsel them on equity and negotiation, and go out of your way to get them the best opportunities (even if you don’t work with the companies in question), they will remember it. They will tell their friends, and they will come back the next time they’re looking. If you can get to the point where a good chunk of your business is coming from referrals, you’re doing it right.

5. If you’re risk-averse or not OK with never knowing where your next paycheck is coming from, this job is going to destroy you.

Be ready for night-sweats, terror, and creeping anxiety. If you’re working on contingency, especially at the beginning, you will likely go for months before making a hire. I started my firm in February of 2013. I didn’t get my first hire until the end of April. Those first few months were hellish. I’d wake up every morning wondering if I was ever going to make any placements. More immediately terrifying, however, was the fact that I had no idea what I was supposed to spend my time on. When I started out, I had 3 clients (2 of which were companies where I had worked previously), none of which were household names. I had no idea how to attack the chicken-and-egg problem of not having clients and not having engineers. Eventually, of course, I decided to start with the engineers, figure out what they wanted, and then beg, borrow, steal and do whatever it took to get them in front of the right people at companies they might like. But that took a lot of time, and there were never any guarantees. Brace yourself, because man is it rough in the beginning.

Which brings me to my next point.

6. Have a project to keep you sane.

When I started my firm full-time, between the night sweats and the terror that I was never going to place anybody, I was working on what eventually became Lessons from a year’s worth of hiring data. Even when I felt completely paralyzed by self-doubt, I had this one thing to keep me going. I knew that, if I could pull it off, it would be an awesome blog post. So, between sending sourcing emails and hating myself, I would spend the time counting grammatical errors and typos on people’s resumes. That work, tedious as it was, was deterministic. I knew what I needed to do and how to do it. Knowing that and feeling like I was making progress toward an achievable, well-defined goal saved my sanity in those first few months and very likely my husband’s as well.

I also started to write on Quora back then. I later learned that what I was doing was called “content marketing”. At the time, I was just doing something to feel like, despite all the unanswered emails and no hires, I was still making progress. Truth be told, if there is a single entity I can thank for my business surviving, Quora is probably it.

7. Find a way to differentiate yourself. Just having been an engineer helps, but it’s not enough.

Because of the low barrier to entry I mentioned, some of the hardest work you’re going to have to do is going to be around differentiating yourself — while getting into recruiting is easy, staying in it and consistently making good money is hard. If you come from an engineering background, as I mentioned earlier, that will be a huge help for differentiating yourself, but that will only give you a bit of a boost. At the end of the day, this is a sales job. Great engineers who are shitty salespeople will not do well at recruiting. Great salespeople with no eng background will likely do well. To that end, you’re going to have to spend time promoting yourself, whether it’s through writing, giving talks, offering services that other recruiters can’t, or something else. Self-promotion always felt very ungainly for me, so I decided to focus on data-driven blogging because then, instead of promoting myself, I could promote interesting findings and let them speak for themselves.

8. Invest in tooling as much as possible.

A lot of what you do in this business is administrative work. Anything you can invest in that will cut down on the manual aspect is going to save you time and keep you from forgetting stuff. Some of my favorite tools:

Boomerang – this email tool will make you look to the world like you’re on top of it, even if you’re crumbling slowly on the inside.

Evernote – the be-all and end-all of note taking. For the love of god, don’t take notes in a physical notebook. I did it for a while because I was worried about people hating hearing typing sounds over the phone. Taking notes you can’t search later is dumb.

Lever and/or Asana – for applicant tracking and analytics; which to use depends on your use case.

Expensify – for keeping track of all the business dinners and drinks! (There can be a lot of drinks.)