Some context first, because I think it changes how you read this.
This isn't a guide written by a recruiter or an HR person, and I'm not claiming any authority. It's closer to a journal: my own experience applying for APS roles, and the things that ended up helping me, written down while they were still fresh.
I've done a lot of interviews at this point, and a fair few didn't go my way. Plenty of applications never got me to the interview stage at all, where the first thing I heard back was a no, sometimes months later and sometimes not at all. That part tends to get left out when people write about this sort of thing, and I don't think it should be, because for most of us it's a decent chunk of the process. Everything here comes from someone who has been unsuccessful a lot, not from someone who worked it out first go.
So take it as one person's notes rather than a rulebook, and keep in mind that processes and panels vary between departments and agencies. If you take one or two ideas out of it and use them in your next interview, that's a win.
The way I used to prepare was to find a list of likely questions online, write out answers to all of them, then lie awake the night before trying to keep the wording straight. It didn't work very well, because all of that preparation was about me, when the conversation was mostly going to be about the role.
This chapter covers the stretch between getting the interview and sitting down in it: researching the team, understanding what sits behind the advertisement, a preparation sequence that starts with the role rather than with question lists, remembering your own experience without memorising scripts, and going through your gaps beforehand.
Researching the team you'd be joining
When I talk about researching the role, I mean something narrower than researching the department. The most useful thing you can work out is what the particular team, branch or area you'd actually be sitting in does: what it's responsible for, where it sits, what it delivers and who for.
That distinction matters more than it sounds. A large department can contain teams doing work that has little to do with each other, and two people who join in the same month can spend their days on completely different things. The department sets your conditions, but the team determines your day to day.
The department is still worth reading about, as the setting rather than the main subject. It's easy to slide into treating that reading like studying for a quiz: when the department was established, how many staff it has, a press release or two. That detail is easy to collect, which is probably why we collect it. What I found more useful was keeping two questions in mind: would I be happy doing this work with these people, and what does this team need that I could help with.
It also helps to get clear, even roughly, on what you want out of a role, whether that's growth, stability, autonomy or something else. That list points your research in a specific direction instead of at everything at once.
Questions that tell you when you're done
These are the questions I use to work out when the research has gone far enough. Once I can answer them, I stop.
- What is this team actually responsible for, and would I want to spend my week on it?
- Where does the team sit, and who does it deliver for, whether that's a minister, another agency or the public?
- Is what the department does something I'd be glad to be part of?
- What does publicly available information suggest about how the department does this work?
- What can I find out about how this particular team works?
- Who would I be working with day to day, and could I realistically grow from this team?
- What do the conditions look like, the flexibility, the leave, all of it?
The first two are worth the most time, because they tell you what the job actually is. Some of those answers aren't in the department's official material, which is written to present the department well. I found more in videos and testimonials from staff, podcast episodes featuring people from the department, and the profiles of everyday employees rather than only the leadership page.
Where to look
For most of us the department's own website is the first stop, which is reasonable. Just don't finish there. Here's what I'd work through, starting with the sources that tell you about the team itself:
- The position description, the closest thing you get to a written statement of what the team is responsible for
- The annual report and corporate plan, where the team's area of work is often described alongside what it delivered
- The organisational chart, which shows where the team sits and what the areas around it do
- The department's own site
- LinkedIn and the public professional profiles of people who work there
Between the position description, the annual report and the org chart you can usually piece together the shape of the work, so that's where I'd start. Employer review sites exist too, but the reviews are anecdotal and incomplete, so I wouldn't put much weight on them.
The other source that's easy to overlook is the contact officer listed on the ad. In many APS processes an informal conversation before you apply is welcomed, and that person is the obvious one to ask what the team does day to day, what's currently on its plate, and how the role sits alongside the rest of the branch. If you're unsure whether it's appropriate for a particular process, the advertisement or candidate information pack usually says.
Before I joined the APS, I looked up the public profiles of people already working there, to get a sense of their backgrounds and what to expect. It didn't hand me the full picture, but it made the whole thing less of an unknown.
Researching the panel
If the panel members are named in advance, it's reasonable to look up their professional backgrounds: their current role, where they worked before, and anything relevant they've published or spoken about. That helps you understand why each person is probably on the panel. A corporate representative and a technical specialist are there for different reasons, and knowing that can help you pitch your answers and questions.
Keep it to professional information. You're trying to understand the panel's roles, not find personal common ground, and researching someone's private life doesn't belong in a merit-based process.
Where this research gets used later
Everything you find gets used at least twice. Good questions for the panel depend on it, something like "while I was reading your annual report, one thing stood out to me", and you can't say that without having done the reading. It's also the difference between a specific answer to "why this department?" and a vague one that could apply anywhere.
What sits behind the advertisement
Before the preparation sequence itself, it helps to think about why the role exists. A vacancy usually means the team has something to deliver and needs another person to deliver it. So three questions are worth asking of any ad.
What is the team trying to achieve? Not the wording of the ad, but the objective behind it. Departmental goals are usually broad; the team has something more specific it's accountable for, and the role was created to help deliver it.
What's likely to be in the way? Budgets, capability, workload, systems, stakeholder relationships. You can make reasonable guesses from the position description and the annual report, and the contact officer can tell you more. Treat these as guesses to test, not facts you've discovered.
What sort of person are they looking for? The position description is the department's description of that person. Read the selection criteria closely, because they're what your application and interview are assessed against. Some requirements are genuinely mandatory, like citizenship, security clearance eligibility, licences, professional registration or required qualifications, and there's no way around those. Others describe experience, where a panel is weighing evidence rather than ticking a box, and closely related experience can still count. The last section of this chapter deals with gaps.
Salary isn't much of a mystery in the APS, since the range is published against the classification. A later chapter covers pay points and offers.
What changed for me with this framing is that I stopped thinking of the interview as auditioning against a checklist. It's a merit assessment, and both sides are working out whether this fits. The real job of preparation isn't a pile of pre-built answers. It's understanding the role well enough that answers come together as you need them.
A preparation sequence that starts with the role
Most of us prepare in reverse. You open one of the endless question lists online and start writing responses, which amounts to guessing what will be asked, scripting replies to the guesses, and trying to hold the scripts in your head. Prep like that never feels finished, and it's hard to sleep on.
Working the other way round helped me more. It's one method rather than the only order that works.
Start with the role, on paper. Before you write a word about yourself, write down what the team is trying to achieve and what's probably in the way, using the research you've done. Say the role is in communications: the team is probably juggling messaging that has to cut through, turnaround expectations from stakeholders, and reporting on what's working. Capture the goals, then the likely obstacles under each.
Find where your experience meets theirs. Now turn to yourself. Which of the things on that page have you dealt with before? The question isn't "what am I good at". It's "which of the things I'm good at does this role need". It's a narrower question, and for me it produced better answers.
Read the position description closely. The position description explains the role, and it can also help you think about likely priorities. "Manage vendor relationships" tells you vendor relationships are a real part of the job, and it's worth thinking about what good management of them looks like. Don't go further than that and invent problems the ad never mentioned. If the position description is thin, which is common for graduate rounds and smaller agencies, look at comparable roles elsewhere, and ask the contact officer or the panel what success in the role looks like.
Prepare your examples. With the role mapped, choose a small group of examples from your own experience that cover the main requirements between them. Structuring examples in an interview explains how to shape them. The point of doing this fourth rather than first is that choosing the right examples means knowing what "right" means for this role, and the earlier steps tell you that.
Only now open the question lists. With the role mapped and your examples chosen, a list of common questions works better as a final check that you haven't missed anything.
Why the order matters
There's a mistake that's easy to make. Take the standard question about a time you influenced someone. The natural move is to pick your best influence story, the one with the satisfying ending, and polish it without much reference to this role. But the example you're proudest of might not be the one that best fits the requirements this panel is assessing against, and that's hard to judge without having mapped the role first.
Prepare in this order and you have less to memorise and less to rehearse. Instead of carrying fifty scripts into the room, you're carrying an understanding of the role.
Remembering without memorising
It can be tempting to write full-paragraph answers to thirty questions and study them the way you'd study a speech. That often backfires: the wording deserts you under pressure, and you spend the hour trying to retrieve a sentence instead of listening to the question. Memorised answers can also come out sounding recited. If you find yourself writing out full answers, take it as an early sign to change approach.
Outlines instead of scripts
What worked better for me was outlines. Carry the bones of each answer in with you: the situation, what you were asked to do, what you did, how it turned out. You already know your own work well enough to fill in the rest as you speak, and each telling can come out a little different and still hold together. The main frame is STAR, covered in structuring APS interview examples.
A small thing that pays off: say your structure out loud as you answer. Opening with "three things made that project work, and the first was..." previews the shape and keeps you located inside your own answer. If your mind stalls for a beat, "and the third thing" is usually enough to get you back on track.
Refresh the history behind your resume
Outlines only work when the material underneath them is fresh, and long stretches of your own career have probably gone blurry. Mine had.
Before each interview round, go back through your resume and your written pitch, the statement where you make your case against the role, one entry at a time, and reconstruct each one: what was going on, what you did, who was involved, what it achieved. It's worth being able to talk about anything you've put on the page, and any line you'd struggle to discuss either needs its memory refreshed or needs to justify its place there.
You don't need every figure in your head. Where notes are allowed, print the key numbers on your copy of your resume or written pitch and refer to them. Checking your own paperwork is a normal thing to do, though it's worth confirming what a particular process allows.
The career achievements journal
One habit that can make future applications easier is keeping a record of useful examples. Each time a significant piece of work wraps up, while it's still fresh, write down the situation, your specific contribution, the outcome, who it served and who worked alongside you. It doesn't need to be long. Recording the details while they're fresh is the useful part, before your memory flattens a whole year into "there was this one big project".
Practise out loud
Include some practice out loud. An answer that reads clearly on paper can still feel awkward when spoken.
Finding the gaps before the interview
Last layer of preparation, and the one that did the most for how settled I felt going in.
You probably know where your resume runs thin, which selection criterion you only half meet, and which question you'd rather not be asked. It's worth getting to those spots yourself first.
Go through the position description line by line
Take the position description apart, requirement by requirement, and hold each line up to one test: is there a gap here I should be ready to talk about? Maybe they want more years than you've logged, or someone who's run bigger teams, spent longer in that policy area, or held a higher classification than you sit at. Flag every instance, then work out what you'd say if it comes up.
Be honest with yourself about which kind of gap each one is. A mandatory requirement, like a qualification, clearance eligibility or registration, is a threshold question, and if you don't meet it the answer is to say so plainly, or to think hard about whether to apply. An experience gap is different: panels weigh evidence, and related experience plus a credible plan to learn can still count for something.
Prepare the gaps most likely to be relevant, while accepting that the panel may still raise something you didn't expect. You can't cover everything, and you don't need to.
Ask someone to test you
A useful exercise: ask a trusted person to read the position description, raise the areas where your experience is less direct, and let you practise answering honestly. It's a bit uncomfortable, which is more or less the point. I'd rather work through the awkward questions at home than face them for the first time in the interview.
Practise the hard questions too
Most of us rehearse the predictable ones, like tell me about yourself, because those are the questions you can see coming. Don't spend all your practice time on the questions you already find comfortable. The harder ones, the questions that go straight at a gap, are usually the ones worth a few extra run-throughs.
Facing the gap head-on
A few shapes that might take.
Say you've managed people for years, all of it in person, and you're going for a team-lead role where the team is spread across locations. It's a small gap and easy to wave off, but I'd pick it up in the position description review and work out beforehand how your approach would change for a distributed team. Then if the question comes, you've already thought it through.
Or say you've run two sites and the role covers eight. That's not a small gap. Go at it yourself first and you can give an honest answer: which parts of running two sites carry over and which don't, what you'd need to put in place at that scale, and what you've already learned about splitting your attention across sites.
None of these gaps close on their own. What changes is that by the time the question comes up for real, you've already answered it several times in private.
If the panel raises something you genuinely couldn't have prepared for, a later chapter covers handling experience gaps in the moment.
What all this adds up to
Preparing your difficult examples in advance can make it easier to respond calmly on the day. That was the main benefit for me: not that I had better answers ready, but that fewer questions caught me completely cold, so I could take a breath before responding instead of rushing at it.