SwiftCover/ Guides/ How to Prepare for an Interview Using the Job Description
Applying & follow-up

How to Prepare for an Interview Using the Job Description

Updated 2026-08-31 9 min read Codevin Studio

Open the posting again and work it line by line. Every responsibility is a question the interviewer is likely to ask, every requirement needs one story ready in advance, and every vague phrase is a question you can ask back. That is the whole method.

Why the posting is the best prep document you have

Someone wrote that posting on purpose. In most companies the hiring manager drafted the responsibilities section or approved it bullet by bullet, because that list is how the role got justified internally before it was advertised. It is their own description of what the job does all day.

When that manager interviews you, they are working from the same understanding, often from a scorecard built out of the same list. The posting is not a marketing document that happens to describe a job. It is the outline of the conversation. Yet most people read it once, on the day they apply, and never open it again.

The posting is the closest thing you get to the interviewer's notes. Rereading it is not a trick. It is just paying attention.

The posting we will work from

Abstract advice about "preparing thoroughly" is useless, so here is a realistic excerpt. Everything below works this one example through end to end.

Job posting excerpt

Customer Success Manager — Aldergrove Systems. This is a newly created role reporting to our Director of Customer Success.

What you will do:

• Own a portfolio of roughly 40 mid-market accounts, from onboarding through renewal.
• Run quarterly business reviews with customer stakeholders, up to VP level.
• Act as the escalation point for at-risk accounts and build the recovery plan.
• Reduce time-to-first-value for new accounts. We currently sit at around 45 days.
• Partner with Product to turn recurring customer feedback into prioritised requests.

What we are looking for: 3+ years customer-facing at a B2B software company; comfortable reading product usage data; experience with Salesforce or a comparable CRM; excellent written communication.

Read it twice. The second read is where you notice what matters: the role is new, a number is attached to a named problem, and "escalation" is doing a lot of work.

Turn each responsibility into the question it implies

Take the bullets one at a time and write the question a competent interviewer would ask to test each. You are not guessing at trick questions. You are converting a statement about the job into a question about you.

What the posting saysThe question it implies
Own a portfolio of roughly 40 accounts"Walk me through how you manage a book of accounts. How do you decide who gets your time this week?"
Quarterly business reviews up to VP level"Tell me about a time you gave bad news to a senior stakeholder."
Escalation point for at-risk accounts"Tell me about an account you saved. Now tell me about one you lost."
Reduce time-to-first-value from 45 days"Where would you start if you wanted to shorten our onboarding?"
Partner with Product on feedback"Tell me about a time you pushed for a product change. What happened?"
Newly created role"What should this role have accomplished six months in?"

Six bullets, six questions, and you have covered most of a 45-minute conversation. Notice the fourth row: a posting that names a number and calls it a problem is telling you the manager has already been asked about that number by their boss. It will come up.

The last row is the one people miss. "Newly created role" is not filler. Nobody does this job today, the manager has a theory about why it should exist, and they are listening for whether your theory matches theirs.

Cross-check your list against one you did not write

Comparing your questions against a second list catches the angle you were blind to. SwiftCover generates likely interview questions from a posting you paste in, which works as that cross-check. Write your own first, though. Writing it is what makes you notice things like the 45 days.

Build one story per requirement, in situation, action, result

For each question you need one story you can tell in about ninety seconds — not a claim about yourself, but an actual thing that happened, with a beginning and an end.

The shape is situation, action, result. Situation is the setup and the stakes, kept short. Action is what you specifically did, in the first person singular. Result is what changed, with a number if you have an honest one and plain description if you do not.

Too thin to be useful

"I've handled a lot of at-risk accounts. I'm good at building relationships, so usually I can figure out what the real problem is and get things back on track. I saved a few big renewals last year that way."

Nothing there can be remembered or followed up on. The interviewer has learned only that you believe you are good at this. Now the same experience with the shape applied.

Situation, action, result

Situation. "Our second-largest account, about £180,000 a year, told us in January they were not renewing. Their champion had left, the new director had inherited a tool she had not chosen, and usage had dropped to two active seats out of thirty."

Action. "I asked for forty-five minutes with her, no slides, just to hear what her team was trying to do that quarter. They had been onboarded onto a workflow that no longer existed after a reorg. I rebuilt the account plan around the reporting she needed for her board, ran two training sessions for the new team myself, and set a fortnightly check-in against three metrics she picked."

Result. "They renewed in April at the same value and expanded by nine seats in the autumn. I wrote it up internally, because the same pattern — champion leaves, usage collapses within a quarter — had hit two other accounts that year. We started flagging champion departures as a risk trigger."

That answer shows the scale you work at, a method rather than a personality trait, a checkable result, and in its last lines it covers the "recurring feedback" bullet unasked. That overlap is the point: you need five or six stories that cover the grid between them, not one per bullet. Lay them out and look for holes.

