Most People Prepare for Interviews Backwards

Search for interview preparation advice and you will very quickly end up with a list.

“50 interview questions you need to prepare for.”

So people do.

They write an answer for leadership.

Another for conflict.

Another for failure.

Another for strengths.

Another for weaknesses.

Another for teamwork.

Then somebody asks:

“Tell me about a time you had to change your approach after discovering that your original assumption was wrong.”

And suddenly none of the beautifully prepared answers seems to fit.

There is a reason for that.

You cannot reliably predict the questions.

You can prepare the evidence.

That distinction changes how I think interview preparation should be done.

The strongest general approach I found while researching this was remarkably consistent:

Work out what the employer needs to assess.

Build evidence that demonstrates it.

Practise retrieving that evidence without a script.

Practise explaining your decisions.

Put the evidence under pressure.

Repair whatever falls apart.

That is a very different exercise from memorising answers.

And it is much closer to what a good interview is actually trying to do.

Start with the job, not Google

Before searching for interview questions, open the job description.

Then ask:

What would someone need to believe about me before they would confidently give me this job?

That is your preparation brief.

Well-designed structured interviews are built around job-related competencies, consistent questioning and defined assessment criteria.

So reverse-engineer the job description.

If it says:

“Develop effective relationships with external partners.”

You probably need evidence of:

• stakeholder management
• communication
• influence
• handling competing priorities

If it says:

“Manage a varied workload in a changing environment.”

You probably need evidence of:

• prioritisation
• judgement
• adaptability
• delivery under pressure

If it says:

“Identify and implement service improvements.”

You need examples showing that you can:

• identify a problem
• understand its cause
• decide what to change
• implement something
• judge whether it worked

Do this across the whole job description.

You will usually end up with somewhere around six to ten important things the employer needs to establish.

Now preparation has boundaries.

Build an evidence map

Take those requirements and create this.

Do not write interview answers yet.

Find the evidence first.

That is where most candidates should spend more time.

Because a beautifully structured answer with weak evidence is still a weak answer.

Build eight to twelve stories, not fifty answers

Next, go through your career.

Find roughly eight to twelve situations worth talking about.

That number is a useful working range rather than some scientifically perfect threshold. The point is to create enough coverage without building an encyclopaedia.

Look for things such as:

• a significant achievement
• a difficult problem
• a mistake
• disagreement
• changing somebody's mind
• improving a process
• delivering under pressure
• making a difficult decision
• handling ambiguity
• receiving feedback that changed your approach
• dealing with a difficult customer, colleague or stakeholder
• taking responsibility beyond the obvious boundaries of your job

Here is where the method becomes useful.

The same story can prove several things.

Imagine you led the recovery of a project that was falling behind.

That story might demonstrate:

leadership if the question focuses on bringing people together.

prioritisation if it focuses on competing deadlines.

problem solving if it focuses on identifying what had gone wrong.

stakeholder management if someone resisted the changes.

adaptability if your first plan failed.

You do not need five different stories.

You need to understand one good story well enough to use the relevant part of it.

Prepare the story as evidence, not prose

Do not write:

“In my previous role, I was responsible for…”

followed by 450 carefully polished words.

Create prompts.

For every story, capture:

Problem

What was happening?

Stakes

Why did it matter?

Your responsibility

What actually belonged to you?

Decision

What choice or judgement did you make?

Action

What did you personally do?

Result

What happened?

Evidence

How do you know?

Learning

What changed in your behaviour afterwards, if anything?

That is enough.

You are building a memory structure.

Not a speech.

STAR is useful. Worshipping STAR isn't.

STAR is perfectly decent:

Situation.

Task.

Action.

Result.

Amazon explicitly recommends it to candidates, and plenty of organisations use similar structures.

But STAR is a communication framework.

It cannot make weak evidence strong.

I have heard answers that technically followed STAR beautifully and still told me almost nothing about the candidate.

The usual problem looks like this:

Two minutes of context.

A detailed history of the team.

Several people introduced who I will never hear about again.

A description of everything “we” did.

Then:

“And luckily we managed to get it over the line.”

What did you do?

That is the part an interviewer needs.

A useful discipline is to spend relatively little time establishing the scene and most of the answer explaining:

• what you noticed
• what you decided
• why you decided it
• what you did
• what changed

The interviewer's job becomes much easier when your contribution is visible.

The strongest answers reveal judgement

Consider these two answers.

Answer one

“The project was behind schedule, so I spoke to everyone involved, we agreed a plan and managed to deliver it.”

Perfectly plausible.

It tells me almost nothing.

Answer two

“We were three weeks behind and had two realistic options: move the deadline or reduce the first release. Moving the deadline would have affected another team's launch, so I reviewed the outstanding work with the technical lead, separated the essential work from what could safely move into phase two, and recommended reducing scope. I then took that proposal to the project sponsor because they owned the final decision.”

Now I can see something.

