You wrote React in the skills section on a Tuesday night, because the job posting asked for it and you had built a to-do app and a weather dashboard from a YouTube series. Fair enough. Now it is the second round of an off-campus drive, the interviewer has your resume open on one screen and your face on the other, and she says: "So, React. Tell me how you managed state in your project."
You start describing the to-do app. She nods, then asks why you did not just use props. Then what happens when two components need the same data. Then what a re-render actually is. Somewhere around the third question, the confidence that was there when you typed the word "React" has gone, and you can hear yourself saying "basically" a lot.
This happens to a very large share of freshers, and it is not because they lied on their resume. It is because they did not realise what a resume is for.
The short answer
Your resume is not a list of things you have heard of. It is the interviewer's question bank. Every technology you name gives them permission to ask about it, and most of them will, within the first ten minutes. The way to prove you know React is not to memorise React interview questions from a list. It is to open the React project you actually built, understand every decision in it well enough to explain it to someone who has not seen the code, and be ready for three follow-up questions on each one.
The rest of this article is about how to do that, what interviewers are really listening for when they ask React questions to freshers, and what to do about the lines on your resume you cannot defend.
Why this matters more for freshers than for anyone else
An experienced developer's resume is mostly work history. The interviewer asks about the last job and the conversation follows the projects. A fresher's resume has almost no work history, so the skills section and the project list carry the whole interview. Whatever you wrote there is the entire agenda.
Indian campus placements and off-campus drives make this sharper. A single interviewer may see fifteen candidates in a day, all with similar CGPAs, all listing React, Node and MongoDB from the same tutorials. The only way to tell them apart in twenty minutes is to pick one skill from the resume and go deep. Depth is exactly the thing a tutorial-only candidate does not have, and the interviewer knows that, so that is where they dig.
What "knowing React" means to the person interviewing you
Interviewers are rarely checking whether you can recite the documentation. Google's own description of its hiring process, in How we hire, says its interviews assess how a candidate thinks and solves problems rather than recall. Most companies that hire freshers in India, from product startups to the large service firms, are doing a version of the same thing even when they have not written it down. They want to know whether you have made decisions with React, not whether you know its vocabulary.
The difference shows up in the follow-ups. Here is a typical chain.
"You used React in this project. How did you manage state?" You say you used a state library. "Why that instead of React's built-in context?" You say something about performance. "What performance problem did you actually hit, and how did you know it was that?"
That third question is the whole interview. A candidate who chose the library because the tutorial did has nothing to say. A candidate who chose it for a reason, even a modest one, has a story. The interviewer has learned what she needed to learn either way.
Start with your own code, not with a question bank
The most useful React preparation for a fresher is not re-reading the React documentation from the start. It is opening the last project you built and interrogating it as if you were the interviewer.
Go through it component by component and ask yourself the questions you would least like to be asked. Why is this component split here and not somewhere else? Where does this state live, and who else needs it? Which props are passed down more than two levels, and did that get annoying? Where do the API calls happen, and what does the screen show while they are loading? What happens when a request fails? Does the user see anything, or does it silently do nothing?
Then look at your effects. The React team's guide You Might Not Need an Effect lists the common cases where developers use useEffect when a plain calculation during render would do. Almost every fresher project has at least one: an effect that copies a prop into state, or a fetch that runs on every render because the dependency array is missing. An experienced interviewer will spot this from your description of the code, before they ever see it.
You do not need to have made perfect decisions. You need to be able to explain the ones you made, including the ones you would change. Something like: "I put the fetch in a useEffect with an empty dependency array. Later I realised it fetched again every time the user navigated back to the page. If I built it again I would use a data-fetching library that caches by key." That answer shows more understanding than a flawless answer would, precisely because it admits a mistake and names the fix.
The React questions freshers actually get, and what sits behind them
Interviewers vary, but React questions for freshers cluster around a few areas. For each, the question they say out loud is standing in for a question they are really asking.
When they ask what causes a component to re-render, they are asking whether you understand React's model at all: state or props change, the function runs again, React compares the output with what is on screen. If you can add "and I used the React DevTools profiler once to see why a list was re-rendering on every keystroke", you are ahead of most of the room. If you have never opened the profiler, do it once before the interview so you have a real example.
When they ask how you managed state, they are asking whether you thought about where state should live. Local state in the component that owns it. Lifted up when siblings share it. Context for things that are genuinely global, like the logged-in user. A store or a server-state library when data comes from an API and needs caching. Knowing this list is table stakes. Pointing to a moment in your project when you moved state from one place to another, and why, is what earns the mark.
When they ask about useEffect, they are really asking about timing. When does it run relative to the paint? What does the cleanup do? Why did a stale value show up inside it? These connect to how the browser schedules work, so a working picture of the JavaScript execution model and event loop will help you across the whole frontend interview, not just this question.
When they ask why lists need a key, or the difference between a controlled and an uncontrolled input, they are checking whether you have hit the problem these solve. A fresher who has only watched tutorials gives the textbook answer and stops. A fresher who has built something says "I used the index as the key once and the checkboxes went out of order when I deleted an item", and that sentence is worth more than the definition.
What a strong answer sounds like next to a weak one
Question: "Why did you use React for this project?"
Weak: "React is a popular JavaScript library for building user interfaces using reusable components and a virtual DOM, which makes it fast and efficient."
That is a definition. It is correct, it is what the first paragraph of every tutorial says, and it does not answer the question. The interviewer asked why you chose it.
Strong: "Honestly, at first because the course used it. But the project had a dashboard where six or seven widgets updated independently, and once I understood components it made sense to give each widget its own state instead of one big page script. If I did it again I might try plain HTML and a small amount of JavaScript first, because two of those widgets never changed."
That answer is less polished. It also shows a decision, a reason grounded in the actual project, and a piece of judgement about when React is unnecessary. Interviewers remember the second answer.
The mistakes that lose the marks
The most common one is answering "why" with "what". The interviewer asks why you chose something and gets a description of the thing. Train yourself to hear "why" as a request for a decision and its trade-off.
The second is claiming the whole project. In a group final-year project, say which parts were yours. "I built the authentication flow and the dashboard; my teammate did the API." Interviewers respect this and they will ask about your part in depth, which is what you want. Claiming the whole thing and then being unable to explain the backend is far worse.
The third is not knowing the difference between the tutorial and your work. If your project is the tutorial project with the colours changed, say so honestly and talk about what you would build next. The alternative, presenting it as original and being caught by "so why did you structure it this way", is the worst outcome available.
Practise saying it out loud
Knowing your project and being able to explain it under time pressure are different skills. The second one is the one interviews measure, and the gap between them is bigger than most freshers expect. That is why so many people leave an interview certain they knew the answer and equally certain they did not manage to say it.
The fix is to rehearse aloud, to a listener who pushes back. Explain your project's state management to a friend who has not seen the code, then have them ask "why" three times. If you can survive three whys on every technology on your resume, you are prepared for that interview.
If you do not have someone to do this with, a structured practice round does a similar job. On 99Interview you can take a frontend practice interview that starts from your background, asks about the technologies you name and follows up the way a real interviewer does, either with an AI interviewer that you can start immediately or as a live session with a working engineer who writes up feedback afterwards; the options are on the pricing page. The useful part is the transcript. Read it afterwards and find the exact moment your explanation turned into a definition. That is the thing to practise next.
Fix the resume, or back it up
There is one more honest option. If a technology is on your resume and you could not survive the three whys, take it off, or move it to a line that says what it actually is: "familiar with", "used in a course project", "currently learning". A precise resume beats a long one. A shorter skills section also means the questions land on the things you can actually talk about, which is the whole game in a twenty-minute placement interview.
Frequently asked questions
What React questions are asked to freshers in interviews?
The common ones are what causes a re-render, how you managed state and why, what useEffect does and when it runs, why list items need keys, the difference between controlled and uncontrolled inputs, and how your project handled loading and error states. Almost all of them arrive as follow-ups to your own project, so prepare from your code rather than from a list.
How do I explain my React project in an interview?
Start with what it does in one sentence, then the structure: the main components, where state lives, where data comes from. Then one decision you made and why, and one thing you would change. Keep it under two minutes and let the interviewer choose where to go deeper.
Should I put React on my resume as a fresher if I only did a course project?
Yes, if you can explain that project's decisions. Label it honestly if it was a guided project. What hurts is not a small project; it is being unable to answer why you did what you did in it.
How many React projects do I need before an interview?
One that you understand completely is worth more than three you followed along with. Interviewers go deep on one project, not wide across many.
How long does it take to prepare for a React interview?
If you already have a project, a focused week is realistic: two or three days going through your own code and writing down the decisions, then several days of explaining it aloud and answering follow-ups. If you do not have a project yet, build a small one first; there is no shortcut around that.
What to do tonight
Open your React project. Pick the component you understand least and write one paragraph explaining every decision in it, including the ones you would now change. Tomorrow, explain that paragraph to someone out loud and let them ask why.
You already know whether the React on your resume is a skill or a keyword. Which lines could you defend for three follow-up questions right now?