The video call connects. The interviewer, a senior engineer with a cold coffee and your resume open on the second monitor, smiles and says, "So, tell me about yourself." You have rehearsed this. You start with your name, your college, your CGPA, your Class 12 percentage, your father's job, your hobbies. Ninety seconds in, you notice the interviewer is scrolling. When you finish, they say, "Okay. You mentioned Spring Boot. What is dependency injection?" And you realise you only wrote Spring Boot on the resume because a tutorial used it.
Nothing in that answer was false. It just did nothing. "Tell me about yourself" is the one question in an IT interview where you choose the direction of the conversation, and most freshers hand that choice straight back.
The short answer
When an interviewer asks you to tell them about yourself, they are doing three things at once: easing you into the conversation, checking whether you can speak clearly about your own work, and looking for the thread they will pull on next. Whatever you mention, they will probe, so your answer is effectively the agenda for the next ten minutes. Keep it to 60 to 90 seconds, spend most of it on one or two pieces of work you can defend in depth, leave out marks and family details unless asked, and end on a specific hook that invites a follow-up about your strongest project. Every claim you make should be one you are happy to be questioned on, because you will be.
Why interviewers open with it
It is a warm-up for both of you
Starting with a question you can definitely answer lets your voice settle before anything hard arrives, and gives the interviewer a minute to re-read your resume. They are still listening, though, and for something specific.
Your answer sets the agenda
This is the part freshers miss. A technical interviewer usually has a loose plan, not a script. When you say "I built a college event booking app with Node and MySQL", you have just given them their next question: how did you stop two people booking the same seat? When you say "I am passionate about AI and cloud", you have given them nothing to work with, so they fall back on generic questions, which are usually harder to answer well.
Think of it this way: whatever you put in your first answer, you are volunteering to be examined on. That is a risk if you mention something you cannot back up, and an advantage if you mention something you know inside out. If you want a feel for how the rest of the session flows from that opening, what happens in a technical interview walks through it stage by stage.
What they are actually assessing
They are listening for three things.
- Communication. Can you say something structured in a minute and a half without rambling, reading, or freezing? This is a preview of how you will explain your approach to a coding problem later.
- Relevance. Do you understand what this job is? A fresher applying for a backend role who spends the whole answer on a photography hobby has told the interviewer they did not think about the audience.
- Whether your claims hold up. Everything you mention is a promise. "I am good at React" will be tested within minutes. Interviewers trust a modest claim that survives questioning far more than an impressive one that collapses.
The variants, and how each one differs
"Tell me about yourself"
The open version. You choose what matters. This is where the hook strategy below matters most, because nothing constrains you.
"Walk me through your resume"
This one asks for a sequence. The interviewer wants a short tour, roughly in order, with the reasoning that connects the steps: why you picked that elective, what the internship taught you, why that led to your final-year project. Do not read the resume aloud; they can already see it. Give them the story behind it, and slow down at the one item you most want them to ask about.
"Introduce yourself"
Common in campus placements and HR rounds, and usually expected to be shorter and more formal. Name, degree, what you have worked on, what you are looking for. 60 to 90 seconds is still the right length. If you want a ready structure and full example introductions to adapt, the self-introduction guide for IT interviews has templates; this article is about what happens around the answer rather than the wording of it.
"Tell me something that is not on your resume"
This tests whether there is a person behind the document. Give something true, specific and ideally connected to how you work: you maintain the WhatsApp bot your hostel uses for mess menus, or you learned to debug by fixing a relative's shop billing software. Avoid generic traits ("I am a hard worker") and anything you would not want to discuss for five minutes.
How a technical interviewer and an HR interviewer hear it
The same answer lands differently depending on who is across the table.
A technical interviewer is listening for nouns they can question. Project names, technologies, problems you solved, decisions you made. They will usually pick the most interesting technical item and go deep on it. For them, one well-understood project beats four shallow ones every time. They are rarely impressed by a list of languages.
An HR interviewer is listening for fit and clarity. Can you communicate? Do you know why you want this role? Are your plans stable? Do you come across as someone a team would enjoy working with? They will often follow up on motivation ("why this company?"), relocation, or the gap between your degree and your interests. The HR interview questions for freshers post covers what usually comes next in that round.
You do not need two separate answers, just one core answer with the weight shifted: more technical specifics for the engineer, more on motivation for HR.
The common mistakes
Reciting the resume
The interviewer has it in front of them. Reading it back adds nothing and wastes the one question where you control the direction. Use the resume as a map, not a script.
Leading with marks or family background
Percentages and a family introduction use up the first twenty seconds without telling a software interviewer anything about your ability to do the job. Mention academics only if they are genuinely distinctive, and family only if asked; the self-introduction guide covers what to cut in detail.
The four-minute monologue
Long answers feel thorough to the speaker and exhausting to the listener. A monologue also spends the time that could have gone on follow-ups, which is where you actually show depth. If you hear yourself say "and also" for the third time, wrap up.
Mentioning a skill you cannot defend
This is the expensive one. Every technology you name is an invitation. Saying "I know Docker, Kubernetes, AWS and Kafka" when you have followed one tutorial for each means the interviewer can pick any of them and expose the gap in a single question. That damages the rest of the interview, because they now doubt the things you do know. Name only what you can talk about for five minutes with a follow-up or two. If you are caught out anyway, how you respond matters more than the gap itself; how to handle a question you don't know covers what to say.
Planting a hook
The best answers end with a deliberate loose thread: a concrete, slightly unfinished detail about the work you are proudest of, phrased so that the obvious next question is one you want to answer.
A hook works when it is specific (a real problem, number or decision), interesting (there is clearly a story behind it), and safe (you know every layer of it). Some examples of the shape:
- "The hardest part was handling two users booking the last seat at the same time, which took me three attempts to get right."
- "We cut the page load from about six seconds to under two, mostly by fixing how we were querying the database."
- "I ended up rewriting the authentication twice, and the second rewrite taught me more than the whole course."
Each one practically asks the interviewer to say "tell me more", which moves the conversation onto your strongest ground. You are not manipulating anyone; you are making it easy to ask the question that shows you best.
Before and after: the generic answer
Before: "Myself Vikram, I am from Indore, I completed my B.Tech in Computer Science with 8.1 CGPA. I scored 91% in Class 12. My father is a businessman. I know C, C++, Java, Python, HTML, CSS, JavaScript and React. I am a quick learner and a team player and I am passionate about technology. My hobbies are cricket and listening to music."
After: "I'm Vikram, I've just finished my B.Tech in Computer Science. Most of my time in the last year went into one project: a booking system for our college fest, built with React on the front end and Node with MySQL behind it. About 1,200 students used it during the fest. The part I learned most from was a bug where two students could book the last seat at the same time, and fixing it properly is what got me interested in backend work, which is why I applied for this role."
The second answer has fewer facts and far more substance, and it gives the interviewer one clear thing to ask about that Vikram can discuss for twenty minutes.
Before and after: walking through the resume
Before: "I did my schooling from Kendriya Vidyalaya, then B.Sc Computer Science from Pune University, then MCA. In MCA I did a project on a library management system. I also did an internship at a startup for two months. I have done certifications in Python and AWS."
After: "I came into computing through a B.Sc, then did an MCA because I wanted to build things rather than only study them. The two-month internship was the turning point: I was put on a small internal tool that generated invoices, and I spent most of it fixing slow reports, which is where I learned to actually read a query plan. My MCA project built on that, a library system where I focused on search being fast. I'm looking for a backend role where I can keep doing that kind of work."
The second version tells a story with a direction, and ends with two obvious places for the interviewer to dig: query plans and search performance.
The follow-ups to expect, and how to handle them
If your hook worked, the next questions are predictable.
- "Tell me more about that project." Have a two-minute version ready: what it does, your specific part, the hardest problem, and what you would do differently.
- "Why did you choose that technology?" Give a real reason, even a modest one (you already knew JavaScript, MySQL suited the relational data), and show you know the trade-off you accepted.
- "How exactly did you fix that bug?" This is where the hook pays off or fails. Walk through the actual mechanism (a transaction, a unique constraint, a lock) and what you tried first that did not work.
- "What would break if ten times more people used it?" Think about the database, the slowest page, and anything that runs on a single server. You do not need a full design, just honest reasoning. If you want to go further, the system design practice track is where these questions grow up.
- "What was a challenge working with your team?" This moves into behavioural territory. Use a short situation, what you did, and the result; the STAR method is the standard structure.
- "Why this role?" Connect it back to the thread you started with. If your hook was about backend problems, say that the role is more of that work. Consistency between your first answer and your last is itself a signal.
If a follow-up lands on something you mentioned but cannot defend, say so plainly and steer back: "Honestly, I've only used Docker to run a local database, so I can't go deep on it. The part I can talk about in detail is how I designed the booking flow." That costs you far less than bluffing.
How to prepare in practice
Reduce your answer to four bullet points: who you are, the work you want to discuss, the hook, and why this role. Say it out loud, timed, across a few days, varying the wording so it never sounds memorised. Then have a friend interrupt you with "why MySQL?" halfway through; the follow-ups you stumble on are the ones you will get. The wider interview preparation for freshers guide covers how this fits alongside coding and core subjects.
Finally, practise it out loud in a scored round. On 99interview, Sia, the AI interviewer, runs technical rounds rather than asking for an introduction, but it follows up on whatever you say, so a vague answer gets probed the way a real engineer would; communication is one of the five criteria every round is scored on, at 20%. If you would rather hear it from a person, a live 40-minute interview over Zoom with a working engineer ends with written feedback on how your answers, including the first one, came across.
The goal is not a perfect paragraph. It is an opening that sends the interview towards the work you know best, and the confidence to follow it wherever the interviewer takes it.