How to Read a Tech Job Description

A job description is a weak signal, but it is still a signal

Most job descriptions are compromises. A hiring manager wants one thing, talent acquisition has a template, legal wants safe language, and the company wants to sound attractive. By the time those four interests have negotiated a paragraph, the advert reads as vague on purpose. The candidate's job is not to believe every line. It is to extract risk, scope and interview clues before investing the twenty to forty hours a serious application now costs.

The mistake most people make is reading an advert as a checklist of requirements they either meet or do not. That framing puts you on the back foot. A better framing is that the advert is a noisy transcript of a planning meeting you were not invited to. Somewhere in it are the real problems the team is trying to solve, the level they are actually hiring at, and the shape of the interview loop. Your task is to reconstruct those three things from the available evidence and decide whether the role is worth your time.

In 2026 this matters more because role names are changing quickly. "AI engineer", "product engineer", "platform engineer", "forward deployed engineer" and "LLMOps engineer" can mean very different work across companies. The same title at two firms can differ by a full seniority band and by half the day-to-day stack. Candidates increasingly ask for role-specific maps rather than generic prep, especially in AI, ML and data roles. Public evidence includes ML candidate discussions on r/MachineLearningJobs, Stack Overflow's 2025 AI survey, and AI hiring pages from OpenAI and Anthropic.

A useful habit: read the advert twice. The first pass for what they wrote, the second pass for what they left out. The gaps are often louder than the bullet points.

Decode level from verbs, not title alone

Titles are inconsistent. One company's Senior Software Engineer may be another company's mid-level engineer, and a startup's "Lead" may carry less scope than a large company's mid-level role. The verbs are far more honest than the title, because verbs describe behaviour the team needs and are harder to inflate without sounding absurd.

Read the responsibilities and map each verb to a level of autonomy and blast radius.

A few patterns are worth naming explicitly:

• If the advert says "senior" but the responsibilities are mostly ticket execution and learning the codebase, you are looking at level inflation. The pay band usually confirms it.
• If it says "mid-level" but expects architecture across services, on-call ownership, mentoring and cross-team leadership, that is level compression. You would be doing senior work at a mid-level title and salary, and a future internal promotion is the only path to fair pay.
• If the verbs span three levels at once ("implements features" alongside "sets technical direction across the org"), the team has not decided what it is hiring. Expect a confused interview loop and clarify scope before you commit.

The cleanest tell is the word "own". Ownership of an outcome (a service, a product surface, a reliability target) is a senior signal. Ownership of a task (a ticket, a component someone else specced) is a junior or mid signal. Count how often the advert hands you outcomes versus tasks.

Identify the real interview loop

Job descriptions often reveal what the interview will test, because the team writes the advert and designs the loop with the same picture of the job in mind. Translate requirements into likely rounds, then prepare for the rounds rather than the buzzwords.

This helps you avoid generic prep. If the role emphasises real-codebase work, practise reading unfamiliar repositories rather than grinding more algorithm puzzles. If it emphasises AI policy and evals, prepare examples around prompt iteration, retrieval quality and monitoring. HackerRank's article on real-world development skills, Wired's reporting on AI-assisted interviews, and Hacker News discussion of take-home modification interviews all show why the loop may no longer be "coding plus culture" only.

Worked example: turning an advert into a prep plan

Take a realistic, lightly edited advert for a product engineer at a Series B company:

We're hiring a Product Engineer to own customer-facing features end to end.
You'll ship to production multiple times a week, work directly with design and
PMs on ambiguous problems, and increasingly build AI-assisted features on top
of our model provider. You should be comfortable in a large TypeScript codebase
and care about measuring whether a feature actually moved a metric.

Read it as evidence, not prose. Here is the decode:

• "own customer-facing features end to end" plus "work directly with design and PMs" reads as mid to senior product engineering. The outcome ownership and the cross-functional verbs push it above junior.
• "ship to production multiple times a week" implies trunk-based or short-lived branches, feature flags, and an expectation that you operate what you ship. Expect debugging and an incident story in the behavioural round.
• "ambiguous problems" plus "measuring whether a feature moved a metric" signals a product-sense round. Prepare a story where you killed or changed a feature based on data.
• "AI-assisted features on top of our model provider" means application-layer LLM work: prompts, tool calling, evals, latency and cost. Not model training. Prepare to talk about how you would measure output quality, not how transformers work.
• "large TypeScript codebase" means a code-reading or debugging round in an unfamiliar repo is plausible. Practise orienting in a repo you have never seen.

From that, the prep plan writes itself: one product-sense story with a metric, one incident or debugging story, one LLM-feature story with an eval angle, and an hour navigating an open-source TypeScript repo cold. Far more targeted than "revise system design and do fifty LeetCode questions".

Read compensation and location wording carefully

Compensation clues are not always in the salary line. The line items around it carry as much information, and the legal jurisdiction often forces disclosures the company would otherwise omit.

Look for:

• Currency and location, which set the real baseline more than the number does.
• Equity wording: options, RSUs or the vaguer "equity available". Ask about strike price, vesting and the current preference stack for options.
• Bonus language: discretionary or target. "Discretionary" is not guaranteed compensation; "target" with a clear trigger usually is.
• Remote policy: country, region, hybrid cadence, and whether "remote" means remote-first or remote-tolerated.
• Contractor versus employee status, which changes tax, benefits and stability.
• Benefits jurisdiction, which tells you which country's pension, healthcare and leave rules apply.

Pay transparency rules vary by jurisdiction, and they change what you can expect to see before you ever talk to a recruiter.

Rely on the primary guidance above rather than social posts, which often overstate what the rules actually require.

