How to hire a software engineer

The six steps at a glance

1. Define the problem Write down what the engineer must own in year one.
2. Set the level and pay Match scope to seniority and check public pay data.
3. Write the brief Describe the work, the team and the constraints.
4. Source beyond applicants Reach employed engineers who are not looking.
5. Assess real work Test the skills the job uses, in a fair amount of time.
6. Close and onboard Move fast, handle counteroffers and plan the first 90 days.

What should you decide before you post a software engineer role?

Decide what the engineer must own in the first year, in plain sentences, before you think about titles or tools. For example: take over the billing service and cut failed payment retries; build the mobile offline sync the field team keeps asking for; or move the reporting jobs off the old server without breaking finance. Those sentences become your scorecard, your interview plan and your pitch to candidates.

Most stalled searches we see began with a list of technologies rather than a problem. A list of languages and frameworks tells a candidate almost nothing about whether the job is interesting, and it tells your interviewers almost nothing about what to test. A problem statement does both.

Next, decide what kind of engineer the problem needs. A product engineer who ships features quickly and talks to users is a different person from an infrastructure engineer who keeps systems reliable at three in the morning, even if both write the same language. Be honest about the mix. If the role really needs someone to carry on-call alone, say so now.

Finally, agree who decides. Name the hiring manager, the interviewers and the person who approves the offer. Searches lose good candidates most often in the gap between a strong final interview and a slow approval.

How do you choose the right level for a software engineer?

Choose the level by scope of ownership, not by years of experience. A useful test is the size of problem the person can take from vague to done without close guidance. A junior engineer finishes well defined tasks with review. A mid level engineer owns features end to end. A senior engineer owns systems and makes design tradeoffs others rely on. A staff level engineer shapes direction across teams and raises the quality of other people's work.

Hiring one level too low is a common and expensive mistake. The new engineer struggles with scope they were never ready for, the team carries the gap and the role gets reopened. Hiring one level too high has a quieter cost: a senior person in a narrow role gets bored and leaves. Match the level to the problem statement you wrote.

If you are a small company hiring your first or second engineer, lean senior. Early engineers make architectural decisions that later hires live with, and they usually have no one to learn from internally.

How much should you pay a software engineer?

Start with public data, then adjust for level, location and the specific skills the role requires. The US Bureau of Labor Statistics publishes pay and outlook information for software developers in its Occupational Outlook Handbook, and its Occupational Employment and Wage Statistics program publishes wage estimates by occupation and metro area. The OEWS methodology page explains how those estimates are produced, including that they come from a survey of employers and are released on a schedule, so they describe the market as of the survey period rather than this week.

Use that data as a floor and a sanity check, not as a final answer. Public estimates group many kinds of software work together and include a wide range of experience. A senior engineer with deep production experience in a scarce specialty can sit well above a broad occupational median, and remote roles complicate location adjustments further.

Our salary guide pages show published figures by role and location with retrieval dates. Whatever source you use, decide the range before you start interviewing, and get it approved. Discovering at offer stage that the budget does not match the person you want is one of the most reliable ways to lose a finalist.

Compensation is more than base salary. Equity, bonus, remote flexibility, on-call expectations and the quality of the team all count. Candidates weigh those differently, and a clear written picture of the whole package helps them compare your offer fairly against the job they already have.

What belongs in a software engineer job description?

A good job description reads like a short letter to the engineer you want. Open with the problem and why it matters. Describe the team: how many engineers, who they report to, how they ship and how they handle incidents. Name the stack honestly, including the parts that are old. State the location rules, the pay range where you can or where the law requires it, and how the interview process works.

Keep the requirements short. Split them into what the person must already have on day one and what they can learn in the first months. Long lists of required technologies discourage strong candidates who match the real need but not every keyword, and they attract weaker candidates who are good at matching keywords.

