Airservices Australia Software Engineer Interview Guide

The 60-second brief

Airservices Australia runs air traffic management for Australian airspace. Software engineers there build and maintain the systems behind that service. In the role descriptions candidates share, the work covers data ingestion, keeping systems resilient, troubleshooting, tuning existing codebases, and making sure systems are documented and monitored. Engineers work with infrastructure teams and operational stakeholders, and solutions have to satisfy safety and regulatory requirements. Candidates describe the role as spanning requirements and design through deployment and monitoring once software is live. That fits the reported technical questions, which centre on logs, observability and production behaviour, not algorithm puzzles.

This guide is for software engineers interviewing at Airservices Australia, especially those coming from infrastructure, platform, SRE-adjacent or backend roles. It covers the Initial Screening and the Panel Interview. You get question-specific answers to the four reported technical questions: Splunk, infrastructure scalability, debugging distributed systems, and monitoring and alerting. You also get STAR structures for the four reported behavioral prompts and a seven-day plan built on those questions. It also covers the requirements candidates describe: infrastructure software development, monitoring and observability tooling, and software testing, with regulated-industry work, cloud-native architecture and automation scripting as extras.

Candidates report two rounds, an Initial Screening and then a Panel Interview with engineering leads and potential teammates, spread over about 2-4 weeks.

Focus areas

• Splunk
• Dealing with Difficult Engineering Problems
• Problem Solving

Overview

Candidates describe the job as engineering for an operational air traffic service. Day to day that means troubleshooting live systems, improving existing code, ingesting data, and making sure every system has documentation and monitoring. Engineers also work with infrastructure teams and operational stakeholders under safety and regulatory constraints. For your preparation, a strong answer here explains how a system fails, how you would find out, and how you would recover. Build every technical answer around that, and back it with a real system you have run.

The topics candidates report are Splunk, Logging & Observability, Data Analytics (Log Analytics), Dealing with Difficult Engineering Problems and Problem Solving. The reported technical questions are open discussion questions: what to consider when using Splunk, how you keep infrastructure scalable, how you debug distributed systems, and how you approach monitoring and alerting. None of these has one right answer, so depth shows in specifics: Splunk ingestion and licence mechanics, alerts tied to service-level indicators, and debugging that follows a timeline and trace IDs rather than a hunch.

The requirements candidates describe are infrastructure-related software development, deep knowledge of monitoring and observability tools, and a solid grasp of testing methodology. The extras are experience in regulated industries, cloud-native architecture, and scripting for automation. Prepare one concrete project for each requirement. Know the design, the trade-off you made, what broke, and what you would change. Candidates report that technical discussion can go further into the tools on your CV than you might expect, so cut anything from your CV that you cannot explain at the level of how it works.

The behavioral half is four reported prompts: a difficult engineering problem, explaining a technical concept to a non-technical stakeholder, balancing delivery speed against stability, and handling feedback on your code or designs. Structure each answer with STAR. Write each story so the actions are clearly yours, the risk is named, and the result is measured.

The Airservices Australia interview process

Candidates report two stages: an Initial Screening that checks qualifications, then a Panel Interview with engineering leads and potential teammates.

Initial Screening

Candidates describe the Initial Screening as a check of qualifications. They do not report specific technical questions at this stage. Treat it as the point where your background gets matched against the requirements candidates describe: infrastructure software development, monitoring and observability tools, and testing. Have a short, ordered walk through your CV that puts infrastructure and observability work first. For each role, name the system, its scale, your part in it, and one production problem you handled. Settle your logistics answers before the call, and ask what the panel will cover so you can aim the rest of your preparation.

What to demonstrate

• Whether your background matches the requirements candidates describe: infrastructure software, monitoring and observability tooling, testing
• Whether your experience covers the extras candidates describe: regulated industries, cloud-native architecture, automation scripting

How to prepare

• Write a two-minute CV walkthrough that starts with your most relevant infrastructure or observability project and states your own contribution in each role.
• Audit every tool on your CV (log platform, metrics stack, cloud services, scripting languages) and remove or downgrade any you cannot explain at the level of how it works.
• Have one example from a regulated or safety-sensitive setting ready if you have one.
• Ask the screener which parts of the panel are technical and which are behavioral.

Panel Interview

