What should you say when you're not sure about a design decision in an LLD interview?
Fast recall
Quick revision
Core answer
Evaluating intellectual honesty, structured thinking under ambiguity, and whether you treat design as a conversation with stakeholders rather than a solo exam.
Freshers either freeze and stop talking when uncertain, or fake confidence and charge ahead with a questionable choice, both showing poor judgment and inability to reason about trade-offs.
Frame uncertainty as a question about priorities or constraints: 'This depends on whether read latency or memory footprint is more critical — what's the typical load pattern here?' shows you're thinking in terms of real-world trade-offs.
Interview-ready guide
Interview answer
When I'm unsure about a design decision, I treat it as a chance to show my reasoning rather than something to hide. The worst things I can do are freeze, just say I don't know, or bluff false confidence — all three read badly. Instead, I lay out the options. I'll say something like, there are two reasonable choices here, and walk through each with its trade-off.
A concrete example: if I'm choosing a data structure for spot lookup, I'd say I could use a HashMap for constant-time lookups, or a TreeMap if I need sorted iteration. Then I make an explicit, reasoned choice for this context — lookups are far more frequent than sorted traversal here, so I'll go with HashMap — and I acknowledge the alternative and when I'd revisit it, like if a requirement for ordered traversal showed up. That whole move demonstrates judgement under ambiguity, which is exactly what the interviewer is scoring.
Sometimes it's also fine, after laying out the trade-offs, to ask the interviewer whether they have a preference, especially if the choice depends on a requirement we haven't pinned down. That's collaborative, not weak. The one thing I avoid is endless hedging without committing, because never deciding looks like an inability to make a call. So the pattern is: name the options, state the trade-offs, commit with a reason, and stay open to changing my mind. Honest, structured reasoning beats fake certainty every time.
What should you say when you're not sure about a design decision in an LLD interview
Direct Answer
When you're uncertain about a design choice, present both options with their trade-offs and either ask for the interviewer's guidance or make an explicit choice while acknowledging the alternative. For example: 'I could use a HashMap for constant-time lookups or a TreeMap for sorted access. I'll go with HashMap since spot retrieval seems more frequent than sorted iteration, but I'd benchmark in production.' This shows decision-making transparency and collaborative problem-solving.
Code Example
// "Spot lookup is far more frequent than sorted iteration, so I'll pick HashMap."
Map<String, ParkingSpot> spots = new HashMap<>(); // O(1) average lookup
// Alternative I considered and rejected for now:
// Map<String, ParkingSpot> spots = new TreeMap<>(); // O(log n), but gives sorted order
Voicing the option you rejected — and why — is what signals real judgement.
Common Mistakes & Pitfalls
- Freezing or saying just "I don't know" — show your reasoning instead.
- Picking silently — verbalise the alternatives and the trade-off.
- Bluffing certainty — false confidence is worse than honest reasoning.
- Never deciding — endless hedging reads as inability to commit; choose and justify.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.