How to read a data job posting

Job postings are written by committee under time pressure, usually by copying an old one. They are a poor description of the job and a surprisingly good description of the organisation, if you know what to read for.

We have a dataset of 3,500 synthetic postings — data-job-postings — built from the patterns in real ones. Some of what follows came from staring at that shape.

The title tells you less than the responsibilities#

"Data Scientist" spans people who run SQL queries for a marketing team and people who train models on a research cluster. "Data Analyst" at one company is "Analytics Engineer" at another. Ignore the title; read the first three bullets under responsibilities. Those are usually written last-minute by the actual hiring manager and are therefore the truest part of the document.

If the first bullet is "build and maintain dashboards", it is a reporting job regardless of what the title says. If it is "partner with product to design experiments", it is a product analytics job. If it is "own our Airflow deployment", congratulations, you are on call.

Requirements are a wish list, and everyone knows it#

A posting asking for eleven technologies is not describing a person. It is describing the union of the tools in their stack, and no candidate has all of them.

The rough rule: the first two or three requirements are real, the rest are preferences. If you have those and a plausible route to the others, apply. The research on this is consistent and its practical consequence is: the bar for applying is much lower than the bar the document appears to set.

Two genuinely disqualifying signals: a specific domain expertise requirement in a regulated field, and a security clearance. Everything else is negotiable more often than you would guess.

Salary disclosure is informative even when absent#

In our dataset, roughly 18% of postings omit the band, and the omission is not random — junior and non-US postings hide it far more often. That pattern holds in the real market too, which means two things.

First, an average of the disclosed salaries runs high, so do not calibrate on it.

Second, and more usefully: a company that discloses a band has usually done levelling work. They have a compensation structure, they have thought about internal equity, and the negotiation will be about where you land in a range rather than what you can extract. That is a signal about the whole organisation, not just the pay.

The words that mean something specific#

"Wear many hats" / "startup mindset" — there is no data platform and you will build it. Genuinely good if you want that, miserable if you wanted to do analysis.

"Fast-paced environment" — deadlines are set without consulting the people doing the work. Not automatically bad; check what they say about planning.

"Data-driven culture" — appears in every posting including at companies where the CEO overrules the data weekly. Zero information content. What does carry information: whether they name a specific decision that data changed.

"Own the full lifecycle" — no separate engineering support. You will be doing ingestion, modelling, analysis, and the dashboard.

"Work with stakeholders to define requirements" — the requirements do not currently exist. This is either the most valuable part of the job or the most frustrating, depending on whether anyone senior backs you up.

"Modernise our data stack" — there is a migration in progress or overdue. Ask in the interview how long it has been in progress. The answer is diagnostic.

What tells you the team is organised#

Look for these in the posting itself:

• They name their stack specifically — "dbt on Snowflake, Airflow, Looker" beats "modern data stack".
• They mention testing, documentation, or data quality. This appears in a minority of postings, and where it does the team has usually been burned and learned.
• They describe who you work with rather than only what you build.
• The levelling is explicit — what distinguishes this level from the one above.
• They say what the first ninety days look like.

And what suggests otherwise: a posting for a "unicorn" who does engineering, analysis, ML and dashboards; a team of one; a stack that spans four cloud vendors; or a requirement list where the technologies contradict each other.

The questions that actually reveal the job#

Save these for the interview, and ask all of them:

1. "What did the last person in this role work on?" If the role is new, "what is the first thing you would want me to fix?"
2. "Walk me through what happens when a dashboard number looks wrong." The answer tells you whether they have monitoring, ownership, and a culture that permits saying so.
3. "How does a request get to the data team, and how is it prioritised?" No answer means no process, which means whoever shouts loudest.
4. "What is a decision that changed because of an analysis in the last quarter?" The single best question. A specific, vivid answer means the work matters. A vague one means it does not.
5. "Who is on call, and for what?"

The fourth one is the one I would keep if I could only ask one. Every organisation says it is data-driven. Only some can name the last time it was true.