10 Most Common Interview Pitfalls: 90% of People Make Mistake #7

Background

I've done over 30 interviews, landed 6 offers, and failed more times than I can count. Looking back, most interview failures weren't because of technical shortcomings — they were because of invisible pitfalls. Nobody teaches you these pitfalls, and interviewers won't tell you about them, but they silently kill your chances. I've compiled the 10 most common ones, each based on real experiences from me or people I know, hoping to save you some painful lessons.

Interview Replay: 10 Most Common Pitfalls

Pitfall 1: Self-Introduction Too Long

My first big tech interview, I rambled through a 5-minute self-introduction — from college clubs to internships to every project detail. The interviewer's expression went from a smile to checking their watch. I later learned that once you pass the 2-minute mark, interviewers stop paying attention.

Real Case: My colleague Chen interviewed at Meta and spent 4 minutes on his intro, covering every project. The interviewer cut him off: "OK, let's jump into the technical portion." Chen never got the chance to deep-dive into his projects, and he didn't get the offer.

Correct Approach: Keep your intro to 1.5-2 minutes. Cover only 3 core points: who you are, your most impressive achievement, and why you're a fit. Save the details for when the interviewer asks follow-up questions.

Pitfall 2: Memorizing Without Understanding

I used to do this too — memorizing system design cheat sheets front to back. When the interviewer asked about consistent hashing, I recited the textbook answer perfectly. But when they followed up with "In what real-world scenario would consistent hashing actually cause problems, and how would you handle it?" I froze.

Real Case: My friend Liu memorized an entire interview prep book. At his Google interview, he nailed the first 20 minutes. Then the interviewer asked: "Have you actually encountered any of these concepts in a real project? How did you apply them?" Liu couldn't answer — he'd never used these concepts in practice, he'd only memorized the answers. The feedback: "Solid fundamentals, but lacks practical understanding and application ability."

Correct Approach: Yes, study the fundamentals, but always connect them to real project experience. For every concept you learn, ask yourself: "Where have I used this? What problems did I encounter? How did I solve them?" Being able to describe real scenarios is what convinces interviewers you truly understand.

Pitfall 3: Projects Without Data

Early in my career, I'd describe projects with vague phrases like "improved system performance" or "enhanced user experience." When the interviewer asked "By how much?" I'd stumble. Project descriptions without data are just empty claims in an interviewer's eyes.

Real Case: My former colleague Zhao interviewed at Amazon and described his recommendation system optimization as "very effective, users were much more satisfied." The interviewer pushed back: "What was the specific improvement? What was the CTR? What were the A/B test results?" Zhao couldn't produce a single number. The interviewer said point-blank: "If you can't articulate the core metrics of your own project, how can I trust you actually did this optimization?"

Correct Approach: Prepare at least 3 core data metrics for each project. For example: "Reduced API response time from 800ms to 200ms, increased QPS by 3x, and decreased production incident rate by 60%." The more specific the data, the more credible your claims.

Pitfall 4: Writing Code Without Communicating

My first coding interview, I read the problem and immediately started writing code. After 10 minutes, the interviewer said, "Are you sure you understood the problem correctly?" I looked again — I'd misunderstood it completely. All that code was wasted. Worse, some interviewers want to see your thought process, and coding in silence makes you seem like a poor communicator.

Real Case: My junior colleague Sun interviewed at Uber and got a medium-difficulty problem. He started coding immediately and finished in 15 minutes. The interviewer asked, "Did you consider edge cases? What if the input is an empty array?" Sun's code had zero edge case handling. The interviewer later told him there was actually a more optimal solution — if Sun had discussed his approach first, the interviewer would have guided him toward it.

Correct Approach: Spend 1-2 minutes confirming the problem with the interviewer, then say "Here's my approach... does that sound reasonable?" Only start coding after confirmation. As you code, explain your thinking out loud so the interviewer can follow your reasoning.

Pitfall 5: Badmouthing Your Previous Company

The interviewer asked, "Why are you leaving your current company?" and I blurted out, "The company is toxic and my manager is terrible." I regretted it instantly — the interviewer's expression visibly changed. No matter how bad your previous company was, badmouthing it only makes you look unprofessional.

Real Case: A PM I know, Zhou, interviewed at Stripe and was asked about his reason for leaving. He said, "My last company was poorly managed, the product direction changed daily, and the CTO didn't understand technology." The interviewer said nothing at the time, but HR later fed back: "The candidate was overly negative about his previous company — we're concerned he'd speak about us the same way someday."

