Software engineer job description

Most software engineer job descriptions are a list of technologies, which is why most software engineer resumes are a list of technologies. The list is checkable in seconds and predicts very little. What predicts this hire is how somebody behaves inside code they did not write, under constraints they did not choose, with something already in production depending on them. Below is a description you can post, and four signals that look like evidence of that and are not.

The job description

We are looking for a software engineer who ships and then owns what they shipped. You will work in a codebase that already exists, on problems that arrive underspecified, alongside people who will review your work properly.

What you will do

Build and ship features end to end, including the unglamorous work around the edges
Change code you did not write without breaking what depends on it
Take part in incident response for the systems you own
Review other engineers carefully enough that the review is worth waiting for
Push back when a requirement does not survive contact with the system

What the job needs

Real depth in one language, plus evidence you have learned a second one properly
Testing, version control and deployment treated as part of your job rather than as another team responsibility
The ability to explain a technical trade-off to somebody who does not write code

Signals we weight heavily

You have inherited something ugly and decided not to rewrite it
You can describe a production failure you caused
You have argued for the smaller version and turned out to be right

What a software engineer is actually accountable for

Writing code is the part that gets taught and tested. The seat is accountable for changing a system other people depend on without breaking it, and for staying with what they shipped after it ships.

Shipping to production and living with what happens next
Leaving the codebase easier to change than they found it, which is rarely the same thing as rewriting it
Scoping down, so the version that answers the question ships before the version that is complete
Reading unfamiliar code well enough to make a safe change inside it
Being useful in review to engineers both more and less experienced than they are

Four ways a software engineer hire looks right and is not

Every one of these passes a resume screen. Ladders eye-tracking study timed the average initial scan at just 7.4 seconds, which is long enough to check the four signals below and not long enough to check anything that would contradict them.

Looks right

An active GitHub profile and open source side projects

Public repositories measure enthusiasm and available evenings. They are usually greenfield, solo, and free of the constraint that defines the job: changing code somebody else wrote, that customers depend on, without a rewrite and without an outage. It is a positive signal about interest and a weak one about the work.

Looks right

Excellent performance on the algorithm screen

These screens select for recent deliberate practice, and they are equally easy to pass with a month of preparation and to fail while distracted. They are a defensible floor. They say nothing about whether the candidate can open an unfamiliar service on day four and make a change that is safe.

Looks right

Several years at a company famous for engineering scale

At that scale the deploy pipeline, the observability, the on-call tooling and the review culture belong to another team entirely, and enormous amounts of judgement are embedded in them. An engineer who has only worked inside that has never had to decide what good enough looks like with no platform team standing behind the decision.

Looks right

A long list of languages and frameworks

Eight stacks on one resume usually describes a services background where each project ran a few months and nobody stayed long enough to maintain anything. Maintenance is where engineering judgement is formed. The signal worth weighting is depth plus one properly learned second language, not breadth.

What to ask for evidence of instead

Four questions, and what the answer actually tells you. Take these into your own process whether or not you ever talk to us.

Describe the last production incident you were part of. What was your change, and what did you change afterwards?: What it tells you: Engineers who ship and leave describe incidents in the passive voice. The ones you want remember their own contribution to it and can name the guard rail that exists now because of it.
Tell me about code you inherited that you decided not to rewrite.: What it tells you: The most reliable seniority signal available in an hour. Junior instinct is to rewrite. Experience is knowing what the ugly code is protecting against and what a rewrite would cost the roadmap.
Walk me through a design where you chose the simpler option. Were you proved right?: What it tells you: Listen for a real trade-off with a cost attached, not a preference for simplicity as a slogan. The best answers include a case where the simple choice was wrong and what it took to unpick.
What is the largest thing you have shipped where you also decided what not to build?: What it tells you: Separates engineers who execute a specification from engineers who negotiate one. In a small team the second is the difference between a quarter that ships and a quarter that slips.

How Continuity1 runs this funnel

The screening above is the job. These are the numbers it produces when a function owns it end to end, set against the published benchmarks for the same market.

1 in 3: Shortlisted candidates you meet who become the hire; Aligned engagements run nearer 1 in 2, distant ones nearer 1 in 10. The market takes about 180 applicants to make one hire, and that sifting lands on your team rather than ours.; Continuity1 tracked engagements
~3: Interviews your team sits in, per hire; Ashby puts technical roles at 17.6 interviews per hire across the whole process, up 52% since 2021. The rest of that load sits with the function, not with you.; Ashby talent-trends report
1 in 9: Accepted offers that ghost before joining; Indian employers report nearly 4 in 10 offers dropped. We lose 1 in 9.; nasscom community
95%: Offers that close inside your stated band; 20 of the last 21. A flat fee earns nothing from an inflated offer; a percentage of CTC earns more.; Continuity1 tracked engagements

Every brief becomes a success profile before sourcing starts, calibrated with the people who will manage the role. That calibration is the step most hiring skips, and it is why a shortlist either matches the job or matches the job advert.

You review a scored shortlist and make the calls. The filtering never lands on your calendar.

Share a role See the workings and the citations

Questions teams ask

Do we need to require a computer science degree?

Only if you can point at the specific work that needs it, which is usually systems, graphics or numerical work. Everywhere else it narrows the pool and filters on background rather than capability. Describe what the job actually needs and let the screening find it.

Take-home or live coding?

A short take-home reviewed by somebody who will actually work with them beats a long algorithm interview, as long as it is short enough that you would be comfortable getting it back the same evening. Long unpaid exercises select for candidates with free time, and the strongest people in the market decline them.

Should we insist on our exact stack?

Match the stack when the seat needs somebody productive in week one with nobody to lean on. Otherwise a strong engineer moves stacks inside a month, and stack matching is the filter most likely to lose you the best candidate in the pipeline.

How senior does this hire need to be?

Ask who is going to answer their questions. A team with nobody to review code cannot absorb junior engineers however good they are, and a senior hire who arrives with nobody to delegate to spends the year doing work they should have been handing on. The level is set by the team around the seat, not by the difficulty of the roadmap.