How to Answer Questions You Don't Know in Interviews: 5 Strategies to Minimize Point Loss

How to Answer Questions You Don't Know in Interviews: 5 Strategies to Minimize Point Loss

Introduction

I've done over a dozen big tech interviews, and there's one brutal truth: nobody answers every question correctly. At ByteDance's third round, they asked about Raft protocol implementation details — I only knew the basics. At Alibaba's second round, they asked me to hand-write red-black tree insertion — I was completely stumped. At Meituan's first round, they asked about MySQL Gap Lock behavior under RC isolation — my answer was vague. But I passed all these interviews. Why? Because I learned how to answer questions I don't know. Interviews aren't exams where you need perfect scores — interviewers evaluate your thinking process and adaptability. Here are 5 battle-tested strategies.

Strategy 1: Be Honest About Not Knowing, But Show Your Thinking Process

This is the most fundamental and important strategy. Never pretend to know something you don't. Interviewers know far more than you — they'll see right through you. Faking knowledge only makes you look dishonest, which is an immediate deduction.

Right approach: "I'm not very familiar with this, but let me try to analyze it. If I were designing this, I might consider..."

Wrong approach: "Um... I know this, it's... you know..." (then starts rambling)

At Alibaba's second round, I was asked about the difference between Java's ForkJoinPool and regular thread pools. Honestly, I only knew how to use it, not the deep internals. My answer: "I've used ForkJoinPool in projects — I know it uses divide-and-conquer with work-stealing, suitable for recursive tasks. But the specific scheduling differences from regular thread pools, I haven't studied in depth. However, I'd guess that work-stealing means each thread has its own task queue, and idle threads can steal from other queues, reducing contention." The interviewer nodded and said "the general direction is right," then explained the specific scheduling differences. I passed that round.

Key points: 1) Clearly say "not familiar with" rather than being vague; 2) Share related information you do know; 3) Use "if I were designing this" to show analytical ability; 4) Let the interviewer see your thinking logic, not rote memorization.

Strategy 2: Approach from Related Knowledge Points

The interviewer asks something you don't know, but you probably know some related knowledge. Share these connections to demonstrate your breadth and ability to make associations.

At Kuaishou's first round, I was asked "How does Kafka implement Exactly-Once semantics?" I only knew the concept. But I knew about Kafka's transaction mechanism and idempotency, so I approached from that direction: "I'm not clear on the exact implementation details of Exactly-Once, but I know Kafka approaches this through idempotent Producer and transaction mechanisms. Idempotency is achieved through Producer-side sequence number deduplication, and transactions through two-phase commit for atomicity. Also, from the consumer side, achieving Exactly-Once requires idempotent processing on the business end, because Kafka only guarantees At-Least-Once delivery."

The interviewer said "What you said is correct — Exactly-Once is the combination of these mechanisms," then moved to the next question. If I had just said "I don't know," the interviewer might have concluded I had a shallow understanding of message queues.

How to execute: 1) Quickly search your brain for keywords related to the question; 2) Choose the direction you're most familiar with and expand; 3) Clearly state "this is a related concept, not the direct answer"; 4) Show you can connect scattered knowledge points.

Strategy 3: Ask for Hints and Progress Step by Step

Interviews aren't one-way assessments — interacting with the interviewer is itself a skill. When you're stuck, you can ask for hints, but be careful about how — ask for direction, not the answer.

At Pinduoduo's second round, I was solving an algorithm problem: given an array, find all possible subsets. My first instinct was backtracking, but halfway through the code got messy. I stopped and asked the interviewer: "My current approach is backtracking — choose or not choose each element — but I'm stuck on code organization. Is this direction correct?" The interviewer said "The direction is fine, think about the recursion termination condition and path recording." That hint instantly cleared my thinking, and I finished writing in 5 minutes.

The right way to ask for hints: 1) First state your current approach and where you're stuck; 2) Ask "is this direction correct?" not "what's the answer?"; 3) After getting the hint, progress quickly to show your learning ability; 4) Don't ask too frequently — at most 1-2 hint requests per interview.

Counter-example: A friend of mine, when encountering a question he didn't know, directly asked "can you give me a hint?" The interviewer asked "what have you thought of so far?" He said "I haven't started thinking yet." That's a major deduction — you need to at least show you've tried.

Strategy 4: Offer Solutions to Similar Problems

If you truly don't know the answer to the interviewer's question, but you know the solution to a similar problem, proactively bring it up. This demonstrates your ability to transfer knowledge and think by analogy.