Avoid vague praise of your own culture. Every company says it is collaborative and fast moving. Specifics persuade: how often you deploy, how code review works, how much time goes to maintenance, what the last big project was and what went wrong with it.

Where do you find software engineers who are not applying?

Many of the engineers you most want are employed, doing good work and not reading job ads. Reaching them takes direct outreach. Start by listing the companies whose engineering problems resemble yours: similar scale, similar architecture, similar domain constraints. Then identify individual engineers at those companies whose public work, talks, open source contributions or professional profiles suggest they have done what your role needs.

Write to each person with a specific reason: what you are building, why their experience is relevant and what would be different for them. Generic messages get ignored. Expect to follow up more than once over weeks, and expect most first replies to be cautious. An employed engineer is deciding whether a conversation is worth an evening, not whether to accept a job.

Do not neglect your own network. Ask your current engineers who the best person they ever worked with was, and whether that person might talk. Referrals from strong engineers are often the highest quality source a company has, and they cost very little.

Job boards still have a place. Plenty of excellent engineers are actively looking at any given time, especially after layoffs. Post the role, read every application with care, and treat outreach as an addition rather than a replacement.

This is the part of the search where an outside specialist adds the most value. Mapping the market and running a persistent, personal outreach campaign is slow work that internal teams rarely have time for. If you use a recruiter, ask them to show you how they would do it for your role, in detail.

How should you assess a software engineer fairly?

Assess the skills the job uses, in an amount of time a busy employed person can reasonably give. For most roles that means a conversation about past work, a practical technical exercise close to your real problems, a system design discussion for senior candidates and a conversation about collaboration.

The past work conversation is the most underused tool. Ask the candidate to walk you through something they built that they are proud of, then go two or three layers deep: why that design, what broke, what they would change, who disagreed and how it was resolved. Engineers who did the work can answer those questions in detail. Engineers who were nearby cannot.

Keep take-home exercises short and relevant, and respect that employed candidates have limited evenings. Many strong engineers decline long unpaid assignments, and you lose them without ever knowing. A live pairing session on a realistic problem often gives better signal in less time.

Use the same questions and the same scoring for every candidate at the same level, and have interviewers write their assessments before they discuss them. Structured interviews reduce the chance that the loudest opinion in the debrief decides the hire.

Check references with intent. Ask former managers and peers about specific behaviors relevant to your problem statement, such as how the person handled an incident or a disagreement over design, rather than asking whether they would recommend the candidate.

How fast should a software engineer hiring process move?

As fast as you can make decisions well. Strong engineers are often in more than one process at once, and the companies that move decisively tend to win them. Schedule interviews close together, give feedback within a day or two of each stage and have the offer approved in principle before the final round.

Tell candidates the full process at the start: how many conversations, with whom, roughly how long each takes and when they will hear back. Predictability is a courtesy, and it also reduces drop off. If something slips on your side, say so before the candidate has to ask.

We do not publish an average time to fill because it depends heavily on role, level, location and how quickly the client decides. In general terms, a well calibrated search with a responsive hiring team reaches a short list far sooner than one where the profile keeps changing.

How do you handle counteroffers?

Expect them. An employed engineer who resigns is often offered more money or a new title to stay. Raise the subject early, before the offer: ask what would make them stay where they are and whether money alone would change their mind. If the honest answer is yes, you have learned something important while there is still time.

The most durable defense against a counteroffer is a clear reason to move that has nothing to do with pay: a better problem, a better manager, more ownership, a healthier team or a path the current employer cannot offer. Keep that reason visible through the process and repeat it in the offer conversation.

After the candidate accepts, stay in touch through the notice period. A short call from the future manager, an invitation to meet the team or an early look at the first project helps the decision feel real.

What are the most common mistakes when hiring a software engineer?

The first is changing the profile mid search. When the requirements shift after several interviews, every candidate already in the process was assessed against the wrong target, and the search effectively restarts. Settle the problem statement and level before the first conversation, and if something truly changes, say so and recalibrate on purpose.

