From A Job Description To A Grading Rubric

A job description analysis turns a posting into three things: the topics you will actually be asked about, the verified facts behind those topics, and a grading rubric that scores your spoken answers. The posting is the raw material. The interview rubric is the finished product, and the gap between them is where most preparation falls apart, because candidates study the words on the page instead of the competencies the words point to.

Here is the short version. A good job description names a role, a level, a set of responsibilities, and a set of requirements. Each of those maps to a topic. Each topic maps to one or more questions an interviewer would plausibly ask. Each question maps to a set of facts that a strong answer must get right. Turn all of that into a checklist of what a complete, accurate, well structured answer contains, and you have a rubric. That is what interviewers carry in their heads. The work of preparation is making it explicit.

What interviewers actually look for

Structured interviews predict job performance far better than the unstructured kind. The classic Schmidt and Hunter meta-analysis put structured interview validity at 0.51 against 0.38 for unstructured, and a 2022 reanalysis by Sackett and colleagues widened the gap to roughly 0.42 versus 0.19. The reason is consistency: every candidate gets comparable questions scored against a fixed standard. Around 72% of companies now run structured interviews to cut bias.

The takeaway for a candidate is that the interview already has a rubric. The interviewer has a list of competencies and a scoring guide. Your job is to reconstruct it before the call, so you answer the real evaluation rather than a vague memory of the posting.

Step one: extract topics from the posting

Read the job description as a structured document, not prose. Pull out:

• The core responsibilities ("own the data pipeline," "lead incident response"). Each is a topic you will be asked to prove.
• The required skills and tools (a specific framework, a query language, a cloud platform). Each is a candidate for a technical or scenario question.
• The level signals ("senior," "lead," "manage a team of"). Level changes the bar. A senior role expects you to talk about trade-offs and other people's work, not just your own tasks.
• The domain context (the industry, the product, the scale). This is where generic prep gets exposed, because it cannot be guessed.

A useful discipline is to rewrite each line as a question. "Experience scaling distributed systems" becomes "Tell me about a system you scaled and what broke first." That single move converts a requirement into a rehearsable prompt.

Step two: verify the facts behind each topic

This is the step almost everyone skips. A topic is only useful if the facts under it are real. If the posting mentions a specific platform or a named methodology, you need to know what it actually is, how it is currently used, and what a practitioner would expect you to say about it. Pulling this from a model's memory is risky, because training data has a knowledge cutoff and models will fill gaps with confident, plausible, wrong detail.

Grounding the research in live sources fixes this. Look up the real company, the real team, the current state of the tools named, and recent public detail about the role. Then run a second pass over your own notes and strike anything you cannot confirm from a source. If a claim is interesting but unverifiable, treat it as a lead to ask about, not a fact to assert. An interviewer needs only one follow-up question to expose a fabricated metric, so an answer built on invented specifics is worse than no answer at all.

This verify-then-strike loop is the core of how Mythic Intel builds a room from a pasted description: it researches the exact role on the live web, then does a second verification pass that removes anything public sources do not support, so the questions and the rubric rest only on facts that hold up.

Step three: turn topics and facts into spoken questions

Each verified topic becomes one or more questions, phrased the way they would be asked out loud. Mix the types deliberately:

• Behavioral: "Describe a time you..." These reward structured storytelling, the STAR shape (Situation, Task, Action, Result), with a measurable result at the end.
• Technical or scenario: "How would you design..." or "What happens when..." These reward correct facts and clear reasoning.
• Role-specific: questions only someone who studied this exact posting and company could anticipate.

Phrasing matters because you will answer these out loud, and spoken answers fail differently than written ones. They ramble, lose the thread, and bury the result. Practicing against the literal spoken question trains the muscle you actually use in the room.

Step four: write the grading rubric

The rubric is the scoring guide an interviewer would use, made explicit. For each question, define what a strong answer must contain across a few dimensions:

• Accuracy: are the technical and factual claims correct, matching what a verified source says?
• Completeness: does it cover the parts of the question the interviewer cares about, with no gap?
• Structure: does it follow a clear arc the listener can track, rather than wandering?
• Proof: is it backed by a specific example, a number, a real outcome, rather than an assertion?

A fact-locked rubric is the difference between "that sounded good" and a defensible score. It is exactly what a structured interviewer carries, and rebuilding it before the call is what separates a candidate who prepared from one who only read the posting.

So before any interview, do the cheap version of this by hand: break the description into topics, verify the facts you can, write the questions, and define what a full answer needs. Then say each answer out loud, score it against your own rubric, and fix the weakest one. The difference between rehearsing on paper and rehearsing aloud is the difference between knowing your answer and being able to deliver it under pressure.