A strong answer

• Names the actual decision, not just the project - which database, which pattern, whether to build or borrow
• Lists the alternatives that were genuinely considered
• Identifies the constraint that settled it: time, team skill, marks, hosting cost
• Says what they would do differently now, without being asked

Red flagDescribes the project for four minutes and never gets to a decision.

A strong answer

• Owns it plainly, with no hedging about who else was involved
• Describes how they diagnosed it - logs, a bisect, a reproduction, asking someone
• Separates the fix from the prevention: a test, a validation, a check in the pipeline
• Treats it as ordinary rather than shameful

Red flagClaims it has never happened, or blames a teammate, the tutor or the tooling.

A strong answer

• Went to the person directly before escalating
• Framed it around the work and the deadline rather than the person's character
• Escalated to a tutor or lecturer only when the direct approach had actually failed
• The team still delivered, and they can say what they gave up to make that happen

Red flagSilently did all the work and is still angry about it - that becomes a code review problem later.

A strong answer

• Names a specific thing, not a category
• Can point at something they built or broke while learning it
• Describes a misconception they had and how they corrected it
• Chose it for a reason they can articulate

Red flagLists a course they enrolled in with nothing to show for it.

A strong answer

• Has actually looked at what the company does and can reference the product or the domain
• Has a view on how they want to learn - depth in one product versus breadth across clients
• Is honest that they have applied elsewhere too

Red flagAny answer that would be equally true of every employer in Australia.

A strong answer

• Lookup by index or position versus lookup by key
• Roughly O(1) average key lookup for a hash map versus O(n) scanning a list
• Gives a concrete case: counting occurrences, caching results, joining two datasets in memory
• Bonus: mentions that hash map ordering is not guaranteed in every language

Red flagRecites Big-O notation but cannot give an example of when they used either.

A strong answer

• DNS resolution, TCP connection, TLS handshake, HTTP request, server response, browser render
• Knows where their own code sits in that chain
• Mentions at least one of: caching, load balancers, CDNs, cookies
• Adjusts the depth as you probe rather than reciting a memorised list

Red flagCannot get past 'it loads the website' even with prompting.

A strong answer

• Inner keeps only matching rows; left keeps every row from the left table with nulls where there is no match
• Gives a real example - customers with no bookings disappear from an inner join, so a count comes out low
• Knows that filtering the right-hand table in the WHERE clause quietly turns a left join back into an inner one

Red flagGuesses, and cannot be led to the answer with a worked example.

A strong answer

• Separates the decision logic from the input and output
• Injects the dependency rather than constructing it inside the function
• Names a stub, fake or mock and knows the difference between at least two of them
• Mentions that you still want one real integration test somewhere

Red flagAnswers 'you write tests for it' and stops.

A strong answer

• Authentication is who you are; authorisation is what you are allowed to do
• Knows authorisation must be enforced server-side, not by hiding a button
• Can describe a token or session travelling with the request
• Bonus: mentions that a user editing another user's ID in the URL is the classic failure

Red flagUses the words interchangeably.

A strong answer

• Stops and checks whether anyone else has pulled it
• Knows revert is safe on a shared branch and reset with a force push is not
• Tells someone rather than quietly fixing it
• Bonus: suggests branch protection so it cannot happen next time

Red flagReaches for a force push on main without a second thought.

A strong answer

• 400 for a malformed or invalid request, 404 for a resource that is not there, 409 for a conflict with current state, 500 for our own failure
• Understands that a 500 is a bug report about us, not about the caller
• Mentions that the response body should say what to do about it
• Bonus: notes that returning 404 instead of 403 can be a deliberate choice to avoid leaking existence

Red flagReturns 200 with an error message in the body and sees no problem with it.

A strong answer

• Measures before guessing - timing, logs, an APM trace
• Splits the time between database, application and network
• Checks the query plan or the number of queries before rewriting anything
• Only then considers caching, indexing or pagination

Red flagJumps straight to 'add a cache' or 'add an index' with no measurement.

A strong answer

• One query to fetch a list, then one more per item in that list
• Spots it in query logs or an APM waterfall rather than by reading code
• Fixes it with a join, an eager load or a batched fetch
• Knows it is invisible with ten rows and fatal with ten thousand

