Skills and requirements
Broken out by category — languages, platforms, practices, domain — and separated into what is required and what is merely wanted. The two attract very different questions.
Job description interview prep
Someone wrote down what they need, and someone else will be asked to find out whether you have it — usually from that same list. Read it properly and most of the interview is on the page before you walk in.
1 credit to analyse a description against your CV. Kept against the job, so once per role.
The five steps
Broken out by category — languages, platforms, practices, domain — and separated into what is required and what is merely wanted. The two attract very different questions.
Seniority, the shape of the team, and what the description accidentally reveals about the current problem. This is what decides whether you are asked to design something or to debug something.
Requirement by requirement: met, nearly met, not met. The middle column is the preparation. Reading your CV against it →
How to read one
None of these are in the text. All of them are in the way it was written.
Requirements are listed roughly in the order the team feels the pain. The first three are what they are short of, which is where the difficult questions and the follow-ups will be.
Generic bullets are inherited from the last posting. A line that names a system, a migration or a deadline was typed by someone with a problem this week — and that problem is the interview.
No mention of who you would report to, of how the work is reviewed, or of anyone to work with. Sometimes an omission, often a description of the team. Either way it is worth a question from you at the end.
“Mentoring”, “set direction”, “own the roadmap” mean the behavioural round carries more weight than the technical one, whatever the title says. Prepare accordingly.
Requirement to question
The pattern is reliable enough that you can do it by hand for any description in ten minutes.
| The line in the description | What you will be asked |
|---|---|
| “Experience with X at scale” | The largest X you have run, what broke at that size, and what you changed because of it. |
| “Comfortable with ambiguity” | A project that started without a spec, how you decided what to build, and what you got wrong. |
| “Partner with product and design” | A disagreement with a product manager, and how it ended. Not “we aligned”. |
| “Improve reliability” | A number before and a number after, and how you measured both. |
| “Mentor junior engineers” | One person, specifically, what they could not do at the start, and what they could do later. |
| “Own the move to …” | Something you owned end to end, including the fallback you prepared and whether you needed it. |
Doing it more than once
Interviewing is rarely one interview. Descriptions are kept so the work of reading one is not repeated.
Paste a description once and it is available to every session — practice and live — for as long as you are going after that kind of role.
A session records the description it actually ran with, so editing the library entry later does not quietly rewrite the history of an interview that used the old one.
Change the text and the old breakdown goes, deliberately: a stale analysis presented as current is worse than no analysis at all.
Then practise it
The breakdown tells you what is coming. The only way to find out whether you can answer it is to try.
Questions
Most of the technical ones, yes. A hiring manager writes the requirements and then an interviewer is asked to assess them, usually working from that same list. “Experience running a multi-site team” becomes “tell me about the sites you ran and what went wrong at one of them” in almost every case.
The first three requirements, and anything written in an oddly specific way. Generic bullets are copied from the last posting; a specific one — “comfortable taking over a region that has missed target for three quarters” — was written by someone with a current problem, and that problem is what the interview is about.
Yes. A vague description means the questions will come from the team rather than the page, so prepare breadth over depth, and prepare two good questions of your own for the end. Asking what the first ninety days actually involve gets you the information the description failed to give.
Prepare for the question underneath it, which is “why would you take this?”. An honest answer — the domain, the team, the hours, the step sideways you want — matters more than any technical answer in that round, and it is the one most people have not thought about.
It breaks the description into required skills by category and nice-to-haves, measures them against your CV so you can see where you are thin, and produces a bank of the questions that description invites. It is kept against the job in your library, so you do it once per role rather than once per interview.
No. Descriptions live in a library on your account: paste it once, and every session for that role — practice or live — can use it. Editing the text afterwards clears the old analysis, because an analysis of a description that is no longer the description is worse than none.
Read next
Ten minutes of reading it properly is worth more than an evening of general revision.
Create your account