How to Explain Your Final Year Project in an Interview: 2-Minute Script, TCS/Infosys Follow-Ups and 3 Worked Examples

"Tell me about your final year project" is asked in nearly every fresher technical round in India. TCS Ninja and Digital panels ask it first. Infosys, Wipro, Accenture, Cognizant and Capgemini interviewers ask it within five minutes. Startups ask it because it is the only real engineering you have done. And most candidates answer it badly, not because the project was weak, but because they describe it in the order they built it rather than the order the interviewer needs.

This guide gives you a two-minute script template, the follow-up questions TCS and Infosys style panels actually ask, the mistakes that lose marks, and three worked examples (a web app, a machine learning project and an IoT project) you can adapt.

Why interviewers ask about your project

The panel is not interested in the project. They are interested in what it reveals:

• Did you really build it? Follow-up questions test whether you can go one level deeper than the abstract.
• Can you explain a technical thing to a listener who does not know it? That is the daily job of an engineer.
• Do you understand trade-offs? Why this database, why this framework, what you would change.
• How do you handle pressure? They will push on a weak spot and watch what you do.

Answer for those four things and the content takes care of itself.

The two-minute script template

Six beats, roughly twenty seconds each. Say them in this order every time.

1. The problem in one sentence (15 seconds). Who had the problem and what it cost them. "Our hostel handled maintenance complaints on a WhatsApp group, so nothing was tracked and nobody knew whether a complaint was closed."

2. What you built, in one sentence (15 seconds). "We built a web app where students file complaints, wardens assign them, and everyone sees the status."

3. Your role and the team (15 seconds). "Team of three. I owned the backend and database; one teammate did the React front end; one did testing and deployment." Be exact.

4. Architecture and stack, briefly (30 seconds). Front end, back end, database, hosting, one sentence each, and why you chose them. "React front end, Node and Express APIs, PostgreSQL because complaints have clear relations, deployed on a free-tier cloud VM."

5. The hardest part and how you solved it (30 seconds). This is where marks are won. Pick one real technical difficulty: a slow query, a race condition, model overfitting, sensor noise. State the symptom, the cause you found, the fix, and how you verified it.

6. Result and what you would change (15 seconds). A number if you have one ("wardens closed complaints in two days instead of nine"), and one honest improvement ("I would add role-based access from the start instead of bolting it on").

Then stop. Silence after a good answer is not awkward; it invites the follow-up you have prepared for.

Follow-up questions TCS and Infosys style panels ask

Group them by what they test, and prepare one crisp answer for each group.

Ownership and honesty

• Which parts did you personally write? Which parts came from a library, a tutorial or a teammate?
• If I open the repository, which file should I read first to see your work?
• What did your guide contribute?

Design decisions

• Why this database and not another? What would break if you switched?
• Why a web app and not a mobile app (or the reverse)?
• How are users authenticated? Where are passwords stored and how?
• What happens if two users do the same action at the same time?

Implementation depth

• Explain one API end to end: request, validation, database query, response.
• What is the most complex query or function in the project? Walk me through it.
• How did you handle errors and invalid input?
• Show me how the data flows from the sensor (or the form, or the dataset) to the screen.

Testing and deployment

• How did you test it? What did you not test?
• Where is it deployed? What would you need to change for a thousand users?
• What broke the week before the demo and how did you fix it?

Reflection

• What would you do differently if you started again?
• What did you learn that is not in the report?
• Could this be a product? What is missing?

Cross-questions to expect if your project is ML

• How did you split training and test data? Did any test data leak into training?
• What was your baseline and did you beat it?
• Why this accuracy metric and not another?

Cross-questions to expect if your project is IoT

• What is the sampling rate and why?
• What happens when the network drops? Is data lost or buffered?
• How did you power the device and for how long does it run?

If you can answer three questions from each group without hesitation, no panel in an IT services round will trouble you.

Common mistakes that lose marks

• Starting with the stack. "We used React, Node, MongoDB and..." before the interviewer knows what the thing does. Problem first, always.
• Saying "we" for everything. The panel needs your part. Use "I" for what you did and "we" for the team's decisions.
• Reciting the abstract. The report abstract was written for an examiner. The interviewer wants a story with one hard problem in it.
• Claiming a technology you cannot defend. If you say "microservices" or "deep learning," the next question is about them. Say what you actually built.
• No numbers. Users, records, response time, accuracy, days saved. Even approximate numbers show you measured something.
• Hiding the failure. Every real project had something break. Panels trust the candidate who describes the failure and the fix over the one whose project was perfect.
• Going over time. A two-minute answer with a strong hard-part beat gets more follow-ups than a six-minute tour. Follow-ups are good; they mean the panel is interested.
• Not knowing the current status. "Is it live? Does it still run?" Know the answer.

Worked example 1: a web application

Project: Hostel complaint management system (B.Tech CSE, team of three).

Script:

"Our hostel of six hundred students tracked maintenance complaints on a WhatsApp group, so complaints got lost and nobody knew what was pending. We built a web app where students file a complaint with a category and photo, the warden assigns it to a maintenance staff member, and everyone sees the status until it is closed.

