What Job Descriptions Actually Ask For
Read the requirements block of a posting and you'll find tools, years and a degree. Sit the interview and almost nothing you're asked comes from there. The questions come from the part most candidates skim on the way to the salary range: the paragraph describing what the person in this job does all day.
Quick Answer
- What candidates optimize for: the requirements block — tools, years, credentials. That block exists to filter a pile of applications, and most of it is resolved before you meet an interviewer
- What gets questioned: the responsibilities — each line is work someone needs done, and work can be asked about from four different angles
- The asymmetry: a tool line yields roughly one question. A responsibility line yields a family of them, each with follow-ups
- Where questions come from: standard practice is to identify the competencies a job requires, then write questions against each one — against an analysis of the role, which is the same work the responsibilities block describes
- What this article is not: a study. No transcript dataset, no proprietary sample. The numbers below are from named published sources; the derivation is a worked example you can repeat on your own posting
What This Is, and What It Isn't
Search for what employers ask about in interviews and you'll be handed percentages: what share of interviewers probe teamwork, how many seconds a decision takes, which skill tops the list this year. Follow the citations and a lot of them end at another blog post that also has no citation.
So, plainly: there is no dataset behind this piece. We don't hold a corpus of interview transcripts, and anyone who claims one should be asked to show it. What we do have is a structure — a job posting is assembled out of parts written by different people for different purposes, and those parts behave very differently once you're in the room. That structure is checkable. You can run the derivation below against your own posting and see whether it holds.
Where a number appears it comes from a named, dated source, with its scope stated underneath — two of them are surveys of employers hiring early-career graduates. Nothing gets generalized into a percentage of postings, because that would need the dataset this article just said it doesn't have.
The Three Blocks of a Posting
Almost every job description is three documents stapled together, and they were not written by the same person.
The pitch. Mission, growth, benefits, the sentence about being a fast-paced team. Written or heavily edited by marketing. It carries almost no interview content, with one exception: it tells you the language the company uses about itself, which is worth borrowing when someone asks why you want to work there.
The requirements block. Years, tools, credentials, the nice-to-haves. This exists to reduce an unmanageable pile of applications to a reviewable one. It's often assembled from a template for the level rather than written fresh, which is why so many of them ask for a suspiciously round number of years.
The responsibilities block. Headed "What you'll do", "In this role you will", or just a list of verbs. This is the closest thing in the posting to the internal requisition — the description of the hole in the team the hiring manager is trying to fill. It is the part that turns into questions.
| Line in the posting | Why it's there | What it produces in the interview |
|---|---|---|
| "5+ years in a similar role" | Application filter, usually set by the level rather than the work | Confirmed on the phone screen; rarely revisited afterwards |
| "Proficient in Salesforce and SQL" | Filter, plus a genuine tool dependency | One verification question, occasionally a short exercise |
| "Bachelor's degree or equivalent experience" | Policy text, often inherited from the template | Usually nothing at all |
| "Own renewal and expansion for a book of accounts" | Describes the actual work | Prioritization, judgement, a behavioral example, a metric question |
| "Partner with Support and Product on recurring issues" | Describes the work, and where the friction lives | Stakeholder and conflict questions — often from a peer interviewer |
| "Comfortable with ambiguity", "strong communicator" | Competency language, sometimes lifted from a framework | Behavioral questions, plus a running unscored judgement of you |
Why the Requirements Block Runs Out of Questions
Three separate reasons, and they compound.
Most of it is settled before you arrive
Years of experience, work authorization, notice period, salary expectations: a recruiter verifies these on the phone screen, which is exactly what that call is for. Whoever interviews you next is reading a summary that already says you clear the bar. Re-arguing your seniority in the room answers a question nobody asked.
A tool question has a ceiling
"Do you work in SQL?" "Yes." "Window functions, CTEs?" "Regularly." That thread is finished in two exchanges, because there's only so far it can go before it stops being an interview and becomes a test. What comes next is a responsibility question wearing tool clothing — "tell me about an analysis you ran that changed a decision" — and what gets scored is the decision, the stakeholder who didn't want to hear it, and whether you checked your own numbers. The tool is the setting, not the subject.
The requirements line is loosely coupled to the decision
The clearest published evidence that the coupling is loose concerns degrees. When large employers announced they were dropping degree requirements from their postings, researchers went looking for the corresponding change in who actually got hired.
Source: The Burning Glass Institute and Harvard Business School, Skills-Based Hiring: The Long Road from Pronouncements to Practice, 14 February 2024; figures as reported by Carolyn Crist, HR Dive, 20 February 2024.
Read that narrowly, because it's a narrow finding: degrees, not tools or years, and hiring outcomes rather than interview questions. What travels is the mechanism. The requirements block could be rewritten at scale without the selection process changing much, which tells you the two are only loosely attached. Treating that block as a preview of the interview assumes a tightness that isn't there.
What Employers Say They're Screening For
Employers get surveyed about this constantly, and the answers are consistent enough to be boring. The National Association of Colleges and Employers asked its members what they want to see on the resumes of graduating candidates: evidence of teamwork, problem-solving and communication, with technical skills, work ethic and analytical ability behind them.
The more useful part is what they said about proving it. Listing the skill doesn't count — NACE puts it bluntly: listing the skill is not enough, employers want to see examples — and employers named the top way to demonstrate those skills in preparation for interviews as planning to share examples and situations where you used them to solve problems.
Source: National Association of Colleges and Employers, Job Outlook 2026 Spring Update, surveyed 12 February – 17 March 2026, 185 respondents (142 NACE employer members, 43 nonmember companies). Scope: employers recruiting the Class of 2026 into entry-level roles. The quoted line is from NACE's announcement of those findings.
That's a behavioral interview described from the other side of the table. The employer isn't asking for a skill inventory; they're asking you to arrive carrying situations. And the move toward assessing skills rather than credentials shows up in the same body of research: almost 70% of respondents to NACE's Job Outlook 2026 survey said they use skills-based hiring.
Source: National Association of Colleges and Employers, Job Outlook 2026, data collected 7 August – 22 September 2025. Same early-career scope, and a separate survey from the Spring Update above.
So where does the question list itself come from? For structured interviews, the method is documented. The US Office of Personnel Management's guidance states that "research shows interview questions based on specific job competencies identified through job analysis as being critical to job success demonstrate high levels of validity, rater reliability, and rater agreement", and describes the most structured version as asking every applicant the same predefined lead and follow-up questions, scored against benchmarks of proficiency.
Source: US Office of Personnel Management, Structured Interviews, assessment and selection guidance, accessed September 2026.
Be fair about the limits of that. It describes how a well-built interview is supposed to work, and plenty of interviews aren't built at all. An unstructured interviewer improvises — but improvises from their own mental model of the job, which is the same place the responsibilities block came from. Structured or not, the source material is the work.
The Four Questions Every Responsibility Generates
Take any line from a responsibilities block and there are four distinct angles on it. They test different things and they fail for different reasons, which is why interviewers use more than one on the same responsibility.
- Capability. "How would you approach this?" Tests whether you've thought about the work at all. Answerable without having done it, which is why it's rarely the only one asked.
- Evidence. "Tell me about a time you did this." Tests whether you actually have. This is where a STAR-structured answer earns its keep, provided the result is genuinely yours.
- Failure. "When has that gone wrong? What did you miss?" Tests whether the experience is real. A rehearsed story has a clean arc and no dead ends in it, and the absence of dead ends is the tell.
- Measurement. "How would you know it was working?" Tests whether you own outcomes or activity. Most candidates are thinnest here, because it's the one angle you can't answer with a story.
The line: "Run the quarterly planning process with Engineering and Finance."
What it generates
- Capability: "How would you structure that process in your first quarter here?"
- Evidence: "Tell me about a planning cycle you ran. What did you change from the previous one?"
- Failure: "When did a plan you'd already agreed fall apart mid-quarter? What had you missed when you wrote it?"
- Measurement: "How would you know your planning process was working, rather than just happening?"
Four questions out of nine words, before anyone asks a follow-up. Now compare that with what "proficient in Jira and Excel" can sustain.
One Posting, Line by Line
Here's the derivation on a realistic posting. Every question below comes from a line in it. Nothing comes from a question bank.
"Customer Success Manager, Mid-Market. You'll own renewal and expansion across a book of roughly 40 accounts, run quarterly business reviews with customer executives, and partner with Support and Product to get recurring issues fixed. Requirements: 4+ years in customer success or account management, experience with Salesforce and Gainsight, comfort working with product usage data, bachelor's degree preferred."
What the requirements block yields
- "How many accounts have you carried, and what size were they?" — one exchange, and the recruiter has probably had it already.
- "Which CRM did you work in, and did you build your own reporting or did someone hand it to you?" — one, maybe two.
- The degree line: nothing. Nobody is going to ask.
What the responsibilities block yields
- From "own renewal and expansion across roughly 40 accounts": How do you decide which of forty accounts gets your Tuesday? Tell me about a renewal you thought was safe and wasn't. What's your leading indicator that an account is drifting? What did you change after your first bad quarter?
- From "run quarterly business reviews with customer executives": Walk me through how you structure a QBR. Tell me about one that went badly. How do you handle a sponsor who sends a deputy every time?
- From "partner with Support and Product": How do you decide what's worth escalating? Tell me about a time Product said no and the customer still needed an answer. This one usually gets asked by someone from Support or Product, who is scoring how expensive you'll be to work with.
"Not support ticket volume — that goes up when people still care. The two I watch are whether the person who sponsored us is still in the room, and whether usage inside the team that actually does the work has gone flat while seat count hasn't moved. Concretely: if the sponsor sends a deputy twice in a row and core-team usage is flat quarter on quarter, I treat the renewal as at risk about ninety days early and go and find a second sponsor. The conversation you don't want to be having for the first time is the renewal conversation."
Why it scores
It names a signal it rejects and says why, gives a threshold instead of a sentiment, and ends on the action. Notice that Gainsight never comes up. The tool was in the requirements block; this answer is entirely about judgement from the responsibilities block.
Count what happened here. The requirements block — four lines, and the bulk of what a candidate rereads — supported two or three exchanges. Three responsibility lines supported nine questions, each opening onto follow-ups, and one arrived with its own interviewer attached. That's this posting, not a statistic about postings in general. Run it on yours.
Doing it properly is an evening's work, and almost none of the evening goes on listing questions. It goes on writing answers you can still defend at the third follow-up. Our guide to preparing from the job description walks through the markup pass; if you've been strong on paper and losing interviews anyway, why interviews fail covers what a requirements-first approach costs you in the room.
How to Read Your Own Posting
The markup pass takes about fifteen minutes, and it changes what you spend the rest of your preparation on.
If the posting is genuinely thin — three bullets and a benefits list — read the company's other openings for the same team, and ask the recruiter what this person will own in their first quarter. That question usually gets answered, and the answer is a responsibilities block.
If you'd rather see the derivation done before you start editing it, that's what an interview question generator working from the job description is for. The judgement it can't replace is the one this article is about: knowing which lines were written to filter you, and which were written to describe the job.
Frequently Asked Questions
What skills do employers ask about in interviews?
Mostly the competencies attached to the job's responsibilities: how you plan, decide, handle conflict, recover from a mistake and measure whether something worked. Tools and software usually get one verification question. Published survey research on early-career hiring points the same way — employers ask for worked examples, not skill lists.
Do interviewers ask about the tools listed in the job description?
Yes, briefly. Expect a question confirming you have used them and at what depth. What follows is usually a responsibility question with the tool attached: not "do you know SQL" but "tell me about an analysis that changed a decision". The analysis is the part being scored.
Does the "5+ years of experience" line get tested in the interview?
Rarely. Years of experience is an application filter, and a recruiter normally confirms it on the phone screen before you meet anyone who will interview you. By the time you are in the room that box is ticked, and almost nobody re-examines it.
Which part of a job description should I prepare from?
The responsibilities block — the "what you will do" list. It sits closest to the actual requisition, it describes work someone needs done, and every line in it supports several questions: how you would approach it, a time you have done it, when it went wrong, and how you would measure it.
Why do interviewers ask about competencies instead of technical skills?
Because a technical skill can be verified from a resume, a test or one question, and judgement cannot. Structured interviewing identifies the competencies critical to the job, then writes questions to elicit behavior against each one. The US Office of Personnel Management's guidance describes exactly that process.
How many interview questions can one responsibility generate?
Four angles each, before follow-ups: how would you approach this, tell me about a time you did it, when has it gone wrong, and how would you know it was working. Three responsibility lines can carry an entire hour of questioning between them.
What should I do if the job description is vague?
Work from what it does say, fill the gaps with the company's other postings for the same team, and ask the recruiter what this person will own in their first quarter. Even a thin posting usually names two or three responsibilities. Those are enough to start from.
Next Steps
The requirements block got you the interview. It has no more work to do. Everything from here is the responsibilities — what the work is, what you'd do with it, when you've done it badly, and how you'd know it was going well.
That's reassuring if you've been anxious about a tool you half know or a year of experience you're short. It's uncomfortable if your preparation so far has been a list of technologies with a confidence rating beside each.
Related resources: How to Prepare Using the Job Description | The STAR Method | Phone Screen Interview Tips