To hire a good software developer, write down the specific problems the person will own in their first six months, set a pay range from market data before you post, and run a short, consistent process that tests the work they will actually do. Those three steps do more for the quality of the hire than any sourcing trick.
This guide is for founders and hiring managers who do not have a recruiting team. It covers the role definition, the pay range, sourcing, the interview process, the offer, and the mistakes that cost the most time.
Define the role before you write anything
"We need a senior full-stack engineer" is a title, not a role. Before you post, answer these in writing:
- What will this person own? Name the systems or product areas. "The billing service and the admin dashboard" is useful. "Backend work" is not.
- What does success look like at six months? For example: the billing migration is shipped, on-call load is shared, and they have reviewed most backend pull requests.
- What level is it, really? Can the person work from a vague problem statement and make design decisions alone (senior), or will they work from tickets someone else scoped (mid-level or junior)?
- Who will they work with and report to? A first engineer reporting to a non-technical founder needs very different judgement from the fifth engineer on a team with a tech lead.
- What must they know on day one, and what can they learn? Most frameworks can be learned in weeks. Production debugging judgement and system design take years.
If you cannot answer the six-month question, you are not ready to hire. You will end up interviewing for general cleverness and then be disappointed when the person does not read your mind.
Also decide which occupation you are hiring for. A developer who builds marketing sites is closer to a web developer; someone building data pipelines and models may be a data scientist; someone running servers and networks is closer to a systems administrator. The skills and the pay are different.
Set the pay range from data
Decide the range before you talk to anyone. Candidates will ask early, and in several states you are legally required to put it in the posting.
The Bureau of Labor Statistics gives you a public baseline. For software developers, the BLS reports May 2025 annual pay of:
| Percentile | Annual pay |
|---|---|
| 10th percentile | $82,460 |
| Median | $135,980 |
| 90th percentile | $214,670 |
The same profile shows that industry changes the middle a lot: software developers working for software publishers had a median of $164,550, compared with $136,330 in manufacturing. If you are a software company competing for the same people as other software companies, the industry median is a better reference than the overall one.
For QA roles, use the separate BLS figures for software quality assurance analysts and testers: a median of $104,300, with a 10th percentile of $61,440 and a 90th percentile of $167,010.
A workable way to set a range:
- Junior: between the 10th percentile and the median.
- Mid-level: around the median, adjusted for your industry.
- Senior: above the median, moving toward the 90th percentile for people who will own systems and lead others.
Then adjust for location using the BLS state and metro wage data linked from the profile. These are national numbers. Also remember what they leave out: the BLS wage survey excludes stock bonuses and nonproduction bonuses, so if you are offering equity, the BLS figure is a benchmark for base salary, not total compensation.
If your range sits well below the median for the level you want, either lower the level or raise the range. Posting a senior role at junior pay produces a pipeline of people who are not senior.
Where to find candidates
For a small company, these are the main channels, from most personal to least:
- Referrals from your own network and your current engineers. Ask specifically: "Who is the best backend engineer you have worked with who might be open to a move?" Vague requests get vague answers.
- Direct outreach. Find people who have built something close to what you need (open source maintainers, conference speakers, authors of technical posts on the problem you have) and write to them personally. Mention the specific work of theirs you saw.
- Job postings. A clear posting with a pay range on general and tech-specific job boards. Expect a high volume of applications and a low share of strong fits.
- Agencies. Useful when you have no time and some budget. Be clear about the fee before you share the role.
Referrals and personal outreach work well, but a team that hires only from its own network tends to hire people like itself. The EEOC treats recruitment as an area covered by federal anti-discrimination law and gives word-of-mouth recruiting from a homogeneous workforce as an example of a practice that can cause problems (EEOC). Use postings alongside referrals so the pool is wider than your contacts.
A fair process that does not waste anyone's time
A good developer process for a small company has four or five steps and finishes in two to three weeks:
- Application review. Look for evidence of the work you need: systems they built, problems they solved, code you can read. Ignore résumé polish.
- Intro call (30 minutes). Explain the role, share the range, and ask about one project they are proud of. Confirm the basics: location, timing, pay expectations.
- Technical exercise (60 to 120 minutes). Something close to the real job (see below).
- Team interviews (2 to 3 hours total). A system design or architecture conversation, a discussion of the technical exercise, and a conversation about how they work with others.
- References and offer.
Write down, before the first candidate, what you are evaluating at each step and what a strong, adequate and weak answer looks like. Use the same questions and the same exercise for every candidate at a given level. This is the single biggest improvement most small teams can make: it lets you compare candidates against the job rather than against each other's charisma.
Evaluate skill without asking for a weekend of free work
The best technical assessments look like the job and respect the candidate's time.
| Format | Strengths | Weaknesses |
|---|---|---|
| Paid or time-boxed work sample | Closest to real work; shows how they structure code | Must be scoped tightly or it eats evenings |
| Pairing on a real-ish problem | You see how they think and communicate | Some strong engineers do poorly under observation |
| Code review exercise | Fast; tests judgement and reading skill | Less signal on writing code from scratch |
| Algorithm puzzles | Easy to standardize | Weak link to most product engineering work |
Practical rules:
- Cap take-home work at two hours and say so. If you need more, pay for it.
- Base exercises on your actual problems, simplified. If you build APIs, ask them to extend a small API. If you maintain a legacy codebase, give them messy code to improve.
- Let them use their normal tools, including their editor, documentation and the language they know best, unless language fluency is a real requirement.
- Follow the exercise with a conversation. Ask why they made their choices and what they would change with more time. This tells you more than the code alone.
- Offer accommodations. Ask every candidate whether they need any adjustment to the format. The EEOC notes that the ADA requires reasonable accommodations in how tests are administered (EEOC guidance on employment tests).
Making the offer
Move fast once you decide. Good candidates are often in other processes, and a week of silence after the final interview loses people.
Call the candidate, tell them you want to hire them, and walk through the offer: title and level, base salary, bonus if any, equity details, benefits and start date. Follow up in writing the same day. If you offer equity in a private company, include the number of options, the strike price, the total shares outstanding and the vesting schedule. An equity grant without the denominator means nothing to an experienced engineer.
Expect negotiation and leave room for it within your range. If you cannot move on base, know in advance what you can move: a sign-on bonus, equity, start date, or an early compensation review.
Mistakes that cost the most
- Hiring for a vague role. If the job is unclear, every candidate looks partly right and none looks clearly right.
- Underpricing the role. A range below market does not save money. It produces months of searching and then a compromise hire.
- Too many interview rounds. Each extra round adds days and loses candidates. If a round does not change decisions, remove it.
- Unstructured interviews. Without written criteria, interviewers grade on rapport. You hire people who interview well rather than people who do the work well.
- Ignoring the pay transparency rules. California, Colorado, Washington, New York and Illinois are among the states that require pay information in job postings, with different rules. Check the labor department rules for each state where the job can be performed; our guide to writing tech job descriptions covers the details.
- Letting the process drift. Set a target timeline and tell candidates what it is.
Your first step
Before posting anything, write a one-page role brief: what the person will own, what success at six months looks like, the level, and the pay range set from the BLS figures above and your local data. Share it with whoever will interview. Every later step (the posting, the exercise, the scorecard, the offer) is easier when that page exists.