Wide salary bands deserve a follow-up. A band of, say, fifty thousand from floor to ceiling usually spans more than one internal level. The right question is not whether the top is "real", it is how they decide where you land:

Could you share how this role is levelled internally and what would determine where a candidate lands in the range?

That question is more useful than asking whether the top of the band is achievable, and it signals that you understand how levelling works. For role-specific numbers to anchor the conversation, compare against a salary guide before you name a figure.

Spot red flags without becoming cynical

Red flags are prompts for questions, not automatic rejections. A single one rarely sinks a role; a cluster of them, or one that goes unanswered when you ask, is the real signal. Treat each as a hypothesis to test in the recruiter call.

Useful general red flags:

• "Must thrive in chaos" with no mention of delivery process. Sometimes honest, often a euphemism for missing structure.
• "Rockstar" or "ninja" language in a mature engineering advert, which suggests the template has not been updated or the culture leans toward individual heroics over teams.
• Many unrelated technologies for one role, which can mean either a genuine generalist need or one person expected to do three jobs.
• Senior scope with junior pay.
• Remote language that contradicts itself across the advert ("fully remote" in one line, "must be in office Tuesdays" in another).
• "Fast-paced" alongside weak or absent on-call and support detail, which hides operational load.
• No mention of the team, the manager, the product area or any success criteria.

AI-era roles carry their own failure modes:

• "Prompt engineer" with no coding, evals, data or domain requirements. Prompting alone is rarely a durable role.
• "AI engineer" that is actually a generic web role with a chatbot wrapper bolted on.
• "LLMOps" without monitoring, deployment, latency, cost or safety language, which means the operational substance is missing.
• "Forward deployed" without travel, customer ownership or delivery expectations, which suggests the team copied a label without the responsibilities.

Prompt engineering is being redefined as workflow engineering, not magic phrasing. The durable skill is designing reliable systems around models: retrieval, evaluation, guardrails and cost control. Reddit prompt-engineering threads and AI lab hiring pages both support that shift. See discussions such as people who landed prompt engineering work and current AI lab hiring pages from Anthropic.

Which words carry the weight depends on the role you are reading for

The same advert rewards a different reading depending on the role it describes. The load-bearing words, the phrases that actually predict the day-to-day, move around by discipline. Find the ones that match the role you want, and discount the boilerplate around them.

There is a second axis underneath the role, and it is not a rung on a ladder. It is how much of the advert you should trust to describe your actual week. If you are early in your career, weight the parts that describe the environment around you: whether senior engineers are named, whether the team ships small reviewable changes, whether mentoring reads as a real commitment rather than a benefits-page word. An advert with no senior engineers named anywhere is a development risk no matter how the tasks read. If you are further along, weight decision rights and on-call reality instead. The advert should make clear what you would be trusted to decide without sign-off, and what a typical week of pages actually looks like. Both readers are looking at the same page. They are underlining different sentences.

Turn the advert into interview questions

Before applying, write three reverse-interview questions drawn directly from the advert. The act of writing them forces you to read closely, and they double as questions you will actually ask. Examples:

• "The advert mentions ownership of production services. What is the on-call model for this team, and what is a typical week of pages?"
• "You mention AI-assisted development. What is allowed in day-to-day work, and what is allowed in the interview itself?"
• "The role spans backend and customer discovery. How is success measured after six months?"
• "The advert lists several stacks. Which are must-have on day one and which are learn-on-the-job?"

These questions protect your time and make you sound like someone evaluating fit rather than someone hoping to be chosen. That matters in a market where candidates report long loops, vague criteria and process fatigue. See Hacker News discussion of interview gauntlets and The Pragmatic Engineer's interview reality piece.

A quick checklist

When time is short, run the advert through six questions:

1. What level is this really, judged by verbs and ownership rather than the title?
2. What problems is the team trying to solve, and are they ones I want to work on?
3. What does the interview loop look like, decoded from the requirements?
4. What does total compensation actually include, beyond the headline number?
5. Which red flags are present, and which would I test in the recruiter call?
6. What three questions would I ask to confirm fit before applying?

If you cannot answer questions one through three from the advert at all, that is itself a finding.

FAQ

Should I apply if I only meet seventy percent of the requirements? Usually yes, if you meet the must-haves. Most requirement lists are wish lists assembled by several people, and the "5+ years of X" lines are filters, not laws. Weight the responsibilities over the requirements.

The advert has no salary. Is that a red flag? Not on its own, outside jurisdictions that mandate disclosure. It is a prompt to ask early. Get the band before the first technical round so you do not spend twenty hours on a role that cannot meet your floor.

How do I read a startup advert versus a big-company one? Startup adverts compress levels and lean on breadth, so expect wider scope and more ambiguity than the title suggests. Large-company adverts are more templated, so the verbs and the specific team description carry more signal than the boilerplate.

What if the advert and the recruiter say different things? Trust the recruiter call for current facts like on-call, remote policy and band, since adverts go stale. But note the contradiction. A team whose advert and recruiter disagree on something material may not have its story straight internally either.

Sources

• New York State pay transparency law, dol.ny.gov
• New York City salary transparency, nyc.gov
• UK increasing transparency for pay, promotion and rewards, gov.uk
• HackerRank, testing real-world development skills, hackerrank.com
• Stack Overflow 2025 Developer Survey, AI section, survey.stackoverflow.co

Where to take this next

Once the advert has told you the likely loop and the real questions to ask, the next moves are researching the team and pressure-testing the numbers:

• Researching a company before an interview
• Researching salary ranges before an interview
• How to pass the recruiter screen