It's easy to give too much background in an interview answer. You start listing dates, duties, tools and everyone involved, then realise you haven't clearly explained what you actually did. The detail isn't bad in itself, but it needs to support the main point.
What made the difference for me wasn't having more experience. It was learning to shape an answer: a real situation, what I personally did about it, and how it turned out. Once I organised my examples that way, I was still answering the panel's questions, but I knew which parts of my experience I wanted to bring forward.
Using STAR
When a question asks about a specific project or situation, one structure handles it well. STAR stands for Situation, Task, Action, Result, and it's a common approach in APS recruitment. Many panels are familiar with it and some selection documentation names it directly, though not every panel expects it and not every question suits it. Check the candidate information pack if you're unsure what a particular process asks for.
- Situation: brief context. What was going on, and why it mattered.
- Task: your responsibility. What you were being asked to do.
- Action: what you personally did, and why you approached it that way.
- Result: the outcome, what it achieved, or what you learned.
The part that most often needs attention is the balance. It's easy to spend a long time on the situation and leave very little room for what you actually did. Keeping the context to a few sentences leaves most of the answer for your own actions, which is usually the part the question is asking about.
Start with what was going on
A common habit is to start the story at the moment you personally showed up. That's when it started for you, but there was usually something happening before that.
Say you're asked about a time you improved a process, and your answer opens with the fact that you rewrote a step in the procedure and retrained the team. That starts in the middle. Wind it back and the sequence becomes clearer: the same step kept failing, work was going out with errors and coming back to be redone, and people waiting on a decision were waiting longer than they should have been. That's the situation. The rewritten step is how you responded to it.
Not every good example involves a problem, though. Plenty of useful examples are about delivering routine but important work well, maintaining quality under pressure, preventing a risk before it became an issue, supporting a decision with good analysis, or managing an ongoing responsibility over time. What each of these has in common is that something was actually at stake, and you can explain what it was. "They wanted a dashboard built" is thin not because there's no crisis in it, but because it doesn't say why the dashboard mattered or what you brought to it.
An example about a mistake can work well too. If the question invites it, describing an error honestly, what you did to fix it, and what changed in how you work afterwards, shows accountability and learning.
Be specific, at a level you can defend
Specifics make an example easier to follow. "There was a significant opportunity to improve uptake" doesn't give much. "Our analysis found a group of eligible people in the regions who weren't receiving a payment they were entitled to, so we ran an outreach campaign to reach them" is concrete and easy to picture.
Use the most accurate level of precision you actually have. If you know the backlog was around 3,000 cases, say so. If you only know it was a few months of work, say that. A figure you can't back up is worth less to you than a rounded one you can explain if asked.
The same goes for the vocabulary of the role. If the position description talks about stakeholder engagement and that's genuinely what your experience was, use the term. Just don't force the ad's keywords into sentences where they don't describe what you did.
Explain your own part honestly
This one seems to worry people, so it's worth saying clearly: an example can be yours without you having done every part of it personally.
There are three honest positions you can hold. You did the work, you directed the work, or you supported or improved somebody else's work. All three are legitimately yours. "I coached the analyst who built that model" is a real contribution. Take the position you actually held and say so plainly.
Then choose verbs that match it: led, contributed, supported, analysed, coordinated. Underselling is the more common problem. "I helped out on a big project along with a lot of other people" doesn't explain what you did, and it leaves your actual contribution unclear. Overclaiming is the other risk: describing a team effort as if it were yours alone is hard to sustain if the panel asks follow-up questions, and in a process built on evidence it isn't worth the risk. Accurate and specific is the aim.
Finish with the result, or the learning
End the example by saying what came of it. The process that runs in half the time, the backlog cleared, the relationship repaired, the report delivered on time. If the outcome was mixed, say what you learned and what you'd do differently. A clear result makes it easier to understand what you did and why it mattered.
It can also help to briefly signal the outcome near the start, so the direction of the answer is clear. That's optional. The thing worth avoiding is burying the result so deep in detail that the answer trails off without one.
After the result, a short connection to the role is often worth adding: "that experience would also be relevant here, because the role involves managing a similar kind of provider relationship." One sentence is enough. Many panels are working through a structured set of questions with limited time, so keep it brief.
The same idea helps in your resume and written pitch. Leading a bullet with the outcome often makes it stronger: "halved decision times by redesigning the step in the workflow that kept failing" says more than a duty statement. It doesn't need to be every bullet, just the ones where the outcome is the point.
Common public-sector outcomes
When you're choosing which examples to prepare, it can help to think about the kinds of outcomes public-sector work is often assessed on:
- Policy or program outcomes
- Service delivery
- Timeliness and quality
- Public value and use of resources
- Risk, compliance and probity
- Stakeholder engagement
- Staff capability
- Trust and accountability
Not every role maps neatly onto every category, and this isn't a checklist to force your examples through. It's a prompt. If you're struggling to explain why an example matters, climbing one level up often helps: you built the dashboard so managers could see how a program was tracking, which mattered because a blowout meant public money wasted.
Build a small example bank
Rather than one perfect example or a dozen loose ones, prepare a small group, maybe four to six, that cover the main requirements of the role between them: something on delivery, something on working with people, something on a problem or conflict, something on a mistake or setback, and whatever the selection criteria specifically call for.
One substantial piece of work can supply more than one of these. A large system rollout might contain a team-coordination example, a technical problem, and a difficult stakeholder relationship, each of which can stand alone as an answer. Drawing on the same project more than once is fine. Using several different examples lets you show a broader range of experience and avoids making every answer sound the same, and some questions will simply fit other parts of your background better.
Run a coverage check
Before you call the preparation done, take a list of common interview questions and check it against your bank. Can you answer, from something you've prepared, questions about a difficult obstacle, working in a team, an unhappy stakeholder, a disagreement with a colleague, presenting to senior people, and a genuine development area? Where a common question has no example, that's the gap to fill.
Practise the shape, not the words
You don't need to memorise a paragraph for every example. Odds are you'll be at least a bit nervous walking in, and that's fine. What matters is holding the shape clearly: the situation, your task, what you did, and the result. If you can recall those four things, you can tell the story, even if the words come out a little different every time.
It doesn't have to sound polished. Trying to recite something word for word is what tends to trip people up, because losing your place in a memorised script is disorienting. Know the four beats and let the sentences come out however they come out on the day.
Then practise out loud. Pick the example you're most likely to use, run it through the full shape, and listen for the places where you're either burying the point in background or skating past what you actually did.