Competency Based Interview Questions (With Example Answers)

A competency based interview scores your answers against a defined list of competencies — teamwork, decision making, resilience, communication — rather than against a general impression. Each answer is marked, often numerically, against the competency it was asked to evidence, which changes how you should answer: relevance to that specific competency matters more than how impressive the story is. Use the STAR technique, keep Situation and Task short, and make the Action explicitly personal, because assessors cannot credit a contribution described as “we”. This is the standard format in UK public-sector hiring and at most graduate assessment centres.

Competency based interviews are the standard format across UK graduate schemes, the Civil Service, the NHS, and most large employers. They are also the most predictable interview format there is — which means they reward preparation more than almost anything else in a job search.

The premise: past behaviour predicts future behaviour. So instead of asking whether you could handle a difficult stakeholder, the interviewer asks for a time you actually did.

On this page

• What a competency based interview is
• The STAR technique
• The core competencies
• Example questions and answers
• How answers are scored
• Mistakes that lose marks
• FAQs

What a competency based interview is

Every question asks for a specific past example, and answers are scored against a defined framework rather than the interviewer’s impression. You will recognise the format immediately:

“Tell me about a time when…” “Give me an example of…” “Describe a situation where…”

Because the competencies are published in advance — in the job description, the person specification, or the Civil Service Success Profiles — you can prepare targeted examples rather than hoping something relevant comes to mind.

This is different from a strengths based interview, which asks what you enjoy and what you are naturally good at (“what energises you?”), and from a technical interview, which tests knowledge directly. Some employers, including parts of the Civil Service, now mix all three in one session.

The STAR technique

The expected structure for every answer:

• Situation — the context, in one or two sentences. Where, when, what was going on.
• Task — your specific responsibility. Not the team’s, yours.
• Action — what you did, step by step. This is the bulk of the answer.
• Result — the outcome, quantified where you can, plus what you learned.

Aim for 90 seconds to two minutes. The most common failure is spending a minute on Situation and ten seconds on Action, which is backwards — Situation is scene-setting, Action is what you are actually being scored on.

Some UK employers, particularly in the public sector, prefer STARR or CARL, which add an explicit reflection step. If the panel names a framework, use theirs.

Prepare six to eight examples rather than one per competency. A good example can be reframed for several competencies — a project where you resolved a disagreement and hit a deadline covers teamwork, conflict, and delivering under pressure.

The core competencies, and what they are testing

Competency	What the panel is really checking
Teamwork	Can you work with people you did not choose?
Leadership	Can you take responsibility without formal authority?
Problem solving	Do you have a method, or do you just react?
Communication	Can you adjust to your audience?
Adaptability	How do you behave when the plan changes?
Delivering at pace	Can you prioritise when everything is urgent?
Conflict resolution	Can you disagree without escalating?
Attention to detail	Do you have a checking process?
Customer focus	Do you distinguish what people ask for from what they need?
Resilience	What do you do after something goes badly?

Example questions and answers

Teamwork — “Tell me about a time you worked in a team to achieve a goal”

“Situation: In my final year I was one of four students building a stock-management system for a local retailer as our capstone project. Task: I owned the database design and the integration between our module and the front end. Action: Two weeks in it was clear we were duplicating work because nobody had agreed interfaces. I proposed we spend a session defining the API contract before writing more code, wrote up the schema and endpoints, and circulated it for comment. I also set up a shared board so blockers were visible rather than discovered at the weekly meeting. Result: We delivered a week early, and the retailer still uses it. What I took from it is that most ‘team problems’ are actually undefined-interface problems — I now push for that conversation early.”

Problem solving — “Describe a difficult problem you solved”

“Situation: In my internship, a nightly report that finance depended on started failing intermittently, roughly twice a week. Task: I was asked to find out why, with no prior knowledge of the pipeline. Action: Rather than guess, I added logging at each stage to find where it broke, which narrowed it to a step reading a partner file. I compared successful and failed runs and found the failures happened when the partner uploaded late, so we read a partially written file. I proposed checking for a completion marker before reading, and added a retry with backoff. Result: The failures stopped, and the retry logic was reused for two other feeds. It also taught me to instrument before theorising — my first guess had been wrong.”

Conflict — “Tell me about a disagreement with a colleague”

“Situation: On a group project, another member and I disagreed on whether to use a framework he knew well or one the rest of us did. Task: I needed this resolved quickly without it becoming personal — we had three weeks. Action: I asked him to walk me through his reasoning properly, and his main concern turned out to be timeline risk, not the technology. That reframed it: the question was not which framework was better but which we could ship in three weeks. We agreed to timebox a two-day spike on both. Result: His was faster to get running, so we used it, and I learned more than I would have otherwise. The lesson was that stated positions usually hide a different underlying concern, and asking for the reasoning surfaces it.”

Note what that answer does: it does not paint the colleague as unreasonable. Panels are listening for that, and candidates who make the other person the villain score badly on this competency regardless of the outcome.

Resilience — “Tell me about a time you failed”

“Situation: I led the logistics for our university tech fest and badly underestimated how long supplier confirmations would take. Task: Two weeks out, three of eight suppliers were unconfirmed and I had no fallback. Action: I escalated to our faculty advisor immediately rather than hoping it would resolve, which I think was the only good decision I made in that stretch. We split the list, called every supplier personally, and secured replacements for two. For the third I changed the format of that session so it did not need the equipment. Result: The event ran, though one session was weaker than planned. I now build confirmation deadlines with slack into any plan, and I escalate at the point I notice risk rather than when it becomes a problem.”

A genuine failure with a genuine lesson scores far better than a disguised success. “I worked too hard and burned out” is heard constantly and scores nothing.

How answers are actually scored

Most frameworks score each competency on a scale — often 0 to 7 in the Civil Service — against published behavioural indicators. Two things follow:

Say “I”, not “we”. The panel cannot award marks for what a team did. If your answer is all “we”, you have described a situation you were present at, not one you acted in. This is the single most common reason strong candidates score low.

Answer the competency you were asked about. A brilliant teamwork example scores nothing against “delivering at pace”. If you are unsure which competency a question targets, it is legitimate to ask.

Mistakes that lose marks

A hypothetical instead of an example. “I would speak to my manager and…” — the question asked what you did. If you genuinely have no example, say so and offer the nearest real one.

No result. Answers routinely end at Action. The Result is where the impact lives, and it is a scored element.

Nothing quantified. “It went well” is weaker than “we cut processing time from four hours to forty minutes”. Use a number wherever you honestly have one.

Too much Situation. Two sentences of context is plenty.

Reusing the same example for everything. Panels notice, and it suggests a thin body of experience.

Blaming other people. Especially on conflict and failure questions.

Rambling past three minutes. Prepare and rehearse aloud. Written preparation reads far shorter than it speaks.

Related

• STAR method — the full framework, with more worked examples
• Behavioral interview questions — the wider question set
• Self introduction in an interview — how to open
• Questions to ask at the end
• NHS interview questions — the values-based variant
• Civil Service interview questions — Success Profiles

Practising the format

Competency answers get sharper by being said out loud. Written notes always read shorter than they speak, and the gap between a rehearsed STAR answer and a first attempt is obvious to a panel within about twenty seconds.

NostrobeAI runs AI mock interviews across competency and behavioural rounds with instant feedback on structure, filler words and pacing. One-time credit packs, no subscription. (See how it compares to other AI interview tools.)