Red flagHas never heard of it and does not ask what it means.

A strong answer

• Gets the cardinality right - a booking has many shipments, a shipment has many tracking events
• Chooses sensible keys and asks whether customer references are internal IDs or something the customer supplies
• Recognises tracking events as append-only and high volume
• Asks a clarifying question before drawing anything

Red flagDraws a single wide table and does not revisit it when you describe a second shipment.

A strong answer

• The same request applied twice has the same effect as applying it once
• Connects it to retries, flaky mobile networks and double-clicked buttons
• Suggests a client-supplied idempotency key or a natural unique constraint
• Knows GET, PUT and DELETE are expected to be idempotent and POST is not

Red flagConfuses it with immutability.

A strong answer

• Distinguishes a preference from a defect and says which one they are raising
• Asks a question before issuing a verdict
• Knows when to take it off the pull request and into a conversation
• Is willing to approve something they would have written differently

Red flagWould say nothing to avoid friction, or treats every comment as a blocker.

A strong answer

• Can navigate their own code without hesitating
• Names a deliberate trade-off they made for time
• Has a specific improvement in mind, not a vague 'more tests'
• Admits any part they are unsure about

Red flagCannot explain a section of their own submission.

A strong answer

• Treats intermittent as a clue: concurrency, caching, a shared variable, an off-by-one on a paged query
• Narrows the reproduction before touching code - which customers, which endpoint, what time of day
• Adds logging or a correlation ID to catch the next occurrence
• Considers whether to mitigate for customers while investigating

Red flagStarts rewriting the endpoint immediately.

A strong answer

• Asks what the customer actually wants before choosing CSV, PDF or an API
• Thinks about volume - a synchronous request will not survive ten years of bookings
• Mentions authorisation: exporting only your own bookings
• Covers tests, review, a staged rollout and how they would know it works

Red flagGoes straight to implementation detail without a single question.

A strong answer

• Asks what cancel means in this business - refunds, notifying the depot, a time cutoff
• Separates what is known from what is not and estimates the unknowns as unknowns
• Gives a range with the assumptions attached
• Is comfortable saying 'I would need half a day in the code to give you a real number'

Red flagSays 'about two days' with no questions asked.

A strong answer

• Names something concrete they operated, not just wrote - a home server, a hosted bot, a lab
• Has a failure story with a real diagnosis: disk filled, certificate expired, memory leak, DNS
• Describes what they changed so it would not happen again
• Shows they cared whether it stayed up, not just whether it started

Red flagOnly has coursework where the marker never saw it run for more than an hour.

A strong answer

• Communicates first - acknowledges, sets an expectation for the next update
• Establishes scope and blast radius before diagnosing
• Asks what changed recently - a deploy, a config change, a certificate, a scheduled job
• Considers mitigating (roll back, fail over) separately from fixing

Red flagDives straight into logs in silence and forgets anyone is waiting.

A strong answer

• Can name the process and why they thought it was unnecessary
• Followed it while raising the concern through the right channel
• Either understood the reason afterwards, or successfully changed it
• Shows awareness that in a health context some processes exist because of harm

Red flagProudly describes routing around a control.

A strong answer

• Recognises availability affects patient care, not just revenue
• Talks about change control, auditability and reversibility
• Understands that access to production data is restricted for a reason
• Does not treat safety as opposed to speed - small reversible changes are both

Red flagSees regulation purely as bureaucracy to work around.

A strong answer

• Goes to the source: source code, provider docs, actual error output, a reproducible test
• Builds a small isolated case rather than guessing in the real system
• Writes down the corrected version for the next person
• Knows when to stop and ask someone

Red flagKeeps trying variations of the same command hoping one works.

A strong answer

• Reaches for df to see which filesystem, then du to walk down into it
• Knows logs and container images and old build artefacts are the usual culprits
• Mentions that a deleted file held open by a process still consumes space
• Thinks about a permanent fix - rotation, retention, an alert threshold - not just deleting things

Red flagSuggests only 'make the disk bigger'.

A strong answer

