How HubSpot's First VP of Engineering Made Their First 40 Technical Hires

June 5, 2014 at 6:00 AM by Kathleen de Lara

tech recruiting tipsThe following is an exclusive interview with Yoav Shapira, Hubspot's 1st VP of Engineering.

As Hubspot gears up for an IPO in the upcoming weeks, Entelo sat down with their former Vice President of Engineering to learn his tactics for hiring and scaling a talented tech team — all from the ground up.

Between 2007-2012, Shapira was as a core member of HubSpot’s management team, serving as vice president of the engineering and the platform strategy teams. He arrived to HubSpot only a year after the company was founded, and led the hiring initiatives to build a robust department of engineers, product managers, and designers. 

By the time he left the company in 2012, HubSpot’s product and engineering team had grown at an exponential rate. In its early stages, HubSpot boasted a grand total of 10 employees. These days, the company that spearheaded inbound marketing SaaS under the same name, is made up of over 500 team members.

But hiring tech talent wasn’t always cake and combatting crap recruiters was a constant. Despite working with underqualified recruiters and their sub-par candidate recs, Shapira customized HubSpot’s tech hiring using one key rule to not only filter out bad candidates, but also less-than-stellar tech recruiters. 

Entelo: You hired employees 4-40 for the HubSpot tech team, which included designers, product managers, and engineers. What were some differences between how you approached hiring employees for the product and engineering teams?

Yoav: With product, we were lucky that we had these other groups like the IMCs, consultants, account managers, because we had these people who were forced to learn our methodology and our points from the beginning and they had at least a few months of getting to know our customers and their goals, their complaints and their pains, which made them really good candidate PMs.

What we had to screen for was wattage, organization skills, being detail-oriented, and communication skills with engineers, whereas if you had to go to the outside world, you sort of have to look for a bunch of different things. A lot of those were pretty filtered for us.

I also hired QA (quality assurance)/test engineers. We tried slotting them into teams, then investing more in test automation and creating a team for that. The latter worked much better than the former. Manual QA is a thing of the past.

Where did you find most of the engineers you’d bring in for interviews?

Referrals. At that point, the team I was supervising, that referrals worked best. This started when we had 15 or 20 people who were at least a couple of years in.

We went from the Paul English playbook, where every couple months to three months, I called people on the team and I said, “Who’s the best person you’ve ever worked with who you haven’t referred yet?” and I would follow up with those candidates.

At that point, we could also afford to fly people in for interviews, which we couldn’t afford at first and if it came down to it, we could also afford to relocate them. We switched from a mix that was mostly recruiters, to probably 75% referrals, and some recruiters were always in the mix.

There was a big evolution. We didn’t have big network, so we hired a lot of contingency recruiters, and they’re a dime a dozen. Most of them suck.

They’ll tell you, “We’re all about quality, not quantity,” and they might have one good candidate in their back pocket, which is usually the same guy they send all their new customers because he’s really impressive. In reality, he doesn’t want to change jobs. He’s just okay being used as bait by the recruiters.

At first, we turned to these recruiters because they sent us that candidate. Then we put in place the “three strikes and you’re out” rule. If a recruiter sent us three candidates that we didn’t hire, we stopped the relationship. And they knew this upfront. I’d tell recruiters what we were looking for, and then gave them feedback on what was good and what was bad about every candidate.

Then you ended up with two contingency recruiters who were great at their jobs. What’d you like about them?

They had just enough of an engineering background that they could wade through a lot of the bullshit, which removed a whole layer of noise. They also knew their referrals really well and weren’t just sourcing resumes stuffed with buzzwords. These recruiters either owned or co-owned the firm that they worked with, and weren’t just normal employees of a big staffing agency. There was an incentive in being more relationship-oriented, less transactional, and more responsive to our feedback. 

You’ll tell a lot of recruiters that you’re looking for a specific engineer candidate. They’ll pretend they understand, and send you someone completely different. So you tell them, “Nope. This was not the person I was looking for,” and send you someone very similar the next day. Importantly, I spent the time giving them careful, detailed feedback on each candidate, good and bad. Well beyond just a cursory "nope." If I spend the time giving the feedback (not to mention interviewing the candidate in the first place), they best well listen.

