Software Engineering · Chapter 1 of 31
What a software engineering job description now asks for
AI in 89%. Product sense in 84% — higher than distributed systems at 75%. Mentorship in 43%.
Software engineering is the largest category in this atlas at 2,609 postings, and the full text of 659 of them produces a ranking that has moved a long way from ‘write good code’.
A correction, and the method behind these numbers.
This chapter previously stated mentorship at 87% and argued it outranked distributed systems. That figure could not be reproduced, and it is now 43%.
The pattern that produces 43% is the plain one — a posting counts if it says mentor or coach. Reaching 87% requires also counting junior and grow, which fire on ‘grow our business’ and on any posting that lists a junior role. A pattern chosen because it produces the number you expected is not a measurement, so the narrower one is published and the argument changed with it.
Every corpus figure on this site is now listed in tools/20_figures.py with the pattern that computes it, and re-checked on every build. The audit result is on the about page.
Two live caveats on the numbers above. The AI figure is a bare word match, so it counts ‘we are an AI company’ in a header — read it as how often the word appears, not how central AI is to the role. And term frequency measures mention, not importance: testing at 9% reflects what employers bother to write down, not what the job requires.
What each of those actually means
- AI at 89% is mostly not an AI job. It means using AI tools in the work, shipping a feature that calls a model, or a boilerplate paragraph. Read the responsibilities rather than the count. But the direction is unambiguous, and being unable to say how you use these tools and where you do not trust them is now a visible gap.
- Mentorship at 43% is higher than it looks. Nearly half of postings name it explicitly — for something almost nobody is taught and almost nobody prepares an answer for, that is a lot. And the figure understates the reality, because above mid-level you are hired partly for what you make the people around you capable of whether or not the posting says so. Have a specific person you grew, not a claim that you enjoy mentoring.
- Product sense at 84% beating distributed systems at 75% is the finding. The market is buying engineers who can decide what to build, not only how. That is the single biggest gap between how people prepare and what is asked.
- Testing at 9% is not permission to skip it. It is assumed rather than absent — nobody writes ‘must write tests’ any more than they write ‘must use version control’. But it does tell you that describing your testing discipline is not a differentiator; demonstrating judgement about what deserves a test is.
Reading a job description accurately
The term frequencies above tell you what the market writes down. They do not tell you what any single posting means, and postings are written by several people with different intentions.
| Section | Who wrote it | How much to weight it |
|---|---|---|
| The one-line summary | The hiring manager | Heavily. This is the only part usually written by the person you will report to |
| 'What you'll do' | Hiring manager, lightly edited | Heavily. The verbs are real: 'build' and 'own' and 'partner with' describe different jobs |
| 'What we're looking for' | Recruiting, from a template | Moderately, and treat the year counts as a filter setting rather than a requirement |
| The long technology list | Accreted over several postings | Lightly. A list of twelve technologies usually means the team uses four and nobody pruned |
| 'Bonus points' | Whoever wanted it there | Read this one closely. It is often where the actual differentiator hides, because it was added deliberately by someone with a specific gap in mind |
What the term frequencies do and do not support
Term frequency measures mention, not importance, and this cuts both ways.
A word appearing in 89% of postings can still be boilerplate — the AI figure is a bare word match, so it counts ‘we are an AI company’ in the header.
And a word appearing in 9% of postings can be central to the job — explicit testing language is rare in postings and universal in practice. Nobody writes ‘you must write tests’ because it is assumed.
So the useful reading is comparative, not absolute. That mentorship and product sense outrank distributed systems is informative about what employers choose to emphasise. That testing sits at 9% tells you about posting conventions, not about the job.
The corresponding preparation error is optimising for the highest-frequency term. Everyone does that, which is precisely why it does not differentiate.
The practical consequence for how you prepare: the things named in almost every posting — a language, system design, cloud — are table stakes; being good at them keeps you in the process and does not win it. The things that win are usually in the 'bonus points' section or absent from the posting entirely: how you behave when the design is wrong, whether you can cut scope, and whether people want to work with you again.
Check yourself