Welcome to part 16. Today we’re going to discuss an alternative approach to early stage hiring: contract hiring.
At Gem, we took a fairly unconventional approach to hiring our founding engineering team: we used “contracts of hire” to hire 9 of our first 10 engineers.
Using recruitment contracts to evaluate candidates
Essentially, candidates work with us as “contractors” for a few days or weeks to see what it’s like to work with us. After all, what better way to see what it’s like to work with us than by collaborating on a real project?
Tactically, it would look like this:
-
We empowered contractors by having them spend an hour or two on the codebase and ship something small.
-
We picked some actual features to have them build, prepared in advance so we could scope the features based on the time we spent with the candidate, and picked features that were meaningful and interesting but not on the critical path.
-
We provided them with their own personal interviewer buddy so that they had someone to ask questions to.
-
We treated candidates as full-time employees and invited them to planning meetings, client conversations, and brainstorming sessions.
-
We made sure to have at least one dinner or social outing with our team members.
-
We have paid contractors who have worked for us for more than one day*.
The employment agreement gave us very good signals in many aspects like coding speed, code quality, ability to learn quickly, product intuition, collaboration, receptivity to feedback, etc. It also helped us avoid at least 3 costly rejections due to cultural misfits and signals that would have been very hard to spot with a regular interview loop.
Sell your candidate
But the biggest reason we did the employment agreement was because it was a great way to “sell” candidates. Joining a startup is a very risky move, and startups can be volatile. Compared to big companies (e.g. Facebook or Google), startups are less well known, and at big companies you generally know what you’re getting into. From the candidate’s perspective, it was a great way to learn about Gem and get an interview. And of course, we built the following points into our pitch when asking candidates if they wanted to apply:
-
“Joining a small startup is risky. Startups are not well known and you probably have never worked at a startup before. Why not come and work with us for a few days to see what it’s like? If you decide to join a small startup, don’t worry. In the worst case scenario, you’ll learn a lot and get an idea of what it’s like to work at a startup.”
This approach worked wonders: when it came time to close the deal with our candidates, our offer acceptance rate was extremely high (I think 40% higher than normal) because they already knew what it was like to work for us, and they really felt like they were part of the team.
Employment contracts aren’t for everyone
This worked because many of our founding engineers were former colleagues at Dropbox, Facebook, and MIT, so we had strong signals that they were good (from experience working together and reputation). If you don’t have a strong network or strong signals about the candidate, I don’t recommend this approach because the hiring deal could be a waste of time if the candidate isn’t a good fit.
We also don’t recommend hire-to-hire for companies where it’s hard to train talent (such as hard tech). It’s important to choose projects that are clear in scope and off the critical path. If you’re struggling to think of such projects, hire-to-hire may not be the right strategy.
Finally, it’s important to note that not all candidates will agree to an employment contract. Spending several days working with you is a big commitment if the candidate doesn’t know you well or is actively interviewing with multiple companies. If you are asking candidates to spend a significant amount of time working with you, it’s important to pay them (more on this later). It can be a small amount, but it’s important to show them that you value their time. Also, make sure you have an interview alternative in place for candidates who don’t agree to an employment contract.
Still, many candidates, even those with full-time jobs and many interviews, were excited to work at a startup. Some candidates with full-time jobs took a day off work or came over a weekend (or two). We chose a weekend that the whole team could attend and gave the team a day or two off to make up for it.
Expanding employment contracts
To date, we have all candidates come to us, spend a day onsite “working with us,” and write actual code on our stack. We’re getting a lot of signals from this process so far, and it’s a great candidate experience, so we intend to extend it for as long as possible.
Here are some of the things we’ve done to maximize Signal and the candidate experience in a short time frame (4-6 hours):
-
Invest in a stack that scales easily (Approximately 30 minutes) – We have several loaner laptops pre-configured with our entire tech stack so you can get started right away.
-
Clarifying what we want – For example, it’s OK to sacrifice code quality or documentation for speed, but you should be able to point out areas of code that could be improved if you had more time, or where you’d like to see this feature made available in production. Make it clear that people are encouraged to ask questions to get past roadblocks, etc.
-
Standardize your questions – We standardized on one question rather than exploring a new feature every time. We chose a product-adjacent feature so candidates feel like they’re working on something related but outside of our scope (something we’ll never ship). We also designed aspects of our product codebase to help them get started on this feature quickly. Standardizing on one question reduces prep time, increases alignment, and reduces variability in candidate experience.
-
Add multiple “interviewer types” – Collect a variety of signals outside of the interviewer’s buddy, including two separate code reviewers and an additional engineer who joins the candidate and buddy at the end of the day to discuss technical aspects and product trade-offs.
-
Create different variations of questions based on the strengths of your candidates – Everyone will need to establish end-to-end foundational capabilities. Still, there are opportunities for all candidates to excel, whether that be back-end optimization, extending full-stack capabilities, or hardening the front-end. Also, expectations will vary based on experience level.
How much should you pay for an employment contract?
Initially, we decided to pay candidates around $70 per hour if they decided to spend more than a few days with us. While it was important to pay contractors something to show that we value their time, we didn’t think it made sense to pay them market price. After all, the main purpose was to test collaboration, not to get a productive outcome (although in many cases we did!). It also provided a lot of learning for the candidates.
We made sure to make this known to contractors: “We’re paying you because we want to show you that we value your time. People like you could probably make more if you put cash first, but we’re a startup and this is all we can offer you. And above all, we hope you’ll see this as a low-risk learning opportunity.” Nine times out of 10, the specific amount didn’t matter to the candidates. And for those who put too much emphasis on the fee, it was a good sign they wanted to work with us for the wrong reasons (like cash) and not to learn what it’s like to work for a startup.
next
In the next part of the series, we will discuss how interviews help you make a hiring decision on a candidate. Part 17.
During…