Those guys make a shitload more money on a contingency basis because if they don’t make successful referrals, they don’t make any money. In-house recruiters tend to be mediocre.

With that said, when companies get bigger, they hire in-house recruiters, because they think they need to have someone dedicated to this and they need recruiters to coordinate and process candidates. Shortly after I left, HubSpot hired at least one in-house recruiter. Now I think they have multiple full-time in-house recruiters. Engineers still do most of the interviewing, but recruiters coordinate the whole process. We never did that while I was there.

We tried recruiting on general job boards, then moved on to more category-specific ones like Stack Overflow, 37Signals (now Basecamp), Joel on Software, and Authentic Jobs. There was a lot of noise, bad candidates, unqualified people, and some of them came from agencies.

Then we did a lot of stuff around Craigslist and LinkedIn. We split-tested a lot of ad copy with short and long job descriptions that were heavy on ninjas and rockstars and tried out more traditional copy, too. Those had mixed results.

By far, the most successful variants of the job ads that got responses on LinkedIn and Craigslist were the ones that started off with the first sentence, “I’m an engineer just like you, not an HR person or a recruiter, so I wont waste your time.” A lot of developers these days are getting  inundated by various requests, so if you can stand out somehow, that’d be a good way to do it.

These job boards, contingency recruiters — no matter what, when you had someone’s info put in front of you, what info was given to you upfront and was it actually valuable? Do people just give you a resume, and you had to do research on them?

Yup, I usually got a resume by default. I would go through sites like Google, LinkedIn, GitHub, or Open Source to find out what I could about the candidate.

If the resume came from a recruiter, sometimes they did the annoying thing of cutting out the candidate’s contact info, and replacing it with their office info, because they were afraid I’d contact them directly. That was a good mark of a bad recruiter.

What was the standard operating procedure to find a developer? Would you go to GitHub, Stack Overflow, or were there some sites better than others?

I love it when a candidate has their own website. My site is a one-page static site that links to everything, but I’d love for them to have a domain. It’s okay if it’s white labeled, but having a domain is a good sign.

Recruiters can recognize a digital native when they have their own domain. I’d look for that in their emails, too. If they had john@johnsmith.com on their resume, it’s better than johnsmith@gmail.com. I don’t care where it goes to behind the scenes, but good candidates demonstrate they’re digital natives.

I do look for a LinkedIn profile, that’s pretty standard. But these days and even then, which was maybe three to five years ago, I was okay if a candidate didn’t have a great LinkedIn profile. LinkedIn is not what it used to be. Everyone is gravitating towards social media sites, like Facebook, and there's less separation between personal and professional.

I look at GitHub, Apache, Mozilla, and other open source contributions anywhere I can find them. I’ve never really looked at Google+, but if they have that, that’s okay, too. If they have code, I look at the code itself. I want them to, at least, have some sort of online profile, personal website, or portfolio. That’s huge.

One issue we’ve heard people run into is they’ll see people have large presences on GitHub, and they have a lot of commits to open source repositories, but when we bring them into interview, they’re not actually good at writing code. Is there a quick way to audit someone’s coding chops?

I might have only seen that happen only once or twice, so it’s pretty rare when it happens, but it does happen.

At HubSpot, the first interviewing round, even if you had a lot of open source, included a coding challenge that any candidate could do remotely. We also screened for factors like cultural fit and a candidate's interest in the company's mission.

We’d do the coding challenge with a shared Google Doc — one person writes code and the other person can see it. We also used similar tools like FizzBuzz and see[Mike]code, which anyone should be able to test with whether or not they have open source contributions before they come into the office.

And by the way, every single time we skipped that test because someone was really senior, we almost always regretted it. Good candidates crush that test, and they don’t mind it. It’s good that we did this because a lot of candidates suck, and bad candidates are like, “Oh my God, I can’t code remotely.” It’s bullshit.

How would that change if you were looking for a product level or a design person. For a designer, would you look at their visual portfolio and that’s it?

