Katkat
Back

Discovering a Design Flaw Right Before a Project Deadline: How Do You Respond?

RobloxSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenBehavioral & Leadership

Last updated

A situational behavioral question for software engineers: your project is close to its deadline when you discover that an earlier design decision is flawed. It tests how you size the flaw's impact, weigh delaying against shipping with a mitigation or cutting scope, communicate with the people who own the date, and follow through.

Your team's project is close to its due date when you discover that a design decision made earlier in the project is flawed. What do you do?

This scenario came up as a single-choice situational question in an online assessment; the answer options were not reported. Answer it in your own words: explain how you would decide what to do, what you would actually do, and, if you have one, support it with a real example from your own work.

Clarifying Questions

  • What kind of flaw is it: does it produce wrong results, lose data or open a security hole, or does it mainly hurt performance, scalability or how easy the code will be to change later?
  • Is the due date a hard external commitment, such as a launch, a customer contract or another team's dependency, or an internal target?
  • How much has already been built on the flawed design, and is there a narrow fix or a mitigation that could contain the problem until after the deadline?
  • Was it your design, a design approved in a review, or one you inherited from someone else?
  • Who can move the date or cut scope: you, your lead, or a product owner?

Hints

Hint 1

Size the problem first: Before choosing between the deadline and the fix, ask what would actually go wrong if the project shipped with the flaw, and for whom.

Hint 2

Think about who needs to know: Consider who depends on the due date, who can change it, and how much notice they would need to plan around a change.

Follow-up questions

  • Your manager wants to ship on time, but you believe the flaw can corrupt user data. What do you do?
  • The flaw is in a part another engineer designed, and they do not agree that it is a problem. How do you handle it?
  • You decided to ship with a workaround. How do you make sure the real fix actually happens afterwards?
  • Looking back, how could the design review have caught this flaw earlier?