At Gem, we did something pretty different to hire our founding engineering team. We used “contract to hire” to recruit nine out of ten of our first engineers.
Using contract to hire to evaluate candidates
Essentially, candidates would come to work with us 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 one to two hours on the codebase and ship something small.
- We picked several 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 as a full-time employee, inviting them to planning meetings, customer conversations, and 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 to 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 miss-hires that would have been bad culture fits or signals that would have been very difficult to uncover during a normal interview loop.
Selling the candidate
But the biggest reason we did contract to 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 than 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? If you decide to join 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 40% higher than usual) 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 to hire is not for everyone
This method only worked because many of our founding engineers were former colleagues from Dropbox, Facebook, or MIT, so we had pretty strong signal they were good (either by working with them or by reputation). If you don’t have a strong network or don’t have a strong signal on a candidate, I wouldn’t recommend this approach, as a contract to hire can be a big waste of time if the candidate isn’t a good fit.
I also wouldn’t recommend contract to hire for companies where it’s difficult to ramp someone up (e.g., hard tech). It’s important to pick projects well-scoped and off the critical path. If you’re struggling to think of projects like this, contract to hire may not be the right strategy for you.
Finally, it’s important to note that not every candidate will be up for contract to 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 you value their time. And for those who aren’t up for contract to 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 to 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 concise period of time (four to six) hours
- 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, making it fast to get started.
- Set clear expectations on what we’re looking for - For example, it’s ok to sacrifice code quality and documentation for velocity, so long as you can point to areas of the code you would improve if you had more time or if we wanted to make this feature production-ready. Make it clear it’s encouraged to ask questions to get through roadblocks, etc.
- Standardize the question we ask - Rather than scope out a new feature each time, we’ve standardized one question. We picked a feature 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.
- Add multiple “interviewer types” - outside of the interviewer buddy to gather different signals. 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 and product tradeoffs.
- 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. Still, then there are opportunities for every candidate to shine, whether it’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 to hire
In the early days, we chose to pay ~$70/hr if a candidate decided to spend a few days or more with us. It was important to pay our contractors something to show 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 and not 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 we value your time. I acknowledge 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.” Nine out of ten times, the specific amount didn’t matter to our candidates. And for folks who indexed too much on rate, it was a good signal they wanted to contract with us for the wrong reasons (e.g., cash) vs. learning about what it’s like to work for a startup.