I owned the backend and the database. One teammate built the React front end, and one handled testing and deployment.

The front end is React. The backend is Node with Express, exposing REST APIs. The database is PostgreSQL because complaints, rooms, staff and status history are clearly relational and we needed reporting by block and category. It is deployed on a single cloud VM with Nginx in front.

The hardest part was the status history. Initially I updated a status column in place, and the warden asked for the timeline of every complaint, which we had thrown away. I redesigned it as an append-only status log table with a foreign key to the complaint, and the current status became the latest row. That also fixed a bug where two wardens updating the same complaint overwrote each other, because appends do not conflict.

In the pilot month, average closure time went from about nine days to two, measured from the log. If I did it again, I would add role-based access from day one; we added it late and it touched every API."

Follow-ups to be ready for: why PostgreSQL over MongoDB; how the photo upload works and where files are stored; how login is done and how passwords are hashed; what the most complex query is (the per-block pending report, a GROUP BY over a join of complaints and the latest status row); what happens if the VM goes down.

Worked example 2: a machine learning project

Project: Crop leaf disease detection from photos (B.Tech ECE, team of two).

Script:

"Farmers near our college identify leaf diseases by asking neighbours, and by the time the answer comes the disease has spread. We built a system where a farmer photographs a leaf on a phone and gets the likely disease and a treatment suggestion.

My part was the model and the training pipeline; my teammate built the Android app and the API that calls the model.

We used a public dataset of labelled leaf images across ten disease classes, fine-tuned a pretrained convolutional network in PyTorch rather than training from scratch, and served the model behind a small Flask API. The app sends the image, the API returns the top three classes with confidence.

The hardest part was that our first accuracy number was misleading. We had split the data randomly, and many images were near-duplicates of the same leaf, so the test set leaked training data and the accuracy looked excellent. When we split by plant instead, accuracy dropped sharply on some classes. We fixed it by grouping the split by plant, adding augmentation for lighting and rotation, and re-balancing the underrepresented classes. The honest number was lower, but it held up on photos we took ourselves in the field.

In field testing with twenty of our own photos, the top-three result included the right disease in most cases. If I did it again I would collect local images from the start; the public dataset's lighting did not match a field at noon."

Follow-ups to be ready for: what the baseline was (a simple classifier on colour histograms) and whether the network beat it; why fine-tuning instead of training from scratch; which metric and why not plain accuracy on an imbalanced set; how big the model is and how long inference takes on the server; what happens with a photo that is not a leaf.

Worked example 3: an IoT project

Project: Overhead water tank monitoring with pump control (B.Tech EEE, team of three).

Script:

"Our college hostel overflowed its overhead tanks daily because the pump was switched off by a guard who forgot. We built a monitor that measures the tank level, shows it on a dashboard, and switches the pump off automatically when the tank is full.

I owned the sensor node firmware and the pump control; one teammate built the dashboard; one handled the enclosure and installation.

An ultrasonic sensor on the tank lid measures distance to the water surface. An ESP32 reads it, converts it to a level percentage, and publishes it over Wi-Fi using MQTT to a small broker on a campus server. A relay module on the pump line is switched by the same ESP32 based on thresholds, with a manual override switch. The dashboard subscribes to the broker and shows the level and pump state.

The hardest part was sensor noise. The ultrasonic readings jumped by several centimetres when water rippled during filling, so the pump chattered on and off near the full mark. I fixed it with a median filter over several readings and hysteresis: the pump switches off at one threshold and back on only at a noticeably lower one. I verified it by logging raw and filtered values for a full fill cycle.

After installation, the overflow stopped, and the guard's job became checking the dashboard once a shift. If I did it again I would add a second sensor for redundancy and store readings locally when Wi-Fi drops; currently those readings are lost."

Follow-ups to be ready for: why MQTT and not plain HTTP; what the sampling rate is and why; what happens if the ESP32 reboots while the pump is on (the relay defaults to off); how the device is powered; what the safety failure modes are; how you tested the relay without the real pump.

Practise it aloud, with someone pushing back

Reading this guide is the easy half. The hard half is saying the two-minute version aloud, on a timer, and then surviving eight follow-ups without saying "basically" or "like" every sentence.

1. Write your six beats on one page. Nothing else.
2. Record yourself on your phone. Listen for the stack-first mistake and for "we."
3. Have a friend ask ten follow-ups from the lists above, including the ones you hope they skip.
4. Run a MockMate Practice session with your resume attached and pick a technical round. The interviewer persona asks about the project on your resume, follows up on your answers, and the report shows response timing, recurring weaknesses and a recommended next practice. Eligible accounts get three free ten-minute Practice starts.
5. Use Live assistance only where the organisation, interviewer or applicable rules permit assistance and disclosure. For a project explanation, Practice is the tool anyway; the whole point is that you can defend the project yourself.

For the rest of the round, see TCS interview questions and Infosys interview questions, and for the HR round that follows, HR round questions for freshers.