What an Engineering Job Posting Tells You About the Team
An engineering job posting is written by people under time pressure, usually by assembling fragments from the hiring manager, a previous posting, and a template. That process leaks a lot of information about what the team actually has and what it’s actually struggling with.
Reading for those leaks is worth ten minutes before you spend an hour on an application. It tells you whether the role is what its title says, and which of your experience is the relevant part.
The requirements list is two lists badly merged
Nearly every technical posting contains a mixture of two different things: the technologies the team uses, and the technologies someone wishes the team used. They’re usually distinguishable.
Anything mentioned twice — once in the responsibilities and once in the requirements — is real and current. Anything appearing only in a long “nice to have” list may be aspirational, inherited from an old posting, or a single service nobody wants to own.
Ordering matters too. The first three requirements were written by the hiring manager thinking about the actual job. The last six were added to make the list look complete. If a stack you don’t have appears at position eight, it is very unlikely to be the reason you’re screened out.
Signals about the codebase
Named versions. A posting that specifies an older major version is telling you the codebase is on that version and probably not moving soon. This is neutral information — plenty of good engineering happens on old runtimes — but it predicts what your first year contains.
Two frameworks in the same layer. Both React and Angular in the frontend requirements usually means two applications, one of which someone will have to maintain. Same for two message brokers, or a posting that wants both Terraform and a configuration-management tool: there’s history in that stack.
“Modernise”, “consolidate”, “migrate”, “stabilise”. These verbs are the honest part of the posting. They name the work. A role described as modernising a legacy platform is exactly that, and the relevant part of your resume is your migration and upgrade experience, not your greenfield work. If most of your experience is that kind of work, when the work was keeping a legacy system alive covers how to make it read as a strength rather than an accident.
“Greenfield” with an existing product. Means one new service inside an existing system, which is a different job from what the word implies.
Signals about operational load
The clearest tell in any infrastructure-adjacent posting is how it treats on-call.
A posting that describes the rotation concretely — its size, its hours, the compensation arrangement — is from a team that has thought about it. A posting that mentions “participate in an on-call rotation” and nothing else, in a role otherwise described as feature development, is worth asking about early. A posting that says nothing at all about operations while describing a customer-facing distributed system has either a separate operations team or an unspoken expectation.
Related tells: mentions of incident response as a named responsibility, whether reliability targets appear at all, and whether the word “runbook” is present. Teams that write runbooks say so, because they’re proud of it.
Signals about the team’s shape
Team size, stated or implied. “Join a team of four” and “join our platform organisation” are different scopes and different resumes. What you emphasise should change: the small team wants evidence of breadth and autonomy, the large one wants evidence you can work inside someone else’s system and standards.
Whether the posting distinguishes levels. A posting that lists one requirements block for a range of levels usually means the team will calibrate you in the interview rather than from the page — which puts more weight on your scope statements. Scope, not years covers making those legible.
The presence of a specialism you didn’t expect. A backend posting that mentions data modelling three times is really a data-heavy role. One that mentions client SDKs is really a developer-experience role. The repeated noun is the job.
Signals to treat carefully
Not every reading is reliable, and it’s worth being explicit about the limits.
Absence of your technology proves nothing. Many teams hire for engineering ability and expect a language switch. A posting listing a language you don’t have is not automatically a no, particularly at senior level where the transferable part is the systems experience.
Boilerplate is boilerplate. Requirements about degrees, “excellent communication skills”, and years-of-experience ranges are frequently copied wholesale and applied inconsistently. Treat them as weak signals, not gates.
Postings vary enormously by company size and region. A small company’s posting is often written by the person you’d report to and reads accordingly; a large organisation’s may pass through several hands and describe a role generically. Norms about what gets stated — compensation, on-call arrangements, remote policy — differ by market too. Don’t over-read a posting written under conventions you’re unfamiliar with.
None of this tells you how the team is to work in. A well-written posting is evidence of a competent writer. That’s all.
What to do with the reading
Three practical outcomes, none of which involve rewriting your resume from scratch.
Decide whether to apply at all. Half the value here is filtering. A posting whose real content is “we need someone to own an unmaintained system alone, on call, with no operational tooling” is legible in advance, and applying to it because the title matched is how people end up in jobs they leave in six months.
Pick which of your systems leads. If the posting’s repeated noun is data modelling and you have a data-heavy project and a feature-heavy one, the data one goes first. This isn’t rewriting; it’s ordering.
Write down the questions. The gaps and contradictions you spotted — the two frameworks, the silent on-call, the aspirational third of the requirements list — are the questions worth asking when you get the chance. Asking about the two frontend frameworks is a better signal of technical seriousness than any question about culture, because it demonstrates you read the posting like an engineer reads a system.