What is a technical job description actually asking for?

What is a technical job description actually asking for?

A technical job description is asking for a person who can do one specific slice of engineering work, described in the vocabulary the team uses internally. The document rarely says that slice out loud. It says "5+ years of Java", "strong in distributed systems", and "experience with modern frontend frameworks", and it leaves the actual work, the system this person will own and the problem the team is stuck on, in the hiring manager's head.

That gap is what this module closes. The real spec exists. The hiring manager can state it, usually in one or two sentences, once the conversation reaches the work itself. Everything in the written req is a lossy translation of that spec, and a good share of it was copied from the last req the team opened, because writing a job description from scratch is nobody's favorite task and the old one was right there.

Reading a req well means running that translation in reverse. The technology names sort into shelves you already know. The team titles map to kinds of work. What remains is the module's territory: the stock phrases hiring managers reach for, the word "senior," the requirement list, the interview loop, the descriptions that describe nobody, and the pay structure underneath the offer. Each section below has a full lesson behind it.

What do the stock hiring manager phrases mean?

Hiring managers describe work in a compressed dialect, and the same phrases recur across companies. "Strong in distributed systems." "We are migrating off the monolith." "Mostly greenfield." Each phrase decodes into concrete work, and the decoded version tells you who to look for.

A monolith is an application built and released as one large piece. It is a normal design, and for many products the right one. "Migrating off the monolith" means splitting that one piece into separate services while customers keep using it, which is slow, careful surgery on a live system. A distributed system spreads its work across many machines, which creates failure modes a single machine never has. Each of these phrases narrows the search: the migration needs backend engineers comfortable changing systems in production, and the distributed-systems phrase points at people who have run software at real scale.

The dialect also encodes the age of the codebase. Greenfield work starts from an empty repository with no users and no prior decisions. Brownfield work changes a system that already exists and already has customers, which is most work at most companies. The two attract different people, because developers care about what they will spend their days touching. The full phrasebook, with each phrase decoded into searchable work, is in the hiring manager speak lesson.

What does senior mean at this company?

Senior means the scope of ownership a company trusts someone with, and the scope varies so much between companies that the word carries little meaning on its own. The useful question is always what a senior engineer owns here.

At a twenty-person startup, a senior engineer often owns whole systems end to end: they choose the stack, build the thing, run it, and answer for it. At a company with thousands of engineers, a senior engineer might own one well-defined service inside a large machine, with strong conventions around every choice. Both are real seniority. They are different specs, and a candidate shaped by one environment steps into the other with a real adjustment period. Seniority levels at big companies are formal ladders with defined expectations per rung, while startups hand out titles by feel.

Years of experience is the number reqs use as a proxy for all of this, and it is a weak proxy. Ten years maintaining one stable internal tool and four years building systems under heavy load produce very different engineers, and the four-year one is often the stronger hire. Depth comes from the difficulty of what someone worked on. The seniority lesson shows how to pin the word down to a scope the hiring manager will sign.

Which requirements are real?

A requirement is real when the work fails in week one without it. Those are the load-bearing lines, and a typical req has two or three of them buried in a list of ten.

The rest of the list splits into two piles. One pile is genuine preference: things the team would enjoy but can teach, which belong under nice-to-have and often get written as musts anyway. The other pile is sediment, lines copied from earlier descriptions that nobody has questioned in years. A req that demands five years of a framework that has existed for six is carrying sediment, and candidates notice, because it tells them the company writing it does not fully understand its own opening.

The reason the load-bearing pile stays small is that engineering skill transfers. An experienced engineer who knows one backend language reaches working depth in a neighboring one in weeks, because the hard-won knowledge, how to structure systems, how to find failures, how to work in a team's codebase, moves with them. Requirements written as specific tool names are usually preferences wearing a must-have costume. The sorting method, with the test for each line, is in the load-bearing lesson.

What does each interview stage test?

An engineering interview loop is a sequence of stages, and each stage exists to test one thing. A typical loop runs: a recruiter screen, a technical screen where the candidate writes code live, sometimes a take-home project, a system design conversation for senior roles, and a set of team and behavioral conversations. Coding stages test whether someone can produce working code under observation. System design tests whether someone can reason about how a whole product fits together, the architecture-level judgment senior scope requires. Team conversations test how the person communicates and collaborates.

Each stage also filters a predictable group out, and the filtering runs on more than skill. Live coding under a stopwatch resembles almost nothing in the actual job, and some genuinely strong engineers perform badly in that format while excellent interview performers can be ordinary on the job. A long take-home filters out people with full-time jobs and families, which describes most senior candidates.

This is why the req and the loop have to be read as one document. When the description promises architecture-level ownership and the loop tests puzzle-speed coding, the loop selects for a different person than the req describes, and strong candidates who clear the screen fail onsite for reasons nobody wrote down. The loop audit lesson walks each standard stage: what it tests, what it filters, and what a mismatch with the req looks like.

What makes a job description impossible?

The common cause of an unfillable req is stapling several jobs into one document. Frontend product work, infrastructure, and machine learning are three different disciplines, done by different people with different daily work. A description requiring years of depth in all three describes a person who exists in very small numbers and is rarely on the market. Recruiting has a name for this animal, the purple squirrel, and engineering reqs breed them by accumulation: each stakeholder adds a wish, nobody deletes, and the union of wishes describes nobody.

The stapling usually signals an unresolved decision. The team could not agree on which hire comes first, so the req contains all of them. That makes the fix a scoping conversation rather than a sourcing push: which discipline is load-bearing this quarter, which parts can an adjacent engineer pick up, and which belong to the next hire. An impossible req rewritten as its load-bearing core plus a genuine nice-to-have list starts returning candidates the same week.

The rewrite has a second payoff in reply rates, because the audience reading the description is fluent in it. Developers read reqs the way you read resumes, fast and pattern-matching, and a coherent one signals a team that knows what it needs. The rewrite lesson covers the diagnosis and the repair, with before-and-after examples.

What is engineering pay made of?

Engineering pay is built from base salary, equity, and sometimes a bonus, and the mix varies by company type. Base salary is the cash number and the most comparable part across offers. Equity is partial ownership in the company, granted over time, and it is where offers differ most. A bonus, where it exists, is usually a modest percentage of base.

Equity means different things at different companies. At a large public company it is stock with a market price, close to deferred cash, and often a third or more of total compensation at senior levels. At a startup it is a bet: potentially worth a great deal, potentially worth nothing, and priced accordingly by candidates. This is why a startup and a big company can compete for the same engineer with offers that look wildly different on paper. The candidate weighs a certain number against an uncertain one, and their appetite for that bet is part of why engineers move between company types at all.

Pay closes the loop back to the intake meeting, because a req scoped against the wrong band is unfillable no matter how well the rest of it is written. The market prices the load-bearing skills, the seniority scope, and the company's equity story together. The intake runsheet lesson puts the whole module into one working document: the questions that surface the real spec, the requirement sort, the loop audit, and the pay structure, so the meeting ends with a req the hiring manager signed and you can fill.