What to Say When You Don’t Know the Answer in a Technical Interview

Sooner or later an interviewer asks you something you can’t answer. You can still get the offer. In a senior interview, they may keep asking “and what happens below that?” until you run out of detail. How you handle that moment gives them something to evaluate too.

Ask for a moment

You’re allowed to think. Say “Let me think about that for a second” and take the pause, even if it feels longer than you’d like.

Say the question back in your own words: “So you’re asking how I’d find the cause if the API were slow for only some users?” If you misunderstood, you find out before spending three minutes on the wrong answer. The interviewer may also add a detail that helps you get started.

Start from the part you know

Say where your knowledge stops, then explain the part you do know.

Take “How does a database index work internally?” Maybe you’ve added plenty of indexes and never read about how they’re built. You could say:

“I haven’t looked at the internals closely, so I can’t give you every detail. Most relational databases use a B-tree, which keeps the keys sorted so a lookup doesn’t have to scan the whole table. I’ve added indexes to fix slow queries, and I know they cost extra storage and slower writes. If I had to guess at the internals, I’d expect each node to hold many keys, so a lookup only reads a few pages from disk.”

On a problem, think out loud

With coding and design questions, let the interviewer follow your reasoning as you work toward an answer. Long silences make that difficult.

Start by asking about the input. How big is it? Is it sorted? Can it be empty? Then get a simple version working, even a slow one, and say that’s what you’re doing: “The simple way is to compare every pair, which is O(n²). Let me get that right first, then look for something faster.” Interviewers would much rather see a slow solution that works than half of a fast one.

When you get stuck, say exactly where. “For each number I’m scanning the whole list to see if I’ve seen it before, and that scan is the slow part.” Saying it out loud often gets you to the fix yourself, which here is a hash set. If it doesn’t, the interviewer now knows which hint to give.

When the hint comes, use it. It’s tempting to treat a hint as a mark against you and carry on without it, but the interviewer is giving you a way to make progress.

When you’ve never used the tool

Sometimes the question is about a tool you’ve never used. Don’t talk around it. Say so, and offer the nearest thing you do know:

“I haven’t worked with Kafka. I’ve used RabbitMQ for the same kind of job, passing events between services. I can walk you through how I set that up, or talk through how I’d expect Kafka to differ.”

This gives the interviewer a choice about where to go next. Bluffing makes follow-up questions harder and gives them a reason to doubt your other answers.

You don’t need to apologize over and over. Say “I’m not sure,” then explain what you do know, how you’d find out, or what you’d try first.

The same thing in behavioral rounds

“Tell me about a time you disagreed with your manager.” Nothing comes to mind.

Ask for a moment here too. If you still have no exact match, offer a close one and say that’s what it is: “I haven’t had a real disagreement with a manager, but I pushed back on a tech lead’s design last year. Can I use that?”

Don’t make a story up. You’ll need to answer questions about who said what, what you did next and how it turned out months later.

You can prevent most of these blanks ahead of time. Write down five or six situations you can tell from memory: a conflict, a failure, a deadline you nearly missed, a decision you’d make differently, something you led. Most behavioral questions fit one of them.

Lines worth having ready

After the interview, write down the questions you missed while you still remember the wording, and look them up that evening. The same questions come around again at other companies.