StoryCovers
The £180k saveEscalation, recovery plan, VP stakeholder, feedback loop
Rebuilding the onboarding checklistTime-to-first-value, usage data, written communication
The account I lostEscalation, judgement, self-awareness
Weekly portfolio triage in the CRMPortfolio ownership, prioritisation, CRM
The feature request I got prioritisedProduct partnership, influence without authority

Prepare the failure story deliberately. "Tell me about one you lost" gets asked far more often than people expect, and it is where good candidates go vague.

Prepare the material, not a script

Memorising answers word for word makes you sound like you are reciting, and it collapses when a question arrives in an unfamiliar shape. Learn the five stories well enough to start any of them from the first sentence, then let the wording differ every time.

The requirements you cannot match

The posting asks for Salesforce. You have three years in HubSpot and have never opened Salesforce. One honest move handles this, and it works better than the alternatives anyway: name it, give the nearest real equivalent, and say how you would close the distance.

Answering an honest gap

"I have not used Salesforce day to day. Everything I described was run out of HubSpot, where I built the health-score view and the renewal pipeline our team worked from. The concepts transfer directly — objects, pipeline stages, reporting across a book of accounts — so it is the query logic rather than the interface that would take me a couple of weeks. I have started on the Salesforce admin modules in the meantime."

That beats a shaky yes, because it demonstrates the underlying capability and shows you have already started closing the gap. Never claim familiarity you do not have. Interviewers ask follow-ups, and being caught overstating a tool costs you the interview, not one answer. The same structure works for a missing years-of-experience number or an unfamiliar industry.

Our guides on tailoring your resume to a job description and reading a posting for its real keywords cover which requirements are load-bearing and which are wish-list padding.

Build your questions out of what the posting leaves vague

At the end you get asked whether you have questions. The good ones are already in the posting, hiding where it goes quiet or imprecise. Reread it looking for what it does not say.

Questions drawn from this posting

"The role is newly created. What is happening to this work today, and what made now the right time to hire for it?"

"You mention around 45 days to first value. Do you know where that time actually goes — is most of it your side, or waiting on the customer?"

"Roughly 40 accounts: how is revenue spread across them? Forty similar accounts and forty where five dominate the number are very different jobs."

"The posting does not mention renewal targets. Does this role carry a number, and how is it measured?"

Each is anchored in a specific line, so asking it shows you read the posting closely. They also get you real information. If nobody has decided the answer to the last one yet, you have learned something important before accepting.

One rule keeps this from backfiring: never ask what the posting already answers. Asking who you would report to, when the posting names the Director of Customer Success, is worse than asking nothing.

The one page you take in with you

Compress all of it onto a single sheet the night before. Nobody minds a candidate with notes, in person or on video. It reads as preparation.

  • The responsibility bullets, in the posting's own words, down the left.
  • Beside each, the two-word name of the story you will tell for it.
  • Your five story titles, with each opening line written out in full. The first sentence is the only part worth having on paper.
  • Your honest-gap answer, one line.
  • Four or five questions to ask back, in priority order, since you may only get to two.
  • Names and titles of everyone you are meeting.

Read it an hour before, then turn it face down. The value was in building it. Afterwards, note which predicted questions came up: posting-derived questions recur across companies, and your grid sharpens with every interview. Then write the follow-up while the detail is fresh, since the specifics you picked up in the room are what make that email worth sending. We cover what belongs in it in the guide on the thank-you email after an interview.

Common questions

How long before the interview should I do this?
Two sessions beat one long one. Do the posting breakdown and the question list two or three days ahead, so your stories have time to surface; the better example usually arrives while you are doing something else. Then spend thirty minutes the night before building the one-page sheet and saying each opening line out loud once. Cramming on the morning produces recitation rather than recall.
What if the job description is vague or full of boilerplate?
Work from whatever is specific and treat the vagueness itself as material. If a posting says only "manage stakeholder relationships and drive results", the detail has to come from elsewhere: the company's product pages, recent announcements, and the public profiles of people who already hold that title there. Then bring more questions than usual, because a vague posting often means the role is genuinely undefined.
What if they ask about a responsibility I have no story for?
Say so plainly, then give the nearest real thing. "I have not run a formal quarterly business review, but I presented renewal cases to my own leadership every quarter, and here is how I structured those." Interviewers are generally fine with an honest adjacent answer and rarely fine with a padded one. Inventing an experience usually unravels on the second follow-up question.
Should I bring a printed copy of the job description?
Yes, and annotate it. A marked-up posting on the table signals that you took the role seriously, and it gives you somewhere to look when you need a moment to think. Use it as a checklist, not a script: glance down between questions to see which bullets have not come up, and steer a later answer toward one of them.