What We’ve Learned from Hiring (and Almost Hiring) Engineers

Recruiting and team building are the biggest challenges facing any growing technology company today. Hiring creative and driven people to build your product can easily mean the difference between customer happiness and customer churn. Companies who don’t invest in culture, opportunities for growth, and access to interesting technical projects have a tough road ahead of them. But the market is ridiculously competitive, and great engineers, designers, and product people have never had an easier time finding compelling work.

HubSpot has been voted a top place to work year after year, our Culture Code has over 1.8 million views, and engineers have complete ownership over the product. Still, those qualities are just the table stakes. They don’t make recruiting easy. In my 4+ years at HubSpot, I’ve seen first-hand how hard it is to attract and retain great people. I helped hire a good part of our product team after HubSpot acquired my former company Performable, traveled to Dublin to recruit and set up our product team there, and have spent the past 6 months working daily with the product recruiting team. I’ve learned a lot of lessons along the way from other leaders, recruiters, and the hard way: from candidates.

We once had a candidate who offered to pay his own travel costs, so we thought, sure, why not? We didn’t end up giving them an offer and they left a negative review on Glassdoor calling us “cheap”. We were kicking ourselves afterward. That was cheap. Companies should always cover costs, review or no review. It’s just the right thing to do.

The “yelpification” of recruiting has made one thing crystal clear: Companies can’t fake a remarkable recruiting process. The only way to become a magnet for talent externally is to be thoughtful about hiring internally. We still have a ways to go, and many more mistakes to make, but these learnings have helped us improve when it comes to finding and interviewing talent, and creating a positive candidate experience.

Even with huge incentives, referrals take work.

Cash incentives don’t motivate everyone in the same way. Frankly, some engineers would rather pay money to avoid feeling salesy or socially awkward by reaching out to friends or former colleagues. We’ve found that helping them think through referrals and strategies for contacting people is more effective than posting a huge bonus and waiting for applications to come flying in. We hosted a Q&A earlier this year where top employee referrers talked about how they qualify and reach out to referrals, and more regularly, we sit down with engineers one-on-one to talk through who they have in mind, where they might be a good fit, and what the best way to start the conversation with them is.

Candidates know way more about the interview process than they used to.

Sites like Glassdoor and Quora make it pretty easy for candidates to know which companies are going to ask what during an interview. Nearly all of our engineering-specific questions have been “leaked” online at some point. This can be very costly if your questions are easily crackable; candidates end up having a big advantage over the interviewer. We’ve started leaning towards interactive design questions which don’t have one “correct” answer and programming questions which don’t rely on tricks. That way, the focus is on getting to a solution, not the solution itself. So far, we haven’t needed to iterate too much on the in-person questions (our automated, online coding tests are a different matter).

Teaching interview questions shouldn’t be like playing telephone.

When we introduced some standard interview questions to help apply a fair and consistent hiring bar, we wrote up the details of the questions and had a few interviewers shadow one another to get comfortable with asking them. While it should have been predictable, years later the standard questions were anything but. Variations between “generations” of interviewers who had been taught by other interviewers were extreme. While it makes sense to allow interviewers some leeway to develop a personal style, driving consistency helps improve candidate experience and reduce poor hiring outcomes (hiring the wrong people, not hiring the right ones.) We’ve recently introduced large-scale training and more thorough write-ups to improve.

Computers are more natural than whiteboards.

Interviews are naturally uncomfortable; candidates are nervous, in a new environment, and meeting tons of new people. If we can do anything to switch them from thinking of it as an interview, and move towards a more normal work setting, we should. Using a computer instead of a whiteboard for technical questions can make a huge difference in their performance. It’s not fair to the candidate to not get an offer because they were too nervous to solve a problem or work through a question. Not to mention, the best way to get a sense of what it would really be like to work with a candidate is to give them an opportunity to display their skills in as close to a real-life setting as possible.

Detailed interview feedback is worth the extra time.

It’s tempting to skip filling out internal interview feedback when the decision on a candidate is a definite and unanimous yes or no. But this has come back to bite us many times, as interviews are not always one-time affairs. Candidates re-apply or become great fits a few years later, and having accurate and detailed feedback from their earlier interviews makes it way easier to pick up where you left off and avoid a few awkward conversations. Terse summaries like “I like this person” or “They were okay” aren’t as helpful two years after the post-interview meeting when the context was still fresh and top of mind. More importantly, giving candidates rich, actionable feedback creates a more positive experience, whether they get an offer or not, by turning their interview into a valuable learning experience.

Internal feedback forms should always be evolving.

Getting the most helpful feedback from interviewers means you need to iterate and experiment with your feedback form. For example, we realized that if you ask a ton of questions, some people will spend a tremendous amount of time answering all of them in detail. You’re better off having a handful of open-ended sections rather than asking for paragraph-sized responses on every possible topic. Give interviewers a handful of prompts and a single place to answer. Instead of asking about coding ability, analytical ability, communication skills, and culture fit separately, you could ask “Technically and culturally, what was remarkable about the candidate?”

Interviewing is a learned skill.

The first interview I ever conducted was for IBM. I had no idea what I was doing and made up all of the questions on the spot. Not surprisingly, the outcome was useless: I truly didn’t know if we should hire the candidate or not. Even worse, the candidate probably had a terrible experience, too. Interviewing is pretty hard, and strong interviewers usually have a lot of experience calibrating themselves. This is one of the key reasons we do post-interviews, have future interviewers shadow experienced interviewers, and recently started running workshops on certain questions and common pitfalls. Not only does it help the team get aligned on hiring decisions, it gives interviewers an opportunity to learn from each other.

Offer speed matters.

The sooner you can extend an offer, the better. Giant tech companies tend to move slowly and can take weeks, even up to a month, to follow up with a candidate with a decision. For engineers, that’s a bad sign of bureaucracy. Time and time again, moving fast has been a big advantage for us in the acceptance stage. A few engineers got a call with an offer on their way home from their interview and they still say that the quick turnaround was a strong testament to how much we value talent. As we grow, this will become harder and harder to do, so it’s important we do everything we can to continue making offers as quickly as possible.

You can’t win them all (but you should try).

Lastly, one of the biggest learnings we’ve had is that sometimes it’s not you, it’s them. There are a ton of factors that go into an engineer’s career decisions and companies can’t influence all of them, no matter how hard we try or optimize for that candidate’s success. We’ve lost engineers at the last minute and had a really hard time figuring out why, but we can’t go into crisis mode and re-evaluate our entire process every time someone doesn’t accept an offer. What’s important is that recruiting is a priority and feedback is taken seriously. Attracting remarkable product people will never be easy, but it’s critical that we’re constantly learning how we can improve our candidate experience.

So, on that note: We’re hiring (and yes, we’ll pay for travel).