• DNS, load balancer or ingress, service, pod, container, process
• Knows a service is a stable address in front of changing pods
• Can say where TLS is terminated in their picture
• Comfortably says which layers they are less sure about

Red flagUses the words without being able to place them in order.

A strong answer

• Containers share the host kernel; VMs run their own
• Consequences: startup time, image size, isolation strength
• Knows a container image is layers plus a manifest, not a running thing
• Bonus: knows why you cannot run a Windows container on a Linux kernel

Red flagDescribes a container as 'a lightweight VM' and cannot go further.

A strong answer

• Resolver, root, TLD, authoritative - or a coherent approximation
• TTL controls how long an answer is cached, and where
• Connects it to practice: lowering TTL before a cutover, and why changes seem not to take effect
• Knows to check with a direct query rather than trusting the browser

Red flagThinks DNS changes are instant.

A strong answer

• Configuration passed into a process at start
• Knows they leak - process listings, crash dumps, logs, child processes, CI output
• Names a secret manager and the idea of short-lived credentials
• Mentions that rotation matters more than storage location

Red flagHas committed credentials to a repository and does not see the issue.

A strong answer

• Build, test, scan, package, deploy to a lower environment, verify, promote
• Knows the pipeline should fail loudly and block, not warn
• Mentions artefact immutability - build once, promote the same artefact
• Bonus: talks about how you would roll back

Red flagDescribes a pipeline that deploys straight to production on every push and sees no risk.

A strong answer

• Reviewable, versioned, repeatable, and the same in every environment
• Knows drift is the enemy and that a plan or diff is the point
• Mentions review and audit trail - who changed what, when, approved by whom
• Honest that IaC introduces its own problems: state files, blast radius, slow feedback

Red flagSays 'automation is good' with no mechanism behind it.

A strong answer

• A record mapping configuration to real resources
• Knows it must be shared and locked when a team uses it
• Understands it can contain secrets and must be protected
• Bonus: knows what happens when something is changed by hand in the console

Red flagHas used Terraform but never thought about where state lives.

A strong answer

• Liveness restarts an unhealthy container; readiness removes it from traffic
• A liveness probe that checks a database will restart healthy pods during a database blip
• A missing readiness probe sends traffic to a pod that is still starting
• Reasons about it even if the exact terms are shaky

Red flagRecites definitions but cannot say what breaks.

A strong answer

• Role-based access - an instance profile, or a workload identity mapped to a service account
• Least privilege: this bucket, these actions, not a wildcard
• Knows credentials are then short-lived and rotated automatically
• Bonus: mentions checking with a policy simulator or by testing the denial

Red flagSuggests a long-lived access key in an environment variable and stops there.

A strong answer

• Treats alert fatigue as a real risk to reliability
• Investigates whether the condition matters at all before changing the threshold
• Either makes it actionable with a runbook, or deletes it
• Wants alerts tied to user-visible symptoms rather than internal metrics

Red flagWould leave it because 'it might catch something one day'.

A strong answer

• Logs are events with detail; metrics are aggregated numbers over time; traces follow one request across services
• Metrics tell you something is wrong, traces tell you where, logs tell you why
• Knows high-cardinality data is expensive in a metrics system
• Has actually used at least one of the three in anger

Red flagOnly knows print statements and does not ask what the others are.

A strong answer

• Confirms scope: all practices or some, all endpoints or one
• Asks what else changed - a scheduled job, a data migration, traffic, an upstream dependency, a certificate
• Looks at the database before the application: connections, slow queries, locks
• Separates mitigation from diagnosis and says which one they are doing
• Communicates to stakeholders on a stated interval

Red flagRestarts everything as a first move and hopes it resolves.

A strong answer

• Follows the process, and knows whether an emergency change path exists
• Gets the second approver rather than skipping the control
• Documents what was done and why while it is still fresh
• Does not treat urgency as permission

Red flagApplies it directly and plans to write the record tomorrow.

A strong answer

• Blameless - the question is how the change got through, not who wrote it
• Asks what would have caught it: review, a migration check, a staging load test, an alert
• Focuses the actions on the system, not on retraining one person
• Would want the graduate in the room, not shielded from it

