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

• Names what they can - single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion - and says plainly which ones they cannot
• Explains one of them properly rather than expanding all five acronyms with nothing behind them
• Says what the set is for: code you can change in one place without the change rippling into unrelated code
• Places them as object-oriented design guidance from the early 2000s, not a rulebook every codebase is scored against

Red flagRecites all five fluently and cannot say what a single one means or why anyone would want it.

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

• Frames a responsibility as a reason to change, not a count of methods or lines
• Gives a concrete case: a class that has to be edited when the pricing rules change and again when the invoice layout changes
• Names the everyday signals - the honest name for the class needs an 'and' in it, the tests need pages of setup, unrelated tickets keep landing in the same file
• Knows the cure can be worse than the disease: forty one-method classes are not obviously better than four honest ones

Red flagSays 'one class, one job' and has nothing further, or would split every class until the flow cannot be followed.

A strong answer

• Points at real code - an interface pulled out so a test could pass a fake, a switch statement replaced because every new case forced an edit to the same method
• Can say what it cost as well as what it bought: another file, another layer of indirection, a longer path to read
• Names a case where it is not worth it - a script that runs once, an abstraction over a single implementation that will never have a second
• Understands the goal is code that stays cheap to change, and the principles are one route to that rather than the point itself

Red flagAnswers entirely in the abstract, or argues that all five have to be satisfied everywhere.

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.