It is 10:40 in the morning, your interview was meant to start at 10:30, and the panel has just joined the call. The interviewer smiles, glances at your resume and says, "So, introduce yourself." You have rehearsed this. And yet what comes out is: "My name is Rahul, I am from Nagpur, I completed my B.Tech in Computer Science with 7.8 CGPA, my tenth percentage was 89 and twelfth was 84, my hobbies are reading and playing cricket, and my strengths are hard work and dedication." Forty seconds. The interviewer nods, and asks the next question from the top of your resume, because you have given them nothing else to pick up.
That introduction was not wrong, just empty. Every fact in it is already on the paper in front of them, and none of it says what you can do. Here is how to build a self introduction for an IT interview that takes 60 to 90 seconds, gives the interviewer something specific to ask about, and sounds like you.
The short answer
A good self introduction for freshers in an interview has four parts, in this order: who you are in one line, what you have built or learned, one specific piece of proof with a number or a detail in it, and why this role makes sense as your next step. Keep it between 60 and 90 seconds, which is roughly 150 to 220 words spoken. Cut your hobbies list, your family background and anything that just repeats your resume, and leave out marks unless they are genuinely distinctive or the panel asks for them (some campus HR panels expect your CGPA in a formal introduction). Write it down, then practise it out loud until you can say it without the script, and keep two versions: one that leans technical for engineering rounds and one that leans on motivation and teamwork for the HR round.
Why the introduction matters more than it looks
Your introduction is the only answer in the interview where you choose the topic. In most technical rounds the first follow-up comes straight out of what you just said. Mention a project with one interesting detail and the next ten minutes are likely to be about ground you know better than anyone in the room. Mention nothing and they pick whatever catches their eye on your resume, possibly the Java course you have mostly forgotten. The goal is not to impress in 90 seconds. It is to hand the interviewer a good first question. If you want the other side of this, what the interviewer is actually listening for while you speak, we cover that in Tell Me About Yourself in an IT Interview. This article stays with building and saying the thing.
The four-part structure
1. Who you are (one or two sentences)
Name, degree, college and year, and the area of software you are aiming for. That is all. "I'm Priya, I graduated in Computer Science from VIT this year, and I'm looking to start as a backend developer." The last clause matters more than people think: it tells the interviewer which lens to listen through for the next minute.
2. What you have built or learned (two or three sentences)
Name one or two things you have done that relate to the role: a project, an internship, serious self-study. Say what it was and what your part was. Two or three named tools you could be questioned on are worth more than ten you could not.
3. One specific proof (one or two sentences)
This is the part almost every fresher skips, and it is the part that makes an introduction memorable. Pick one concrete detail: a number, a problem you solved, a decision you made and why. "The search page was taking four seconds to load, so I added an index on the product name column and got it under 400 milliseconds." That single sentence tells the interviewer you have debugged something real, that you know what an index is, and that you measure things. It also practically writes their next question for them.
4. Why this role (one or two sentences)
Connect what you have done to what they need. Not "I want to grow in a reputed company", which everyone says. Something specific: "I enjoyed the API and database side of that project far more than the UI, which is why I applied for this backend role." Then stop. No "That's all about me." Finish the sentence and pause.
The fill-in template
Copy this, fill in the brackets, then rewrite it in your own words so it does not sound filled in.
I'm [name], I [graduated / am in my final year] in [degree] from [college], and I'm looking to start my career as a [role, e.g. backend developer / frontend developer / software engineer].
Over the last [time period] I've [built / worked on / studied] [project or experience], where I [your specific part in it] using [two or three technologies].
One thing I'm proud of from that is [specific problem, decision or result, ideally with a number or a concrete detail].
I'm applying for this role because [connection between what you've done and what this team does], and I'd like to [what you want to get better at next].
That is four short paragraphs, which spoken at a calm pace comes out at about 70 to 80 seconds. If yours runs longer than 90 seconds, cut from part 2, never from part 3.
Three worked examples
Read these for structure, not wording. Copied word for word, they will sound copied.
Example 1: CS graduate with a full-stack project
I'm Ananya, I graduated in Computer Science from a college in Pune this year, and I'm looking to start as a full-stack developer.
In my final year, two classmates and I built a hostel complaint tracker that our college actually uses now. I owned the backend, a Node and Express API with MySQL, and the React screens for wardens.
The part I'm proudest of is that complaints used to get lost when wardens changed shifts, so I added a status history to every complaint and a daily summary email. Unresolved complaints older than three days dropped from around forty to under ten in the first month.
I'm applying here because your team builds internal tools for operations staff, which is very close to what I enjoyed most in that project: working out what the person using it actually needs.
The interviewer now has four good questions available: how the status history was modelled, how the email job was scheduled, how the work was split, and how she measured the drop. She can answer all of them well. If you are aiming at this profile, our full-stack practice track is built around exactly these kinds of follow-ups.
Example 2: ECE graduate who moved into software
I'm Karthik, I did my B.E. in Electronics and Communication from Coimbatore, and over the last year I've moved into software. I'm applying for backend developer roles.
I started with the embedded C we used in college, then taught myself Python and spent about six months on data structures and building small APIs with Flask and PostgreSQL.
My main project is a parking-slot booking API. The tricky part was two users booking the same slot at the same moment, so I read up on database transactions and used a row lock so only one booking could succeed.
I'm applying for this role because I've found I like the logic and data side of software much more than hardware, and I want to work somewhere I can get proper code review from experienced engineers.
Do not apologise for a non-CS degree or hide it. State it in one line, show the path in one line, and let the proof carry the weight: a concurrency problem solved with a row lock says more about your readiness than the degree would.
Example 3: candidate with an internship
I'm Sneha, I'm finishing my B.Tech in Information Technology from Indore, and I'm looking for a frontend developer role.
Last summer I did a three-month internship at a small fintech startup, where I worked on their customer dashboard in React and TypeScript.
My main task was the transactions table, which became very slow once a user had a few thousand rows. I moved it to paginated loading from the API and memoised the row components, and the page went from freezing for a few seconds to loading almost instantly.
I'm applying here because your product is heavily dashboard-driven, and I'd like to go deeper into frontend performance and accessibility, which I only scratched the surface of during the internship.
With an internship, the trap is describing the company instead of your work. One clause on the company, then straight to what you did.
What to cut
Most weak introductions are not missing things. They are carrying things that crowd out the useful part. Cut these.
- Marks and percentages. Your CGPA, tenth and twelfth scores are on your resume and, in many companies, already passed a cut-off before you were shortlisted. Saying them out loud spends ten seconds on a fact that cannot lead to an interesting question.
- The hobbies list. "Reading, music and cricket" tells the interviewer nothing. If a hobby is genuinely relevant, for example you run a coding club or you build small games for fun, it can go into part 2 as something you built. Otherwise leave it for when they ask.
- Family details. "My father is a government employee and my mother is a homemaker" is common in Indian interviews and almost never helps in an IT one. It is not unprofessional, it is just not about you as an engineer.
- Reciting the resume. If you are walking through your resume in order, school to college to certifications, you are reading them a document they already have. Pick the one or two things that matter for this role and go deep instead of wide.
- Generic strengths. "Hard-working, quick learner, team player." Everyone says these, so they carry no information. Show the trait in your proof instead.
How to deliver it
Length and pace
Aim for 60 to 90 seconds. Under 45 usually means you skipped the proof; over two minutes and the interviewer stops listening. Nerves speed you up, so slow down deliberately, and pause briefly between the four parts so the structure is audible.
Do not memorise it word for word
Memorise the four beats and the proof detail, not the sentences. A word-perfect script falls apart the moment you lose a word, and sounds recited even when it works.
Practise out loud, not in your head
In your head it always flows. Out loud you find the sentence too long for one breath and the point where you start rambling. Say it out loud at least ten times over a few days, and record it once on your phone: most people are surprised how fast they talk and how often they say "basically".
Prepare for the first follow-up
Your proof sentence is bait, and the interviewer will usually take it. Before the interview, write down the three most likely questions that come out of your introduction and make sure you can answer each for two minutes. If you said you added a database index, be ready for "Why that column?" and "What does an index cost you?" If a follow-up goes somewhere you do not know, that is normal; our guide on what happens in a technical interview walks through how these rounds usually unfold.
Adapting it for technical and HR rounds
You do not need two different introductions. You need the same four parts with the weight shifted.
In a technical round
Lean on parts 2 and 3. Name the technologies, give your proof one more level of technical detail, and keep part 4 short. Tilt the project towards the track: a frontend round should hear about the UI problem, a backend round about the API or the database.
In an HR round
Lean on parts 1 and 4. Keep the technical proof, but say it in plain language: "the page was too slow, so I found the cause and fixed it" rather than "I memoised the row components". Add a line about how you worked with others on the project, because HR rounds care about how you will fit into a team. Spend more time on why this company and this role, and make it specific to them. For the questions that usually follow in this round, see HR Interview Questions for Freshers, and if they turn into "tell me about a time when…", the STAR method gives you a structure for those answers.
A quick check before the interview
Read your introduction against these questions.
- Can you say it in under 90 seconds at a calm pace?
- Does it contain at least one number or one concrete technical detail?
- Is every technology you named something you could answer three questions about?
- Does the last sentence connect to this specific role, not to "a reputed company"?
- Have you removed marks, the hobbies list and family details?
- Can you name the first follow-up question it is likely to trigger, and answer it?
If all six are yes, your introduction is doing its job. The rest of your preparation, from coding rounds to project questions, is laid out in our interview preparation guide for freshers.
Say it to someone who will ask back
The weakness of practising alone is that nobody follows up. Your introduction can sound perfect to the mirror and still collapse at the first "Why did you choose MySQL there?" The fix is to say it out loud to someone who asks the next question.
On 99interview, Sia, our AI interviewer, does not ask for an introduction, but its technical rounds drill your project choices the way an interviewer follows up on one (why that column, what the index costs). A live 40-minute Zoom interview with a working engineer is where you can deliver the introduction itself and get scored, written feedback. Either way you get a breakdown across five criteria, including communication, which is where an introduction quietly wins or loses you the first few minutes.