Common Interview Mistakes Freshers Make (and How to Avoid Them) 2026
Placement preparation focuses heavily on what to do. This guide focuses on what not to do. Candidates report that many rejections at TCS, Infosys, Amazon, and...
What changed in 2026 drives
Mass-recruiter offer letters are flatter for 2026 batch - the 4-5 LPA ASE band has barely budged in three years while inflation eats real wages. Premium tracks (Digital, Pro, Elite, Specialist) are still where the differential lives, and they are entirely test-driven. If you are aiming higher than the default offer, the coding round is not optional pageantry - it is the entire interview.
What I'd actually study for this
- 01Two solid coding-round answers (1 medium-hard DSA each, with edge-case discussion) > five half-baked ones
- 02One real project you can defend end-to-end - file paths, design decisions, and what you would change
- 03One DBMS schema you actually built (not a textbook ER diagram), with at least 3 join-heavy queries written from memory
- 04Three behavioural STAR stories: failure recovered, conflict handled, ownership taken
Where most candidates trip up
The single biggest mistake is treating company-specific guides as primary prep and DSA as secondary. It is the opposite. Mass recruiters use the test as a filter, but premium tracks at every IT services company use coding to allocate offer band. Spend 70% of prep time on DSA + system fundamentals, 20% on company-specific patterns, 10% on HR rehearsal. Reverse that ratio and you collect the default offer.
Editorial commentary by Aditya Sharma · written for PapersAdda · not generated, not aggregated.
Placement preparation focuses heavily on what to do. This guide focuses on what not to do. Candidates report that many rejections at TCS, Infosys, Amazon, and product companies come from avoidable mistakes. Based on public preparation resources and candidate-reported interview accounts, the same mistakes appear repeatedly across campus placement seasons.
Before the Interview
Mistake 1: Lying on the resume
The mistake: Listing technologies, frameworks, or tools you've never actually used or have only heard about. Writing "Machine Learning" because you watched 2 YouTube videos. Putting "React" because you followed a tutorial once.
Why it fails: Technical interviewers probe every skill on the resume. "You listed React -- tell me about the state management approach you used." If you can't answer, the credibility of your entire resume collapses.
The fix: Only list skills you can discuss for 5-10 minutes at interview depth. For skills you know shallowly, list them under "Exposure" or "Beginner" rather than presenting them as core skills. Removing skills from your resume is better than being caught bluffing on them.
Mistake 2: Not researching the company
The mistake: Walking into an interview without knowing what the company does, what products or services it offers, or why you're interested in that specific company.
Why it fails: "Why do you want to work at [Company]?" is a guaranteed question. "Because it's a good company with growth opportunities" is the answer given by candidates who did not prepare.
The fix: Spend 20-30 minutes before the interview on the company's website, recent news, and LinkedIn. Know: what does the company do? Who are their clients or users? What technology stack do they mention? What are they known for? One specific observation is worth more than generic enthusiasm.
Mistake 3: Not preparing for the company's specific process
The mistake: Treating all interviews as interchangeable. TCS interviews are different from Amazon interviews, which are different from a startup interview.
Why it fails: Preparing for FAANG-style algorithm problems and walking into a TCS service company interview -- or vice versa -- means you're optimizing for the wrong things.
The fix: Research the company's interview process. Sites like Glassdoor, PrepInsta, and college placement cells often have candidate-reported interview formats. Know: is there a coding round? What type (DSA, SQL, logic)? Is there a technical interview? How many HR rounds? What competencies does the HR focus on?
Mistake 4: Underestimating basics
The mistake: Spending all preparation time on advanced topics (system design, ML) while neglecting core fundamentals (OS, DBMS, CN, OOP, data structures).
Why it fails: Interviewers at all types of companies -- service and product -- probe fundamentals. You can fail an Amazon interview on a basic recursion problem. You can fail a TCS interview for not knowing what a deadlock is.
The fix: Fundamentals first, advanced topics second. Ensure you can explain: the 4 pillars of OOP with code examples, process vs thread, SQL joins, TCP vs UDP, and time/space complexity for standard algorithms. These appear across every type of interview.
During Technical Rounds
Mistake 5: Jumping to code before understanding the problem
The mistake: Starting to write code the moment the problem is stated, without clarifying the requirements, discussing examples, or considering edge cases.
Why it fails: You solve the wrong problem. Or you solve the right problem with no edge case handling. Interviewers are evaluating your thinking process, not just the code. Rushing to code suggests you don't think before acting.
The fix: Before writing a single line, ask 2-3 clarifying questions:
- "What should I return if the input is empty?"
- "Can I assume the input is sorted?"
- "What's the expected scale -- is optimization important?" Then state your approach out loud before coding. "I'm thinking of a two-pointer approach because..." This shows reasoning.
Mistake 6: Freezing silently when stuck
The mistake: Hitting a wall on a problem and sitting silently for minutes. The interviewer watches you stare at the board in silence.
Why it fails: Silence does not help you and it makes the interviewer uncomfortable. More importantly, it denies the interviewer the chance to give hints or redirect you.
The fix: Think out loud. "I'm trying to think of whether a hash map could help here... the problem is duplicates... what if I track frequency?" Even incorrect thinking out loud is more valuable than silence. Interviewers often hint when they hear you get close. And thinking aloud gives partial credit for the approach even if you don't reach the solution.
Mistake 7: Not testing your solution
The mistake: Writing the code and presenting it without tracing through a test case.
Why it fails: Common bugs (off-by-one errors, edge cases, wrong loop termination) only surface when you test manually. Submitting untested code signals you don't validate your own work.
The fix: After writing the code, immediately trace through a simple example. Then test at least one edge case: empty input, single element, all same values, maximum/minimum values. Do this before saying "this is my solution."
Mistake 8: Claiming unfamiliar concepts rather than saying you don't know
The mistake: When asked about something you don't know (say, MVCC in databases), making up or guessing an explanation that sounds plausible rather than admitting uncertainty.
Why it fails: Experienced interviewers immediately recognize when candidates are guessing. One follow-up question exposes the bluff. Worse, it signals intellectual dishonesty -- a trait no employer wants.
The fix: "I haven't worked with that directly. Could you give me a brief context and I'll reason through it?" or "I know the concept at a surface level but not well enough to explain it accurately -- I'd rather not guess. Can I tell you what I do know about [related concept]?" Honesty combined with an offer to contribute what you do know is always better than bluffing.
Mistake 9: Not asking clarifying questions in system design
The mistake: When given a system design question like "Design a URL shortener," immediately diving into architecture without establishing requirements.
Why it fails: System design answers change significantly based on scale. "Design a URL shortener for 100 users" and "Design a URL shortener for 100 million users" have completely different answers.
The fix: Always start system design with:
- What scale? (users, requests per second, data volume)
- What are the core features? (which to prioritize)
- Any specific constraints? (availability vs consistency trade-offs) This demonstrates engineering maturity -- real engineers always start with requirements.
Mistake 10: Giving only the brute force answer without considering optimization
The mistake: Solving the problem with O(n^2) or O(n^3) complexity and presenting it as the final answer, without mentioning that a better approach might exist.
Why it fails: Interviewers almost always expect discussion of complexity. Presenting only the brute force solution suggests you've stopped thinking.
The fix: After presenting the brute force, say: "This is O(n^2). I think we can do better -- let me think about whether a different data structure would help..." Showing you know the solution can be improved, even if you don't reach the optimal, is better than presenting brute force as optimal.
During HR Rounds
Mistake 11: Speaking negatively about previous experiences
The mistake: Saying negative things about professors, previous interviewers, your college, classmates, or a past employer/internship.
Why it fails: Interviewers think: if this candidate talks this way about their past experiences, they'll talk this way about us after they leave. It signals poor interpersonal maturity.
The fix: You can acknowledge difficulties without negativity. "My internship had some communication challenges" instead of "my manager was terrible." "I learned from the experience even though it was not ideal" instead of "it was a waste of time." Frame every experience as a learning, even bad ones.
Mistake 12: Generic, vague answers to behavioral questions
The mistake: Answering "Tell me about a time you showed leadership" with "I have always been a natural leader and I guide my team in the right direction."
Why it fails: This answers nothing. There is no situation, no specific action, no outcome. Interviewers hear this and think the candidate has no real experience to share.
The fix: Use STAR (Situation, Task, Action, Result). Name the specific project, your specific role, your specific actions, and the specific outcome. Even a small academic project story with real details is more compelling than a vague claim about general leadership.
Mistake 13: Not asking any questions at the end
The mistake: When asked "Do you have any questions for us?" saying "No, I think everything is clear."
Why it fails: Not asking questions signals either lack of preparation or lack of genuine interest. It's also a missed opportunity to learn something useful about the role.
The fix: Prepare 2-3 questions to ask every interviewer. Good questions:
- "What does the onboarding process look like for new engineers?"
- "What does success in this role look like in the first 6 months?"
- "What's the biggest technical challenge the team is currently working through?"
- "What opportunities exist for growth into senior roles from this position?"
Avoid questions about salary in technical rounds and questions easily answered on the website.
Mistake 14: Dressing inappropriately for the culture
The mistake: Showing up overdressed (formal suit for a casual startup) or underdressed (casual t-shirt for a formal banking interview).
Why it fails: First impressions matter. Dressing far outside the norm for that workplace signals either you didn't research the culture or you don't notice cultural cues.
The fix: Research the company's culture beforehand. For most Indian tech companies, business casual (formal shirt, trousers) is universally appropriate and rarely wrong in either direction. When in doubt, slightly overdress rather than underdress.
Mistake 15: Showing desperation or excessive eagerness
The mistake: Repeatedly saying "I really need this job" or "This is the only company I've applied to" or following up multiple times after a one-day silence.
Why it fails: Desperation shifts negotiating power entirely to the employer and can signal the candidate has no other options. Excessive eagerness can also make interviewers uncomfortable.
The fix: Be genuinely enthusiastic but composed. "I'm very interested in this role and I believe I'd do well here" is confident. Following up once after a week is appropriate. "Please please hire me, I'll do anything" is not.
After Technical Questions
Mistake 16: Getting defensive when the interviewer challenges your answer
The mistake: When an interviewer says "Are you sure this is correct?" or "What about this edge case?", becoming defensive or repeating your answer without engaging the challenge.
Why it fails: Interviewers often challenge correct answers to see how candidates handle pressure. Getting defensive and digging in rather than engaging the question suggests poor collaboration style.
The fix: Welcome challenges as a collaborative problem-solving exercise. "That's a good point -- let me think about that edge case." If you remain confident in your answer: "Let me trace through your case specifically... I think it holds because... but tell me if I'm missing something." This is collegial, not combative.
Mistake 17: Not knowing your own projects deeply
The mistake: Writing a project on your resume that you can explain only at a surface level. "I built a chatbot" -- but cannot explain the architecture, the challenges you faced, or the specific decisions you made.
Why it fails: Projects on your resume are guaranteed to be probed. "Walk me through your project architecture." "What was the hardest part?" "Why did you choose this database?" If you can't answer these, it looks like you copy-pasted a tutorial.
The fix: For every project on your resume, be able to answer: What problem does it solve? What is the architecture? What libraries/frameworks did you use and why? What was the hardest bug? What would you do differently? What is the time complexity of the critical algorithm? Practice this.
Mistake 18: Forgetting to state time/space complexity
The mistake: Writing a perfectly correct algorithm without mentioning Big-O complexity.
Why it fails: At every technical interview, time and space complexity analysis is expected. Omitting it suggests you don't think about performance, which is a core engineering concern.
The fix: After every coding problem, automatically add: "This solution is O(n) time and O(n) space because [brief reason]." If you don't know the exact complexity, reason through it: "For each element we do constant work, so it's O(n)."
Communication Mistakes
Mistake 19: Speaking too fast when nervous
The mistake: Nerves cause rapid speech that becomes hard to follow, with key words rushed or swallowed.
Why it fails: If the interviewer can't follow you, your content is lost. Fast speech also signals anxiety, which can lower your perceived confidence.
The fix: Consciously slow down in the first 60 seconds of each round. Take a deliberate breath before answering each question. A slightly slower, clearer pace sounds more confident, not less. Practice out loud before the interview.
Mistake 20: Using too many filler words
The mistake: "So, like, I basically, you know, kind of built this project, like, and it was, you know, pretty good."
Why it fails: Filler words reduce perceived competence and fluency. They also slow communication and can frustrate the interviewer.
The fix: Record yourself answering 3-4 practice questions. Count the fillers. Becoming aware of them is the first step. In the interview, brief silences ("Let me think for a second") are better than filler-heavy rambling.
Mistake 21: Not making eye contact (in person or camera contact in video)
The mistake: Looking at the desk, the wall, or your own face in a video interview instead of at the interviewer.
Why it fails: Lack of eye contact signals discomfort, lack of confidence, or disengagement -- all of which create a negative impression regardless of content.
The fix: In video interviews: look at the camera, not your own preview. In person: maintain natural eye contact during answers, not staring but consistent engagement. This signals confidence and engagement.
Mistake 22: Pretending to understand when you don't
The mistake: Nodding and saying "yes" when you didn't understand the question or the hint the interviewer just gave.
Why it fails: You then proceed to answer the wrong question, or ignore a hint that would have helped you solve the problem.
The fix: "Could you rephrase that?" or "I want to make sure I understand correctly -- are you asking about X?" Confirming understanding before answering saves far more time than proceeding confidently in the wrong direction.
Mindset Mistakes
Mistake 23: Treating all rounds equally
The mistake: Treating the HR round as a formality after passing the technical round, or vice versa.
Why it fails: Candidates are rejected in HR rounds after strong technical performance. HR round is an evaluation, not a celebration.
The fix: Prepare equally for HR and technical rounds. Have STAR stories ready. Know your "Tell me about yourself" cold. Have questions ready for the interviewer. HR evaluators specifically note candidates who seem unprepared or disengaged in their round.
Mistake 24: Catastrophizing after a bad round
The mistake: Spiraling mentally after one bad answer or one bad round, letting it affect the rest of the interview.
Why it fails: One wrong answer rarely kills an interview if the rest is strong. But letting one bad moment ruin your confidence for the remaining questions amplifies the damage.
The fix: If you know you gave a bad answer: "Actually, let me reconsider that -- I think I missed an edge case earlier. The correct approach would be..." Correcting yourself demonstrates self-awareness and persistence. If it was a full round that went poorly: reset between rounds. The next interviewer does not know how the previous one went.
Mistake 25: Not following up after the interview
The mistake: After the interview is over, doing nothing.
Why it fails: A brief thank-you email or LinkedIn note is a small differentiator that most candidates do not send. It also gives you one more chance to mention something you forgot to say.
The fix: Within 24 hours, send a brief message (email or LinkedIn) to your recruiter contact: "Thank you for the interview opportunity today. I enjoyed the conversation, particularly the discussion about [specific topic]. I remain very interested in the role and look forward to hearing about next steps." Keep it short. One paragraph. This is not required, but it adds a small positive data point.
Quick Reference: Mistake Checklist
Before interview:
- All resume skills are genuinely interview-ready
- Company research done (what do they do, why do you want to work there)
- Interview format researched (rounds, types, typical questions)
- Fundamentals revised (DS, Algo, OOP, OS, DBMS, CN basics)
During technical round:
- Clarify problem before coding
- Think out loud, especially when stuck
- Test solution manually before presenting
- State time and space complexity
During HR round:
- STAR stories prepared for at least 8 behavioral themes
- No negative talk about any past experience
- 2-3 questions ready to ask the interviewer
General:
- Speak clearly, not too fast, not too much filler
- Camera/eye contact maintained
- Ask for clarification rather than proceeding confused
Frequently Asked Questions
Q: Is it okay to ask for time to think during a technical question? Yes. "Give me a moment to think through this" is completely acceptable. 30-60 seconds of real thinking is better than immediately heading in the wrong direction.
Q: I have a placement interview tomorrow and haven't prepared much. What should I focus on? In order of priority: (1) Your resume projects -- know them cold. (2) Your most important technical skill on the resume -- be ready for 10 minutes of depth. (3) Your self-introduction. (4) "Why do you want to work here?" -- 2 sentences of genuine research. (5) One STAR story about your best project. This is the minimum for a credible interview.
Q: How do I handle an interviewer who seems bored or unengaged? Don't let their demeanor change yours. Maintain your energy and quality. Some interviewers are simply process-oriented and show little visible reaction regardless of answer quality. The evaluation happens even when they seem disengaged.
Q: I got nervous and gave a wrong answer I know is wrong. Should I bring it up later? Yes. "I want to revisit something I said earlier -- I realize my answer about [topic] was incorrect. The correct answer is [X]. I apologize for the confusion." This demonstrates intellectual honesty and self-correction, which is a positive signal.
Internal Links
Methodology applied to this articlelast verified 8 Jun 2026
- No fabricated salary numbers or success rates. If we quote a range, it's sourced.
- No noun-substituted templates. This article was not generated by swapping company names in a stock prompt.
- No paid placements, sponsored coaching links, or affiliate-shilled course pushes.
topic cluster
More resources in Interview Questions
Use the category hub to browse similar questions, exam patterns, salary guides, and preparation resources related to this topic.
paid contributor programme
Sat this this year? Share your story, earn ₹500.
First-person experience reports help future candidates prep smarter. We pay verified contributors ₹500 via UPI per accepted story with byline.
Submit your story →ready to practice?
Take a free timed mock test
Put what you learned into practice. Our mock tests match the 2026 pattern with timer, navigator, reveal, and score breakdown. No signup.