Technical Interview Answers: What to Say When You Don't Know

You will eventually get a technical interview question you don't know. It might be a technology you've never used. It might be a system you've never designed. It might be a question where you know part of the answer but not enough to be certain. The worst response is usually to bluff. The better skill is learning how to reason under uncertainty.

Step 1: Clarify the question

Before answering, identify what is actually being asked.

For example

“When you say scale, do you mean traffic volume, storage, or number of users?” That isn't avoidance. It's problem definition.

Step 2: State what you know

Suppose the question involves a technology you haven't used.

You can say

“I haven't worked directly with that system, but I know the underlying pattern involves…” Now explain the concept you do understand. That gives the interviewer something to evaluate.

Step 3: State your assumptions

Technical questions often contain missing information.

Say

“I'll assume we're optimizing for low latency and can tolerate eventual consistency.” Now your reasoning has a clear foundation.

Step 4: Work from first principles

When you don't know the exact technology, think about the underlying problem.

Ask

What data exists? Who needs it? How often does it change? What are the failure modes? What are the latency requirements? What happens when traffic increases? What consistency is required? Those questions can help you reason without memorizing every tool. Example

Interviewer

“How would you design a globally distributed notification system?”

Candidate

“I haven't built that exact system at global scale, so I'd start by clarifying the requirements. I'd want to know the delivery guarantees, expected traffic, latency requirements and whether duplicate notifications are acceptable. From there I'd design the ingestion, queueing and delivery layers separately.”

That's much stronger than

“I'm not sure.” You don't need the perfect final architecture immediately. You need a credible reasoning process. What if you genuinely don't know? Say so.

For example

“I haven't worked with that technology directly, so I don't want to invent an answer. Based on the underlying problem, I'd approach it this way…” Honesty plus reasoning is stronger than confident nonsense. What interviewers can learn from your reasoning Even when the final answer isn't perfect, your process can demonstrate:

• problem decomposition
• assumptions
• tradeoffs
• technical judgment
• curiosity
• ability to learn
• communication

That matters. Use the “known → unknown → approach” structure

Try

Known: What do I understand? Unknown: What am I uncertain about? Approach: How would I investigate or solve it?

Example

“I know the system needs shared state with low-latency reads. I'm less certain about the exact behavior of the technology you're asking about under failure. I'd therefore start by checking its consistency guarantees and then compare that with the requirements.” That's a professional answer. Don't overuse “I don't know” One honest admission is good.

Repeating

“I don't know.” for every unfamiliar detail can end the conversation prematurely.

Instead, separate

what you know

from

what you would investigate Technical interviews often contain incomplete information That is deliberate. Real engineering problems are rarely perfectly specified.

You may need to ask

Who are the users? How much traffic? What are the SLAs? What happens if the dependency fails? Is consistency more important than latency? These questions demonstrate engineering judgment. Practice thinking aloud Technical candidates often practice silently. Then the interview requires them to explain every step. That creates a gap.

Practice saying

“My first assumption is…” “The tradeoff here is…” “I'd choose A over B because…” “The main failure mode I'd worry about is…” Those phrases make your reasoning visible. Recovery language

Useful phrases include

“Let me break that down.” “I'd start by clarifying…” “The assumption I'm making is…” “I haven't implemented that directly, but…” “I see two approaches…” “The tradeoff is…” “I'd want to validate that assumption.” These are not scripts. They're tools for thinking aloud. The mistake to avoid Don't turn uncertainty into a performance. Some candidates talk endlessly because they think silence looks bad. A short pause is better. Think. Then answer. What to do after a technical interview

Write down

Questions you knew Questions where you partially knew Questions you didn't know Where your reasoning broke down Then practice those areas. A technical mock interview should reveal your knowledge boundaries. That is useful information. [Practice technical reasoning with Mockly] Related: Technical Interview Questions → Mock Interview Tips → Unexpected Interview Follow-Ups