Red flagWants the person spoken to, and stops there.

A strong answer

• Chooses one thing and can defend it against the alternatives
• Prefers detection or reversibility over prevention if prevention is expensive
• Considers what other teams would have to change to adopt it
• Says how they would know it worked

Red flagLists eight improvements and cannot prioritise.

A strong answer

• Has a concrete failure and can describe it precisely
• Diagnosed it rather than abandoning it - data quality, leakage, a bad metric, an unrepresentative test set
• Distinguishes 'the model was wrong' from 'I measured the wrong thing'
• Is comfortable being unimpressive about their own work

Red flagEvery project in their history worked on the first attempt.

A strong answer

• Has a filter - a few sources, a rule for what to read deeply
• Distinguishes benchmark news from things that change practice
• Can name a technique they decided not to adopt and say why
• Has actually run something rather than only read about it

Red flagLists newsletters and cannot say what they changed as a result.

A strong answer

• Assumes the disagreement is real information, not a customer error
• Gets the specific example rather than arguing about the general case
• Recognises the definition of correct may differ from theirs
• Turns the disagreement into a test case either way

Red flagWants to explain to the customer why they are mistaken.

A strong answer

• Plain language, no jargon and no hand-waving about neural networks
• Honest about probabilistic behaviour without being fatalistic
• Explains what the guardrails and citations are for
• Gives them something actionable - what to check, how to report it

Red flagEither promises it will be fixed, or hides behind complexity.

A strong answer

• Has actually thought about failure modes on legal and insurance documents
• Mentions hallucinated citations, silent errors, over-trust, privacy of customer documents
• Is thoughtful rather than performatively worried
• Connects it to something they would do about it

Red flagHas no concerns at all, or only rehearsed talking points.

A strong answer

• Immediately asks about class balance
• Knows that a 97%-negative dataset makes 'always no' a 97% model
• Reaches for precision, recall, F1, or a confusion matrix
• Asks which error is more expensive in this business context

Red flagTakes 97% as good news.

A strong answer

• Correct definitions, ideally with the confusion matrix in mind
• Recognises the trade-off is a business decision, not a technical one
• Reasons about the cost of a missed fraud versus the cost of accusing a legitimate customer
• Mentions that a flag feeding a human reviewer changes the answer

Red flagMixes them up and cannot recover when you give a worked example.

A strong answer

• Learning the training set rather than the pattern
• Compares training and held-out performance
• Checks how the split was made - random splits leak when documents or customers repeat
• Mentions regularisation, more data, simpler models or early stopping as responses

Red flagDefines it correctly but has never checked for it.

A strong answer

• Information in training that would not be available at prediction time
• Good examples: a field populated after the outcome, duplicate documents split across train and test, normalising before splitting
• Knows leakage shows up as suspiciously good results
• Would check by looking at what the model relies on

Red flagHas not encountered the concept and does not ask.

A strong answer

• A dense vector where geometric closeness approximates semantic closeness
• Knows similarity is defined by what the encoder was trained on, not by universal truth
• Mentions that domain mismatch degrades it - legal documents against a general-purpose encoder
• Bonus: knows similarity is not the same as relevance to a question

Red flagTreats embeddings as magic that always works.

A strong answer

• Time series - training on the future to predict the past
• Grouped data - the same customer, document or patient in both sets
• Suggests time-based or group-based splitting
• Connects it to the model looking better offline than in production

Red flagBelieves random is always correct.

A strong answer

• Ingest, chunk, embed, index, retrieve, rerank, assemble prompt, generate, cite
• Says retrieval is usually the problem, not generation
• Names real failure points: bad chunking splitting a table, the answer spanning two chunks, a query that does not lexically match the source
• Mentions hybrid search or reranking as responses

Red flagDescribes it as 'you give the model your documents'.

A strong answer

• Builds a labelled set from real questions, even a small one
• Separates retrieval evaluation from answer evaluation
• Uses graded criteria - is it supported by the cited text, is it complete, does it hedge appropriately
• Knows model-as-judge needs its own validation against human labels
• Insists on holding some examples out

Red flagWould 'just try it and see if the answers look good'.

A strong answer

