A strong answer

• Has a real view of what the job involves day to day, not the job title in the abstract
• Names the part that appeals: the problem definition, the people, the sitting between two languages
• Can say what they would find hard about it
• Does not describe it as a fallback from something else

Red flagDescribes it as 'the business side of IT' and cannot go a level deeper.

A strong answer

• Worked out why they were reluctant - too busy, threatened by the change, burnt before
• Changed the approach rather than repeating the request louder
• Went to them on their terms - their desk, their shift, their language
• Got something useful, or escalated with a clear statement of what was blocked

Red flagSent three emails and concluded the person was difficult.

A strong answer

• Established what had actually changed rather than reacting to the panic
• Renegotiated scope or timeline explicitly instead of absorbing it silently
• Wrote the change down somewhere the whole group could see
• Can say what was dropped and who agreed to drop it

Red flagThe team worked nights to absorb it and nobody ever discussed the trade-off.

A strong answer

• Asked questions anyway, and asked them early rather than nodding through
• Prepared beforehand so the questions were worth people's time
• Wrote down what they did not understand and closed the gap afterwards
• Was comfortable saying they did not know, in front of people who did

Red flagStayed quiet to avoid looking inexperienced - which is the whole job, done wrong.

A strong answer

• Has looked at what a mutual is and can say why customer-owned changes the incentives
• Interested in a domain with real rules, real money and real consequences for members
• Honest that they have applied elsewhere as well
• Has read something about the industry beyond our careers page

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

A strong answer

• Recognises a solution has arrived dressed as a requirement, and goes looking for the problem
• Asks what decision the dashboard would support, and what they do differently based on it
• Asks who else would use it, how often, and what they do today instead
• Is prepared to come back with something smaller than what was asked for, and to justify it

Red flagStarts sketching the dashboard.

A strong answer

• Business requirement is the outcome the organisation wants - reduce claim lodgement time
• Functional requirement is what the system must do to support it
• Acceptance criterion is the testable condition that says the story is finished
• Knows the three should trace to each other, and that the trace is the point

Red flagUses the three terms interchangeably and defends it as semantics.

A strong answer

• Produces something testable - a given, a when, a then - rather than a restatement
• Asks the questions the sentence hides: postal or risk address, effective from when, mid-policy or renewal
• Covers at least one unhappy path - invalid address, address outside the states we cover
• Thinks about what else the change touches: premium, documents, the record of who changed it

Red flagWrites 'the system should update the address correctly' and cannot say how anyone would test that.

A strong answer

• The conversation it forces, more than the diagram it produces
• Handoffs, waiting time, rework loops and the steps that exist only because of a system limitation
• The exceptions - the volume nobody counts and everybody handles
• Validates the map back with the people who do the work, and expects to be wrong the first time

Red flagTreats the documented process as the real process.

A strong answer

• Makes the conflict explicit and visible rather than quietly picking one
• Frames both options with what each costs and what each gives up
• Takes it to whoever owns the decision, with options rather than a complaint
• Records the decision and who made it, so it is not relitigated in six weeks

Red flagBuilds both, or waters both down until neither stakeholder is served.

A strong answer

• Knows there is no complete - the question is enough to start a slice safely
• Prioritises by risk: the assumption that would hurt most if wrong gets tested first
• Comfortable starting with open questions logged rather than waiting for certainty
• Uses delivery feedback as the next round of elicitation instead of a failure of analysis

Red flagDescribes a sign-off gate where all requirements are known before anything is built.

A strong answer

• The business confirming it meets the need - not a second pass of what QA already tested
• Goes badly when the scripts only walk the happy path someone already knows works
• Goes badly when testers are never released from their day job, or the test data is unusable
• Wants defects triaged with an owner and a decision, not a list that grows until go-live

Red flagTreats UAT as a formality to get signed.

A strong answer

• Separates the what from the how, and asks which constraint is actually binding
• Asks what would be possible, and at what cost, rather than accepting or arguing
• Goes back to the underlying need to see whether a different shape satisfies it
• Brings the right people together instead of relaying messages between them

Red flagEither folds immediately or escalates before understanding the constraint.

A strong answer

• Goes and watches it, and follows one real case from end to end
• Asks 'what do you do when...' to find the exceptions, which is where the volume hides
• Hunts for the shadow systems - the spreadsheets, the shared inbox, the sticky notes
• Validates the draft with the people who do the work, and expects corrections

Red flagAsks the manager how it works and writes that down as fact.

A strong answer

• What values it actually contains today, not what the design says it should
• Who sets it, when, and what downstream process reads it
• What a blank means - unknown, not applicable, or nobody filled it in since 2011
• How it maps to the new model, and what happens to the values that do not map

Red flagAssumes the field means what it is called.

A strong answer

• Acceptance criteria met, tested, and whatever the team's definition of done adds - docs, monitoring, non-functionals
• Distinguishes the story being complete from the outcome being achieved
• The product owner accepts it. The analyst does not accept their own requirement
• Knows a story is not done because it was demonstrated

Red flagSays done is when the developer says it is finished.

A strong answer

• Attaches it to a scenario and a number - lodgement submits in under two seconds at the 95th percentile
• Sources the number from a business consequence rather than inventing one
• Says how it will be verified and by whom, before it is agreed
• Knows non-functionals that arrive late are the classic cause of a late release

Red flagLeaves it as an adjective and assumes the developers will interpret it sensibly.

A strong answer

• Leads with the recommendation, then supports it
• Uses the language of claims, not the language of analysis
• Says what it would cost and what would have to change
• Finishes inside five minutes and leaves room for the questions

Red flagWalks through the method for four minutes and reaches the recommendation as time runs out.

A strong answer

• Has a list ready, because they wrote assumptions down while working
• Distinguishes an assumption that changes the answer from one that does not
• Names the single question that would most change the recommendation
• Does not pretend the brief was complete

Red flagPresents the answer as if the brief contained everything needed.

A strong answer

• What is built, what is not, and what each remaining item is actually worth
• The dependencies - what cannot be cut without breaking something already delivered
• What is regulatory or contractual and therefore not available to cut
• Options with consequences attached, so the sponsor can decide rather than be advised

Red flagBrings a status report and waits to be told what to remove.

A strong answer

• Goes and watches before concluding it is a training problem
• Assumes the workaround exists because it is faster or safer for them, and finds out how
• Looks at the numbers - who, how often, which claim types - rather than the loudest complaint
• Is willing to change the design or the process, not just send more communications

Red flagConcludes that users are resistant to change and recommends more training.