A decision with incomplete information interview question asks one thing. How did you size a call you couldn’t fully check? So a strong answer covers four points in order. First, name the fact you were missing and why you couldn’t wait for it. Second, say how hard the decision would be to undo. Third, describe the check you set up to learn early if you were wrong. Last, give the result, including any part that went badly. The second and third points carry the answer. Without them, the story only proves you got lucky. An interviewer can’t score luck. They can score how you split the decision. Some parts were cheap to reverse and some weren’t. They can also score what you put in place to catch a wrong guess. A mixed outcome is fine, because the check you built is what caught it. The rest of this post builds one Android story into a full answer.
A story that ends in “it worked out” gives the interviewer nothing to write down
Most engineers answer this question with a guess that happened to be right. They lacked data, made a call and the numbers came in fine. The interviewer’s notes from that answer are thin. The candidate decided something and it went well.
That note doesn’t separate good judgment from a coin flip. The same process could have failed. The story wouldn’t show whether the candidate would have noticed. So the follow-up usually goes straight there. “What would you have done if it hadn’t worked?” A candidate who never planned for that has to invent an answer on the spot.
So tell the planning as well as the outcome. The planning happens before you know the result. That makes it the part of the story that reflects your judgment.
Companies describe this skill in terms of reversibility
Amazon and GitLab both describe this skill in public writing. Amazon’s Bias for Action principle says many decisions are reversible and don’t need extensive study. Jeff Bezos went further in his 2016 letter to shareholders, published in April 2017. He called reversible decisions “two-way doors” that can use a lightweight process. He wrote that most decisions should probably use around 70% of the information you wish you had. He added that you need to be good at spotting and correcting bad decisions quickly.
GitLab’s public values handbook uses the same split. It says two-way door decisions need less input, while one-way door decisions benefit from more. Its bias for action value also expects occasional mistakes and quick course correction.
These are two companies’ stated values. They don’t prove every interviewer scores this way. They do give you the frame most likely to match the interviewer’s notes. So in your answer, say which parts of the decision were two-way doors and which were not. Then show you treated them differently.
The running example: a document scanner SDK with no usage data
You’re an Android engineer on a lending app. Product wants users to scan ID documents in the app. A third-party scanning SDK exists. It charges per scan, on either a monthly plan or a cheaper annual contract. Building your own scanner would take a quarter you don’t have.
The missing fact is scan volume. The feature is new, so nobody knows how many users will scan or how often. You also don’t know how the SDK performs on the low-end devices many of your users own. The launch date is fixed by a partner agreement, so you can’t run a long trial first.
This decision has parts with different costs of being wrong. The vendor choice feels like the big call. Yet the app code can be written to swap vendors later. The annual contract can’t be undone for a year. Sizing each part separately is the skill the question is checking.
Split the decision into what you can undo and what you can’t
Here is how the parts sort. Using the SDK at all is reversible if you put it behind your own interface. The rest of the app calls your interface, so a later swap touches one module. The monthly plan is reversible, because you can move to annual once you know the volume. The annual contract is the one-way door. It locks in a price based on a guess.
So you make the reversible calls fast. You integrate the SDK behind an interface and start on the monthly plan. You delay the one-way call until real volume comes in. The interviewer wants to hear that split. It shows you spent caution only where it paid.
The last piece is the check. Before launch, you write down two numbers that would change the plan. One is monthly scan volume. The other is the scan failure rate on devices below a set memory tier. You set a date six weeks out to look at both. The date matters because a plan to revisit with no date tends to slip.
A full answer to the decision with incomplete information interview question
We needed ID scanning in our lending app for a partner launch, with a fixed date. There was a good scanning SDK that charged per scan. The cheap option was an annual contract. The problem was we had no idea what our volume would be. I also didn’t know how the SDK ran on our users’ low-end phones.
I split the decision. Using the SDK was easy to reverse if it sat behind our own interface. So I built it that way and moved fast. The monthly plan cost more per scan but we could change it anytime. The annual contract was the one thing we couldn’t undo, so I held off on it.
Before launch I agreed two numbers with my manager. One was monthly volume. The other was the failure rate on low-memory devices. We set a review six weeks after launch.
At the review, both numbers were off. Volume was about three times my estimate, so the monthly plan had cost more than I’d projected. We signed the annual contract then, based on real data. Failures on low-end devices were also high. The SDK sat behind our interface. So I added a manual photo fallback in about a week without touching other code.
If I did it again, I’d pull a volume estimate from the partner’s own user base before launch. That data existed. I just didn’t ask for it.
This is a sample answer written for this post. Swap in your own decision and keep the numbers honest.
How each paragraph of the sample earns credit
The first paragraph names two specific missing facts and the deadline that ruled out waiting. A vague “we didn’t have all the data” gives no reason to believe the gap was real.
The second paragraph is the core. It sorts the decision into reversible and irreversible parts in plain words. It never uses the phrase “two-way door.” You can use the term with an Amazon interviewer. Elsewhere, describing the idea is safer than naming a framework.
The third paragraph shows the check was agreed before launch. Naming the manager also shows you made the risk visible to someone else, rather than carrying it alone.
The fourth paragraph admits both guesses were wrong. It still reads as a success, because the check caught both misses early. The interface made the second fix cheap. It shows that being wrong cost little because of choices made up front.
The last paragraph gives a specific lesson with a specific missed source. A small, concrete lesson is easier to believe than a grand one.
Three follow-ups this answer invites
A detailed answer draws probing. Prepare these three for your own story. Our post on behavioral interview follow-up questions covers how that probing works in general.
“How did you decide you had enough information?” Tie it to the deadline and the cost of waiting. In the scanner story, waiting meant missing the partner date. The reversible design meant a wrong guess would cost weeks, not the launch.
“What if the numbers had come back fine?” Then you’d still have signed the annual contract at the review, just with confidence. The six-week check existed to replace a guess with data before the one-way call.
“Did anyone disagree?” If someone pushed for the annual contract to save money, say so. Explain that you proposed waiting six weeks and why. Keep it short. A long argument turns this into a conflict story. That’s a different question.
When your honest story has no check in it
Many real decisions were made without a formal review date. You can still use one of them. Tell it as it happened, then say what check you’d add now and why. That’s weaker than a story with the check built in. It’s still far stronger than inventing a review you never held. A single invented detail can come apart under a follow-up.
If you have time before the interview, look for a smaller decision that had a real check. A choice about a library, a rollout percentage or a feature flag often fits. A small, well-structured decision is easier to defend than a big lucky guess. Our post on why a real story beats a bigger one makes the same case more broadly.