Behavioral: Making Progress When Requirements Are Vague
J.P. MorganSoftware Engineer · Onsite
Last updated
A behavioral question about how you move forward when requirements are vague or incomplete. It tests how a software engineer clarifies goals with stakeholders, separates assumptions from facts, delivers in small verifiable steps, and handles changes in direction along the way.
In the behavioral round of a software engineering loop, the interviewer asks scenario questions drawn from real work. One of them is about ambiguity:
Tell me about a time you were given a problem with vague or incomplete requirements. How did you approach it, and what happened?
Clarifying Questions
- Is a story where the requirements changed midway acceptable, or should they have been unclear from the start?
- Should the ambiguity be technical or about the product?
- Does it matter whether I was the person who owned the work?
Hints
Hint 1
Name the unknowns: Be ready to list exactly what was unclear at the start, which unknowns you resolved by asking, which by building something small, and which you chose to assume.
Follow-up questions
- What did you do when two stakeholders wanted different things?
- How did you decide you knew enough to start building?
- Which of your assumptions turned out to be wrong, and how did you find out?
- What do you do differently with ambiguous work now?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.