When, Who, How to Hire an Engineering Team (including Hiring Remotely)
This is the blog post version of a talk I gave at True University in Berkley, CA in June 2018 to help early stage startups scale their engineering teams from 2 to 20.
Hiring is hard. Really hard. I’ve been hiring on small startup engineering teams for the past 8 years (most recently grown Close’s engineering team from 2 to 14) and hiring really great engineers never gets easy. But it does get easier with practice and the right strategy.
Here I’m going to share some things I’ve learned about when and how to find the right people for your stage, how to structure a hiring process, and distributed/remote work. And most importantly: mistakes I’ve made along the way at Close.
When to hire
There are just two simple rules to follow about when to start hiring your engineering team.
Don’t hire too early (rule #1)
Hiring is hard. It’s a REALLLLLLLY hard, slow, painful process. Seriously, you don’t want to go through it before you have to. Avoid the pain as long as you can!
People are really expensive ($$$). Generally nothing in your startup will cost more money or take up more of your time and attention than… people.
Do the job yourself first. Be busy. Learn and do all the things! If you do everything yourself for a while, you’ll be in better shape to understand what really needs doing. You’ll be able to write a better job description, and you’ll be better at identifying a good person to fill the role when the time comes.
Small = fast & nimble. As much as everyone tries to avoid it, there’s just always inherent communication and process overhead of having a larger team. Enjoy moving as fast as possible while you’re small.
Focus on what matters: building a product that people love. Spending your time on hiring activities (job posts, resume screening, phone screens, in-person interviews, job offers, great employee onboarding, etc.) – none of these directly matter to your business! What matters first is finding product-market fit with a product that people love. Customers paying you money.
At Close, we got to company profitability making a few million dollars in annual recurring revenue, all with a 3 person Product/Engineering team (with total company size of 6). Take advantage of your small team size as long as you can!
Don’t hire too late (rule #2)
Because it takes forever. Remember how I said hiring is a really hard, slow, painful process? This means that if you wait too long to start hiring… by the time you really accomplish your hiring goals, it will take you even longer than you’d think to add more people to the team.
Our mistake: At Close.io, we started hiring way too late. We were heads down focused exclusively on building and supporting our product for the first few years. By the time we finally decided to start hiring, we were already in a bad spot. We had too small of a team to support our product’s complexity and all of our customers. We slowed down on our pace of product development. We just didn’t have the team size that the business size and opportunity size justified.
To make matters worse, once we started recruiting/hiring, we didn’t really try hard enough at first. We failed at it for too long because we didn’t really make it a true priority even after we started.
So, when?
I can’t tell you exactly when to hire, but…
Wait until you know you really need to
- When your current processes are breaking
- When you know you can’t accomplish your goals without more people
But then don’t wait any longer
- Once it’s time, make it a #1 priority
- You must really commit to hiring.
When we finally did really put in a full effort to grow our engineering team, it started taking 50%+ of my time for many months. You can’t half do it and expect results.
Who to hire
Just one simple rule here: Aim high. Don’t settle.
Aim high
In your early engineers, you should look for:
Senior people. Junior people can be a huge asset longterm but will take years to get there, you probably don’t have time for that.
Leadership potential. You need people you don’t need to “manage”. Your first few engineers should be people who you think you can trust leading major projects and taking on large amounts of responsibilities. They should be people you can envision leading future teams.
They should “wow” you somewhere along the way. Can you learn from this person?
Don’t settle
The temptation is strong. It happens every time… somewhere after about a dozen mediocre interviews you might start thinking you just want anybody decent. Resist! DON’T SETTLE. The management and culture hit will slow you down worse than not getting the help you need for a while. There are really great candidates out there – persevere to find them.
Maybes = No’s. If you’re not sold & excited about a candidate, there’s probably a good reason for it. Trust your gut. You should be excited about candidates to move forward. If you think of them as a “maybe”, that’s a great sign you should reject them.
Hiring the wrong people = VERY BAD. Hiring the wrong person can really hurt you in a way that’s hard to recover from. The wrong hire can quickly poison your culture, frustrate your top performers, and set you down the wrong path.
More about “who”
First few hires…
First hires are the hardest roles to fill.
It’s hard to attract the very first few people. Early stage startups barely look like a real job to people. Most people don’t “get it” until there are already other people in the role.
Story: I’ve literally had a fresh out of college job candidate reject our offer (that he was excited about) because his mother didn’t think it was a “real job”.
Most people also aren’t really a good fit for a really early stage startup. Tiny startups just aren’t for everyone. Most people need more structure and a more narrow job description than is typical for a very early startup employee.
First hires are the most important.
They’ll impact the caliber of your future hires. Your first engineers will help hire and attract the next engineers.
They will (or should) become leaders. It’s likely a bad sign for your first few hires if you cannot picture that person leading a project or team one day. Early in startups, you want people who can learn and grow quickly as your startup grows.
Find your bottlenecks
Different stages of your company require different types of people.
The first few engineers on our team were “Full Stack”. As a tiny team we needed engineers who could go both deep and wide. We were able to go deep in specific areas as needed, but also comfortable working across various parts of the tech stack.
Hiring generalists worked well when the engineering team was very small, but as we grew it was time to start specializing. That doesn’t mean restricting people to one part of the tech stack, but rather it meant finding our software development bottlenecks and really focusing on finding some great people in the specific areas we were weakest in.
At Close.io, our first specific bottleneck was on the infrastructure side. We had grown with so many customers, so much data, and a larger codebase to support that our engineering team was really slowing down trying to work on both the infrastructure and the product itself. We eventually hired a couple really great DevOps/Infrastructure Engineers, and that dramatically helped.
Next our bottleneck was Frontend Development (couldn’t keep up with Backend), then Design (we finally had frontend bandwidth to implement design work), then Backend, and most recently a Product Manager (for the first time it felt like customer problem discovery/definition was bottlenecking engineering effectiveness).
What’s your biggest team bottleneck for building a better product? Focus your hiring there!
Mistake: Focusing only on technical qualifications
A mistake that I’ve made a couple times is focusing almost entirely on a candidate’s technical capabilities. It’s so hard to find programmers that actually know how to program, that when you find someone who passes your technical quality bar, the temptation is to assume they would be a great hire.
But in reality, it’s incredibly important to pay attention to their written and verbal communication skills, maturity, attitude, desired work/life balance, culture, how they will work with people, their work processes, and other “soft skills” that separates a senior professional from just somebody who is good at programming. Do they have experience working in companies your size? If you’re remote, have they ever worked remotely before? Ask yourself if you actually think you would like working with this person. Finally, always trust your gut.
If you aren’t careful about qualifying candidates as an entire person and not just based on their technical skills, you risk ruining your culture, building a team that is difficult to manage, doesn’t work well together, and who you can’t trust with important projects that aren’t 100% about the code.
How to hire
The 6 steps for hiring are pretty obvious, so I’m going to just provide a few specific tips or hard lessons learned for each one.
- Prep work
- Sourcing
- Screening
- Interviews
- Offer
- Onboarding (& beyond)
How to stand out
Before we get into each step of how to hire, let me first say a couple words about standing out from other companies. Every other tech company is doing these same exact steps. Great candidates have hundreds of great jobs to consider. So it’s important to figure out how to make your company and role stand out among the rest.
Stand out by making the whole process fun and respectful, and play to your strengths.
Be respectful
The best way to stand out is to just treat all your candidates with respect.
Get back to people quickly. People really appreciate if you always get back to them within a few days. Most companies don’t. Setup email templates to make this easy.
Declined candidates should still walk away impressed. Your goal should be to make everyone who interacts with your company to be impressed by you and want to tell their friends, even if they are a horrible fit themselves.
Make it fun
Try to find a way to make the application and interview process fun for candidates. This could look different at different companies, but a couple quick ideas…
Make your interview questions connected in some way so the candidate feels like they are making progress, rather than just being asked a series of unrelated technical questions.
Examples: For one position at Close.io we have a 1 hour interview where we ask 12 connected questions that lead a candidate through architecting a real-world standalone web service. For another position, we have an application question that is related to the take-home challenge they’ll do in round 2, and our final interview is based on their work done in the take-home challenge.
Help them learn about your company along the way. The more you can share about your own company and the type of real-world challenges you experience, the more a candidate will understand if the role is a good fit for them (and hopefully be excited).
Example: All our job applications require a candidate to send a POST with a specific JSON payload to an endpoint. The response payload returns not only the “answer” they need to apply, but also returns the URLs to a few engineering blog posts and open source projects of ours so they can learn more about us and our work.
Play to your strengths
There is something unique and attractive about your company or the specific role you’re hiring for. Something that can help you stand out as more interesting than the countless other jobs out there.
Here are some examples of possible strengths:
- Unique tech stack (niche programming language, big data, using cutting edge frameworks, etc.)
- New technology area (e.g. virtual reality, cryptocurrency, AI)
- High salary, significant equity, or unusually strong benefits, etc.
- Building a new product from scratch
- Employee #1 who will work closely with founders and wear many hats
- Ability to work remotely or set own hours
Whatever it is for you… make sure you focus on sharing that. Advertise it clearly in your job description, mention it in your interviews, repeat it when you make a job offer, etc. Play to your strengths.
For us at Close.io, we have several advantages over most companies: remote (work from anywhere, no set hours), good tech stack, and profitable. Sometimes we try to even fit these advantages into the job titles – e.g. we have advertised job posts with titles like “JavaScript/React Frontend Engineer @ a *profitable* fast-growing startup” which stands out among a sea of plain “Software Engineer” posts.
Prep Work
Plan your process
Who are you really looking for? Make sure both you and the rest of your team have clear alignment on exactly what type of person you’re looking for.
Plan the entire hiring process upfront. Once interviews start it will be much harder if you’re winging it.
For the last position that I hired for, before talking to a single candidate or even posting a job advertisement, I first wrote a document with the outline shown here (to the right) and made sure the rest of the team was on board with not only who we were looking for, but why now and how we would evaluate that person.
Write the job description
Take your time writing an excellent job post. It’s a mistake to just list out a bunch of requirements. Instead, be sure to:
Sell your company & the role. Remember that great candidates have lots of options – let them know why they should want to join your company.
Be specific about what they’ll do. People don’t just want to know they’ll be writing Python backend code, they’ll want to know specifically what types of projects they will be doing and what their impact will be.
Get feedback from people who are good at that role. After writing your job post, send it around to people who you think are excellent at that role and ask for feedback before promoting it. This is especially important when hiring for a role that you yourself wouldn’t be qualified to fill.
Sourcing
Where do you find candidates? 7 main places…
Outbound vs Inbound. You need to do both. But you have to treat outbound differently (more casual & more selling) in early stages of the process.
Your Network. Your direct and 2nd degree network is already full of great people.
- Directly reach out to people you think are great – even/especially if you think they are happy in their current situation. Often they are more ready for a change than you may think. And worst case, they might be able to recommend somebody else great for the role.
- Get everyone in your company to do the same. When you hire someone new, one of the first things you should ask them is who else they know that might be a good fit for your open roles.
- Use social media. Not as a replacement for reaching out to people directly, but in addition.
A good example of how effective networking hiring can be is how we found our recent Product Manager hire, Ben. I posted the tweet below, and Ben was one of the people who “liked” the tweet. I didn’t directly know Ben, but he had “Product @ [startup]” in his Twitter Bio and had previously cofounded a company with a former colleague of mine. Since he liked my post, I sent him a Direct Message asking him if he knew anyone who might be good for our PM role. Soon enough we setup a call to discuss the role for himself! Not long after, Ben became our first PM and has been doing great.
The most important part: Ben said that if I hadn’t sent him that message, he probably would have never applied!
Job Boards. This is the easiest way to find candidates, since you basically just pay ~$300 and you get your ad in front of a lot of people who are looking for a job. The trick is to post on the most relevant job boards for your specific role as possible. I suggest avoiding the very big name sites like Monster, and instead focusing on specific niche sites that have the most overlap with your ideal candidate as possible.
For example, since our roles are remote, we post on remote-focused job boards like WeWorkRemotely.com, RemoteOK.io, and Remotive.io. For Frontend Development roles, we post on sites like Codepen. For Designers, Dribbble. You get the idea – the more targeted, the better.
Targeted Communities. Similar to job boards, there are online (and even offline) communities where your target audience hangs out that often you can informally share a job post with. This includes Slack groups, tech newsletters, MeetUps, etc. Often the organizer of these communities are happy to share highly targeted job opportunities with their members.
When looking for targeted communities, consider: industry-specific, location-specific, or technology-specific.
Matching Sites. There are some sites that serve as middle ground between inbound & outbound recruiting. Sites like Hired, AngelList, AList, or TripleByte serve as a place to find profiles of developers who are job seeking (and sometimes pre-screened) where you can browse for developers who look like a really good fit for you and reach out.
Targeted Outbound. Good old-fashioned cold emails to people who look like they would be the perfect fit for your role based on their exact experience. This is a lot of work but can be more effective than you may think.
Tip: If you have open source projects that strangers have made helpful contributions to, reach out to them! If not, then reach out to contributors for open source projects for the libraries that you use.
Recruiters. If you go this route, just be very careful about how they are representing your company.
Relentless follow-up
When you find someone you really want to work with… never stop following up. Recruiting is like sales.
The screenshot to the right shows an example of how I followed up with Casey, a developer that I had met a couple years prior and was really impressed with. You can see how every few months for ~19 months I kept checking in with him. At the bottom, you can see it eventually paid off. Casey is now a really key person on our engineering team.
For two more great examples of this, check out Steli’s blog post on how he recruited me for 3 years before I finally joined him.
If there’s a single lesson here, it’s this: When you find amazing people, follow up and follow through with them forever.
Screening
Use an Applicant Tracking System. A dedicated ATS like Breezy.hr, Workable.com, or Lever.co will make collecting, screening, and tracking a large number of resumes/applicants much more efficiently than just using your inbox/Trello/spreadsheet.
Customize your application form. When advertising jobs online (especially if you’re open to remote candidates), one of the toughest parts is actually having too many applicants, where many of them are low quality. A good solution to this is to customize your job application form to make it fun for the right kind of person and turn away people who just want to blindly apply to as many jobs as possible.
The form should, of course, give them a chance to share their resume/experience, which you’ll pay close attention to when screening.
But a good application form will also include technical screener questions which should only take a few minutes for someone good to solve, but will quickly weed out those who aren’t qualified. We’ve done this and have actually gotten great feedback about it. People love little technical challenges in application since it makes it less boring to apply.
Finally, include questions to help you evaluate their written communication, which is often under-appreciated in engineering hiring.
Having thoughtful questions on your application form will give you way more data when screening candidates.
Interviews
Example flow:
- Phone Screen (30-60m) – Intro, quick technical screener questions, hear about their experience and determine whether they seem overall impressive.
- Get good at phone screens – this is where most of your recruiting time will be spent.
- Have good technical screener questions that get you to a “No” as quickly as possible if someone isn’t great. For me I like to ask something one level deeper than frameworks might take care of for you, e.g. asking about SQL escaping/injection (for people used to ORMs), or direct DOM manipulation (for people used to React).
- Use coderpad.io for quick “can they actually code” live coding exercises of something simple.
- Technical Interview 1 (60m) – In depth technical/architectural questions
- Take-home project (2-3h) – Let’s see them actually build something (2-3 hrs). It’s important to timebox these for candidates so they don’t feel taken advantage of. Some companies actually pay. If you aren’t paying them, then don’t give a real problem that could be misinterpreted as trying to get free work from them.
- Technical Interview 2 (60m) – Drill in on missing technical areas, evaluate softer skills, overall seniority, etc.
Things to keep in mind during interviews:
The best interviews should feel like a dialog rather than just you asking a bunch of technical questions in a row. For example: Let them tell you about their experience, and ask questions along the way to go deeper.
Remember to sell. Use every interview as a chance to share what you think is great about your company and this role, since great candidates can have many opportunities to choose from.
Let them ask good questions. They should have good ones and be engaged. No questions is a bad sign.
Gut check / do you like them? If something doesn’t feel right during an intro call (when everyone is trying to put their best foot forward) that’s usually a sign of a bad fit.
Have all interviewers leave detailed notes & a summary/conclusion. It’s best if each interviewer independently writes their thoughts immediately following interviews to avoid groupthink. Press interviewers to summarize with a simple rating scale. For example we use language like “strong like” or “weak dislike”. This allows you to review everyone’s feedback afterwards and reject anyone where most interviewers are only ambivalent toward a candidate.
Offer
So you found someone you like? Great! Now comes the pivotal offer stage.
Always check references. Before you make the offer, reference checks are key to validate that someone is as good as you think they are, and not just good at interviewing. Great people with a decade or more of experience should easily be able to come up with a long list of names of current or past coworkers that would happily vouch for them.
Cautionary tale 1: Early in Close.io’s history we made a hire that turned out to be really, really terrible. In hindsight, I’m sure we would have avoided this hire if we had done thorough reference checks. Sadly, we also saw him go on to get hired (and also eventually fired) by another startup we respected. Had they talked to us first, they could have also avoided wasting time.
Cautionary tale 2: We were once trying to move quickly with a candidate, so we made an offer first but contingent upon reference checks. It turns out that once we did references, we detected that there was a significant error on his resume about the duration of time he spent in the role that was most relevant to us.
Make the offer & close it. Remember to focus the offer not only on the salary & benefits, but especially on selling the opportunity, quality of the team, and their ability for learning/growth.
Trial periods. If you have the opportunity to do a contract / trial period with someone before jumping to a full-time offer, that can be a really great lower risk way to see if they are truly a good fit (and if you are a good fit for them). Not all candidates can risk leaving a good job for a 1 month contract, but when possible, this can be a very useful tool.
Mistake: Assuming that accepted offer = position filled
It’s a rookie mistake to assume that just because a candidate accepts your job offer, that you’ve actually finished your job hiring.
Recruiting doesn’t stop at signed offer. Believe it or not, I’ve had more than one example where a candidate accepts an offer (including signing paperwork) and then changes their mind before their start date. I’ve heard reasons like “I got more excited by a different company”, “my current employer made a counteroffer too good to refuse”, and “my spouse ended up not being okay with the retreat travel requirements”. Don’t get mad, just move on.
You’ll have to make more offers than you think. Between some offers being declined, and some candidates dropping out before their start date, you will end up needing to make more offers than positions you’re trying to fill. While you definitely shouldn’t make more offers than roles you’re prepared to hire for, I do recommend that you continue talking to candidates even after you’ve made an offer, until you have somebody on board doing a great job.
Sell to start date. Keep candidates engaged from offer to start date by checking in along the way and continuing to sell. Specifically, we make sure that in the days/weeks between offer and start date that we send candidates at least a couple emails with links to blog posts we wrote, links to 5 star reviews of our product left by customers, a keynote video from our CEO, etc.
Onboarding & Beyond
Mistake: Assuming that your hires will work out
For the candidates that do make it to their start date, unfortunately many will still not work out – probably a higher percentage than you may think. Either you or they will determine the role isn’t right for them.
Your work doesn’t stop at their start date – focus on post-hire success. The first 1-2 months of onboarding is critical!
Don’t assume new hires are happy. Be checking in with new hires frequently. Ask questions like “We’re a couple weeks in and you’ve gotten a better sense for us now — what’s different than what you expected, good and bad?” New hires just may realize the job isn’t for them. For example, we’ve had someone tell us “I learned more in the past 3 months than the 3 years before that – but the pace is not for me”. Do what you can to make people happy, but then move on if it’s the wrong fit.
Learn from each bad hire. Your goal from each bad hire is to learn how you can improve your hiring process to avoid similar mistakes in the future.
Make sure you’re still excited after 30 days (or fire fast). Realistically, you’ll never get a perfect sense of someone from a few hours of interviews. So after you’ve had some time actually working with someone, if you’re not still excited about them being on the team, fire fast so you both can move on.
Hire more people than you think you need. Realizing that many hires don’t work out, you should plan to hire more people than you actually need in order to end up with the people you really need. Of course, you need to be able to afford everyone that you hire. But where you have room to hire an extra person (e.g. hiring 3 instead of 2 people for a role), doing so will increase your odds of success. It’s much easier to hire in parallel than serial for the same position, so it’s also more efficient to over-hire upfront than to keep restarting your hiring process after a hire doesn’t work out.
Onboarding tips
- Have a well thought out onboarding plan. I create a Dropbox Paper doc with a long list of checkboxes with a combination of things that they should do (project work) and learn (reading, talking to specific people, etc.) broken down by day and week for the first month.
- Ship on day 1. Get new engineers to ship something (even if super tiny) on their first day if at all possible. Definitely within the first week.
- Start with small quick wins but rapidly give them increasingly difficult projects. Get them in the habit of moving fast and shipping, quickly working toward giving them big amounts of responsibility.
- Spend a lot of time with them. Check in multiple times per week. If hiring remotely, try to find a way to start out in-person if possible.
Managing/running a growing team
Eventually all your hard work hiring will pay off and you’ll start to have a larger team. Now what? Leading a growing team is where things get fun. This topic really deserves its own blog post, but here are a few quick principles that have helped our team scale…
Hand over responsibilities. The sooner you trust your team with big problems and stop trying to control everything yourself, the better.
Have frequent 1:1s. Give the people you manage a meeting every week or two that is primarily their time. Discuss challenges and how they are feeling about work. Ask questions and listen. Tip: I like to keep an Apple Note per person on my team and when I think about something to discuss with them (a question or positive or negative feedback) throughout the week I’ll jot it there, and then use that Note before/after the 1:1 to take notes.
Build camaraderie. Especially with a remote team, it’s important that everyone feels connected and like they are a part of building something great together. Here are a few things that have helped us accomplish that:
- Retreats. 2-3 times per year we get everyone physically together in one place for about a week (different places around the world). This is where the most important team bonding, vision setting for the year, etc. occurs.
- Retrospectives. We try to (but need to do them more often!) have open discussions after projects wrap up where we discuss how it went, what we learned, what we did well, and what we’d like to do better as a team next time. The goal is to have a culture of continually seeking growth and improvement through healthy/safe discussions.
- Show & Tells. When you’re tiny, everyone knows what everyone else is working on. After you grow beyond a few people that’s no longer possible, so having a regular time where people are encouraged to share details of what they’ve been learning/coding/designing/launched/etc. is a fun way to keep people on the same page and decrease bus factor.
- Highs & Lows. Recently we’ve introduced a time where each person on the team very quickly (~30s/person) shares their High (best part) and Low (worst part) of their past week – related to either their work or personal life. Especially for our remote team, this has been great for hearing about wins and getting a better sense of what everyone is struggling with.
Add structure as the team grows. Setup Project Leads, Tech Leads, Engineering Managers, etc. so that you can give people on your team more responsibility and ensure you don’t bottleneck too many things.
Remote hiring
Being a distributed / all-remote team has been a huge asset for us both in terms of recruiting as well as retention.
Really great people are everywhere. We’ve found amazing candidates from countries all around the world. The Close.io Product/Engineering team is 14 people – all remote – working from 6 different countries.
Way more candidates. We pretty quickly get hundreds of candidates for every remote position we advertise. There are just a lot of people in the world who want to work remotely. (This is a blessing and a curse, see the “Screening” section.)
You can really stand out as a top company. It was very hard to stand out in Silicon Valley among all the other tech startups hiring. But among remote-friendly companies we were easily able to stand out as a very attractive option for candidates.
Cheaper. SFBay area engineering salaries, housing, cost of living, and office space are all insanely expensive. Go remote and hire more great people!
Retain employees longer. People stick around longer, since they can live where they want, move around as needed, and don’t have to deal with commutes or distraction-prone offices. At Close.io, once we went remote, me and 3 other people on our team moved out of California when family or other needs arose. Our jobs stayed the same even as our locations changed drastically.
For me, working from home has been wonderful as I became a father last year.
Conclusion
Building and growing an engineering team is hard… but it does get easier. And seeing your new team be able to accomplish more than you could ever before is a really great feeling.
Do you have your own tips for growing an engineering team? Questions or want to hear more? Tweet at me.