• Fluent output unsupported by any source
• Grounding in retrieved text with enforced citations
• Allowing and rewarding 'I do not know' as an output
• Verification passes, constrained output formats, checking cited spans actually exist in the source
• Knows prompting alone is a weak control

Red flagSays 'better prompts' and stops.

A strong answer

• Measures where the time and money go before optimising
• Considers a smaller model for easy cases and routing hard ones up
• Caching, shorter context, fewer retrieved chunks, parallel calls, streaming for perceived latency
• Asks what the user actually needs - 11 seconds may be fine for a batch job and fatal in a chat

Red flagImmediately suggests fine-tuning as the first move.

A strong answer

• When the failure is format, style or a consistent domain behaviour rather than missing knowledge
• Knows fine-tuning does not reliably add facts
• Weighs the cost: labelled data, retraining on model upgrades, evaluation burden
• Would exhaust retrieval and prompting first

Red flagTreats fine-tuning as the default answer to any quality problem.

A strong answer

• Constrain the tools available rather than asking nicely in the prompt
• Validate outputs against a schema and reject rather than repair silently
• Human approval on irreversible actions
• Limits on iterations, spend and time; logging every tool call
• Knows prompt injection from document content is a real threat when documents are untrusted

Red flagRelies entirely on instructions in the system prompt.

A strong answer

• Established a baseline before optimising - even a trivial one
• Can state their metric and defend the choice
• Knows which of their changes helped and which did not
• Says what they ran out of time to do

Red flagReports one final number with no baseline and no error analysis.

A strong answer

• Looks at the 18% first and categorises the failures
• Distinguishes systematic errors from long-tail ones
• Checks whether some labels are simply wrong
• Asks whether 95% overall is the real requirement, or 95% on the fields that matter
• Willing to say the target may not be reachable with the current approach

Red flagStarts trying different models or prompts at random.

A strong answer

• Thinks about the pipeline before the model - OCR quality, orientation detection, layout parsing, tables
• Knows garbage extraction caps everything downstream
• Would sample and measure OCR quality rather than assume it
• Considers handling handwriting separately, or routing it to a human

Red flagAssumes the text extraction step is solved.

A strong answer

• Monitoring in production, not just an offline test set
• Tracks proxy signals: user corrections, escalations, retrieval scores, refusal rates, input distribution shift
• Wants a periodically re-labelled sample of live traffic
• Mentions that a model version change upstream can move behaviour overnight

Red flagAssumes offline evaluation before launch is sufficient.

A strong answer

• Checked the work before announcing the finding
• Names what they verified - the join, the filter, the date range, the denominator, duplicates
• Distinguishes a genuine insight from a data artefact
• Escalated or shared it appropriately once confident

Red flagReported the surprising number straight away because it made a good story.

A strong answer

• Asks what decision the number will inform before running anything
• Clarifies definitions - which customers, which period, active means what exactly
• Confirms understanding back to them in writing
• Knows the requested number is often not the useful one

Red flagGoes straight to the query.

A strong answer

• Chose a concrete example over an abstract explanation
• Checked understanding rather than assuming
• Adjusted when the first attempt did not land
• Can admit an attempt that failed

Red flagDescribes the audience as the problem.

A strong answer

• Produces it if required, with the caveat attached and visible
• Offers the better alternative alongside rather than instead
• Escalates only if the number will cause real harm
• Understands they are an adviser, not a gatekeeper

Red flagEither refuses outright, or hands it over silently knowing it is misleading.

A strong answer

• Has some grasp of the domain - meter data, tariffs, hardship, regulation
• Interested in a domain deep enough to learn over years
• Honest about wanting breadth early in a career
• Has read something about the industry

Red flagInterested in data generically, with no view on where.

A strong answer

• WHERE filters rows before grouping, HAVING filters groups after aggregation
• Gives an example: filtering by a customer state versus filtering to customers with more than five invoices
• Knows an aggregate cannot be used in WHERE

Red flagUses them interchangeably and cannot be led to the difference.

A strong answer

• Duplicates on the join key in the right-hand table
• Knows to check the grain of both tables before joining
• Would run a count of distinct keys to confirm
• Recognises this is the single most common cause of wrong numbers in reporting