At ByteDance's second round, I was asked to "design a URL shortener system." Honestly, I'd never built one. But I knew similar system designs — I'd worked on ID generation and database sharding projects. So I said: "I haven't actually built a URL shortener, but I can analyze it from several core problems: 1) Short URL generation — could use Snowflake algorithm or Base62 encoding; 2) Storage and lookup — mapping short to long URLs, large data volumes need sharding; 3) Redirection — use 302 instead of 301 to track click counts; 4) Caching — cache hot short URLs with Redis. These approaches are similar to my previous distributed ID generation and sharding projects."

The interviewer later told me they didn't expect me to have built a URL shortener — they wanted to see my analytical approach. My analysis from similar experience was stronger than candidates who just recited answers.

Key points: 1) First state you haven't worked on this specific problem; 2) List the core sub-problems; 3) For each sub-problem, offer solutions from your existing experience; 4) Clearly note "this is analogical reasoning and may not fully apply."

Strategy 5: Follow Up After the Interview

For questions you didn't answer well during the interview, you can proactively follow up afterward. This doesn't apply to every situation, but it can be very effective in certain cases.

At Meituan's second round, I was asked "Are you familiar with Redis Stream?" I only knew it was a message queue feature added in 5.0, but couldn't explain details. After the interview, I spent an hour studying Redis Stream's structure (Consumer Group, XPENDING, XACK, etc.), then sent the interviewer an email: "Regarding the Redis Stream question today, let me supplement my understanding: it's essentially an in-memory message queue supporting Consumer Group consumption mode, with XPENDING to view pending messages and XACK to confirm consumption. Compared to Kafka, it's lighter but not suitable for large-scale scenarios."

The interviewer replied "Great supplement — looks like you have strong learning ability." I ended up getting the offer. Of course, not all interviewers will read follow-up emails, but sending one at least doesn't hurt and shows your attitude and learning ability.

Things to note about post-interview follow-ups: 1) Send it the same day, don't wait until the next; 2) Content should be specific and in-depth, not superficial; 3) Tone should be humble — "supplementing my understanding" not "I actually knew this"; 4) Don't send for every interview — only for key questions; 5) If the interviewer didn't leave contact info, you can relay through HR.

Summary of Real Questions

Here are questions I successfully handled using these 5 strategies:

1. ForkJoinPool vs ThreadPoolExecutor → Strategy 1 (honest + analysis) → Passed

2. Kafka Exactly-Once → Strategy 2 (related knowledge) → Passed

3. Subset algorithm stuck → Strategy 3 (ask for hint) → Passed

4. URL shortener design → Strategy 4 (similar problem solution) → Passed

5. Redis Stream → Strategy 5 (post-interview follow-up) → Passed

6. Raft protocol implementation → Strategy 1+2 → Passed

7. MySQL Gap Lock under RC → Strategy 2 (reasoning from RR) → Passed

Tips and Advice

1. Not knowing is normal — don't let one question you can't answer break your confidence. Interviews are comprehensive evaluations; one question doesn't determine the outcome.

2. Attitude matters more than answers — interviewers care more about how you face the unknown: do you evade, fake knowledge, or think actively?

3. Build related knowledge regularly — the broader your knowledge, the more effective Strategies 2 and 4 become. Much knowledge is interconnected.

4. Practice "thinking out loud" — verbalize your thought process. Silence is the biggest enemy in interviews — interviewers can't see what you're thinking.

5. Review after each interview — note questions you couldn't answer and learn them. Every interview is a learning opportunity; the more you interview, the fewer "don't knows" you'll have.

FAQ

Q: Will saying "I don't know" get me eliminated?

A: No. Interviewers ask hard questions specifically to see how you handle the unknown. Being honest + showing your thinking process is a hundred times better than faking knowledge.

Q: Does asking for hints make me look incompetent?

A: No, but be careful about how. Show your thinking first, then ask if the direction is correct. Interviewers appreciate communicators more than people who silently struggle.

Q: Do post-interview follow-up emails really work?

A: Not every time, but at Meituan it genuinely helped me get the offer. The key is that the supplementary content must be in-depth, not perfunctory.

Q: What if I have absolutely no idea about a question?

A: At least share your first reaction and intuition. Like "I haven't encountered this problem before, but intuitively it might relate to XX because..." Then ask the interviewer for a direction. Complete silence is worse than a wrong answer.