- The common fresher questions are: introduce yourself, explain one project, a strength, a weakness, why this role, and one technical question from your resume. Keep each answer under a minute.
Short answer: The questions that show up in almost every fresher interview are: introduce yourself, explain one project, name a strength and a weakness, say why you want this role, and answer one technical question that is already on your resume. Speak for under a minute, then give one concrete example. If you do not know the technical point, say what you do know and stop. Do not invent a tool you have never used.
This page is the set that sits underneath the subject pages. Use it for the questions that are common across companies. Then open the page for the stack you are actually sitting: Java, Python, SQL, JavaScript, React, DSA, or Spring Boot. HR wording is expanded in HR interview questions. A classroom run of the same round is what placement preparation in Chennai is for.
Which questions are actually common?
Companies change the coding problem. They rarely change the opening. You will be asked who you are, what you built, why you are in the room, and whether the skill on your resume is real. Technical rounds then pick one topic from that resume and stay there. A Java resume gets Java and SQL. A data resume gets Excel, SQL, or Power BI. A testing resume gets a project and a defect you found.
Prepare the common frame once. Prepare the technical depth for the one stack you claim. A candidate who has a polished introduction and cannot explain their own project fails later, not earlier. The introduction only buys the next question.
- Write the introduction and time it.
- Pick one project and learn its request path, or its report path, end to end.
- Prepare one strength and one weakness you can prove with a story.
- Prepare the technical definition that matches the first skill on the resume.
- Prepare two questions you will ask them.
How do you answer "Tell me about yourself"?
Use four lines and no life story. Your degree and the year. The role you are here for. One project, with the tool and the outcome. What you want to learn in this job. Sixty to ninety seconds is enough. End on the role, not on a hobby, unless they asked about a hobby.
A sample you can adapt: "I finished a B.Sc. computer science this year. I am applying for a junior Java role. For my final project I built a small student API in Spring Boot: a controller, a service, and a table of registrations, with a check that rejects a blank email. I want a team where I can take a ticket, write the test, and review the result with someone senior." Change the degree, the tool, and the project. Do not keep the sample if it is not yours.
How do you explain a project?
Answer in five beats. Who the user is. What they could do when you finished. What you personally built. How the data was stored. What broke and how you fixed it. Then stop. If they want a class name or a measure, they will ask.
Weak answers list technologies: "I used Java, Spring, MySQL, HTML, and Git." Strong answers use one action: "A clerk posts a registration, the service rejects a duplicate email, and the row is stored in MySQL." The technology list can follow in one sentence. The action is the answer. If the project was a group project, say which part was yours. Claiming the whole system when you only built the login page is how a friendly panel becomes a hostile one.
What is a good strength?
Pick a strength the job uses, and tie it to a fact. "I can explain a bug in writing" is a strength if you once wrote the steps that let a teammate reproduce it. "I am hardworking" is not a strength until it has a scene. The scene needs a task, what you did, and what changed.
One is enough. A list of five adjectives sounds rehearsed and none of them can be checked. If the role is support or testing, a strength about careful reproduction is more useful than a strength about competitive programming you do not practise.
What is a good weakness?
Name a real limit that is not the core of the job, and name what you do about it. "I used to start coding before I could state the input and the output. I now write two examples on paper first, including one failure." That is a weakness with a habit attached. "I am a perfectionist" is a compliment in disguise, and interviewers have heard it enough to ignore it.
Do not pick a weakness that means you cannot do the work. "I do not like testing" is a poor line for a testing role. "I have not used Kafka" is fine if the role does not require Kafka and you do not pretend otherwise.
How do you answer "Why should we hire you"?
Connect three things they can verify. You have the base skill on the resume. You have one project you can walk through. You can say what you do not know yet. The third point matters. A fresher who claims to be production-ready in every tool is less convincing than a fresher who can learn a ticket without hiding the gap.
Skip the flattery. "Your company is a dream" does not answer the question. "I can take a small API from the controller to the table, and I will ask before I guess at a library I have not used" does.
How do you answer "Why this company" or "Why this role"?
Say something you could only say if you had looked at the role. The stack in the job post. The kind of work: support, development, testing, or analysis. One public fact, such as a product you have actually used. Then say what you want to practise there. Two sentences. Do not recite the About page from their website.
If you do not know the company well, say what you do know and do not invent a value statement. "I applied because the post is a junior Java role and that matches the API I built" is honest. It is better than a paragraph about innovation you cannot connect to the team in front of you.
How do you answer "Where do you see yourself in five years"?
Stay inside the craft. "I want to own a small feature end to end, review other people's changes, and be the person who can explain a production incident calmly." That is a believable five years for a fresher. "I want to be the CEO" is not useful in this round, and "I have no idea" wastes the question.
You can mention a skill you intend to add, such as SQL beside Java, or a model beside Excel. Keep it adjacent to the role. A five-year plan that abandons the job you are interviewing for tells them you will leave at the first chance.
How do you talk about relocation, shifts, and joining date?
Answer the question that was asked. If you can relocate, say the cities you will actually move to. If you cannot, say so before the offer, not after. If you can join after your exams or after a notice period, give the date you mean. "Immediately" is only correct if it is true.
Shifts are the same. A support role may include nights. Agree only if you will do them. A careful no, early, is more professional than a yes you reverse in the first week.
How do you answer a salary question without inventing a number?
Do not quote a figure you found in a comment thread. Say you want a package that matches the role and the city, and that you will read the offer letter before you accept: fixed pay, variable pay, and the bond or training clause if there is one. If they insist on a number and you have a researched range from the company's own drive or from a recent offer a classmate actually received, give that range and say it is a starting point.
If you have no range, say you do not want to guess. Ask what band the role is in. Guessing a high number with no basis ends some fresher rounds. Guessing a very low number because you are nervous does too. The introduction guide and the HR page cover the wording. This page will not invent a CTC for you.
What do you do when you do not know the answer?
Say which part you know. Say the part you do not. Offer the next step you would take: read the documentation, write a small example, or ask a teammate before you ship it. Then stop talking. Filling the silence with a wrong definition is worse than the gap.
Example: "I know a measure is calculated in the filter of the visual. I have not used time-intelligence functions yet, so I would not pretend to write a year-to-date formula from memory. I would check the DAX reference and test it against a month I can add by hand." That answer still shows judgment.
How do you answer "Tell me about a time you failed"?
Use a small, real failure. What you tried. What went wrong. What you changed. A student example is enough: you demoed a project with a password in the config file, a reviewer caught it, and you moved the value out of the repository before the next review. Do not pick a failure that harmed someone, and do not pick a failure you still blame on the team.
The panel is listening for ownership. "We failed" with no "I" in it dodges the question. "I skipped the failure test, the blank email was saved, and I added that test the same day" is the shape they want.
How do you answer a conflict question?
Keep the other person respectful and the dispute about the work. You disagreed on an approach. You showed an example. You accepted a decision or you changed their mind with a result, not with volume. If you have never had a workplace conflict, use a college team: two people wanted different database designs, you wrote both queries against a sample, and you kept the one that returned the right rows.
Do not tell a story whose ending is that everyone else was careless. Panels hire people who can disagree and still ship.
What are the common technical questions for any fresher?
These are the definitions that appear even when the job post is vague. Answer in two or three sentences, then offer an example if they want one.
- What is a variable? A named place for a value. In Java you declare the type. In Python the name is bound when you assign. Either way, the name should say what the value is for.
- What is a function or a method? A named block you can call with inputs. It should return a result or do one action, not both in a way you cannot test.
- What is OOP? You group data and the actions on that data into objects. A class is the plan. An object is one instance. Inheritance, encapsulation, and polymorphism are the three words to be ready to define with a single example, not with a slogan. The longer set is on the Java interview page.
- What is an API? A contract another program can call. You name the URL or the function, the inputs, and what comes back, including the error.
- What is a primary key? A column, or a set of columns, that identifies one row and does not repeat. A foreign key points at a primary key in another table. Joins are the follow-up, and they live on the SQL page.
- What is Git? A history of the files. You commit a change with a message, and you can see who changed a line. Say the commands you have really used. Commit and push are enough if that is all you have done.
- What is a bug? Behaviour that breaks the rule you stated. A good report has the input, the expected result, and the actual result. Testing roles live on this sentence.
If the resume says React, be ready for state and props, and use the React interview page. If it says JavaScript, be ready for scope and a promise, and use the JavaScript page. If it says arrays and loops, the DSA page is the practice set. Do not recite a topic that is not on your resume just because it is common on the internet.
How do you behave in a coding round?
Repeat the problem in one sentence. Name an input and the output you expect. Mention one edge: empty input, a duplicate, or a negative number. Then write the simple correct version before you talk about speed. Narrate the loop as you type. When you finish, run the example you stated at the start.
If you are stuck, say where. "I can collect the values. I am not sure how to avoid the second pass." That gives the interviewer a place to hint. Silence while you stare at the screen does not. A brute-force answer you can explain beats a clever answer you cannot finish.
How do you handle an online test?
Read the question until you can state the output for the sample. Watch the constraints if they are printed: a loop inside a loop is fine on a hundred rows and wrong on a million. Do not switch tabs if the test says not to. If you finish early, re-read the last question you were least sure of, not the one you liked.
Aptitude sections are their own practice. Use aptitude questions, quantitative aptitude, and logical reasoning instead of hoping the coding page covers the numerical paper. They are different clocks.
What happens in a group discussion?
You are being watched for whether you can enter a conversation without burying it. Make one point that uses the topic, listen long enough to refer to what the previous person said, and disagree with the point rather than the person. A candidate who speaks first and then never again has not discussed anything. A candidate who interrupts every sentence has not either.
If you do not understand the topic, ask for the definition once, then contribute to that definition. Inventing statistics is obvious. "I have not seen a figure for that, so I will stay with the example in front of us" is allowed.
Which questions should you ask the interviewer?
Ask about the work, not about the canteen first. What does a junior do in the first three months? How is a ticket reviewed? Which stack is actually in production? Those questions tell them you intend to do the job. Skip a question whose answer was in the first five minutes of the interview. Skip salary if this round was clearly technical and a recruiter round is still ahead. Ask salary in the round that owns the offer.
Two questions are enough. Write them down so you do not go blank when they turn the interview around.
How should your resume and your answers match?
Every tool on the resume is a permitted question. If you wrote Spring Boot, you can be asked what a starter is. If you wrote Power BI, you can be asked what a measure is. If you wrote machine learning and you only imported a CSV, take it off. The common questions are common because they are a check that the page you submitted is true.
Keep one project at the top. Put the tools you can speak about beside it. Leave the rest in a shorter list or remove them. A one-page resume you can defend beats a two-page resume you have to apologise for.
How do you structure the day of the interview?
Sleep, eat, and open the project once so the names are in your mouth. Carry a notebook. For an online round, test the camera and sit where your face is visible. For a campus or office round in Chennai, leave earlier than the map suggests. A late arrival becomes the first story they remember.
During the round, answer, then pause. You do not have to fill every silence. If you need the question repeated, ask. Repeating a question you misheard is better than a fluent answer to a different question.
What is a reasonable one-week plan?
Day one: write and time the introduction, the project walk-through, the strength, and the weakness. Day two: the technical definitions that match your resume, out loud. Day three: one coding or SQL problem where you state the example before you solve it. Day four: aptitude or reasoning if the company uses a written test. Day five: a mock with a friend who is allowed to interrupt. The weekend is only for the project you will be asked to open.
Do not add a new framework in that week. The common questions reward a small set you can say cleanly. A new tool learned the night before shows up as hesitation on the second question.
Where do you go after the common questions?
Move to the page that matches the job. Java and Spring Boot candidates should sit the Java set and the Spring Boot set, with the Java tutorial under them. Python candidates should use the Python set and the Python tutorial. Data candidates should use SQL and Power BI. Testing candidates should use Selenium. The HR wording that is longer than this page is in HR interview questions.
The common round is passed by people who sound like the resume in front of the panel. Say what you built. Say what you have not built yet. Then answer the technical question they choose from that.
How do you close the interview?
Thank them, repeat the role in one line, and stop. "Thank you. I am interested in the junior analyst role, and I can walk through the report again if you want the measure in writing." Do not add a new story after they have stood up. If they offer a next step, note the date. If they do not, ask when you should expect to hear, once.
The same evening, write down the questions you stumbled on. That list is the revision for the next company. The common questions do not change much between panels. The candidate who fixes the one weak answer before the next morning is the one who sounds prepared the second time.
