How to prepare for an interview for a specific job

Most interview advice is generic because it is written before anyone knows which job you are interviewing for. But you do know. The job description is the closest thing to an exam syllabus you will ever get, and almost nobody reads it as one.

What follows is a procedure, not a list of tips. You can run it tonight for one specific role in about ninety minutes.

How do you prepare for an interview for one specific job?

Work backwards from the job description in four passes. First, decompose it: split every line into genuine requirements, nice-to-haves, and HR boilerplate, because you should not spend equal effort on all three. Second, map each real requirement to one concrete piece of evidence from your own history — a project, a decision, a number, an outcome. Third, plan your gaps: for every requirement where you have no evidence, decide in advance how you will answer honestly, rather than being ambushed into inventing something. Fourth, rehearse the five or six questions the job description makes near-certain, and prepare two or three questions of your own that prove you read it. The output is not a script. It is an inventory of true things you can reach for under pressure.

Step 1: Decompose the job description into real requirements

Job descriptions are usually written by at least two people — the hiring manager, who knows what the job needs, and HR or legal, who add padding. Learning to tell those apart is the actual skill here.

Read the description line by line and sort each item into three buckets.

Genuine requirements. These are specific, testable, and usually named: a language, a framework, a regulated domain, a team size, a measurable outcome. Signals: a hard number of years, a named tool, “you will own”, “day one”, or anything repeated in a different form later in the advert. Repetition is the strongest tell I know — if a responsibility appears both in the intro prose and in the bullet list, someone cared enough to say it twice.

Nice-to-haves. Signals: “is a plus”, “bonus”, “ideally”, “exposure to”, “familiarity with”. Note the difference between “familiarity with Kubernetes” and “strong Kubernetes experience” — the first is a request for orientation, not depth, and you should not over-prepare it.

Boilerplate. “Excellent communication skills”, “collaborative mindset”, “passion for”, “degree or equivalent experience”. These are not topics to prepare. Communication is assessed by how you answer everything else, not by an answer about communication. In practice, the “or equivalent experience” clause is what lets the degree line be waived.

One warning: the most important requirement is often not in the bullet list at all. It is in the one-sentence summary at the top — the line that says what the role exists to do. Bullet lists get copied between adverts; that opening line is usually written fresh.

If you want a fast first pass over the vocabulary, a job description keyword extractor will pull the named tools and terms out for you. Do the required-versus-padding sort yourself, though. That judgement is the part no extractor makes for you. If you would rather not lose the advert in the process — job pages expire, and you will want the exact wording again the night before — you can capture the advert off the page it lives on and keep it attached to the application.

Step 2: Map each requirement to evidence you actually have

Take your sorted list and give every genuine requirement exactly one owner: a specific thing you did. Not a skill claim — an episode with a beginning, a decision, and a result. Your CV (or resume, if you are applying in the US) is where the inventory starts, but it is deliberately compressed, so expect to recover detail from memory. If your CV has grown past two pages, it is worth seeing which sections are crowding out your evidence — a long profile paragraph or a skills wall usually costs you the specific episodes this exercise needs.

For each requirement write four lines:

1. The situation, in one sentence, including the constraint that made it hard.
2. What you specifically decided or built — not what the team did.
3. The outcome, with a number if you have a real one, and no number if you do not.
4. What you would do differently now.

That fourth line is the one people skip and interviewers value most. It is also your defence against the follow-up question, which is almost always “and what went wrong?”

If you need a structure to hold these in, the STAR method is the standard one and it works fine. The important part is not the acronym; it is that each requirement has a designated example so you are never searching your memory live.

When you finish, some requirements will have no evidence at all. Do not paper over them — that list is the most valuable output of the whole exercise. If you would rather see the mapping done against the actual text than build it by hand, you can see which requirements your evidence supports and start from the gaps.

Step 3: Decide how to answer your gaps — honestly, in advance

The moment that ruins interviews is not being asked about something you have not done. It is being asked about it unprepared, and improvising a half-claim that collapses two questions later.

So write the honest answer before the interview, in three beats:

1. Say plainly what you have not done. One clause, no hedging, no drifting into a different question.
2. Give the nearest true adjacent thing, concretely. The same class of problem, the same constraint, the same kind of responsibility.
3. Say how you would approach the real thing, specifically enough that it is clearly not a bluff — what you would read, who you would ask, what you would do first.

Worked out loud, for a payments role asking about PCI-DSS: “I have not worked in a PCI-scoped environment. The closest is a GDPR deletion pipeline I built, where I had to prove data was gone across three services and produce an audit trail an external assessor accepted. So I am used to designing to an auditable standard rather than to my own judgement. For PCI I would start by finding out exactly which systems are in scope, because that determines almost everything else.”