Correct Approach: Reframe negative reasons as positive aspirations. Instead of "my company was terrible," say "I'm looking for bigger technical challenges," "I want to grow in a more mature team," or "I want the opportunity to work on higher-impact projects." Interviewers know why you're leaving — they want to see your attitude and perspective.

Pitfall 6: Undervaluing Yourself in Salary Negotiation

The first time I negotiated salary, HR asked for my expectations and I said, "Market rate is fine." The offer I got was 20% below market. I later learned that "market rate" in HR's ears translates to "minimum rate".

Real Case: My friend Wu, a backend developer with 3 years of experience, was interviewing at a mid-size company. Afraid of pricing himself out, he told HR, "15K is fine." He later discovered the budget for the role was 18-22K. Because he lowballed himself, he not only got the lowest-tier offer but also hurt his future raise potential — his base was too low.

Correct Approach: Research market rates beforehand (levels.fyi, Glassdoor, Blind) and give a justified range. For example: "Based on my experience and market data, my expected compensation is in the range of $150K-$180K." If you're unsure, flip the question: "What's the compensation range for this role?"

Pitfall 7: Going Silent When You Don't Know the Answer (90% of People Make This Mistake)

This is the pitfall I want to emphasize the most, because I've fallen into it myself, and I've observed that 90% of candidates make the same mistake — when they encounter a question they can't answer, their mind goes blank, and they go completely silent.

The moment that sticks with me most was interviewing at a FAANG company. The interviewer asked, "How would you design a URL shortener that's highly available?" I had zero preparation for system design. My mind went completely blank, and I sat there in silence for about 30 seconds. Those 30 seconds were the longest of my life. The interviewer waited a bit and said, "You can share your thoughts, even if they're not fully formed." But I was already panicking — I mumbled a few words and gave up.

Real Case: My colleague Lin was interviewing at Lyft and got asked, "What are the different Redis clustering strategies, and what are the pros and cons of each?" Lin only knew about master-slave replication and Sentinel — he wasn't familiar with Redis Cluster. He chose to go silent, staring down at his desk for nearly a full minute. The interviewer later told me (yes, that interviewer later became my colleague): "When he went silent, I was more uncomfortable than he was. If he'd just said, 'I'm not deeply familiar with Cluster, but I know it's a distributed solution — can I share my understanding of distributed systems instead?' I would have been happy to continue the conversation. Silence is the worst possible choice because it tells me he doesn't just lack knowledge — he lacks communication skills too."

Why do 90% of people go silent? Because our instinctive reaction is "I don't know = I'll look stupid = shut up." But what interviewers really want to see isn't whether you know the answer — it's how you respond to the unknown. Encountering problems you don't know how to solve is a daily reality at work. Interviewers want to know: Can you think on your feet? Can you break down a problem? Are you willing to communicate? Silence tells the interviewer, "I give up when things get hard."

Correct Approach (This Is Critical): When you encounter a question you can't answer, remember this formula: Acknowledge what you don't know + Share what you do know + Propose a direction for thinking + Ask the interviewer for guidance. For example: "I'm not deeply familiar with Redis Cluster, but I know it's Redis's official distributed solution that supports automatic sharding and failover. If I were to reason through it, I'd think about data sharding strategy, node communication, and failure detection. Could you give me a hint about which direction to explore?" This kind of response shows the interviewer you think clearly, you're proactive, and you communicate well — and those qualities matter far more than getting one question right.

Pitfall 8: Not Preparing for the "Do You Have Questions" Part

At the end of the interview, the interviewer asked, "Do you have any questions for me?" I said, "No, I think we covered everything." The interviewer looked disappointed. I later learned that the reverse Q&A is a key signal interviewers use to gauge your interest level and depth of thinking.

Real Case: My friend Yang interviewed at Airbnb and aced the technical rounds, but when the reverse Q&A came, he said, "No questions." HR later fed back: "The candidate didn't seem highly interested — no desire to deeply understand the role." Another candidate had asked, "What's the biggest technical challenge your team is facing right now? What would a new hire be responsible for in the first 3 months?" The interviewer felt that candidate showed more initiative and thoughtfulness.

Correct Approach: Before every interview, prepare 3-5 questions to ask. Examples: "What's the most important project your team is working on?" "What are the main goals for this role in the first 6 months?" "What traits do people who succeed on your team have in common?" These questions demonstrate your engagement and also help you evaluate whether the role is right for you.

