5e. How Gem interviewed our founding engineering team
5e. How Gem interviewed our founding engineering team

5e. How Gem interviewed our founding engineering team

At Gem, we did something pretty different to hire our founding engineering team. We used contract → hire to recruit 9 out of 10 of our first engineers.

Using contract → hire to evaluate candidates

Essentially, candidates would come work with us for anywhere from a few days to a few weeks as “contractors” to see what it would be like to work together. After all, there’s no better way to see what it’s like to work together than to collaborate on a real project.

Tactically, here’s what that meant:

  • We ramped contractors up by having them spend ~1-2 hours on the codebase and ship something small.
  • We picked 1-3 real features for them to build. We prepared in advance to ensure features were scoped to the time we had with the candidate. We also picked features that were meaningful/interesting but not on the critical path.
  • We set them up with a designated interviewer buddy so they had someone they could go to with questions.
  • We treated the candidate like a full-time employee, inviting them to planning meetings, customer conversations, brainstorming meetings.
  • We made sure to have at least one dinner or social outing with the team.
  • We paid* any contractor who spent more than a day with us.

Contract → hire got us really great signal on a ton of aspects, including coding velocity, code quality, ability to learn quickly, product intuition, collaboration, and receptiveness to feedback. It also helped us avoid at least three costly mis-hires that would have been bad culture fits, signals that would have been very difficult to uncover during a normal interview loop.

Selling the candidate

But the biggest reason why we did contract → hire was that it was a great way to “sell” the candidate. Joining a startup is such a risky move and startups can be higher-variance. They’re less of a known quantity compared to larger companies (like Facebook and Google) where you generally know what you’re getting into. From the candidate’s perspective, this was a great way to learn about Gem and “interview” us. And of course, we incorporated these points into our “pitch” to candidates when asking if they’d be up for it:

  • “”“Joining a small startup is risky. Startups are less of a known quantity and maybe you’ve never worked at one. Would you be interested in coming and working with us for a few days to see what it’s like? At the end of it, if you decide that joining a small startup is not for you, no sweat. Worst case, you learn a lot, and get to see what it’s like to be at one.”””

This approach has worked phenomenally well. When it came time to close the candidate, we had a very high offer accept rate (I’d guess 30-50% higher), because the candidate already knew what it was like to work with us. In fact, they felt like they were a part of the team.

Contract → hire is not for everyone

Note, this only worked because many of our founding engineers were former colleagues from Dropbox / Facebook / MIT, so we had pretty strong signal that they were good (either by working with them or by reputation). If you don’t have a strong network or you don’t have strong signal on a candidate, I wouldn’t recommend this approach, as contract → hire can be a big waste of time if the candidate isn’t a good fit.

I also wouldn’t recommend contract → hire for companies where it’s difficult to ramp someone up (e.g. hard tech). It’s important to pick projects that are well-scoped and off the critical path. If you’re struggling to think of projects like this, contract → hire may not be the right strategy for you.

Finally, it’s important to note that not every candidate is going to be up for contract → hire. Taking a few days to work with you is a lot to ask if they don’t know you very well or if they’re actively interviewing at a bunch of companies. If you’re going to ask a candidate to spend a substantial amount of time working with you, it’s important to pay them (more on this below). It can be a nominal amount, but it’s important to show that you value their time. And for those who aren’t up for contract → hire, make sure to have a plan B for interviews you can fall back on.

Still, many candidates were excited to try working at a startup, even those with full-time jobs or lots of interviews. For candidates with full-time jobs, some of them took a day off work or came in on a weekend (or two). We made sure to pick a weekend when our whole team could be there and gave our team a day or two off to make up for it.

Scaling Contract → Hire

To this day, we have every candidate come “work with us” onsite for one day where they write actual code on our stack. At this point, we get so much signal from this process and it’s such a great candidate experience, that we’re going to continue scaling it for as long as possible.

Here are some of the things we’ve done so far to maximize signal & candidate experience in a very short period of time (4-6 hours):

  1. Invest in a stack that’s easy to ramp on (~30 mins). We have several loaner laptops that are pre-configured with our entire tech stack, which makes it fast to get started.
  2. Set clear expectations on what we’re looking for. For example, it’s ok to sacrifice code quality & documentation for velocity, so long as you can point to areas of the code that you would improve if you had more time or if we wanted to make this feature production-ready. Make it clear that it’s encouraged to ask questions to get unblocked, etc.
  3. Standardize the question we ask. Rather than scope out a new feature each time, we’ve standardized on one question. We picked a feature that’s adjacent to our product, so candidates will feel like they’re working on something relevant, but outside of our field of play (something we’d never ship). We’ve even designed aspects of our production code-base to make it easy to get started on this feature quickly. Standardizing on one question decreases prep time, increases our calibration, and reduces variance in candidate experience.
  4. Add multiple “interviewer types” outside of the interviewer buddy to gather different signal. This includes two code reviewers (different from the buddy) and an additional engineer who joins the candidate + buddy for a wrap-up conversation at the end of the day to discuss technical & product tradeoffs.
  5. Create different variants of our question depending on the candidate’s strengths. Everyone has to get to a base-line end-to-end feature wired up, but then there are opportunities for every candidate to shine whether that’s optimizing the back-end, expanding the full-stack functionality, or snazzing up the front-end. We also have different expectations based on experience level.

How much to pay contract → hire

In the early days, we chose to pay ~$70/hr if a candidate decided to spend a few days or more with us. We felt like it was important to pay our contractors something to show that we valued their time, but didn’t think it made sense to pay them market-rate for contractors. After all, the primary goal was to test working together, not to get productive output (although, many times we did!). And for our candidates, they learned a lot too.

We made sure to acknowledge this with contractors — “We want to pay you because we want to show you that we value your time. I acknowledge that someone like you can probably make a lot more if you wanted to optimize for cash. But we're a startup, and here’s what we can offer you. And hopefully, you see this as a low-stakes learning opportunity more than anything else.” — 9/10 the specific amount didn’t matter to our candidates. And for folks who indexed too much on rate, it was good signal that they wanted to contract with us for the wrong reasons (e.g. cash) vs. learning about what it’s like to do a startup.

Next Steps

Back ← Back to home here ← 5. How to interview here
Next Up → 6. Selling & closing here

Feedback? Suggestions? Ideas? Comment directly or email steve@gem.com