Candidates report a panel of engineering leads and potential teammates. The reported questions fall into two groups. Technical and domain questions cover Splunk, infrastructure scalability, debugging complex distributed systems, and monitoring and alerting for production services. Behavioral questions cover difficult engineering problems, explaining technical ideas to non-technical stakeholders, balancing speed against stability, and handling feedback. Candidates report that technical depth varies and that you should be ready to defend your technical decisions in detail. They also report that the panel gives you room to ask questions. For each technical answer, give your process, then a real incident or system from your own work, then the trade-off you accepted. Answer behavioral prompts in STAR form with your own actions in the first person singular.

What to demonstrate

• Depth on the technologies on your resume, including how your own projects and tools actually work
• Depth on logging, observability and log analytics, including Splunk, as the reported technical questions cover
• Reasoning about scalability and debugging in distributed production systems
• Behavioral answers on difficult problems, stakeholder communication, speed versus stability, and feedback

How to prepare

• Rehearse aloud the four reported technical questions using the outlines in this guide, each tied to one system you actually ran.
• Write four STAR stories, one per reported behavioral prompt, each with a measured result and one thing you changed afterwards.
• Prepare one project deep dive: the architecture, why you chose it over an alternative, how it was monitored, and its worst incident.
• Write two or three questions for the panel about how the team monitors and supports its systems in operation.

Where candidates lose points

Answering the Splunk question with "it is a tool for searching logs" and nothing on ingestion, licence volume, search cost or retention.

Learn the four layers in this guide (ingestion and timestamps, licence and noise filtering, search performance with tstats and summary indexes, retention and access per index) and tie each to something you configured or fixed. If your hands-on experience is with a different log platform, say so and map the same concepts across. Do not claim Splunk depth you lack: candidates report that questioning can go deep on the tools on your CV.

Answering the distributed debugging question with a favourite theory and no mitigation step, timeline or trace across services.

Rehearse a fixed sequence (contain, timeline of changes, follow one request by trace ID, test one hypothesis at a time that halves the possibilities, fix and verify, post-incident review) and walk through it on a real incident. Say what each step ruled out.

Describing monitoring as CPU, memory and disk thresholds that page someone.

Lead with service-level indicators and SLOs, page only on user-facing symptoms or fast error-budget burn, give every page a runbook, and name your plan for silent failures such as a feed or job that stops. Bring one example where you cut alert noise and what it achieved.

Behavioral stories told as "we did", with no personal decision and no measured outcome.

Rewrite each of the four STAR stories so the Action section is all first person singular, contains one explicit decision, and ends with a number. Remove any story where you cannot name what you personally changed.

Defending an architecture choice with "it is best practice" when the panel asks why.

For your deep-dive project, write down the alternative you rejected, the constraint that decided it (load, consistency, operability, regulation) and what you would choose now. Candidates report being asked to defend technical decisions in detail, and this is also how to prepare a question such as choosing between two architectural patterns for a new service.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

• The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
• How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

What should you consider when using Splunk?

Medium · Technical and Domain Expertise

Approach

1. Organise the answer around a pipeline: get data in, store it, search it, act on it. On ingestion, cover universal forwarders on hosts, heavy forwarders only where you must parse or route before indexing, and a correct sourcetype per source. Line-breaking and timestamp settings in props.conf (TIME_FORMAT, TZ, MAX_TIMESTAMP_LOOKAHEAD) matter because a wrong _time quietly breaks every time-bounded search and alert.
2. Cost and volume: under ingest-based licensing, daily indexed volume is what gets metered. Cut noise at the source (log levels, sampling) or send unwanted events to the nullQueue with props/transforms on a heavy forwarder or the indexers. Prefer search-time field extraction. Index-time fields grow the index and are fixed once written.
3. Search performance: always restrict index, sourcetype and time range first. Avoid leading wildcards. Use stats in place of transaction where you can, and watch subsearch and join result limits. For dashboards that run constantly, use tstats over indexed fields or accelerated data models, or a summary index.
4. Governance: set retention per index (hot/warm/cold buckets, frozenTimePeriodInSecs) to match audit needs, control access by role per index, and mask sensitive values at ingest (SEDCMD or transforms). In a regulated setting, say who can see which index and how long it is kept.
5. Acting on data: scheduled alerts need throttling so one incident does not page twenty times. Add an absence alert (no events from a host or sourcetype in N minutes), because a forwarder that silently stops looks exactly like a healthy, quiet system.

