How should Leah describe her contribution?
Leah’s panel asks about the same project from three perspectives.
The question
Leah interviews at fictional Alder Services. Release checks confirmed that the service blocked invalid requests and gave the requester a reason. The panel includes a commercial lead, an engineer and a future peer.
- LeahDefined validation requirements, wrote acceptance examples and coordinated release communication.
- EngineeringImplemented the validation service.
“Choose what you would say to the panel.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: How should she frame the result?
What would you do here? Open the move you’d make.
Name the outcome and her own work
The strong move. The result and the contribution stay distinct.
Say she delivered the entire service herself
Tempting, but it misses something. That erases the engineering team’s implementation role.
See how a strong candidate says it
“The release checks showed that invalid requests were blocked with a reason. I defined the requirements and acceptance examples. Engineering built the service.”
Why it works: The result and the contribution stay distinct.
Step 2: What detail should she add?
What would you do here? Open the move you’d make.
Explain the acceptance example she wrote
The strong move. The answer gives the engineer a specific boundary Leah can explain.
Describe implementation details she cannot verify
Tempting, but it misses something. A more technical answer still needs to reflect the work she knows.
See how a strong candidate says it
“One acceptance example checked that an invalid request stopped and gave the requester a reason. I wrote that example and checked it against the requirement.”
Why it works: The answer gives the engineer a specific boundary Leah can explain.
Step 3: What should she correct?
The engineer says, “So you wrote the service.”
What would you do here? Open the move you’d make.
Correct the claim and name her work
The strong move. The candidate corrects the attribution and continues with useful detail.
Accept the coding credit because the panel offered it
Tempting, but it misses something. That conflicts with the supplied project record.
See how a strong candidate says it
“Engineering wrote the service. I defined what it had to do and wrote the acceptance examples that checked it.”
Why it works: The candidate corrects the attribution and continues with useful detail.
Step 4: What did she miss?
The future peer shows that the first requirements missed a retried valid submission. QA found the duplicate before release. Leah added the acceptance example and engineering fixed the service.
What would you do here? Open the move you’d make.
Own the omission and explain the repair
The strong move. The answer owns the omission and identifies the different contributions to the repair.
Say QA was responsible for writing every requirement
Tempting, but it misses something. The original requirements were Leah’s responsibility.
See how a strong candidate says it
“My initial requirements missed a retried valid submission. QA found the duplicate. I added the acceptance example, and engineering fixed the service.”
Why it works: The answer owns the omission and identifies the different contributions to the repair.
The answer, in short
- Decision
- Keep the ownership account consistent.
- Because
- The panel heard different details about the same work.
- What would change it
- New records could change which contribution Leah can claim.
Common traps
- A technical follow-up calls for detail about the same work.
Check your answer
- I named my part of the result.
- I explained a check I owned.
- I corrected a mistaken attribution.
- I owned the missed requirement.
Last reviewed Nov 10, 2026