Notes from the interview room
It's rarely one big mistake. It's usually a handful of small ones — and most of them happen before you even sit down. Structured, practical prep from IIES can help close that gap.
The interviewer looked at Rahul's resume and smiled.
"Tell me about yourself."
Rahul had prepared this answer at home at least 20 times. He started confidently.
"Good morning, sir. My name is Rahul. I recently completed my engineering degree. I have knowledge of Python, SQL, Java, communication skills, leadership, teamwork, problem-solving…"
The interviewer stopped him.
"Okay. You mentioned Python. Which project did you build using Python?"
Rahul paused.
"Well… actually, I learned Python from an online course."
"Okay. What did you build?"
"I haven't built anything yet."
The room became quiet. Rahul's interview lasted another 10 minutes, but he already knew what had happened. He had prepared for the interview. He hadn't prepared for himself.
This is one of the biggest reasons freshers get rejected in interviews. And surprisingly, it is not always because they don't have enough technical knowledge. Sometimes, it is because they don't know how to present what they already know.
Every year, thousands of freshers attend campus placement interviews. Many prepare for weeks — revising technical subjects, practicing aptitude questions, improving their resumes, watching interview videos. Still, some walk out with an offer while others hear "Thank you for your time. We'll get back to you." The answer is usually a combination of small things that happen inside the interview room. Here's what that actually looks like.
You know the answer. You studied it last night. The interviewer asks what object-oriented programming is, and you deliver the textbook definition perfectly.
INTERVIEWERCan you give me a simple real-world example of polymorphism?
Silence.
This happens more often than you'd think. One of the most common interview mistakes by freshers is preparing definitions without understanding the concept behind them. Interviewers don't always ask questions exactly as they appear in your textbook — they change the wording to see whether you actually understand what you studied. The same thing happens with SQL, Java, Embedded C, electronics, or any other technical subject.
You don't have to know everything. But if you say you know something, be ready to explain it in your own words.
INTERVIEWERPython?
PRIYAYes, sir.
INTERVIEWERGood. What did you use Python for?
PRIYAI know Python basics. I completed a Python course.
INTERVIEWERWhat is the difference between a list and a tuple?
Priya struggles.
The problem isn't that Priya lacks advanced Python — it's that she's written Python prominently under "Technical Skills." Your resume creates expectations. If you mention Python, SQL, Java, Power BI, AutoCAD, Embedded C, or MATLAB, expect to be asked about it.
A good resume isn't the one with the most skills listed. It's the one where you can confidently explain every line. Before submitting yours, ask: if the interviewer points at any line on this resume, can I explain it? If not, remove it, or learn it properly.
"Tell me about your project" sounds like the easiest question in the interview. It shouldn't be. Say your resume lists "Smart Home Automation using IoT." The interviewer starts simple, then keeps going:
Suddenly your five-line project description has turned into a 15-minute technical discussion. Many candidates know the title and the technology names, but not the story of the project. Understand what problem you were solving, why you chose that approach, what went wrong, and what you learned. Explain your project like a story — a PG Diploma in Embedded Systems with AI that includes real builds can give you exactly that kind of story to tell — and the interview gets a lot easier.
One of the most common questions in fresher interviews, and yet many candidates fumble it — starting with their birth year and schooling while the interviewer glances at the clock.
Think of it as a 30–60 second trailer of your professional story, not a biography. Cover your education, relevant skills, a project or internship, something you've learned, and the kind of role you want. For example:
"I recently completed my engineering degree in Electronics and Communication. During college, I became interested in programming and embedded systems, so I worked on a sensor-based project using a microcontroller and UART communication. I particularly enjoyed debugging the hardware-software issues. I'm now looking for an entry-level role where I can keep building on that and contribute to real-world projects."
It doesn't sound like a memorized biography — and it gives the interviewer places to ask the next question. That's exactly what you want.
You've spent two hours preparing technical questions for a company. Then comes: "Why do you want to join our company?" and you answer, "Because it's a reputed company with good career growth" — an answer the interviewer has heard hundreds of times.
You don't need to become an expert on the company. Just understand what it does, what role you're applying for, what skills that role needs, and why it interests you. Then your answer becomes specific instead of generic:
"I'm interested in this role because it matches the programming and project experience I've developed during college, and it would let me work on real-world applications rather than only theoretical tasks."
INTERVIEWERWhat is a deadlock?
CANDIDATEI don't know, sir.
INTERVIEWEROkay — can you explain what a process is?
CANDIDATEI don't know.
One difficult question becomes three, and the candidate starts to panic. But you're not expected to know everything. When you genuinely don't know something, it's far better to say so plainly than to invent an answer:
"I'm not completely sure about that — I haven't worked with that concept yet."
Sometimes the interviewer will even explain it and move on. The goal of an interview isn't to prove you know everything. It's to understand what you know, how you think, and how you respond when you don't know something.
Top 50 HR questions. Top 100 technical questions. Most commonly asked fresher questions. You memorize the answers — then the interviewer asks something slightly different, and everything falls apart. That's because you prepared answers instead of developing understanding.
A better approach is to practice situations, and keep challenging your own answers with follow-ups:
INTERVIEWERWhy did you choose this project?
YOUBecause I was interested in IoT.
INTERVIEWERWhy IoT?
YOUBecause it connects hardware with software and lets devices communicate.
INTERVIEWERWhat communication protocol did you use?
YOUUART.
INTERVIEWERWhy UART instead of SPI?
Now you're having a conversation instead of reciting an answer. That's what real interviews often feel like.
You don't need six months of preparation before your next interview. You need a different question. Instead of asking "what questions will they ask?" — start asking "what can they ask me based on my resume, project and skills?"
Read every line and imagine someone questioning you about it. If you mention a skill, revise it. If you mention a project, understand it deeply. If you mention an achievement, be ready to explain it.
You may understand a topic perfectly on the page, but an interview requires you to explain it out loud. Pick a topic and explain it aloud as if someone were sitting in front of you. If you can't explain it simply, you probably need to understand it better.
Don't stop after the first answer. Keep asking yourself: Why? How? Why did you choose that? What if it didn't work? Can you give an example? These simple follow-ups bring your preparation much closer to a real interview.
He didn't get that job. On his way home, he opened his resume and looked at the skills section — Python, SQL, Java, communication, leadership — and realized he'd spent weeks preparing questions but never seriously asked himself whether he could explain those skills.
So he changed his approach. He removed the skills he couldn't confidently explain. He rebuilt his project and practiced explaining it. He started doing mock interviews. And most importantly, he stopped trying to sound like the "perfect candidate," and focused on becoming a better one.
A few weeks later, at another interview, the question came again: "Tell me about yourself." This time, Rahul didn't recite a memorized paragraph — he told his story. Some technical questions he answered; some he couldn't. For one, he simply said:
"I haven't worked on that yet, but I understand the basic idea and I'd like to learn it."
The interview continued. This time, he walked out feeling different — not because he knew every answer, but because he knew what he knew, and he knew how to communicate it.
Getting rejected doesn't always mean you're not good enough. Sometimes it simply shows you what you need to improve. If you're preparing for campus placements, don't make your goal "I should answer every interview question." Make it: "I should understand my skills, explain my projects, communicate clearly, and stay calm when I don't know something."
That's a far more realistic way to approach how to crack placement interviews. Your first interview may expose your weaknesses. Your second may expose fewer. And eventually, one interview may turn into the offer you've been waiting for.
So if you've recently faced rejection — don't treat it as the final result. Treat it as feedback from the interview room. The next interview could go differently.
Freshers may have good technical knowledge but struggle to explain concepts, communicate clearly, handle follow-up questions, or show confidence during the interview.
Common mistakes include poor preparation, adding skills they cannot explain, giving memorized answers, not understanding their projects, and failing to research the company.
Freshers should revise role-specific fundamentals, understand every skill on their resume, prepare their projects thoroughly, practice HR questions, and take mock interviews.
Don’t guess or make up an answer. Be honest and say that you don’t know or haven’t worked on the topic yet. Staying calm and showing a willingness to learn can leave a better impression.
Indian Institute of Embedded Systems – IIES