Follow-up

• A dashboard panel times out over a 30-day range. What do you change first?
• How would you find out that a forwarder stopped sending data last night?
• Licence usage doubled this week. How do you find the cause and cut it without losing what incident response needs?

How do you ensure the scalability of your infrastructure components?

Medium · Technical and Domain Expertise

Approach

1. Start by naming the load dimension and the target: requests per second, events per second, bytes ingested or concurrent connections, at your busiest periods rather than on average, with an explicit headroom margin. Then run a load test to find the point where latency bends upward, so capacity is measured rather than guessed.
2. For a system that operations staff rely on, as in air traffic management, treat redundancy and failover as the main lever, not autoscaling alone. Say how many instances or zones can be lost while the service still carries peak load, and what degraded-mode operation looks like when capacity runs short.
3. Keep compute tiers stateless so they scale horizontally behind a load balancer, and move session and state into a store. Where you do autoscale, use a signal that moves before users feel pain, such as queue depth or concurrency. CPU alone often reacts too late.
4. For the data tier, use read replicas and caching for read-heavy paths, partitioning or sharding when one writer becomes the limit, and a queue between producers and consumers to absorb bursts. Consumers must be idempotent, because a queue delivers at least once.
5. Protect against the dependency that does not scale: bound connection pools, set timeouts shorter than the caller's, retry with exponential backoff and jitter, and use circuit breakers and load shedding so overload degrades one feature instead of the whole service. Track saturation per component and keep a load test in the release process.

Follow-up

• Traffic grows ten times overnight. What breaks first in a system you have run, and why?
• How do you scale a component that has to keep state, such as a database or a stream processor?
• How would you keep a service running at reduced capacity if a zone failed during a busy period?

How do you approach monitoring and alerting for production services?

Medium · Technical and Domain Expertise

Approach

1. Start from what users and operators depend on, and define service-level indicators for it: availability, latency at a stated percentile, correctness, and data freshness for feeds. For a system that supports live air traffic operations, data freshness and availability are the indicators worth defending first. Set SLOs on those indicators and cover the four golden signals (latency, traffic, errors, saturation) per service.
2. Page on symptoms, not causes. A human gets woken when users are affected or an SLO's error budget is burning fast, ideally with multi-window burn-rate alerts. High CPU or a full disk on one node goes to a ticket or a dashboard unless it is about to cause an outage.
3. Every paging alert needs an owner, a runbook link and a clear first action. Use durations and hysteresis on thresholds, deduplicate and group related alerts, and review alert volume regularly. An alert that is routinely ignored should be fixed or deleted.
4. Cover the silent failures: heartbeat or absence alerts for batch jobs and data feeds, synthetic checks from outside the service, and monitoring of the monitoring pipeline itself (a log shipper or metrics agent that stopped reporting). In an operational setting, say what the standby or failover path does when the primary stops reporting.
5. Keep the three signal types in their roles. Metrics are for alerting and trends, structured logs for detail, traces for tracking a request across services. Mention cost and cardinality: high-cardinality labels on metrics belong in logs or traces instead.

Follow-up

• An alert fires most nights and the team ignores it. What do you do?
• How would you monitor a nightly job whose failure mode is that it never starts?
• Why alert on p99 latency and not the average, and when is p99 the wrong choice?

What is your process for debugging complex, distributed systems?

Medium · Technical and Domain Expertise

Approach

1. Mitigate first, then find the cause. Confirm the symptom in metrics, gauge the blast radius (which services, which users, since when), and use rollback, failover or a feature flag if they can stop the harm while you investigate.
2. Build a timeline of what changed: deploys, config, certificates, traffic shape, dependency versions, infrastructure events. Line it up against when the error rate or latency moved. Most incidents trace back to a change, but the change that triggered it is not always the root cause.
3. Follow a single failing request across services using a correlation or trace ID in centralised logs and distributed traces. Find the first span where the latency or error appears, not the span where it is noticed. Check for clock skew before you trust cross-host ordering.
4. Form one hypothesis at a time and pick a test that rules out half the possibilities whichever way it comes out: one zone or all, one client version or all, every request or only the large ones. Watch for distributed-system patterns such as retry storms, mismatched timeouts, partial partitions and connection-pool exhaustion.
5. Close the loop: reproduce the fault or prove it with data, fix it, confirm the metric recovered, then write the post-incident review. Add the alert, log field or test that would have caught it sooner.

