Practice example
The interview question
How did you turn an unclear request into a workable solution in a project?
A response that leaves gaps
“I worked on an expense approval project. I spoke to the stakeholders, wrote user stories, and helped the team build a prototype. The project went well.”
This names tasks, but leaves the work itself unclear. Who did you speak to? What was difficult? What did you change, and what happened because of it? The response also leaves out what you learned.
A more complete response
“In a university project, I was responsible for turning a request for faster expense approvals into requirements. The difficulty was that the sponsor wanted fewer delays, while the approvers described different causes and no one had agreed what the prototype should fix. I interviewed the sponsor and two approvers, mapped the process, and reviewed ten example requests. I found two recurring problems: missing receipts and requests with no assigned approver. I narrowed the scope to those problems, wrote two user stories with acceptance criteria, and walked through the proposed flow with both sides to resolve their disagreements. The sponsor and approvers agreed on the scope and criteria, and the team used them to build the prototype. I learned to turn a broad request into a shared problem definition before proposing features, and to agree on a success measure before claiming an improvement.”
What the response makes clear
Specific actions
The response identifies interviews, process mapping, and the review of example requests. It explains the candidate’s own work instead of relying on “we helped.”
The difficulty
The sponsor and approvers described the problem differently, and the prototype had no agreed scope. This gives the actions a reason.
How it was resolved
The candidate identified two recurring problems, set boundaries, wrote testable user stories, and checked the proposed flow with both sides.
The result
The sponsor and approvers agreed on the scope and acceptance criteria, which the team used to build the prototype.
What was learned
The response connects the experience to a reusable lesson: agree on the problem and a success measure before proposing features or claiming improvement.
Use the approach in your next attempt
Choose an experience that is true for you. Explain your actions, the difficulty, how you dealt with it, the result, and what you learned. A result can be an agreed decision, a completed deliverable, or a supported change; it does not need an invented percentage.
Use this as a way to organize a relevant project or behavioral example, not a script to copy. Other question types may need a different structure.