That answer costs you nothing. Being calibrated about your own experience is cheap to demonstrate and hard to fake; claiming everything is the opposite — it costs nothing to say and collapses on the second follow-up. The failure mode is inventing an example: unverifiable at the time, disqualifying afterwards.

A worked example: mid-level backend engineer

Here is a short, invented job description snippet — not a real advert — to show the mapping end to end.

Backend Engineer (Mid-level), Payments. You will work on the services behind our payments platform, owning features end to end from design through to production.

• 3+ years building backend services in Go or Java
• Experience with event-driven architecture (we run Kafka)
• Familiarity with Kubernetes and CI/CD pipelines
• Exposure to PCI-DSS or another regulated environment is a plus
• Excellent communication skills and a collaborative mindset
• Degree in Computer Science or equivalent experience

Seven lines in the advert, four things to actually prepare, one gap with a written answer. That is the whole point of the sort.

Step 4: Rehearse the questions the job description makes near-certain

You can derive most of the interview from the advert’s own wording. Apply these rules:

• Any named tool becomes a depth question: “how did you use it, and what broke?”
• Any verb of ownership — own, lead, drive, be responsible for — becomes a behavioural question: “tell me about a time you owned X.”
• Any stated constraint or scale — high volume, tight latency, small team, regulated — becomes a “how did you handle it under that constraint?” question.
• Any stated pain — “we are migrating off the monolith”, “we are building the team out” — becomes a forward-looking question: “how would you approach that here?”
• The opening summary line becomes the framing question: “what do you think this role actually involves?” — which is also, in practice, “did you read this?”

Five or six questions is the right target. Say the answers out loud, once, timed. Two minutes is long enough for almost any of them, and hearing your own answer is the only way to notice that beat three of your gap script sounds defensive. This is where an AI mock interview earns its place over reading notes: it asks the follow-up, which is the part you cannot rehearse against yourself.

Step 5: Prepare questions that prove you read the advert

Ask two or three, and derive them from the description rather than from a list of clever questions.

• Ask about something the advert implies but does not resolve. “The description mentions owning features from design to production — where does that boundary actually sit with the platform team?”
• Ask about the requirement that looks out of place. If a backend role asks for a regulated-environment background, something happened. Find out what.
• Ask what the first ninety days look like against the ownership claim. It tests whether “end to end” is real or aspirational.

Avoid anything answered on the careers page, and leave salary to the recruiter screen — in UK processes it is normally raised there, and asking a panel to negotiate is asking the wrong people.

Where SiviGen fits

SiviGen was built for the tailoring half of this problem: it parses your CV into individual facts and matches a job description against them, so the alignment is evidence-first rather than aspiration-first. Anything it writes is checked back against your CV, unbacked claims are flagged and gate the result, and it tells you which requirements went unmatched — which is exactly the gap list Step 3 depends on. The same machinery produces a cover letter you can defend, which matters here because a letter is read by the person who will interview you: every line in it is a question you have agreed to answer.

For the interview itself, SiviGen runs a voice mock interview grounded in that same fact graph and the specific job’s requirements, then scores the transcript and returns per-competency detail. Your spoken answers are not filtered or corrected — the readiness score judges what you actually said, because that is the only thing the real panel will hear.

FAQ

How long before the interview should I do this?

Do the decomposition and evidence mapping two to three days before, so your examples have time to settle, then rehearse out loud the day before. Doing it all in the hour beforehand produces memorised phrasing that collapses under a follow-up question. The mapping is the slow part; the rehearsal is short.

What if I do not meet all the requirements?

Almost nobody does, and job descriptions are routinely written as a wish list. Prepare the genuine requirements properly and write a three-beat honest answer for each gap: what you have not done, the nearest adjacent thing you have done, and how you would approach the real thing. Do not invent an example — that is the only version of this that ends badly.

How do I tell a real requirement from HR padding?

Real requirements are specific and testable: named tools, hard numbers, ownership verbs, or anything repeated in two places in the advert. Padding is generic and unfalsifiable: “excellent communication skills”, “passion for”, “degree or equivalent experience”. The single most important requirement is usually in the opening summary line, because bullet lists get copied between adverts.

How many examples do I actually need?

Fewer than you think. Four to six well-prepared episodes will cover most of a job description, because a strong example usually answers three or four different questions from different angles. Map them to requirements rather than to question types, then check that each one has an honest “what I would do differently” ending.

Should I memorise my answers?

No. Memorise the inventory — which example belongs to which requirement — and let the wording happen live. Memorised answers sound recited, and they break as soon as the interviewer asks the follow-up they were always going to ask. Saying each answer aloud once is preparation; saying it ten times is a script.

Can I prepare this way for a vague job description?

Yes, but the balance shifts. When the advert is thin, the opening summary line and the company’s own product carry most of the signal, and your prepared questions matter more because you are partly diagnosing the role during the interview. Prepare fewer examples and more questions.