Pitfall 9: Not Testing Your Equipment Before the Interview

In the era of virtual interviews, equipment issues can genuinely destroy an interview. Once, I turned on my camera and the image was blurry — it took 5 minutes to fix, and the interviewer was already getting impatient. Even worse, a friend of mine was mid-interview when his microphone suddenly died. By the time he switched devices, the interviewer had disconnected.

Real Case: My former colleague Zheng interviewed at Microsoft using his laptop's built-in camera — the image was dark and grainy. The interviewer asked, "Can you switch to a better camera?" Zheng didn't have one, so he had to make do. The feedback: "Candidate seemed unprepared — didn't take the interview seriously enough." One camera cost him a Microsoft interview.

Correct Approach: Test all your equipment 30 minutes before the interview — camera, microphone, internet, and the interview platform. Have a backup plan ready: mobile hotspot, spare earbuds, and the mobile version of the interview app. Join the meeting room early and verify everything works.

Pitfall 10: Not Following Up After the Interview

I used to just walk away after interviews and never proactively reach out to HR. Then I realized that candidates who follow up proactively get higher impression scores from interviewers, especially when candidates are similarly qualified.

Real Case: Another candidate and I both interviewed at the same company with similar technical levels. The day after my interview, I sent HR a thank-you email, expressing gratitude for the opportunity and supplementing my answer to a question I hadn't nailed during the interview. The other candidate did nothing. I got the offer, and HR later told me: "Your follow-up email showed genuine interest, and the supplementary answer resolved our concerns."

Correct Approach: Send a thank-you email within 24 hours of the interview. Include: thanks for the interviewer's time, a supplement to any question you didn't answer well, and a reiteration of your interest in the role. It takes minimal effort but could be the extra push that gets you the offer.

Common Interview Questions

High-Frequency Questions (Mapped to Pitfalls Above)

1. Tell me about yourself (Pitfall 1)

2. How does consistent hashing work? What are its limitations in practice? (Pitfall 2)

3. Tell me about the most challenging project you've worked on — what were the measurable outcomes? (Pitfall 3)

4. Coding: Two Sum / Reverse Linked List / LRU Cache (Pitfall 4)

5. Why are you leaving your current company? (Pitfall 5)

6. What are your salary expectations? (Pitfall 6)

7. Design a URL shortener / flash sale system / message queue (Pitfall 7)

8. Do you have any questions for me? (Pitfall 8)

9. (Virtual interview scenario) Your internet drops mid-interview — what do you do? (Pitfall 9)

10. What do you do after an interview? (Pitfall 10)

Key Takeaways

1. Interviews are conversations, not exams. Interviewers aren't testing you — they're getting to know you. Relax and treat it as a technical discussion.

2. Never go silent when you don't know the answer. Sharing your thought process, even if imperfect, is 100x better than silence.

3. Data is the best proof. Project descriptions must include metrics — claims without numbers are just empty words.

4. Prepare thoroughly before every interview. Self-introduction, reverse questions, equipment check — these small things can determine the outcome.

5. Never badmouth your previous company. Reframe negatives as positive aspirations to show your professionalism.

6. Negotiate salary with confidence. Know your market value, provide a justified range, and don't lowball yourself.

7. Always follow up after interviews. A thank-you email could be the key to landing your offer.

FAQ

Q: How long should my self-introduction be?
A: 1.5-2 minutes is ideal. Cover only 3 core points: who you are, your most impressive achievement, and why you're a fit. Save details for follow-up questions.

Q: Should I memorize common interview answers?
A: Yes, but don't just memorize — understand. For every concept, be able to describe a real scenario where you applied it.

Q: What should I do when I completely blank on a question?
A: Remember the formula: Acknowledge what you don't know + Share what you do know + Propose a thinking direction + Ask for guidance. Never go silent.

Q: What questions make the best impression in the reverse Q&A?
A: Ask about the role and team — "What's the biggest technical challenge your team faces?" "What are the first 3 months like for a new hire?" Avoid asking about compensation and benefits — save those for the HR round.

Q: How soon should I send a follow-up email?
A: Within 24 hours. Keep it brief: thanks for their time + supplementary answer + reiterate interest. Don't ask about results — that's a negative signal.

Q: How do I negotiate salary without leaving money on the table?
A: Research market rates beforehand (levels.fyi, Glassdoor, Blind), provide a justified range rather than a specific number, and leave room for negotiation.