Tell me about yourself: how software engineering freshers should answer

The interviewer already has your resume. What they do not have yet is a sense of how you think, what you have actually built, and whether you can explain it clearly in your own words. Your self introduction is a short spoken answer to those three things. Done well, it also decides what the next twenty minutes of the interview are about.

This guide gives you a structure that fits in 60–90 seconds, two full sample answers for freshers, a short version for experienced professionals, and a way to practise until it sounds natural instead of memorised.

Why the question is asked, and what the interviewer is listening for

It looks like an icebreaker. It is not. In the first minute the interviewer is quietly checking a few things:

• Can you summarise yourself? Picking the two or three things that matter out of four years of college is itself a skill. Rambling suggests you cannot prioritise.
• Is there real work behind the resume? They want one concrete thing you built or did, described specifically enough that they believe you did it.
• Do you know why you are here? A candidate who can say why this role makes sense for them is easier to place than one who wants "any good opportunity".
• How do you communicate? Pace, clarity, and whether you sound like you are talking to a person or reciting to a wall.

A 60–90 second structure: present, proof, direction

Three parts, in this order. Each one is two or three sentences.

1. Present. Who you are right now, in one line: your degree, your year or graduation, and the area of software you are focused on. Not your hometown, not your school.
2. Proof. One or two specific things you have done that back up that focus — a project, an internship, a hackathon, an open-source fix. Say what the problem was, what you built, and one detail that only someone who built it would know.
3. Direction. Why this role. Connect what you have done to what the job involves, in plain words. This is where you end, so the interviewer's next question comes from here or from your proof.

Spoken at a normal pace, that is roughly 150–220 words. If your written draft is longer than that, it will run past two minutes out loud.

Sample answer 1: CS fresher with a project and an internship

This is an invented example. Ananya is a final-year computer science student with one strong project and a short internship.

"I'm Ananya, a final-year B.Tech Computer Science student, and over the last two years I've mostly worked on backend development with Python and Node.

The project I'm proudest of is a hostel complaint tracker I built with two friends. Students used to report broken fans and water issues on a WhatsApp group, and things got lost. We built a small web app where complaints get logged, assigned to the warden's office, and closed with a status update. I handled the backend and the database. The tricky part was duplicate complaints — ten people reporting the same leak — so I added a simple check that groups complaints by room and category within a time window. Our hostel used it for one full semester.

Last summer I did a two-month internship at a logistics software company, where I wrote API tests for their order service and fixed a couple of bugs that the tests caught.

I'm applying for this backend role because that's the work I've enjoyed most so far — building things other people depend on and making sure they don't break."

Notice what it does: one line of present, one project with a specific detail (the duplicate complaints), one internship with a concrete task, and a direction that links back to the role. No marks, no list of every language she has touched.

Sample answer 2: non-CS branch fresher moving into software

Also invented. Rohit studied mechanical engineering and wants a software role. His job is to make the switch sound deliberate, not accidental.

"I'm Rohit, I graduated this year in Mechanical Engineering, and for the last year and a half I've been focused on moving into software development.

It started in my third year, in our machines lab. We were logging vibration readings from a lathe by hand in a spreadsheet, so I wrote a Python script to read the sensor data and flag readings that looked unusual. That was the first time code solved a real problem for me, and I kept going. Since then I've completed a data structures course, solved problems regularly on practice sites, and built an inventory app for our college workshop — a small Flask app with a SQLite database that tracks which tools are issued to which batch. The lab assistant still uses it.

I know I don't have a CS degree, so I've tried to make up for it with things I've actually built and used. I'm applying for this role because I want to work on software full-time, and I think my background helps me understand the people who use the systems, not just the code."

The important move is that Rohit names the gap himself, calmly, and immediately points to evidence. If you leave the branch question hanging, the interviewer will ask it anyway, and it will sound worse coming from them.

If you are an experienced professional

The same structure works, with the weight shifted. Present becomes your current role, years of experience, and the scope you own. Proof becomes one or two outcomes from recent work — a system you designed, a migration you led, a problem you diagnosed — with your part in it stated clearly. Direction becomes why you are moving now and why this role in particular. Leave college out entirely unless you graduated in the last year or two. Keep it under two minutes even if you have ten years to cover.

What to cut

• Reciting the resume. "I did my schooling from…, then I joined…, then I did…" is a timeline, not an introduction. They can read it.
• Family background. Your parents' occupations and your siblings are not relevant to a software role. Leave them out unless directly asked.
• Hobbies with no point. "I like reading and listening to music" adds nothing. A hobby earns its place only if it connects to the work, like a chess engine you wrote or a club website you maintain.
• Marks and percentages, unless asked. If your CGPA matters to them, it is on the resume. Spoken aloud, it uses time you could spend on proof.
• Lists of technologies. Naming eight languages sounds like you know none of them well. Name the one or two you used in the project you described.

Set up your follow-up questions deliberately

The interviewer's next question will almost always come from something you just said. Use that. Leave one or two "hooks" in your answer — specific details you would be happy to talk about for five minutes.

In Ananya's answer, the hook is the duplicate-complaints logic. It is interesting, it is clearly hers, and an interviewer is likely to ask how she defined a duplicate. In Rohit's, it is the sensor script. Both are things they can explain in depth because they built them.

The reverse is also true. Do not mention anything you cannot defend. If you say "I've worked with machine learning" because you watched a course, the next question will expose it. Every noun in your introduction is an invitation, so only invite questions you want.

Delivery: length, pace, and not memorising word-for-word

• Length. Aim for 60–90 seconds. Under 30 sounds like you have nothing to say; over two minutes and the interviewer starts waiting for you to finish.
• Pace. Nerves make most people speed up. Slow down slightly on the proof section, because that is the part you want them to remember.
• Memorise the structure, not the sentences. Know your three parts and the one detail in each. Let the exact words change each time. A memorised script sounds flat, and if you lose one line you lose the whole thing.
• End cleanly. Finish on the direction line and stop. Do not trail off with "…so yeah, that's about me."

Common mistakes

• Starting with your name and nothing else for 20 seconds. Get to the present line quickly.
• Using the same answer for every role. The proof can stay the same, but the direction line must match the job you are interviewing for.
• Saying "we" throughout a team project. The interviewer cannot tell what you did. Say "we built" once, then "I handled".
• Generic adjectives. "Hard-working, passionate, quick learner" are claims with no evidence. Replace each one with something you did.
• Apologising for gaps. State a gap once, factually, and move to what you did about it.

How to practise out loud

Writing your answer is the first step, not the last. Your introduction only gets better when you say it out loud and hear it back.

1. Draft the three parts in bullet points, not full sentences. One line for present, two or three for proof, one for direction.
2. Record yourself on your phone and time it. Listen once for length, once for filler words like "basically" and "actually", and once for whether the proof sounds specific.
3. Practise with someone who will interrupt. A friend should ask a follow-up on whatever you said last. If a question catches you out, either prepare for it or remove the line that invited it.
4. Run a full mock interview on mangoose.tech. You sit a live interview with Meera and speak your answers out loud, in English. She asks follow-ups on the thin parts of your introduction the way a panel would. Afterwards, the gap report marks the moments where an answer weakened and what to do differently, with delivery notes such as your speaking pace and filler words.