Red flagAdds DISTINCT to make the row count look right without diagnosing it.

A strong answer

• Reaches for a window function - ROW_NUMBER partitioned by customer, ordered by date
• Or a correlated subquery or a max-date join, and knows the tie-breaking problem
• Asks what to do when two invoices share a timestamp
• Thinks about customers with no invoices at all

Red flagUses GROUP BY with a max date and then selects other columns without understanding why it is wrong.

A strong answer

• Calculates across a set of rows while keeping each row
• Names real uses: running totals, rank within group, month-on-month change, deduplication
• Understands PARTITION BY versus GROUP BY
• Has actually used one

Red flagHas heard the term but has never written one and does not ask.

A strong answer

• Counts at each stage of the pipeline to find where the drop happens
• Suspects an inner join, a date filter, a timezone boundary, or a null in the join key
• Compares against the source rather than another derived table
• Knows nulls do not behave as expected in comparisons

Red flagRebuilds the query from scratch hoping it comes out right.

A strong answer

• Grain is what one row represents - one customer per day, one meter read, one invoice line
• Knows mixing grains is how double counting happens
• Would state the grain explicitly when designing a model
• Connects it to sums that are inexplicably too large

Red flagHas never thought about it and shows no curiosity when it is explained.

A strong answer

• Row counts and freshness, uniqueness of keys, nulls where they should not be, accepted values, referential integrity
• Runs them after load and fails or quarantines rather than publishing silently
• Distinguishes a hard failure from a warning
• Knows someone has to be told, and who

Red flagAssumes the pipeline running successfully means the data is correct.

A strong answer

• Someone is alerted, with enough context to act
• Decides between rerunning, backfilling and publishing stale data with a notice
• Considers whether partial data is worse than no data
• Communicates to consumers rather than hoping nobody notices

Red flagWould rerun the job and say nothing.

A strong answer

• Full rebuilds everything; incremental adds or updates only what changed
• Knows incremental is faster and cheaper but can silently miss late-arriving or back-dated records
• Mentions needing a reliable change indicator, and periodic full reconciliation
• Deleted source rows are the classic trap

Red flagOnly knows one and does not ask about the other.

A strong answer

• Separates dimensions from facts, or reasons to that structure without the vocabulary
• Handles a customer moving house - a meter can have several customers over time
• Recognises meter reads as high volume and invoices as low volume with corrections
• Asks about restatements and history: do we need to know what we believed last month

Red flagProduces one flat table and does not revise it when you introduce a moving customer.

A strong answer

• Assumes a definition difference before assuming an error
• Checks period boundaries, GST, credits and adjustments, cancelled invoices, accrual versus cash
• Reconciles at a smaller grain to isolate where the gap appears
• Writes the agreed definition down so it does not recur

Red flagAssumes finance is wrong.

A strong answer

• Shared business logic belongs upstream so every consumer agrees
• Presentation-only logic can stay in the dashboard
• Knows logic buried in a report is invisible and unversioned
• Weighs reusability against speed of delivery honestly

Red flagPuts everything in the dashboard because it is quicker.

A strong answer

• Leads with the answer, not the method
• States the recommendation and what would change if acted on
• Caveats are present but proportionate and near the end
• No jargon, and no apologising for the data

Red flagWalks through their process chronologically and never reaches a conclusion.

A strong answer

• Found at least two of the planted problems - duplicates, impossible dates, a units change partway through, missing months
• Says what they did about each: excluded, corrected, flagged
• Quantifies the impact on the answer
• Notes anything they suspected but could not confirm

Red flagReports no problems at all.

A strong answer

• Names the biggest source of uncertainty in their own answer
• Wants additional data they can specify
• Would validate a finding against a second source or with a stakeholder
• Prioritises rather than listing

Red flagWould make the charts nicer.

A strong answer

• Distinguishes correlation from a causal claim
• Knows the sample, the period and what else changed during it
• Suggests a limited trial or a holdout before a full rollout
• Is comfortable saying the data supports investigating, not deciding

Red flagPresents a correlation as a reason to change pricing for 210,000 customers.