How to answer a question when you don’t know the answer

It will happen. In an interview, a viva, a client call or a team meeting, someone will ask you something you don’t know. Your stomach drops, and you have about two seconds to decide what to do.

Most people pick one of two bad options. They bluff, saying something confident and vague, hoping it sounds right. Or they freeze and say “Sorry, I don’t know” in a small voice, and the conversation stalls.

There is a better third option, and it can actually make you look more credible than if you had known the answer.

Why bluffing doesn’t work

Experienced interviewers and managers can usually tell when someone is bluffing. The answer gets longer, vaguer and faster. There is lots of “basically” and “in general”. And the follow-up question, “Can you be more specific?”, exposes it.

Worse, bluffing damages trust in everything else you said. If they catch one made-up answer, they start doubting the true ones.

In technical interviews, bluffing is especially risky. Saying you know a tool or concept you don’t often leads to three more questions about it.

Why a flat “I don’t know” isn’t great either

Saying “I don’t know” is honest, which is good. But on its own, said nervously, it ends the conversation and leaves the interviewer with nothing.

The interviewer often isn’t testing whether you know the answer. They want to see how you think when you don’t. A flat “I don’t know” gives them nothing to evaluate.

The better approach: Honest, Near, Next

When you don’t know, use three steps.

1. Honest: say you don’t know, calmly

Say it directly, without apology or panic.

• “I haven’t worked with that directly.”
• “I’m not sure of the exact number.”
• “That’s not something I know yet.”

Notice: no “sorry”, no nervous laugh. Just a plain statement. Said calmly, it sounds confident.

2. Near: share what you do know that’s related

Then move to the closest thing you do know.

• “I haven’t used Kubernetes, but I’ve deployed apps with Docker, so I understand the container side.”
• “I don’t know the exact market size, but I’d expect it to be large, given how many small businesses still do billing manually.”
• “I haven’t handled that exact situation, but when something similar happened in my internship, I…”

This shows your knowledge, your reasoning, and that you can connect ideas.

3. Next: say how you would find out or approach it

Finally, show what you would do.

• “If I needed to use it, I’d start with the official docs and set up a small test project.”
• “I’d want to check the latest NASSCOM or government data before giving a number.”
• “If I faced that, my first step would be to ask the client what outcome they need.”

This turns a gap into a demonstration of how you work.

Examples

In a technical interview:

Interviewer: “How does garbage collection work in Go?”

Candidate: “I haven’t used Go, so I don’t know its specifics. I do know garbage collection from Java, where the JVM tracks objects that are no longer referenced and frees that memory periodically. I’d guess Go uses a similar idea, but I’d want to read how it handles pauses, since that’s usually the trade-off.”

Honest, shows related knowledge, reasons sensibly. That is a strong answer to a question they didn’t know.

In an HR interview:

Interviewer: “What is our company’s revenue?”

Candidate: “I didn’t find the exact figure. I know you’re one of the larger mid-tier IT firms, with most revenue from banking and healthcare clients. That’s part of why I applied, because banking is the domain I want to work in.”

In a meeting:

Manager: “What’s the impact of the delay on the client’s launch?”

You: “I don’t have that yet. I know their testing team was waiting for our build, so I’d expect at least a few days. I’ll check with their PM today and send an update by 5.”

Buying time when you might know

Sometimes you might know the answer, but it isn’t coming. In that case, buy yourself a few seconds.

• “Let me think about that for a second.”
• “Good question. There are a couple of ways to look at it.”
• Restate the question: “So you’re asking how we’d scale this to a million users.”

Then pause. Silence while thinking looks thoughtful. A rushed half-answer doesn’t.

If it still doesn’t come, move to Honest, Near, Next.

When the question is unclear

Sometimes you don’t know the answer because you don’t understand the question. Asking for clarification is always fine:

• “Do you mean in terms of cost, or time?”
• “Just to check, are you asking about my project or the industry in general?”

This is a sign of good listening, not weakness. In our scoring, it’s exactly what “Listening” means: confirm understanding first, then answer precisely.

What not to do

• Don’t apologise repeatedly. One plain “I don’t know” is enough.
• Don’t make up numbers or facts. Ever.
• Don’t go silent and wait for rescue. Say something: what you know, or how you’d find out.
• Don’t over-explain. Honest, Near, Next can be done in 30 seconds.

Practise it

This is a skill you can practise. Ask a friend to ask you questions you probably can’t answer: obscure facts, technical topics outside your area, odd hypotheticals. Answer each one using Honest, Near, Next.

After a few rounds, the panic fades. You learn that not knowing is survivable, and that handling it well is impressive.

Some interview questions that commonly produce this moment: salary expectations, when you haven’t researched the market, and project deep-dives, when a panel asks about a part a teammate built.