HR Interview Questions: Answers for Every Fresher Situation

HR interview questions are not a test of trivia — they are a test of whether you can talk about yourself, your work, and your motivations without sounding rehearsed or evasive. The questions themselves ("tell me about yourself," "why should we hire you," "what's your weakness") barely change from company to company. What changes is whether your answer sounds like a template you copied or an actual person explaining actual decisions. This article gives you the exact questions that come up in nearly every Indian HR round, plus complete sample answers for four different situations: a fresher with no internship, a fresher with an internship, someone with a year of experience switching jobs, and someone moving from a service company to a product company.

What the HR round is actually checking

By the time you reach the HR round, a technical panel has usually already confirmed you can do the job. HR is checking three things: can you communicate clearly under mild pressure, will you stay long enough to be worth training, and will you cause friction on a team. Every question in this round maps back to one of those three. "Tell me about yourself" checks communication. "Why do you want to leave your current company" checks retention risk. "How do you handle conflict with a colleague" checks team friction. Once you see the round this way, you stop trying to guess the "right" answer and start giving an answer that's true and reassuring on those three axes.

In Indian campus and off-campus hiring specifically, HR rounds also do quiet filtering on things nobody says out loud: whether your salary expectation is realistic for your experience band, whether you'll accept the notice period and joining timeline the company needs, and whether you'll relocate if the role requires it. Answer those directly when asked — vague answers here read as evasive, not smart.

The questions that come up in almost every HR round

These aren't guesses — they are the same dozen questions that recur across TCS, Infosys, Wipro, Accenture, Cognizant, and most product-company HR screens in India. The table below breaks down what each one is really checking and how to approach it, separate from the exact words you'd say (full sample answers are in the next section).

Question	What it's actually checking	How to approach it
Tell me about yourself	Can you structure information; communication baseline	Present → Past → Future in under 90 seconds. See how to answer tell me about yourself for the full breakdown
Why should we hire you	Do you understand the role, or just want any job	Match 2 of your actual skills to 2 things the JD asked for, with proof
What is your greatest weakness	Self-awareness, not the weakness itself	Name a real, non-fatal weakness plus the specific action you're taking on it
Where do you see yourself in 5 years	Retention risk and whether your ambition fits this ladder	Describe growth within the function they're hiring for, not a different career
Why do you want to leave your current company	Are you running from a problem or running toward growth	Frame around what you're moving toward — scope, tech stack, learning — never trash the current employer
Why the gap in your education/employment	Whether the gap signals a pattern or a one-off event	State the reason factually in one line, then pivot to what you did with the time
What are your salary expectations	Whether your number is realistic for your band	Give a range anchored to market data, not a single fixed number, and know what that number actually converts to in-hand before you answer
Are you okay relocating / with the notice period	Logistics fit, joining timeline risk	Answer with a yes/no and a specific date, don't hedge
Tell me about a time you handled conflict	Team friction risk	Use a real, small example; show you resolved it without escalating unnecessarily
Do you have any questions for us	Genuine interest vs. checkbox candidate	Ask 1–2 specific questions about the team or role, not about leave policy

Full sample answers for four different situations

Generic advice ("be confident," "show enthusiasm") is useless when you're sitting in the chair. Below are complete, spoken-style answers to the two hardest questions — "tell me about yourself" and "why should we hire you" — for four situations that cover almost every candidate reading this.

Situation 1: Fresher with no internship

Tell me about yourself: "I'm a final-year B.Tech Computer Science student from [college], graduating in 2026 with a CGPA of 8.1. Since I didn't have a formal internship, I used my final two years to build depth on my own — I've completed three full projects, including an inventory management system using Java and MySQL that's on my GitHub, and I did a 6-week certification in Python for Data Analysis through [platform] where I finished in the top 10%. I also mentored two juniors in DSA for our college coding club, which pushed me to get faster and more precise myself. I'm looking for a role where I can apply that foundation on real production systems and grow into someone who owns a module end to end within a year."

Why should we hire you: "You need someone who can pick up your stack quickly without much hand-holding — my three self-driven projects show I don't wait for a syllabus to start building. You're also likely hiring for consistency in a fresher batch, and my academic record plus the fact that I kept building outside coursework for two straight years shows that's not a one-off effort."

Situation 2: Fresher with an internship

Tell me about yourself: "I'm a final-year B.Tech student, and I did a 4-month internship at [startup/company] as a backend intern, where I built two REST APIs that are now live in their production app and fixed a caching bug that cut average response time by about 30%. Before that, I built a personal project — a expense tracker with React and Node — to teach myself the stack before the internship started, which is partly why I could contribute from week two instead of week six. I'm now looking for a full-time role where I can go deeper into backend systems and eventually own a service, not just a feature."