The candidate:

identified options.

understood dependencies.

made a trade-off.

involved the right person.

could explain why.

That is professional judgement.

And that is usually much more interesting than whether somebody remembered the STAR acronym.

Practise the question behind the question

This is one of the best interview exercises I know.

Take every story and interrogate it.

Ask:

What exactly did you do?

Why?

What other option did you have?

Why did you reject it?

Who disagreed?

What did they want?

What information did you have at the time?

What information didn't you have?

What was the risk?

What happened?

How do you know?

What would you do differently?

Did you ever use that learning again?

These are very close to the sorts of follow-up questions used to get beyond surface-level interview answers.

If your example falls apart after two follow-ups, it is not ready.

If you claimed:

“I improved the service.”

be ready for:

“How?”

If you said:

“I led the project.”

be ready for:

“What did leadership mean in practice?”

If you said:

“I increased engagement by 40%.”

I would want to know:

“Forty per cent of what?”

Evidence should survive curiosity.

Stop rereading your answers

This was probably the most useful finding in the research.

A lot of interview preparation involves recognition rather than retrieval.

You write an answer.

Read it.

Read it again.

Edit it.

Highlight something.

Read it one more time.

Eventually it feels incredibly familiar.

That can create the illusion that you know it.

Then someone asks the question differently and your brain apparently leaves the building.

Memory research has repeatedly found advantages from actively retrieving information rather than repeatedly rereading it. Spacing retrieval over time also improves longer-term retention.

So practise interviews differently.

Write this on a card:

Stakeholder conflict

Project X

Contract deadline

Partner objected

Discovered actual concern

Changed implementation

Result X

Then put the card away.

Ask yourself:

“Tell me about a difficult stakeholder.”

Answer aloud.

Tomorrow ask:

“Tell me about a time somebody disagreed with your recommendation.”

Use the same evidence.

Later:

“Tell me about a time you had to influence somebody without authority.”

Use it again if appropriate.

Now you are practising retrieval and adaptation.

Those are interview skills.

Failure questions should contain an actual failure

A surprising amount of interview theatre happens when candidates are asked about mistakes.

Suddenly everyone becomes a perfectionist.

“Sometimes my standards are almost too high.”

Or:

“I probably care too much.”

Please don't.

A useful failure answer contains something that genuinely went wrong.

Then four things matter.

1. Ownership

What part was yours?

2. Diagnosis

Why did it happen?

3. Correction

What did you do afterwards?

4. Behaviour change

What do you now do differently because of it?

That fourth part matters enormously.

Suppose someone says:

“I underestimated how much stakeholder engagement the project required. I concentrated heavily on proving the technical approach and assumed operational teams would adopt it once they saw the benefit. They didn't, and the implementation slipped.”

Good.

Then:

“On subsequent projects I started mapping the people affected by the change during the planning stage, alongside the technical dependencies.”

Better.

Now learning is observable.

“I learned communication matters” is an opinion.

Changing how you subsequently work is evidence.

Conflict does not need a villain

Another common interview trap:

The candidate tells a conflict story.

Somebody else was unreasonable.

The candidate remained professional.

Eventually everybody realised the candidate had been right all along.

Convenient.

Good conflict answers often contain curiosity.

Try preparing yours using:

What did I want?

What did they want?

Why were those things different?

What did I initially misunderstand?

What common outcome existed?

What did I do?

What changed?

A particularly useful question is:

What was the other person actually trying to protect or achieve?

You do not have to agree with them.

But understanding why somebody disagrees with you is often where influence begins.

Quantify what you can defend

Numbers make examples concrete.

They can also destroy credibility when they have obviously been reverse-engineered for an interview.

Do not invent precision.

Useful evidence might include:

• £45,000 saved
• eight staff recruited
• waiting time reduced from six weeks to three
• 94 people supported
• delivery completed two weeks early
• complaints reduced
• attendance increased
• a contract renewed
• a project recovered
• a board approved the proposal

But outcomes do not always come with neat percentages.

A new process may have stopped people abandoning a service.

A strained relationship may have been repaired.

A team may have adopted a better way of working.

A regulator may have accepted the corrective action.

A funder may have renewed support.

Use the strongest evidence you genuinely have.

The research underpinning this guide is explicit on that point: hard evidence is valuable, but it does not have to mean revenue or percentages.

Never manufacture a number because LinkedIn told you to quantify everything.

“Tell me about yourself” needs its own structure

This question is different.

Do not STAR it.

And please do not narrate your CV.

A much cleaner structure is:

Present

What are you doing now that matters to this role?

Relevant past

What experience explains why you are credible?

Next

Why does this particular move make sense?

For example:

“I currently manage two community programmes, with most of my work focused on staff leadership, partnership development and service delivery. Over the last few years I have increasingly taken responsibility for improving the systems around delivery as well, including redesigning our referral process and developing new partnerships. My earlier frontline experience means I understand how those decisions affect the people using the service. I'm now looking for a role where I can combine that operational experience with more responsibility for service development, which is what attracted me to this post.”