Follow-up

• Logs from two services disagree on which event came first. How do you resolve it?
• One percent of requests fail intermittently and you cannot reproduce it. What do you do next?
• How do you show that your fix caused the recovery and that it was not a coincidence?

Suggested practice checklist

Each day targets one of the two reported rounds or one cluster of reported questions. The technical days pair a reported question with a related practice problem, and the last day is a full panel rehearsal.

Day 1 — Screening readiness and CV audit

• Write and time a two-minute CV walkthrough that opens with your strongest infrastructure or observability project.
• List every tool on your CV and mark each one: can explain how it works, have used it, or only touched it. Rewrite the CV wording for the last group.
• Pick the one project you will use for the panel deep dive and write down its architecture, the alternative you rejected, the constraint that decided it, and its worst incident.

Deliverable: A timed CV walkthrough, an audited tool list, and a one-page project deep-dive sheet.

Day 2 — Splunk and log analytics

• Write an answer to the Splunk considerations question covering ingestion, licence volume, search performance and retention, with one example from your own work for each.
• Write three searches against logs you know: an error-rate-by-host stats search, a tstats or summary-index version of a slow dashboard search, and an absence-of-data alert search.
• Say the answer aloud, then trim it to the parts you could defend under follow-up questions.

Deliverable: A written and spoken Splunk answer plus three working or annotated searches.

Day 3 — Monitoring and alerting

• Define SLIs and SLOs for one service you have run, and write two burn-rate or symptom alerts plus one heartbeat alert for it.
• Solve the rolling failure-rate practice problem and explain how the same sliding-window logic would drive an alert threshold.
• Say aloud the answer to the monitoring and alerting question, including one alert-noise story.

Deliverable: An SLI/SLO sheet with three alerts, a solved rolling-window problem, and a spoken monitoring answer.

Day 4 — Debugging distributed systems

• Write a past incident as a timeline: detection, mitigation, changes checked, the trace or log evidence that found the cause, the fix, and the follow-up.
• Solve the overlapping job-attempts and peak-concurrency practice problem and connect it to diagnosing contention from lease or lock records.
• Say aloud the answer to the distributed debugging question using the incident timeline as the worked example.

Deliverable: An incident timeline, a solved concurrency problem, and a spoken debugging answer.

Day 5 — Scalability of infrastructure components

• For your deep-dive system, write the load dimension, the measured or estimated limit, and what breaks first at ten times the load.
• Solve the keyset-paging practice problem and the redelivered-event high-water-mark problem. Note how each one removes a scaling or at-least-once delivery hazard.
• Sketch a managed-cloud version of your deep-dive system: an autoscaling group or managed queue, multi-AZ failover, and what you would monitor. Cloud-native architecture is one of the extras candidates describe, so rehearse the follow-ups it invites.
• Say aloud the answer to the scalability question, covering stateless scaling, queues with idempotent consumers, failover and dependency protection.

Deliverable: A one-page capacity note, a managed-cloud sketch, two solved practice problems, and a spoken scalability answer.

Day 6 — Behavioral STAR stories

• Write STAR stories for the difficult engineering problem and speed-versus-stability prompts, each with an explicit decision and a measured result.
• Write STAR stories for the non-technical stakeholder and feedback prompts, each ending with what you changed afterwards.
• Record yourself telling all four and cut any sentence where "we" hides what you did.

Deliverable: Four written STAR stories and a recording of each, edited to first person singular.

Day 7 — Panel rehearsal

• Run a mock panel with two people if possible: two technical questions from this guide, two behavioral prompts, and a deep dive on your project with follow-up questions.
• Note every follow-up you could not answer cleanly and write a two-sentence fix for each.
• Write three questions for the panel about how the team runs, monitors and supports its systems.

Deliverable: A completed mock panel, a list of weak follow-ups with fixes, and three questions for the interviewers.

Behavioural preparation

Candidates report four behavioral prompts at Airservices Australia: a difficult engineering problem, explaining a technical concept to someone non-technical, trading delivery speed against stability, and handling feedback on code or designs. Structure each answer with STAR. For this role, pick stories set in production or infrastructure work, where you can name the operational risk and the specific decision you made.