The second is letting too many people into the decision. A loop with many interviewers who each hold a veto tends to reject strong but unusual candidates and favor safe ones. Give each interviewer a clear area to assess and keep the final decision with the hiring manager.

The third is treating candidates as applicants when they are not. An employed engineer you contacted did not ask for your job. If your process asks them to prove interest before you have explained why the role is worth their time, many will quietly withdraw. Sell the problem first, then assess.

The fourth is silence. Gaps of a week or more without news are where most good candidates drift away. Even a short message saying the team is still deciding keeps trust intact.

What makes a software engineer offer land?

A good offer answers the candidate's real questions in writing: base pay, bonus and equity terms, start date, location expectations, on-call duties, the title and the person they will report to. Call before you send it so the candidate hears the offer from a person and can ask questions straight away.

Avoid exploding deadlines. A short, reasonable window is fair. Pressure tactics tend to backfire with experienced engineers, who read them as a preview of how the company will treat them later.

How do you onboard a new software engineer so they stay?

Plan the first ninety days before the person arrives. Make sure equipment and access are ready on the first day, assign a named peer to answer questions, and give them a small real change to ship in the first week so they learn the deploy path. By the end of the first month they should own something meaningful from the problem statement you wrote at the start.

Hold a short check-in at thirty, sixty and ninety days about what is working, what is confusing and what they would change. Early friction is easier to fix than to recover from, and new engineers often see problems the team has stopped noticing.

How can you protect candidates and your brand from recruiting scams?

The US Federal Trade Commission warns job seekers about fake job offers and recruiters who request money, payment for equipment or sensitive personal information early in a process. Scammers frequently borrow the names of real employers. Publish your genuine openings on your own careers page, tell candidates how your real process works and never ask a candidate to pay anything. If you work with a recruiter, confirm they never charge candidates either.

How should a small company without a recruiter run this process?

Give one person ownership of the search, even if that person is the business owner or the engineering lead. Block regular time on their calendar for outreach and candidate calls, because hiring done only in spare minutes tends to stall for weeks at a time. Keep a simple shared list of every candidate, the stage they reached and the next action, so nobody falls through the gaps when the week gets busy.

Borrow structure from larger teams without copying their bureaucracy. Write the problem statement, agree the interview questions in advance and decide who makes the final call. Two or three interviewers are usually enough for a small company, as long as each one knows exactly which skills they are checking.

Be candid about what a small company offers and lacks. Candidates weighing your role against a larger employer want to know about funding, runway, the people they would learn from and how decisions get made. Answering those questions directly builds more trust than a polished pitch, and it filters out people who would be unhappy later.

What should you do if the search is not working?

Look at where candidates drop out. If few people reply to outreach, the message or the target list is wrong. If many reply but decline after the first call, the role, the pay or the pitch is the problem. If candidates reach the final round and then fail, your early screening is not testing what the final interview tests. Each pattern points to a different fix, and guessing wastes more time than measuring.

Revisit the pay range against current public data and against the offers your finalists mention. Revisit the requirements and remove anything that is a preference rather than a need. Then talk to two or three engineers who declined and ask, politely, what would have changed their mind. Their answers are usually more useful than another month of the same approach.

When should you bring in a recruiter for a software engineer search?

Bring in a specialist when the role is hard to fill from applicants, when nobody on your team has time to run a long outreach campaign, or when you have already tried and the right people are not responding. A specialist contingency recruiter costs nothing unless you hire someone they present, so the main investment is your time calibrating the search at the start.

Technology Headhunters recruits software engineers for direct hire on contingency. We start from the problem you need solved, reach employed engineers who are not applying, qualify each one in a live conversation on the real stack, and give you a written brief on every person you meet. If that sounds useful, send us your open role.

Related pages

• Software engineering roles we recruit
• Salary guide
• Recruiting fees
• Recruiting agency vs staffing agency
• Our process
• Editorial policy