The pool of interview questions is smaller than it looks, and once you can recognise the type of question you've been asked, some of the nerves settle, because less of it is a surprise.
Treat this as a menu rather than something to read end to end.
The broad types of question
Two broad categories cover a lot of what panels ask.
Past-example questions look backwards: "tell me about a time you...". These ask for a real situation and what you actually did. They're usually called behavioural questions, and the STAR structure from the previous chapter suits them well.
Hypothetical questions hand you a scenario: "how would you handle...". These ask you to work through a problem out loud.
Sorting a question into one of those two buckets as it lands is a useful habit. It isn't the whole picture, though. Interviews also include questions about your motivation, your understanding of the role and the department, your values, technical knowledge, availability and eligibility, and your own reflection on your career. Not everything is a story prompt, and part of answering well is noticing when a question just wants a direct, factual answer.
One more general habit: if a question is genuinely unclear, ask. "Could you clarify whether you'd like an example from my current role, or from any point in my experience?" costs ten seconds and saves a long answer to the wrong question. Keep it for questions that actually need it.
"Tell me about yourself"
This is the most common opener there is. The panel usually has your resume and written pitch already, so the question isn't a request for your life story. A brief overview focused on the experience most relevant to the role does the job.
Something like: "I currently work in program delivery, with most of my recent experience in grants administration. The parts most relevant to this role are the reporting work and the provider relationships, including a project last year where I took over a relationship that had broken down and rebuilt it."
Two or three sentences of overview, one concrete pointer to your strongest relevant experience, and stop. The panel can then follow up on any area where they want more detail. Resist the urge to walk through every job you've held, and don't answer a clear question with a question of your own.
"Walk me through your resume"
Similar idea, slightly different shape. Give a concise overview weighted by relevance: compress the stretches that don't matter for this role into a sentence, slow down on the parts that do, and let the panel redirect you if they want more on something.
You might cover five years in one line, finished the degree, started as a graduate, moved into policy, then spend a couple of minutes on the work that maps directly onto their needs. A quick "happy to go deeper on any of that" at the end hands the steering back to them.
Don't read the document out loud, and don't simply recite responsibilities. A list of duties alone may not explain what you personally contributed, which is usually the more useful thing to talk about.
Behavioural questions
"Tell me about a time you disagreed with someone." "Describe a situation where something went wrong." These are the core of many APS interviews, and the preparation from researching the role and structuring examples with STAR is most of the answer: know the requirements, have your example bank ready, and tell each example clearly.
One optional addition: before the example, a sentence or two on how you generally approach the topic can help frame it. For a disagreement question, that might be: "My starting point in a disagreement is to listen properly first, because the other person may be seeing something I've missed, and most disagreements are about the route rather than the destination. That reminds me of a time when..." Then the example.
Keep framing like that to a couple of sentences. Plenty of good answers skip it entirely and go straight to the example.
A few of the common behavioural topics, briefly.
A disagreement or conflict. Choose an example where you genuinely listened and the outcome was constructive. One where two people who started on opposite sides built something together is ideal if you have it, but any honest example where you handled the disagreement professionally works. An example whose real message is that you were right all along is a harder one to land well.
Something that went wrong. This is a good place for a genuine mistake or setback. What happened, what you did about it at the time, and what changed in how you work afterwards. A mistake example can be useful when it shows accountability, repair and learning.
Your management or working style. If you manage people, describe how you actually operate, with an example: how you set direction, how you adjust to different people, what you do when someone is struggling. If you don't manage people yet, talk about how you work in a team, with the same honesty.
Hypothetical questions
"How would you approach X" questions make people nervous, and they usually don't need to. The scenario is generally a variation on work you've done, so the first move is to walk through your usual approach, step by step, in plain terms.
Say you're in a program area and the panel asks how you'd lift engagement with a stakeholder group that's gone quiet. You'd start by working out who the stakeholders are and which relationships matter most, then look at why contact dropped off before designing anything, then plan the engagement around what you find. Naming the practical issues you'd expect to hit, and how you'd handle them, usually makes the answer more concrete.
If the scenario is genuinely outside your experience, be upfront about that, then reason from the nearest thing you have done: "I haven't dealt with that specific situation, but it looks like a version of resistance to change, which I have worked through before. Here's how I'd approach it."
One boundary: this works for situations, not for missing hard skills. If they ask whether you know a particular system or language and you don't, the answer is no, said plainly. A yes-or-no question about a skill deserves a direct answer.
After a hypothetical answer, if you have directly relevant history, it's fine to offer it once: "I'm happy to walk through a time I dealt with something close to this, if that's useful." Some panels will take it up, some won't have time.
Other common questions
These come up often enough to prepare for. Panels vary, so treat this as a selection rather than a complete list.
Why are you leaving your current role? A neutral, honest answer is fine. You're looking for work in an area your current role doesn't cover, the new role is a better fit for where you want to develop, you're moving cities. You don't need to manufacture a structural reason, and criticising your current department or manager rarely helps. If part of the truth is that you're unhappy, it's usually easier to talk about what you're moving towards.
Why do you want to work here? This is where the research chapter is useful. Specific answers name specifics: a program they run that you want to work on, an area of their work that your current role can't offer, something concrete from the annual report or the conversation with the contact officer. "Great culture" could be said about almost any employer.
What do you bring to the role? Skills with evidence attached. Not "I'm strong in stakeholder engagement" on its own, but the same claim with an example or a figure behind it, at whatever level of precision you can defend. If the question arrives before you understand what they most need, it's reasonable to ask which parts of the role carry the most weight, then answer against that.
What would you do in your first few months? Confirm your understanding of the role, name your assumptions out loud so they can be corrected, then give a realistic early plan: learning the systems and context, meeting the stakeholders, and taking on your first piece of work.
How do you keep learning? Name your actual sources and habits, whatever they honestly are: reading, courses, the people you learn from, how you approach picking up something new. This one also does double duty as the backbone of a good answer about experience gaps, below.
What motivates you? Answer honestly and connect it to the work the role involves. If you don't yet understand the day-to-day well enough to answer, it's fine to say so and ask.
Team or solo? Everyone says they're a team player, so the claim alone carries little. A brief example of you actually supporting a colleague, sharing credit, or reworking your own plans around the team's needs is more concrete.
Describe your ideal manager. Describe what you work well with: clear priorities, trust, feedback, room to operate. Criticising a current or former manager, even by implication, is worth avoiding.
The weakness question
"What's your greatest weakness?" still gets asked, and the old dodges don't serve you well. A strength dressed up as a weakness, "I'm too detail-oriented", is a very familiar answer, and inventing a flaw in the department instead of answering is evasive.
An honest, bounded answer works better:
- Name a genuine development area that isn't a core mandatory requirement of the role.
- Say briefly how it shows up.
- Describe what you're doing about it.
- If you can, point to progress.
For example: "Written briefs are the part of my work I've had to develop most deliberately. Early on mine ran long and buried the recommendation. I've been using my manager's feedback and the department's writing guidance, and my last few have gone up without major rework." That's honest, specific, contained, and it ends on evidence of improvement.
"Where do you see yourself in five years?"
I'm not a fan of this question, but it gets asked. Naming a specific title isn't automatically a problem, whatever some advice says, but it does narrow the conversation.
An answer built on direction usually gives more to talk about: the kind of work you want to be doing, the responsibility you want to grow into, and what you want to develop. "I want to be leading delivery work, managing a small team, and building deeper policy knowledge in this portfolio" says plenty about your ambition without hanging it on a single box in the org chart. If you do have a specific goal, EL1 in this stream, say, it's fine to name it alongside the direction.
When you don't have the experience they ask about
The moment most people dread: a question about something you haven't done.
Some perspective first. Being shortlisted means your application contained enough relevant material for the process to continue. That doesn't prove every gap in your background was noticed, and it doesn't mean the gap won't matter, but it does mean you're there on the strength of what you actually wrote.
Then the answer, in three parts.
Acknowledge it once, plainly. "I haven't worked in that area yet." One sentence, without re-explaining what you haven't done.
Bridge to related experience. "I haven't used that particular system, but I spent three years in one that handles the same kind of casework." The related experience can come from a different tool, a different sector, or study. Adjacent experience is real evidence, as long as you're accurate about how adjacent it is.
Describe how you'd close the gap. Your actual approach to learning something new: the training you'd do, the people you'd learn from, how you've picked things up before.
Two honest boundaries. If the gap is a mandatory technical requirement, don't minimise it; answer truthfully. And if the gap is about scale, you've run two sites and the role covers eight, be straightforward about what carries over and what you'd need to learn. Some technical knowledge can be learned on the job, but how much a gap matters depends on how central the skill is to the role, and that's for the panel to weigh.