How to hire an engineer

To hire an engineer, decide what the person will own in their first six months, source from networks and engineering-specific channels, and run a short, structured loop that tests the work they will actually do. This playbook covers whether to hire an employee, a contractor or an agency, which type of engineer you need, what it costs, where to find candidates, the interview plan, technical screen questions for nine engineering roles, references, evaluation and the offer.

When to hire your first engineer

The right choice depends on whether the work is ongoing or bounded.

Hire a full-time engineer when there is more work than the current backlog, your runway supports the next milestone and someone has time to onboard them. Do not hire yet if the scope is a one-off project, if nobody can review code and set direction, or if you cannot yet say what the engineer would ship in six months.

The first-engineer decision has its own wrinkles, covered in how to hire your first engineer. For a founding role at an AI company, see hiring founding engineers for AI startups. If you are not technical, involve a senior engineer you trust, such as an adviser or an investor’s technical partner, in designing the technical steps. You still own the decision, but you should not be the only judge of code quality.

Types of engineers and levels

Most bad engineering hires start with a vague role. Before you write a job description, write down four things:

1. The outcome. What should this person have shipped or owned after six months? “Own the billing system end to end” is a role. “Help with engineering” is not.
2. The level. Be honest about the support you can give. A junior engineer needs regular code review and mentorship. A senior engineer is expected to make decisions on ambiguous problems without waiting for direction. If nobody on your team can review their work, hire for independence.
3. The shape. A product-minded full-stack engineer suits most early-stage application work. Specialist depth matters when frontend, backend, infrastructure, data, machine learning or quality drives your hardest problems. The technical screen section below covers nine specialties.
4. The stack, split into must-have and learnable. A strong engineer can pick up a new framework. A language requirement is usually softer than a requirement to have shipped and operated production systems.

Then write the posting. Lead with the problem and what the engineer will own, list a short set of true requirements, and include the compensation range, which many jurisdictions now require; see compensation requirements for job postings. Keep the wording inclusive, using the advice in de-biasing job descriptions, because long lists of “required” skills discourage capable candidates from applying.

What to look for in an engineer

• Technical depth. Solid fundamentals in their area and the ability to apply them to your problems.
• Problem solving. They break down an unfamiliar problem, debug methodically and use hints well.
• Code and design quality. Readable, tested code and clear trade-offs, written so another engineer could maintain it.
• Communication. They explain a complex idea simply and ask clarifying questions before building.
• Collaboration. They handle disagreement and feedback well, including with product and design.
• Ownership and judgment. They scope, prioritize and decide under ambiguity, and follow through to production.

Write these down before the first interview. They become the criteria you evaluate candidates against below.

Red flags to probe. Vague answers where “we” hides who did the work, no stories about their own mistakes, defensiveness when you suggest a different approach, and no questions about your codebase or users. Each is a reason to ask more, not an automatic no.

What it costs to hire an engineer

Hiring an engineer has three costs: the recruiting fee if you use outside help, your team’s time across a four to five stage process that engineers have to run, and the pay package itself. For pay, see the compensation section below and our compensation strategy guide. For the recruiting fee, Dover’s Marketplace publishes what companies actually paid for engineering hires:

Recruiters on Dover set their own pricing, and you can engage them without a long-term contract. Weigh that against the engineering hours it takes to source, screen and interview on your own.

Where to find engineers

Engineers are usually found, not just posted for. Combine channels.

• Your network and your investors’ networks. For a first or founding hire, ask former colleagues, founders and investors who they would work with again. Make the ask easy to forward: what the person would own, the stage and the stack.
• Referrals from your own engineers. They know who is good and who is looking, so ask early.
• Direct outreach. Look for people who have built something relevant: open-source work, technical writing, conference talks. Reference the specific work and what they would own. See how to source candidates.
• Job boards and startup boards. Post where engineers who want startup work already look, and see where to post jobs and find candidates.
• Communities and meetups. Slower, but good for senior and specialist hires. Read each community’s rules before you post.
• A vetted recruiter. Recruiters on Dover’s Marketplace who hire engineers can run the search while you stay in the technical interviews.

Widen the pool on purpose: engineers who are underrepresented in your network will not appear unless you look elsewhere.

In Dover’s ATS, post the job to 50+ job boards from one place, post to Dover Startup Jobs if you are a venture-backed startup, and see which source produces hires in Reporting & Analytics. See Managing job boards.

The interview plan for engineers

A good loop gathers different evidence at each step, wastes nobody’s time and ends with a decision within a few weeks. For most startup engineering roles, this works:

Steps 4 and 5 can be combined into a short virtual onsite for senior hires. A few rules keep the loop fair and efficient:

