How to hire engineers: your ultimate guide
You’ve nailed the idea. You’ve developed your vision. How do you bring it to life?
Bring in the engineers! It’s likely that your founding team has experience in software engineering, but as you begin to scale, you’ll need dedicated, advanced, full-time engineers. These are typically the first hires you make as an early-stage startup, meaning that they’re not only mission critical for shipping product — they’ll also set the tone for the type of company culture you’ll build.
Engineering is the intersection of problem solving, strategic thinking, and technology. Engineers focus in on different areas of expertise, whether frontend, backend, or fullstack, and spend most of their time developing the product by writing code in various languages or programs.
Some day-to-day tasks may include:
Working with Product and Design teams to develop features
Pushing lines of code
Resolving bugs and maintaining quality assurance
Building feature requests for clients/customers
Analyzing data and creating dashboards that display data in a logical way
Managing internal tech stacks and external integrations
How do we define engineers and engineering departments?
A software engineer who specializes in the development of the user interface (UI) is called a frontend engineer. The user interfaces include visual elements like layouts and aesthetics. Frontend engineers deal with cross browser compatibility and fixing bugs to ensure an excellent visual presentation of the UI. Thus, they work with the code that runs on different user devices, browsers, and operating systems. Developing a responsive application also falls under their responsibilities.
A software engineer who specializes in the underlying logic and performance of the application is called a backend engineer. They often design and implement the core logic, keeping in mind scalability. They do this by integrating with data systems, caches, and email systems using Application Programming Interfaces (APIs).
A software engineer who can handle both frontend and backend work is called a fullstack engineer. They have the skills required to create a fully functional web application.
Software Engineer in Test (QA Engineer)
A software engineer who is responsible for writing software to validate the quality of the application is called a QA engineer. QA engineers create automated tests, tools and methods to make sure that products and processes run as expected.
Site Reliability Engineer
Site reliability engineers will be dedicated full-time to creating software that improves the reliability of systems in production, fixing issues, responding to incidents and usually taking on-call responsibilities.
Software engineers who are familiar with the technologies required for the development of systems to build, deploy, integrate and administer backend software and distributed systems are called DevOps engineers. They mostly manage the application infrastructure, i.e., the database systems, servers, etc.
A software engineer who specializes in creating systems, methods, and procedures to test the security of a software system and exploit and their flaws is called a security engineer. This type of developer often works as a “white-hat” ethical hacker and attempts to penetrate systems to discover vulnerabilities.
Machine Learning (ML) Engineer
A machine learning engineer (ML engineer) is a person in IT who focuses on researching, building and designing self-running artificial intelligence (AI) systems to create and automate predictive models.
Mobile engineer is a broad term that is used to describe anyone who builds and programs mobile applications. The most common are Android developers or iOS developers.
Where can I find great engineers?
General Job Boards:
Hiring your founding engineer
Your founding or first engineer might be the toughest hire you ever make. As an early-stage startup that is pre-funding or pre-product launch, you need to enlist the help of someone from your internal network for three reasons:
It’ll be hard to convince a stranger on your vision and work ethic
This person may become your future CTO — you want someone you work with well
Your first hires are going to take on the biggest risk (and potentially a pay cut) when joining your company — these are going to have to be folks who trust you, not just your product
Similar to investors, it's usually a bit of a red flag when the founder can't convince family, friends, or old colleagues to work with them. Though you may never get this feedback directly from candidates, knowing that you have a team who trusts in your vision and product (and enjoys working with you!) builds your credibility.
Here are four tips that can help you as you begin your search:
1. Determine what the ideal profile of your founding engineer would look like.
At a high level, your founding engineer will be building your product and team from the ground up. However, not every engineering team has the same pain points, needs or tech stack. You’ll want to be able to answer the following questions when considering who to source:
Will they need expertise in a specific area/tech stack? Sourcing someone with deep knowledge of a particular platform or language is probably the route you’ll want to take, as opposed to bringing on a generalist.
Will this person move up the ranks to become a CTO? Determining how closely they’ll be managing and growing your team is critical — you’ll need someone with previous management experience, who has a strong network to pull from when building out your early team. Arum, co-founder and CEO of Coffee Meets Bagel, says she nurture the relationship with her founding engineer over coffee chats for almost six months. When asked why she waited so long, Arum expressed just how important it was to find the right person.“What’s important for anyone I bring on to the team is that we really know each other well. They have to be smart and good at what they do, and they also have to be mature. You just cannot force that.”
Do you want to offer a contract-to-hire option? A contract-to-hire option offers more flexibility and limits hard feelings if the relationship isn’t the right fit. Even if someone is your friend or former colleague, early startups are a fast-paced and stressful environment — even the strongest of friendships can falter. Plus, even if the candidate ends up being a bad match, you’ll still learn valuable insights into what you should look for.
2. Lean on your investors, your network and developer meetups to find the right candidate.
If you’re a nontechnical founder, it may be difficult to find someone with the skills necessary to build your software from the ground up. There are a few workarounds here, but obviously, they’ll require a bit more time and selling compared to someone you already know well:
Developer meetups. Popular ATS platform Lever interviewed several founders to get their advice on hiring their first employees. Arum met her founding engineer at a developer meetup, citing that it was a positive signal to see someone invested in professional development and emerging trends.
Your investors. It can be difficult to get candidates on the phone when you’re a small team, but social proof (i.e. a personal referral) can go a long way. Your investors have a concerted interest in helping you succeed. They likely have extensive knowledge of who is at the top of their career and might be a good fit for your team. Ask them to make an introduction on your behalf.
Your network. Even if you don’t personally know any engineers, your network certainly has folks in mind. Similar to the point above, this is a powerful form of social proof: selecting former friends or colleagues who you know will speak highly of you can go a long way in getting top talent on the phone for an informational conversation.
3. Hire engineers with design experience.
Aaron Epstein, partner at Y Combinator, recommends hiring engineers who also have design experience. Otherwise, you’re left with an awesome framework and no UI or optimized user experience.
These don’t necessarily need to be folks who are former designers, but you should look for those who have an eye. They’ll be able to move much faster if they can iterate, code and design on their own. It also ensures you’ll be creating a strong foundation that a designer won’t have to come in and fix later on.
4. Have them work on an actual part of your code base.
if they pass initial interviews and screenings, invite them to work with your team on the codebase for a day. there’s no better assessment of culture and company fit than throwing them in the ring.
One of Dover’s co-founders, Anvisha Pai (who has been a founding engineer herself), mentions this is the best assessment of competency and teaches you how someone will actually perform on your team outside of their credentials.
“At Dover, we were introduced to some highly credentialed people who didn’t end up being a fit and it came out pretty clearly in this process in a way that wouldn’t have come up in a whiteboard interview.” - Anvisha Pai, Cofounder and Head of Product
When hiring Dover’s founding engineer, she gave him three potential features and told him to pick one to build out. Within three days, he had built all of them. A great thing about this process is it gives you clear conviction — the decision to hire John, one of Dover’s founding engineers (who is now the CTO), was unanimous and easy.
Along with technical coding knowledge, the following skill categories are essential to an engineer’s success. You’ll want to assess these skills in the second remote screen, as well as throughout the onsite and final interview process. We’ve provided examples of strong and weak answers as well, so you can align everyone involved in your interview loop.
An engineer will have to function as a mediator between product, design and different engineering departments. Not only will they need to be good at delegating, they’ll also need to effectively compromise and argue for various improvements in the product with various stakeholders.They’ll also need to be able to debug, help QA other engineers’ projects, and provide assistance to unblock team members if need be.
Pro tip: Product designers have ascended to become the “third leg of the stool” alongside PMs and engineers. One way to evaluate design sensibility and product instincts is to include product designers in the interview loop.
Tell me about a time you disagreed with an engineer on your team and how you resolved it.
Weak answer: Defensiveness, placing blame on others, the problem resulted in gridlock or deprioritization rather than compromise and solution.
Strong answer: They have humility and self-awareness. They’re able to diagnose where and why they needed to compromise, and how they did so. A candidate who ends their response by saying what they learned from the situation and how they applied these lessons going forward should get serious bonus points.
More points if they allude to/give credit to the teammates they worked with to get the project accomplished. If an engineer is using a ton of “I” or “me” statements, they might not be the best collaborator, or are poor at giving credit where credit is due.
Working at a startup or on a small team often means that engineers will receive projects without crystal clear direction.
It’s not enough to have an engineer who is a talented coder — you need someone who is capable of making decisions that are in the best interest of your company’s overall strategy/vision, defining deadlines and goals, as well as success metrics. Execution entails other important qualities like time-management, effective communication, and excellent people management skills.
Can you talk through a project where the product requirements or end goals weren't well defined and you had to fill in the gaps?
Weak answer: They discuss broad strokes, or their overview is rambling, and difficult to follow.
Strong answer: They’re able to discuss the roadblocks and hurdles along the development process (including how they solved them), as well as articulate how they sought feedback and revised the scope while still aligning with the company strategy or vision.
Do you have an example of a time you've not had clear direction of a project?
Weak answer: They’ve either never worked in an ambiguous environment, or express stress at working without definitive direction.
Strong answer: They take proactive action and know how to involve and communicate effectively with the correct stakeholders to get the answers they need. They can describe specific situations in which they’ve worked with little guidance and enjoy working autonomously.
To put it simply, great engineers should love to code. Especially as an early-stage company, technical knowledge is key in getting over the tough hurdles of building infrastructure from the ground-up, iterating on coding projects and design, and debugging platform issues.
Consider asking: How do you sanity and quality check code? What is your process for debugging an app?
Weak answer: Giving obvious or broad answers, not naming specific programs or procedures they’ve used in the past to QA and debug projects.
Strong answer: Look for a wide breadth of knowledge when it comes to writing quality code: they should mention reliability, stability, integration and testing. You should also listen for examples of humility and willingness to collaborate. You want someone self-sufficient, but modest enough to ask for help when they’re stuck. Also, look for references to development and deployment testing techniques or debugging tools.
Measuring impact in previous roles is your best signal when determining the success of an engineering hire. We define some things to look out for below, but generally it’s important that they’re able to express what they’ve built in the past, and how they solved bugs, collaborated with the team, and improved on a product or feature over time.
What’s the most important or impactful product you shipped? What made it so important or impactful? Would it have been as impactful without you, and why?
Strong answer: Articulates tangible impact, including metrics, historical data, increases in product adoption, or revenue generation streams.
Weak answer: If they only talk about qualitative impact, or don’t have a good example of product innovation, leadership, or ownership. This could signal that they’re not good at working autonomously.