Please explain how you deal with a difficult engineering problem.

Medium · Behavioral and Problem-Solving

Approach

1. Pick a problem that was hard on its merits: unclear cause, conflicting data, or no obvious owner. A big workload alone is not enough. Set it up in two sentences: the system, the symptom, and why the obvious fixes failed.
2. Spend most of the answer on how you broke it down: the hypotheses you listed, the evidence you gathered for each (logs, metrics, a reproduction), what you ruled out, and who you brought in and why.
3. Make your own actions explicit with "I" ("I added request-level tracing to the ingestion path"), and name the decision point where you chose one route over another.
4. Close with a measured result (error rate, latency, hours saved) and what you changed afterwards: a test, an alert, a runbook or documentation.
5. The mistake that sinks it is a story where the team solved it and your part is unclear, or a problem that was only difficult because of a deadline.

Follow-up

• What did you try first that turned out to be wrong, and how did you find out?
• If the same problem appeared tomorrow, how much faster would you solve it and why?
• Who disagreed with your approach, and how did you settle it?

Describe a time you had to explain a technical concept to a non-technical stakeholder.

Medium · Behavioral and Problem-Solving

Approach

1. Pick a case where the stakeholder had a decision to make: approve a change window, accept a risk, fund work, or delay a release. Explaining for the sake of explaining makes a weak story.
2. Show how you adjusted the message. Start from the decision and its consequences in their terms (operational impact, risk, cost, time), use one accurate analogy, and leave out internal jargon. Say what you deliberately left out.
3. Show that you checked understanding: you asked them to restate the trade-off, followed up in writing, or used a simple diagram or a single number instead of a dashboard.
4. Give the outcome: the decision they made, and whether it held up. If they misunderstood at first, say how you noticed and corrected it.
5. Avoid answers that sound condescending ("I dumbed it down"), or that bury the stakeholder in detail and call it transparency.

Follow-up

• How did you know they had actually understood the risk?
• What would you do if they made the decision you advised against?
• How would you explain the same issue to an operational manager versus a regulator?

Tell us about a project where you had to balance speed of delivery with system stability.

Medium · Behavioral and Problem-Solving

Approach

1. Set up the tension with specifics: the deadline and why it was real, and the stability risk in concrete terms (what could fail, how many users or operations would be affected).
2. List the options you weighed and the one you chose. Strong answers show you can ship a smaller scope safely: feature flags, staged or canary rollout, a tested rollback, extra monitoring for the release window, and the tests you would not drop.
3. In a safety-regulated environment, make the trade-off on scope and sequencing, never on safety assurance. Show the story working within change control, approvals and release windows, so it is clear you did not cut corners to hit the date.
4. Say what you deliberately left out or postponed, and how you recorded it as tracked work so it did not quietly become permanent debt. Give the result with numbers (delivered on date X, no incidents, or one incident caught by the canary and rolled back in N minutes), then say whether the deferred work was actually done.
5. Two framings sink this answer: claiming stability always wins (it avoids the trade-off the question asks about), or describing a reckless launch that happened to work.

Follow-up

• What signal would have made you stop the rollout?
• Which of the shortcuts you took caused problems later?
• Who else had to approve the trade-off, and how did you get their agreement?

How do you handle feedback on your code or architectural designs?

Medium · Behavioral and Problem-Solving

Approach

1. Use one real example of critical feedback on a pull request or a design document. Say what the feedback was, who gave it, and why it was uncomfortable to hear.
2. Show how you weighed it on evidence rather than ego: you reproduced the concern, ran a benchmark, or checked the failure case the reviewer raised.
3. Show both outcomes in your habits. Give a case where you changed the design because the feedback was right, and briefly a case where you disagreed and settled it with data or a small experiment, not seniority.
4. Finish with what changed permanently: a checklist item, an added test category, or how you now write design documents so reviewers can find gaps earlier.
5. The mistake that sinks it is a generic "I welcome all feedback" with no example, or a story where the reviewer turns out to be wrong and you come across as dismissive.

Follow-up

• Describe a time feedback on your work turned out to be wrong. How did you handle it?
• How do you give feedback on a design you think is unsafe?
• What review comment changed how you write code today?