The email says "Technical Interview, 45 minutes, Google Meet link below." That is all it says. You have cleared the online coding test, which was at least a known format: problems, a timer, submit. This is different. Will they ask you to code? Will it be theory questions like the viva? Will they go through your resume line by line? Will there be a puzzle?
You spend the evening before revising everything at once, because you do not know which part will be needed, and you sleep badly because a question you could answer comfortably at your desk feels much harder when you do not know what is coming after it.
The short answer
Most technical interviews for freshers follow a consistent shape, whether the company is a product startup, a large service firm running a campus drive, or a mid-size company hiring off-campus. A short introduction sets the agenda. Ten to fifteen minutes of technical questions follow, taken from your resume and the job description, each with follow-ups. Then a discussion of one of your projects. Then, usually, one problem to solve live. Then a behavioural question or two and a chance for you to ask something. Forty-five minutes, five phases. The questions change from company to company. The shape hardly does.
Knowing that shape does not tell you what will be asked, but it tells you what kind of conversation to expect at each minute, which is enough to stop bracing and start listening.
Why the shape is so consistent
It is not an accident. Structured interviews, where every candidate goes through the same phases and is assessed against the same criteria, predict job performance better than free-form chats, and large employers know it. Google says as much in its own description of how it hires. Indian companies running placement drives have a more practical reason as well: an interviewer seeing fifteen candidates in a day needs a fixed format to compare them fairly. Either way, the effect for you is the same. The interview is predictable in structure, and you can prepare for each phase separately.
Here is each one, with rough timings for a standard 45-minute round.
Minutes 0 to 5: the introduction
Nearly every interview opens with the interviewer introducing themselves and the role in a sentence, then asking you to do the same. "Tell me about yourself" or "walk me through your resume" is the usual form.
This looks like small talk and freshers treat it as small talk. It is not. Whatever you say here becomes the agenda for the next fifteen minutes, because interviewers take their first technical questions from the things you have just mentioned. Say React, Node and MongoDB and you have told them exactly where to dig. Mention your final-year project prominently and expect to be asked about it in depth.
Use that deliberately. A good introduction runs about ninety seconds. It names your degree and college briefly, the two or three technologies you are most confident in, and one project you could talk about for ten minutes without notes. Leave out anything you would rather not be asked about. If it is on your resume they may still ask, but you do not have to hand them the opening.
What the interviewer is doing here: forming a first impression of your communication, and picking the first thread to pull.
Minutes 5 to 20: technical questions and follow-ups
Now the conversation moves to the technologies from your introduction and from the job description. For a frontend role that means the framework, rendering, state and the browser. For a backend or Java role it means the language, OOP concepts, databases, APIs. For a general software role at a service company it is often fundamentals: OOP, SQL, a bit of the language you listed, maybe operating systems or networking basics from your syllabus. Lists of the standard questions, like the one in Naukri's campus guide, are a fair picture of the starting questions. They are not a picture of the follow-ups, and the follow-ups are where the marks are.
The pattern to expect is question, answer, follow-up, follow-up. The first question is usually broad and easy. "What is the difference between an abstract class and an interface?" The follow-ups get specific. "Where did you use an interface in your project? Why there?" Interviewers push until they reach the edge of what you know, then watch how you handle the edge. That is the design, not a trick, and there is a separate article on that moment in how to handle a question you don't know.
How to prepare: for every technology on your resume, write down the three follow-up questions you would least like to be asked, and answer them from your own experience rather than from a definition.
Minutes 20 to 30: the project discussion
Most interviews then narrow to one project, usually the one you introduced. For freshers this is the most important phase of the hour, because it is the only place you have real experience to show, and it is also the easiest to do well in if you actually built the thing.
Typical questions: how does it work end to end? Why did you choose this database or framework? What was the hardest bug and how did you find it? What broke when you demoed it? What would you change if you started again? In a group project, which parts were yours?
The interviewer is checking whether you made the decisions or watched them being made. The tell is the "why" question. A candidate who built the project can explain why in terms of a constraint they hit. A candidate who followed a tutorial can only explain what.
How to prepare: explain the project aloud, from memory, to someone who has not seen it. Include the parts you would now do differently. Admitting a mistake and saying what you learned scores better than pretending it was flawless. And be precise about which parts of a group project were yours; interviewers respect it, and they will go deep on your part, which is what you want.
Minutes 30 to 40: solving a problem live
Many rounds include one problem to work through while the interviewer watches. For freshers this is nearly always a coding or data-structures problem sized for ten minutes, or occasionally a debugging exercise or a small logic question. Full system design questions are rare at entry level; Design Gurus' summary matches what most freshers experience, which is that design comes up only in simplified form and usually only at product companies or startups.
The mistake here is to start typing immediately. The better sequence: restate the problem in your own words, ask one or two clarifying questions, say your assumptions, describe the approach in a sentence, then code while narrating. Mention edge cases before you are asked. If you get stuck, say what you are stuck on. An interviewer can help a candidate whose reasoning they can see; they cannot help one who has gone quiet.
What is being assessed is how you move through a problem, and, when you write code, whether it is readable and correct. Not whether it compiled first time.
Minutes 40 to 45: behavioural questions, and yours
The last few minutes usually hold one or two behavioural questions and then an invitation for you to ask something. "Tell me about a time you disagreed with a teammate." "Tell me about a deadline you missed." In many Indian companies these are pushed to a separate HR round, but they appear at the end of technical rounds often enough that you should have two or three real stories ready. The STAR method is the standard way to structure them.
Your own questions matter less than freshers fear. One or two genuine questions about what the team is building, how code is reviewed, or what a new joiner's first month looks like will do. Avoid questions the job posting already answered.
How the shape changes with format
A panel interview compresses the same phases and rotates who asks. A multi-round process splits them: an online test, then a technical round covering phases two to four, then a managerial or HR round for phase five. Service companies running large campus drives often run a shorter technical round, twenty to thirty minutes, that leans on fundamentals and the project and skips live coding because the online test already covered it. Product companies tend to run the full version and add a second coding round.
An AI-led practice round follows the same arc because it is modelled on it, which is why it is useful for rehearsal. A structured practice interview on 99Interview opens with your background, moves through technical follow-ups and your project, and can include a problem or a behavioural question depending on the track you choose, from frontend and backend to DSA; you can run it with an AI interviewer that scores the transcript, or as a live mock interview with a working engineer who writes up feedback on each area afterwards, and the details are on the pricing page. Afterwards, read the transcript with this article beside it and mark where each phase began. The phase where your answers got shortest is the one to work on.
The interview is one conversation, not five tests
The most useful thing to take from all of this is that the phases connect. What you say in the introduction chooses the technical questions. Your technical answers name the project they will dig into. The project discussion often surfaces the problem they ask you to solve. The behavioural questions frequently come from something you mentioned along the way. You have far more control over the direction of the hour than it feels like from the inside, and that control is exercised in the first five minutes.
Frequently asked questions
How long is a technical interview for freshers?
Usually thirty to forty-five minutes for a single round. Campus drives at service companies often run shorter, around twenty to thirty minutes, because the online test has already covered coding. Product companies may run two technical rounds of forty-five minutes each.
What is asked in the technical round of a campus placement?
Fundamentals from your resume and syllabus (OOP, SQL, the language you listed), a discussion of your project with follow-ups, and often one coding or logic problem. The exact questions vary; the phases do not.
How many rounds are there in a software engineer interview?
For freshers, commonly three or four: an online assessment, one or two technical rounds, and an HR or managerial round. Startups sometimes compress this into two. Large product companies sometimes extend it to five.
What do interviewers ask about your project?
How it works end to end, why you chose each technology, the hardest bug, what broke, what you would change, and which parts were yours. Every answer should be a decision with a reason, not a description.
How should I introduce myself in a technical interview?
In about ninety seconds: degree and college briefly, the two or three technologies you are most confident in, and one project you can discuss in depth. Whatever you mention becomes the agenda, so mention what you want to be asked about.
What is the difference between the technical round and the HR round?
The technical round assesses your knowledge, your project and your problem solving. The HR round assesses communication, behaviour, fit and practical matters like location and notice period. Behavioural questions can appear in both.
Before your next round
Write your ninety-second introduction tonight and say it aloud until it is smooth. Then, for each thing you mentioned in it, write down the follow-up you would least like to get.
You now know the shape of the hour. Which of the five phases would you least want to be in right now, and what would it take to change that before the interview?