Recruiting software engineers for clients: level, stack and pay
How to run a client's software engineer search: pin down level and stack at intake, map must-haves to evidence in the submittal and check pay against BLS data.
By the Recruiting ATS team (How we write)Published 8 min read
A client tells you they need "a senior backend engineer, Python, as soon as possible." Two weeks later you've sent three candidates and each one came back with a single line: "not senior enough", "we're really a Go shop now", "great engineer, wrong kind of systems". None of those candidates were bad. The brief was.
When you're recruiting software engineers for a client, most rejected submittals fail on level or stack, and both get settled, or not, on the intake call.
Why "senior" means something different at every client
Titles don't travel. A senior engineer at a twelve-person startup may have built half the product and answer the pager at 3 a.m. A senior engineer at a bank may own one component of a large system, with an architect above them. Both titles are honest. They describe different jobs.
Years of experience don't settle it either: "seven years" says how long someone has been employed, not what they've been trusted with. Ask what the person will own.
Level calibration worksheet for the intake call
Go through these with the hiring manager, not only with HR, and write the answers down in their words.
| Ask | What you're listening for | Write down |
|---|---|---|
| What will this person own in their first six months? | A feature, a service, a whole system or a team's direction | The specific thing, by name |
| Who decides how that system is built today, and will this hire? | Whether they make design calls or implement someone else's | "Decides", "proposes" or "implements" |
| Is there an on-call rotation? How often, and how noisy is it? | Real production responsibility, not just a title | Rotation size and frequency |
| How many engineers are on the team, and who is the most senior? | Whether the hire gets mentored or does the mentoring | Team size and where the hire sits in it |
| Who will this person report to? | An engineering manager, a CTO or a non-technical founder | Name and role |
| Will they get tickets or problems? | How much ambiguity they're expected to handle | One sentence |
| Who is the best person you've hired at this level, and what did they do in their first quarter? | The client's real bar, described through a person | The example they give |
| What's the salary range, and is there a bonus or equity? | Whether the money matches the level they just described | Range and structure |
Then read it back as one paragraph. Example: "So senior here means owning the payments service end to end, joining a six-person on-call rotation, being the second most senior of five engineers and reporting to the CTO. Is that right?" If the hiring manager corrects you, you've just saved three rejected submittals. If they agree, put that paragraph at the top of the job so everyone working the search reads it first.
Separate the stack they need from the stack they listed
Engineering job descriptions tend to list every technology the team has ever touched. At intake, sort that list into three groups:
- Must-have: the candidate has used it in production, or the client won't interview them.
- Nice to have: a plus, never a filter.
- Learnable: a competent engineer picks it up in the first weeks.
The quickest way to sort is to test a near miss. "If a strong engineer built the same kind of service in Java instead of Kotlin, would you interview them?" The answers show you which items are real filters. A list of fourteen technologies usually shrinks to two or three must-haves plus the kind of system the person has built: high-traffic APIs, data pipelines, mobile apps, internal tools.
Then ask about scale. An engineer who has run a service for a few hundred internal users and one who has run it for millions of customers both "know Python", and the client has one of them in mind. Ask too what the team runs in production today and what it's moving to, because good candidates will ask you.
If the client hires remote engineers in other countries, add two questions: how many hours of overlap with the team's working day they need, and what level of English the team works in. Both rule out candidates as fast as a missing must-have.
Where to source engineers who fit
With level and stack pinned down, sourcing narrows:
- Your own database first. Runners-up from past searches and people who turned down an offer because the timing was wrong.
- Companies that solved the same problem at the same scale. If the client is building payments infrastructure, look for people who've built it elsewhere, not only for the right keywords.
- Public technical work. Open source, conference talks, technical posts. Useful when it exists, but an empty public profile doesn't mean a weak engineer. Most professional code is private.
- Engineers you've placed. They know who the strong people were on their last team. If they now work at one of your clients, ask for names and leave them where they are.
When you reach out, lead with the problem, the stack, the team and the range, so the engineer can decide in one read.
Why clients reject engineering submittals
When feedback comes back negative, sort it before you send the next candidate:
| Rejection reason | What it usually means | Fix before the next submittal |
|---|---|---|
| "Not senior enough" | Right years, smaller scope than the job | Re-check the candidate against the "will own" answer |
| "Too senior" | Candidate wants a lead or architect path the role doesn't offer | Ask the candidate where they want to be in two years |
| Wrong stack | A must-have was missing, or a nice-to-have was used as a filter | Re-sort the must-have list with the client |
| Wrong kind of systems | Right language, different domain or scale | Add system type and scale to the brief |
| Resume too vague | Lists technologies, not what they built | Rewrite the submittal around evidence |
| Above budget | Range and level don't match | Raise it with the client now, with data |
If three rejections in a row share a reason, stop sourcing and get the hiring manager back on a call before you send anyone else.
What evidence goes in an engineering submittal
Technical hiring managers read resumes looking for proof. "Strong Python developer" gives them nothing to check. Map each must-have to something the candidate has actually done.
Submittal template: must-haves mapped to evidence
Candidate: [Name], [current title] at [company], [location or remote]
Level fit: one sentence measured against the calibration paragraph.
| Must-have | Evidence from the candidate | How you checked |
|---|---|---|
| [Python services in production] | Example: four years building and running the order API at an online retailer | Screening call: walked through the design and its trade-offs |
| [Owns a service end to end] | Example: led the move of billing out of the monolith and owned it afterwards | Described a production incident and the fix |
| [On-call experience] | Example: one week in five on a team of five | Candidate's account, to confirm with a reference |
Gaps: what's missing and how they'd close it.
Why they'd move: one honest sentence.
Notice period and interview availability: dates.
Fill in the gaps line every time. Example: "Has used RabbitMQ, not Kafka. Read your post on the event pipeline and had good questions about it." Hiring managers trust the rest of the submittal more when you name the gap before they find it.
Check the pay before you start sourcing
A brief can be perfectly calibrated and still unfillable at the client's range. For US roles, the Bureau of Labor Statistics reports a median annual wage for software developers of $135,980 in May 2025, with the lowest 10 percent earning less than $82,460 and the highest 10 percent more than $214,670 (BLS Occupational Outlook Handbook, software developers, as of October 2026). The same page lists medians by industry, from $132,050 in computer systems design to $164,550 at software publishers.
A national median mixes every level, city and industry, so treat it as a sanity check, not a price. What it's good for is catching a mismatch early: if the worksheet describes someone who owns a system and carries the pager, and the range sits well below that median, say so at intake, not after the third rejection. Then ask about bonus and equity, because they change how a candidate reads an offer.
These figures cover jobs in the US. For roles in other countries, or remote roles based outside the US, they don't apply: work from the client's range, your recent placements and what candidates are telling you, and agree which currency the salary is paid in.
Fee notes for engineering searches
Engineering offers often include more than base salary, so agree in writing what your fee is calculated on before the first submittal. For the model and the percentage, see how to price a contingency or retained search.
Example: your agreement says 20% of first-year base salary. The client hires your candidate at $150,000 base, plus a $10,000 signing bonus and an equity grant.
- On base salary only: 20% × $150,000 = $30,000.
- If the agreement says first-year cash compensation, signing bonus included: 20% × $160,000 = $32,000.
- Equity: leave it out unless your agreement says otherwise. It's hard to value and easy to argue about.
- Monthly salaries: if the client quotes pay by the month, agree whether first-year base includes any 13th-month payment or extra pay periods.
Two engineering situations belong in your terms. Down-leveling: you submitted for the senior role and the client hires the candidate one level down at, in this example, $125,000. On a percentage of base, your fee follows what they actually pay, $25,000 here, so decide before the offer whether you accept that. And a candidate hired months later for a different team: your candidate ownership clause should cover any role at the client, not only the one you were briefed on. Agree the guarantee up front too; this guide on replacement, refund or pro-rata guarantees compares the options.
Engineering searches move faster when the hiring manager can read the submittal and answer in the same place, instead of forwarding a PDF to a tech lead and losing the thread. In the Recruiting ATS client portal you share candidates on the client's job, and the hiring manager can invite the tech lead from their own company. They see each profile and its current stage and reply in a thread with your team, which gets an in-app notification and an email. Current and expected salary and your internal notes stay on your side.