• Give every interviewer a different job. If two interviewers ask the same questions, you have wasted a round. Assign each one a signal, such as coding, system design, collaboration or ownership.
• Tell candidates the plan up front, including what each round covers and how long it takes.
• Keep the loop short. If you cannot decide after four to six hours of interviewing, the problem is usually the criteria, not the candidate.
• Collect written feedback before the debrief. It stops the first or most senior opinion from anchoring the room.

For the principles behind this, see interview process best practices and interviewing diverse candidates. For the first call, how to run a recruiter screen has a script.

Choosing the technical exercise

No method is perfect. Pick based on the level of the role and what you most need to learn, and use at most one or two.

To make any exercise fair:

• Use a task that resembles real work, such as fixing a bug in a small project, adding a feature or reviewing a change. Avoid abstract puzzles.
• Cap take-homes at a few hours, state the cap, and pay for anything longer. Never run several unpaid assignments back to back.
• Share the evaluation criteria with the candidate, and use the same exercise for everyone applying to the role.
• Follow every take-home with a 30-minute live walkthrough. Ask what they built, why they made each trade-off and what they would do with more time.

Whatever the method, watch for these signals: do they clarify an unclear requirement before building, explain their trade-offs, test the likely failure cases, write code another engineer could maintain, respond well to hints, and say what they would change?

In Dover, build this plan on the job’s Interview Plan tab. Use a single-part stage for the screens, a multipart stage for the onsite and an assessment stage for the take-home. Assign each a feedback form and an email template, and send candidates a scheduling link from their profile. See Setting up your interview plan.

Technical interviews and AI coding tools

Most engineers use AI coding assistants on the job, so a blanket ban measures something that will not be true after day one. Candidates may also use them to prepare, to write take-home solutions or, covertly, during live interviews. Decide the policy per round, tell candidates before each round and apply it consistently:

• Take-home or work-sample round: AI allowed. Ask candidates to use whatever tools they would use at work, then require a live walkthrough. You are evaluating judgment: what they asked the tool for, what they rejected and how they checked the result.
• Live conversation or system design round: AI not used. The point is to hear how the candidate reasons, so keep it conversational and follow up on every answer.
• Technical screen: your call, but state it in the interview invitation.

Whether or not the candidate used an assistant, test whether they understand the code. Ask them to explain a choice, extend or break their own solution live, say what the generated code got wrong and what they would check before shipping it. Candidates who hand work to an assistant without reading it cannot do this; candidates who use the tool well can. Methods that are hard to outsource, such as live pairing, past-project deep dives and short walkthroughs after take-homes, work better than surveillance, which tends to push away strong engineers. Our guide to how to prevent cheating on technical interviews covers this in more detail.

For roles that will build and operate AI-assisted systems, add one or two questions: how do you use AI tools day to day and where do they get in the way; tell me about a time a tool gave you plausible but wrong code and how you noticed; how do you review a pull request that is mostly generated code. Strong answers describe habits for checking output, such as reading the diff and writing tests. Weak answers either reject the tools entirely or trust them blindly.

Interview questions for engineers

Open every technical screen the same way: introduce yourself, explain the format, ask for a short overview of the candidate’s background, then work through three or four questions from the list for the role. Leave five minutes for the candidate’s questions. Treat the questions below as prompts for a conversation, not a quiz. If someone gives a textbook answer, ask what they did on a past project, what went wrong and what they would change.

Fullstack engineer

• Walk me through a feature you built end to end, from the database to the screen. Where did you spend most of your time?
• How would you design authentication and authorization for a multi-tenant web app? Where do things most often go wrong?
• When does caching help, and when does it cause bugs? Give an example you have dealt with.
• Describe a problem you debugged that crossed the frontend and the backend. How did you narrow it down?
• Exercise: design a signup form and the API behind it. Listen for validation, error handling, security and what they would leave out of a first version.

Frontend engineer

• Describe an interface you are proud of. What were the trade-offs, and what would you do differently?
• How do you decide where state should live in a frontend app? Give an example of getting it wrong.
• What would you check for accessibility on a form before shipping it?
• A page is slow to load or feels janky. How do you investigate, and what are the usual causes?
• How do you test frontend code, and what do you choose not to test?
• Exercise: build a navigation menu that collapses on small screens, or a form with clear error messages. Notice semantic markup, keyboard use and whether they ask about edge cases.

Backend engineer

• Describe the most complex service or API you have built. How did it behave under load, and what broke?
• How do you design an API so it can change without breaking clients?
• A query is slow in production. How do you find the cause and fix it?
• Where have you used caching or a queue, and what problems did they introduce?
• How do you handle retries, timeouts and failures when calling an external service?
• Tell me about a production incident you helped resolve. What did you change afterward?
• Exercise: implement an endpoint that returns a user’s data with authentication and permission checks, or design a schema for orders and payments.

