Start with the position description
For an ACT Government Software Engineer application, map the advertised capabilities to evidence from your own work before choosing technical exercises. Prepare concise examples of your contribution, a difficult delivery decision and how you verified the outcome. Then practise the technology and assessment format specified for that vacancy.
ACT Government publishes a selection framework, but it does not define one coding-interview loop for every software role. Your position description and assessment invitation determine which parts apply.
The official selection framework
The ACT Government selection guidance describes shortlisting against the role's requirements and the use of assessment methods chosen for the position. These may include interviews, practical exercises, presentations and referee information. They are not mandatory successive rounds for every applicant.
| Part of selection | What to prepare |
|---|---|
| Application and shortlisting | A response showing relevant evidence against the advertised requirements. |
| Assessment chosen for the role | Examples and technical preparation matched to the invitation, which may specify an interview or practical task. |
| Referee information and decision | People who can substantiate your contribution; clarification of any outstanding requirements. |
The official guidance also describes a selection recommendation and decision process. Do not interpret this framework as a promised technical-screen, coding and system-design sequence. Confirm the format with the vacancy's contact officer.
Turn the requirements into usable evidence
The application guidance directs applicants to the advertisement and position description. Follow their requested response format and length.
Build a short evidence sheet using the actual wording of your vacancy. The examples below are preparation advice, not universal ACT Government criteria.
| If the vacancy asks for… | Prepare evidence of… |
|---|---|
| Software delivery | A feature you implemented, tests you selected and how you verified its release. |
| Problem solving | A defect you investigated, competing explanations and the evidence that resolved them. |
| Stakeholder communication | A requirement you clarified and how agreement changed the implementation. |
| Technical risk management | A migration or access-control decision, its failure cases and a recovery plan. |
Structure each example around context, your action and the result. Make the individual contribution explicit: what you designed, implemented, tested or decided. Use observed outcomes; do not manufacture percentages.
Technical preparation: match the advertised service
For a public-facing application role, accessible workflows, authorisation and recovery are useful practice themes. For an integration or data role, prioritise validation, reconciliation and migration. These are editorial inferences from the type of work, not confirmed ACT Government interview topics.
If the invitation specifies live coding, practise implementing and testing in the permitted language. If it specifies a presentation, prepare a clear explanation of a real project and be ready to examine a decision in detail.
Practice questions with answer checkpoints
These original scenarios are not reported ACT Government questions.
1. Let a person resume an application safely
For this exercise, a resident can save a draft application and return later. Supporting documents may be uploaded, and a submitted application must not be silently changed.
Start by defining draft, submitted and failed-submission states. Check ownership on every read and write, including document access. Saving progress and final submission need different validation rules: an incomplete draft can be useful, but submission must meet the agreed requirements.
Explain how the service handles an expired session without falsely reporting success or unnecessarily losing entered data. Make errors understandable and keyboard-accessible; do not rely on colour alone.
Test: another user requests the draft, a document upload fails, a submission is repeated, and a save races with submission. Define how the system resolves each case before adding infrastructure.
Follow-up: support staff need to help a user. Explain the authorised support workflow and audit information without granting unrestricted access to every application.
2. Migrate records without hiding omissions
An old service stores applicant records in several tables. A replacement uses a different schema. Explain how you would check that the migration preserved the intended data.
Agree on field mappings, identifiers and how missing or invalid values are handled. Reconcile more than row counts: compare key coverage, relationships and selected field values. Equal counts can conceal one duplicated record and one missing record.
For a staged migration, define which system is authoritative and how changes made during migration reach the destination. Describe what happens to new writes if rollback is needed.
Test: duplicate source identifiers, missing related records, invalid dates and changes arriving during cutover. Produce an exception report instead of silently dropping records.
3. Explain a risk to a non-technical panel member
A release is requested before a data-integrity defect is resolved. Explain the user impact, the available options and the evidence needed for a decision.
Use a real example if you have one. Describe how you communicated the tradeoff and who owned the decision. Avoid answering only with framework names or saying the whole team “handled it.”
For extra implementation and design exercises, use the PracHub Software Engineer question bank. It offers role-level practice, not a government interview-question archive.
How to prepare
Interview tomorrow: read the position description and invitation together. Match each requested capability to an example, rehearse your individual contribution, and work through the technical scenario most relevant to the role. Prepare a question about the service's users or the team's immediate delivery priorities.
For deeper preparation: practise answering follow-up questions that test your evidence: why this approach, what failed, how you knew the result was correct, and what you would change. Review one technical artifact from your own work that you can discuss without revealing confidential information.
Do not divide your time according to a generic interview difficulty score. The biggest preparation gap may be technical implementation or weak evidence against the advertised capabilities; assess both.
Frequently asked questions
Is a coding test guaranteed?
No. Official guidance allows different assessment methods. Your invitation or the vacancy contact should establish whether a coding task applies.
Do I need a particular clearance or citizenship status?
Check the vacancy's eligibility and pre-employment requirements. This guide does not assert one requirement for all ACT Government software positions.
Should I use STAR answers?
A situation, task, action and result structure can help organise an example. Use it to make your evidence easy to follow, not as a script that avoids the actual question.
How long does the process take?
This guide does not promise a hiring timeline. Ask the contact officer about the vacancy's current schedule and next steps.
Sources and evidence
Reviewed 6 September 2026.
- ACT Government selection processes: official selection framework and possible assessment methods.
- Prepare your application: application instructions and role-document guidance.
The framework is official. The evidence sheet, technical scenarios and preparation priorities are PracHub editorial advice, not a verified software-specific interview loop.