That is a professional narrative.

A chronological tour through every job since you left school isn't.

Research the problem the job exists to solve

“Research the organisation” is technically correct advice.

It is also so broad that people often end up memorising:

the organisation was founded in 1987;

its mission statement;

the CEO's name;

four values;

and something from the latest press release.

Then:

“Why do you want to work here?”

And all of it comes tumbling out.

I would research something different.

Why does this job exist?

Look at:

• what the team is responsible for
• current priorities
• strategy
• annual reports
• funding changes
• current programmes
• growth
• restructuring
• service challenges
• relevant regulation
• who the organisation serves

Then ask:

What problem are they hoping the person they appoint will make easier?

Your “Why this role?” answer becomes much more credible when you can connect:

their situation

to

your evidence

to

what you want to do next.

Run a mock that can hurt you

A mock interview where your friend asks five questions and then says:

“That sounded great.”

is emotionally pleasant.

It may not tell you very much.

Run something closer to the real thing.

Give another person the job description.

Do not give them your prepared questions.

Ask them to interview you for 40 to 50 minutes.

Tell them to interrupt with:

“What did you do?”

“Why?”

“How do you know?”

“What happened next?”

“That sounds like the team's achievement. What was your contribution?”

“What would you change?”

Then score the answers.

The original research proposes a fuller scoring framework, but you can get a lot from five questions.

For every answer:

Relevance

Did I answer the question they actually asked?

Evidence

Did I provide something concrete?

Contribution

Was my role obvious?

Judgement

Did I explain my thinking?

Result

Did the listener know what happened?

Anything weak gets practised again.

Prepare questions that actually tell you something

You are interviewing them too.

Use the final few minutes to gather information you cannot easily find online.

Try:

“What problem would you most like this person to have made progress on after six months?”

“What does somebody who is excellent in this role do differently from somebody who is competent?”

“Where does the team currently experience the most friction?”

“What decisions would this role be expected to make independently?”

“What tends to make people struggle in this role?”

“What has changed about the priorities for this position during the last year?”

And one I particularly like:

“If we were having a conversation a year after I started and you regarded the appointment as a really successful one, what would have happened?”

Listen carefully to the answers.

They are giving you information about the job you might actually be accepting.

The seven-day interview preparation system

If you have a week, I would structure it like this.

Seven days before

Print the job description.

Identify the six to ten things they most need evidence of.

Research the organisation and understand why the role exists.

Six days before

Build your evidence bank.

Find eight to twelve examples.

Do not script them.

Five days before

Retrieve those examples using random interview questions.

Answer aloud.

Notice gaps.

Four days before

Work on anything specific to the role:

technical exercises;

presentations;

cases;

portfolio;

regulatory knowledge;

sector knowledge.

Three days before

Run a full mock interview.

Score it.

Two days before

Repair the weakest evidence.

Prepare your questions.

Check your salary expectations and any practical issues.

One day before

Light retrieval.

Check route or technology.

Clothes.

Documents.

Times.

Then stop trying to rewrite your career.

The original research contains both longer and accelerated preparation schedules built on the same principle of spaced rehearsal rather than last-minute cramming.

Make yourself one page

You should not need twelve pages of notes sitting beside you.

Create one.

INTERVIEW SHEET

ROLE

WHAT THEY MOST NEED

1. ---
2. ---
3. ---
4. ---
5. ---

MY STRONGEST EVIDENCE

1. ---
2. ---
3. ---
4. ---
5. ---

ACHIEVEMENT

Problem → decision → action → result

FAILURE

Failure → ownership → change afterwards

CONFLICT

Difference → understanding → action → outcome

LEADERSHIP

Situation → influence → result

PROBLEM SOLVING

Problem → diagnosis → options → decision → result

FIVE CLAIMS OR NUMBERS I CAN DEFEND

QUESTIONS FOR THEM

1. ---
2. ---
3. ---

At the bottom:

**Answer the question.
Make my contribution clear.
Explain why.
Give evidence.
Stop.**

One final check

Before the interview, forget how many questions you have rehearsed.

Ask yourself:

Do I understand what this employer needs?

Can I prove I have done relevant things before?

Can I retrieve those examples without reading a script?

Can I explain my own contribution?

Can I explain why I made the decisions I made?

Can every major claim on my CV survive a follow-up question?

Can I talk honestly about something I got wrong?

Can my strongest stories survive “why?”, “how?” and “what happened next?”

Do I understand why I want this particular job?

Do I have questions that will help me decide whether I want it?

That is interview preparation.

You can still be nervous.

You can still pause.

You can still get a question you never expected.

None of those things means the preparation has failed.

Your career already contains the material.

The work beforehand is making sure you can find the right piece of it, explain it clearly and make your ability easy to see.