Engineering manager

• Tell me about a team you managed. How did it change under you, and what did you do about the people who struggled?
• Describe a time two engineers strongly disagreed. How did you handle it?
• How do you scope and estimate a project with a lot of unknowns? What do you do when it slips?
• How do you balance shipping with technical debt, and who decides?
• How do you hire, and what have you learned from a hire that did not work out?
• Scenario: your team misses a deadline because a key engineer leaves. Walk me through the next two weeks.

DevOps engineer

• Tell me about a delivery pipeline you built or improved. What made deployments safer or faster?
• How do you manage infrastructure as code, and how do you handle drift and secrets?
• How do you set up monitoring and alerting so people trust the alerts?
• Walk me through an incident you handled: how you found it, fixed it and what changed afterward.
• How do you control cloud costs without slowing engineers down?
• Scenario: deployments take forty minutes and developers have stopped trusting them. What do you do first?

Infrastructure engineer

• Describe the infrastructure you have been responsible for. What was its scale and what went wrong?
• How would you make a critical service survive a zone outage?
• Something is intermittently failing and you suspect DNS, load balancing or latency. How do you approach it?
• Describe your backup and disaster recovery approach. How do you know the restore works?
• How do you decide between managed services and running something yourself?
• Scenario: a database becomes the bottleneck as traffic grows. What options do you consider, and how do you choose?

Data engineer

• Describe a data pipeline you built. Where did the data come from, what broke and how did you know?
• How do you design a pipeline so it can be re-run safely and handle late or duplicate data?
• Tell me about a time poor data quality caused a problem downstream. What did you change?
• When do you choose batch over streaming, and what does each cost you?
• How do you test and monitor a pipeline in production?
• Scenario: design a pipeline to ingest event data from a product, clean it and make it queryable for the business within a day.

AI and machine learning engineer

• Describe an AI feature you shipped to production. What was the failure mode, and how did you measure quality?
• How do you evaluate an LLM-based feature before and after launch, and keep your evaluation set from going stale?
• When would you use a hosted model through an API, fine-tune a model or build retrieval over your own data?
• What do you do when the model is confidently wrong? Describe the guardrails and fallbacks you have used.
• How do you handle sensitive data, prompt injection and misuse in an AI feature?
• Scenario: build a feature that summarizes customer support tickets. How would you ship the first version and know whether it works?

For more on this specialty, see how to hire AI engineers at a startup.

QA and test engineer

• How do you decide what to test and what to leave untested? How do you think about risk?
• Walk me through a test automation framework you built or improved. What made it reliable or flaky?
• How do you test an API, and what do you check beyond the happy path?
• Tell me about a significant bug you found late. How did it escape, and what changed after?
• How do you write a bug report an engineer can act on quickly?
• Scenario: you join a product with no automated tests and a release next week. What do you do first?

Behavioral questions for any engineer

Ask the same few of every candidate in the hiring manager and team rounds, and take notes on specifics: what did they personally do, what was the result, and what did they learn?

• Tell me about a project that did not go as planned. What happened, and what did you do?
• Describe a time you disagreed with a technical decision. How did you handle it?
• Tell me about the last time you had to learn an unfamiliar tool or codebase quickly.
• Describe a time you cut scope. What did you drop, and how did you decide?
• Tell me about a mistake you made in production. How did you respond?
• What would you want to own in your first six months here?

Reference checks for engineers

Do them for finalists, after the technical rounds and before the offer, and always with the candidate’s consent.

• Ask what the candidate personally owned and delivered, not just what the team shipped.
• Ask how they handled disagreement, code review feedback and a production incident.
• Ask the same questions of each reference so the answers are comparable.
• Ask whether the reference would work with them again, and in what kind of role.
• If you can, speak to someone who reviewed their code or worked beside them, not only the manager the candidate named.

Ask candidates for permission before you contact a current employer.

How to evaluate engineer candidates

Evaluate each candidate against the same criteria right after the interview, before you compare notes with other interviewers. Write what you saw and heard, not a number, and have each interviewer cover only the criteria they were assigned.

Decide in advance which criteria are must-haves, and do not penalize a candidate for not knowing a specific tool you use if they have solved the same problem with another one. Rate the evidence, not the person: “missed the null case, found it after a hint” is evidence, while “seemed sharp” is not.

Interview feedback form

Give every interviewer the same short form:

1. Overall recommendation: strong yes, yes, no, strong no.
2. For each criterion assigned to you, one or two lines of evidence: what the candidate said or did.
3. The strongest signal from this interview.
4. The biggest concern.
5. What we should probe in the next round.

Ask interviewers to submit their feedback before they read anyone else’s. Compare notes in a short debrief, not in a chat thread.

