Verified against ChatGPT · 2026-08-09
Decode what a job posting is really asking for versus what it's just listing
Separates a job posting's actual must-have requirements from boilerplate padding and reads between the lines for what the posting's phrasing implies about team maturity, scope, and likely day-to-day.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I need you to decode a job posting, not summarize it. Job postings mix genuine requirements with boilerplate and sometimes signal things about the role that aren't stated directly — I want that separated out.
JOB POSTING
Senior Data Analyst — a newly created role reporting to the Head of Ops. Own reporting for a team of 40, build the first version of a metrics dashboard from scratch, present to leadership monthly. Nice to have: SQL, Python, Tableau, Looker, dbt, Airflow, stakeholder management, forecasting experience, familiarity with logistics...
WHAT I ALREADY KNOW ABOUT THIS COMPANY
They raised a Series B six months ago and I've heard from a friend there that ops is still fairly scrappy/undefined.
WHAT I'M UNSURE WHETHER TO APPLY FOR
I'm worried 'newly created role' means no infrastructure exists yet and I'd spend a year just building pipes instead of doing analysis.
Do four things with this posting:
1. MUST-HAVE VS BOILERPLATE. Separate the requirements into ones this specific posting seems to genuinely care about (repeated, given detail, tied to a named responsibility) versus ones that read as standard boilerplate every posting for this title includes regardless of the actual role ("strong communication skills," "bachelor's degree preferred"). Tell me which list each requirement lands in and why.
2. WHAT THE PHRASING IMPLIES BUT DOESN'T STATE. Read between the lines on scope and maturity — does the phrasing suggest this role is being created for the first time versus backfilling someone, does the listed responsibility list suggest one person is meant to cover work that's usually split across two roles, does an unusually long "nice to have" list suggest the team doesn't actually know what they need yet. Flag anything like this as an inference, clearly labeled as your read rather than a stated fact.
3. QUESTIONS WORTH ASKING IN AN INTERVIEW. Based on what's ambiguous or implied rather than stated, give me 3 questions that would clarify the gap, phrased the way I'd actually ask them in an interview rather than as generic "what does success look like" questions.
4. FIT CHECK AGAINST MY HESITATION. Given what I said I'm unsure about, tell me directly whether this posting's actual (non-boilerplate) requirements resolve that hesitation one way or the other, and say so even if the honest answer is that the posting doesn't give you enough to tell.
WHAT NOT TO DO
Do not just restate the posting's bullet points back to me in a different order — every line of output should add interpretation the posting itself didn't spell out, or it isn't worth including.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A job posting is written by whoever had time to write it — sometimes the hiring manager, sometimes recruiting, sometimes a template inherited from the last time the role was open — and its phrasing carries real signal about team maturity and scope that a plain summary discards by flattening everything into one undifferentiated bullet list. Splitting requirements into genuinely-emphasized versus boilerplate works because postings tend to give real weight (repetition, specificity, tie to a named responsibility) to what the hiring manager actually cares about, while requirements copied from an HR template read as generic and disconnected from the rest of the text — a model instructed to look for that contrast, rather than just listing every bullet at equal weight, surfaces a distinction a skimming human reader usually processes intuitively but couldn't necessarily articulate. The instruction to clearly label inferences as inferences rather than facts matters because this is exactly the kind of task where a confident-sounding model could present a guess ("this role is probably a demotion for someone") with the same authority as a directly stated fact from the posting, and a candidate making an application or negotiation decision needs to know which parts of the analysis are solid ground versus informed speculation. Generating interview questions from the ambiguous parts specifically, rather than generic culture-fit questions, is more useful because it turns the decode into something actionable in the actual interview — a candidate who asks "is this role backfilling someone or is the team splitting existing scope onto a new headcount" gets real signal back, while a generic "what does a typical day look like" question rarely surfaces the same information.
What you get back
Must-have (emphasized): 'own reporting for a team of 40' and 'build the first version of a metrics dashboard from scratch' — both tied to specific, named responsibility. Boilerplate: the six-tool 'nice to have' list reads as the team not yet knowing their own stack, likely inherited from a generic template. Inference (labeled as a read, not fact): a newly created role with an unusually long tool wishlist and a Series B six months ago suggests ops infrastructure is genuinely immature — your hesitation about spending a year on pipes rather than analysis is well-founded and worth asking about directly.
Verified against
ChatGPT GPT-5.1 · 2026-08-09
Changelog
- 2026-08-09 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