With a designer, it’s a little more subjective. You look at their visual portfolio if they have one, and you hope you like it. Even if I don’t like it, I still try to understand how they got their design, which you can do again with Google Docs or over the phone.

You could both look at the portfolio at the same time, pick one of their projects and ask, “Tell me how this came about.” Hopefully they can explain an evolution that shows they took into account users’ needs, did some market research, looked at comparables, and ended up with something. If they have something that’s well-rationalized and well-supported, even if I don’t like it visually, at least that makes sense, and that’s good.

With product candidates, it’s actually similar, but a little more abstract. On their resume, you look for an achievement and hope they can explain how they got there. I’d say, “Oh you increased this feature from this adoption to that adoption. Tell me how that came about. Tell me how you prioritized your road map." Stuff like that. But the initial screening stage is harder with product people than it is with developers.

For product people, especially a good referral from someone who says, “Hey, I worked with this person. They’re smart, worked hard, worked fast,” we’ll bring them in to interview them in-person because it’s hard to do a quick, efficient screening over the phone.

Did diversity hiring among the engineering and product teams ever come up in management meetings?

Yes, not in every single management meeting, but it came up when we were recruiting and looking at our pipeline. We were actively thinking, “How do we find more minority candidates?” We never actually never solved that nugget that well, but we always wanted to. I would love to find more qualified minority candidates. All the research is there that shows that diversity on the team is great for a company. Diversity hiring came up regularly, and we never had a good solution.

What are a couple of things you tried that didn’t work very well?

We sponsored a Python for Women workshop at our office, which brought a bunch of women to learn how to code. It seemed like a good idea, but they were too beginner. They may have been at a better level maybe two or three years down the road.

We also told our recruiters, obviously, we’d love to have more minority candidates. That didn’t help much. I don’t think we tried to tweak our job board ad copy to target minorities. That could’ve been interesting. It’s hard to do it in a legal way, but we never really tried.

What do you think disconnect was?

There weren’t a lot of great examples of things you could do to find more candidates. There wasn’t even evidence that the candidates were there. It’s not like there was a place we knew of that had 50% of the team who were women. Otherwise, I would’ve tried to reach out and ask them, “How did you make that happen?” But we didn’t know of any such place, a comparable or company that was really good.

Let’s say you could go back and talk to the HubSpot management team on recruiting on your first day. Advice?

Invest more in co-op programs. We did a little bit of the Northeastern co-ops, and I would’ve done more. You get them for about six months, not just three, and that’s enough time to shape and mold them, and that’s a big difference. I’m sure Northeastern may be relatively unique, and I’m sure that’s not the only school that has co-ops programs.

Find other co-ops nationwide and really recruit hard at those places, as opposed to just MIT or Harvard or whatever. Find schools that have co-ops, grab as many smart cohorts as you can, and teach them for about six months. Your goal should be to hire them as full-time employees. That’ll fill all your entry-level, junior-level recruiting needs potentially forever with scalable approach.

One piece of advice for recruiters trying to place folks on engineering teams?

Learn how to code just so you can do the screening more efficiently. And, like everyone says, quality over quantity is true at all levels, even college recruiting. If you talk to executive recruiters, like really high end — “Help-me-find-the-CFO” sort of recruiters — those guys know it’s quality over quantity.

I don’t know why the people who are recruiting at the junior or mid-levels think that it’s a volume business. It’s not. If you give me one awesome perfect candidate that I’m likely to hire every three months for a year, I would love you, Mr. Recruiter, and keep paying you and be happy about it. But they try to scam me with all these people for entry-level jobs, and that sucks. I want you to actually do the filtering and funneling for me in an efficient way.

Yoav Shapira is currently the Vice President of Product Management at Jana, a mobile tech platform founded in 2009 with global customers, including Microsoft, Google, Unilever, P&G, Johnson & Johnson, Nestlé, Danone, and General Mills.

Thanks, Yoav, for the insight! As he mentioned, recruiters' referral networks are one of the best sources for finding top candidates. Want to learn how to get started with building your team's referral program? Register for our webinar, happening on June 10 at 10 am PT/1 pm ET.

employee referral program

comments