In Dover, create it as a feedback form in Settings → Feedback Forms and assign it to each stage so every interviewer answers the same questions; on Premium the AI Notetaker can capture the conversation and fill in the form. See interview feedback forms.

Engineer compensation and closing the offer

How to think about engineering pay

Decide the package before you post the role, so you can state the range in the first conversation. Salary and equity depend on location, level and stage, and they move quickly. Use a current benchmark from a source you trust and read the compensation strategy guide; this guide deliberately gives no figures. Settle these decisions with your team:

• Level and range. Which level are you hiring for, and what range fits it and your location policy?
• Equity. If you offer it, explain the number of shares, the vesting schedule, dilution, the exercise cost and the time people have to exercise options. Equity has no guaranteed payout, and candidates should hear that from you. Suggest they get tax advice.
• Remote and location policy. Decide whether pay varies by location before candidates ask.

Our guide to compensation requirements for job postings explains when you must publish a range.

Close an engineering hire

Engineers with options evaluate your company as much as you evaluate them.

1. Move fast after the final round. Aim to decide within a couple of days and make the offer soon after. Waiting is the most common way to lose a strong candidate.
2. Talk about compensation early. Align on a range before the final stage so the offer is not a surprise.
3. Sell on the work. Engineers care about what they will build, who they will work with, how decisions get made and how much they will learn. Let them talk to the people they would work with.
4. Make a written offer that covers the whole package: compensation, equity, start date, reporting line and any conditions. For negotiation and counteroffers, follow how to make an offer. Dover Premium includes offer management and e-signing.
5. Plan the first week before they accept. Prepare repository and infrastructure access, a small first project and a person they can ask questions.

For a founding engineer, the equity, authority and title conversation is longer; see how to hire your first engineer.

Common mistakes when hiring engineers

• Hiring without a defined outcome. If you cannot say what the engineer will own in six months, the interviews will not either.
• Using puzzles instead of real work. Abstract algorithm tasks measure puzzle practice, not how someone will build your product.
• Giving every interviewer the same job. Repeated questions waste a round and leave gaps in what you know.
• Long unpaid take-homes. They push away strong candidates with options and favor people with free evenings. Cap them and follow with a walkthrough.
• Having nobody who can judge the work. A non-technical founder should bring in a trusted senior engineer to design and review the technical steps.
• Banning AI tools without a plan. State the policy for each round and test whether candidates understand their code.
• Moving slowly. Strong engineers are rarely on the market for long. Decide within a couple of days of the final round.

Get help hiring an engineer

Engineering is a hard search for a small team: the best candidates are employed and busy, and every hour spent sourcing is an hour not spent shipping. Dover’s Marketplace connects you with vetted independent and fractional recruiters who have made engineering hires, and you can engage them without a long-term contract. They run sourcing, screening and scheduling, and every candidate stays in your own free ATS.

• Browse recruiters who hire engineers and see what past engineering hires cost.
• Run the process in Dover’s free ATS with interview plans, feedback forms and offers.

Frequently asked questions

How do you hire a software engineer?

Decide whether you need an employee or a contractor, define the level and the first six months of work, source from networks and job boards, run a short structured loop, evaluate every candidate against the same criteria, check references and move quickly to a written offer.

What is the best way to interview engineers?

Use a structured loop where each interviewer owns a different signal, ask every candidate for the same evidence, and prefer work that looks like the job (debugging, extending an existing codebase, a design discussion) over trivia. Write feedback before the debrief so one loud opinion does not decide the outcome.

Should you use a take-home test or live coding?

Neither is always better. A short, time-capped take-home gives candidates room to think but can be outsourced, so follow it with a live walkthrough. Live pairing shows how someone reasons but can stress strong candidates, so keep it collaborative and on a realistic task.

Should candidates be allowed to use AI coding assistants in interviews?

Decide per round and tell candidates up front. Many teams allow AI in a work-sample round and test how the candidate verifies and explains the output, while keeping at least one live conversation where the candidate reasons without it.

When should a startup hire its first engineer instead of a contractor?

Hire an employee when the work is ongoing and you need someone to own the product's technical direction. Use a contractor or agency when the scope is bounded, such as a prototype or a defined integration, and you do not yet know what you will build next.

How much does it cost to hire an engineer?

It depends on how you hire. A traditional recruiting agency typically charges 15 to 25% of first-year salary, while Dover's Marketplace publishes the all-in cost of each engineering hire, shown in the live table on this page. Add your team's interview time and the pay package.

Where do you find engineers to hire?

Start with referrals from your own engineers, former colleagues and investors, then direct outreach to people who have built relevant work, engineering communities and job boards. A vetted recruiter who specializes in engineering can run the search if sourcing takes more hours than you have.