Why should we hire you: "I've already shipped code that's running in a live product, so you're not hiring someone who's only worked on toy problems — I've dealt with a real bug backlog and a real deploy process. And because I taught myself the stack before the internship even needed it, I move fast on ambiguous tickets instead of waiting for detailed specs."

Situation 3: One year of experience, switching jobs

Tell me about yourself: "I've spent the last 13 months at [company] as a Software Engineer, where I work primarily on their billing microservice in Java and Spring Boot. In that time I moved from picking up small bug fixes to owning a full feature — a proration logic change for mid-cycle plan upgrades — end to end, from design doc to production rollout. I'm looking to move now because I've plateaued on the learning curve there; the team is small and I'm not getting exposure to the scale or the newer parts of the stack I want next, like event-driven systems, which is why this role caught my attention."

Why should we hire you: "I'm past the fresher ramp-up — I already know how to work with a codebase I didn't write, follow a review process, and ship without a senior babysitting every PR. What I want next is exactly what this role offers: more scale and a stack I haven't touched yet, which means I'll be motivated to learn fast rather than coast."

Situation 4: Service company to product company switch

Tell me about yourself: "I've been at [service company] for a year and a half, currently on a project for a US retail client, where I work on their inventory sync module in .NET. I've delivered three client-facing releases on schedule and became the go-to person on my team for a legacy integration nobody else wanted to touch. I'm moving toward product companies now because I want to work on one product deeply over years rather than rotating across client projects every few months — I want to see the long-term consequences of the decisions I make in code, and get closer to actual users instead of a client's project manager."

Why should we hire you: "I've already proven I can deliver reliably under a client SLA, which is a harder constraint than most internal deadlines. What I lack is deep product-company exposure, but I've been closing that gap on my own — I've been building a side project with the exact stack your team uses, specifically so the ramp-up here is shorter than it looks on paper."

Tricky HR questions that trip people up

• "Your CTC expectation seems high for a fresher" — Don't get defensive. Say: "I anchored that number to the [track/band] range reported for this role this year; I'm flexible if the total compensation and growth path make sense." Know your numbers before you walk in — see how CTC differs from in-hand salary so you're not negotiating against a number you don't actually understand.
• "Why so many companies in 2 years?" — Give the real, short reason (layoff, bad manager, wrong tech stack) once, without ranting, then show the pattern has stopped: "This role is different because [specific reason tied to this job]."
• "What's your notice period?" — State it exactly, and mention if it's negotiable. Know how it's calculated at your current employer before you commit to a date you can't keep.
• "Do you have any offers in hand?" — Be honest. It doesn't weaken you; it can speed up your process if the company wants you.

Mistakes that get freshers rejected at the HR round

• Reciting a memorized answer word-for-word — interviewers can tell, and a single follow-up question exposes it.
• Bad-mouthing a previous employer, professor, or teammate, even when you're right to be annoyed.
• Giving a weakness that's actually a strength in disguise ("I'm a perfectionist") — HR has heard this a thousand times and it signals you didn't think about the question.
• Not having a single question to ask back when invited to — it reads as disinterest, not humility.
• Answering "why this company" with information copied straight from their About page instead of something specific to the role or team.

Questions worth asking the interviewer

Two or three of these, not all of them: What does success look like in this role at the 6-month mark? What's the size and structure of the team I'd be joining? What's the biggest challenge the team is currently dealing with? What does the onboarding and training process actually look like in the first month? Avoid asking about leave policy or WFH in the first HR round — save that for the offer-negotiation stage once you're clearly the preferred candidate.

FAQ

How long should an HR interview answer be?

60–90 seconds for open-ended questions like "tell me about yourself." Longer than that and you lose the interviewer's attention; shorter and it looks like you have nothing to say.

Is it okay to say I don't know the answer to a question in the HR round?

Yes, for factual or hypothetical questions outside your control. Say so briefly and offer how you'd find out, rather than making something up.

Should freshers negotiate salary in the HR round?

You can indicate a range if asked directly, but detailed negotiation usually happens after the offer letter, not during the interview itself.

What if I genuinely have no weakness I'm comfortable sharing?

Everyone has one. Pick something real but not job-critical — public speaking anxiety, tendency to over-plan, difficulty saying no to extra work — and pair it with one concrete action you're taking.

Do HR interview questions differ between TCS, Infosys, and product companies?

The core questions are nearly identical, but weighting differs. Service companies like TCS and Infosys probe joining-date flexibility and long-term commitment harder; see what TCS actually asks in its HR round and what Infosys asks across its SP, DSE, and SE tracks for company-specific detail.

Can I reuse the same "tell me about yourself" answer across companies?

Keep the structure the same but tweak the ending to match what each specific role needs — a generic close signals you didn't read the job description.