Interview Insights · React Developer
What Junior React Developers Get Wrong About Talking to Interviewers
Quick summary — Talking in interviews
Junior React developers often treat the interview as an exam to survive, when it works far better as a conversation. The most common communication mistakes I see are not about grammar or accent. They are habits: using big terms like reconciliation and Fiber without explaining them, defending code when the interviewer points out a problem, saying 'we' for everything in a team project, and answering a different question from the one asked. These habits make capable developers sound less capable. This page shows each habit, how it sounds from my side of the table and how to explain React ideas in a way that builds trust.
In this guide you will learn:
- Why jargon makes answers weaker, not stronger
- How to explain reconciliation and useReducer in plain words
- Handling 'is this a bug?' without getting defensive
- Using 'I' and 'we' correctly in team project answers
- A conversation practice kit for React interviews
SECTION 01Jargon dumps: when big words hide understanding
Ask a junior developer how React updates the screen, and many will say something like 'React uses the virtual DOM and the Fiber architecture for reconciliation with a diffing algorithm'. Every word is real. But the sentence does not show me that they understand anything. It sounds memorised, and my next question is usually designed to find out whether it is.
The stronger approach is to explain the idea in plain words first, then use the correct term as a label. That way the term shows knowledge rather than replacing it.
| Term juniors use | Plain-words explanation | Tiny example | Follow-up you can handle |
|---|---|---|---|
| Reconciliation | React compares the new UI description with the old one to decide what changed | Only the changed price text updates, not the whole card | What helps React match list items? |
| Virtual DOM | A lightweight description of the UI in JavaScript objects | Elements created by JSX are plain objects | Is the virtual DOM always faster? |
| Batching | React groups several state updates into one re-render | Two setState calls in a click cause one render | When does batching happen in React 18? |
| Hydration | Attaching React behaviour to HTML rendered on the server | Server HTML becomes clickable after JS loads | What causes a hydration mismatch? |
Me: How does React update the screen when state changes?
Candidate: React uses virtual DOM and Fiber, so it does
reconciliation using a diffing algorithm which is O(n),
and then it commits to the real DOM, so it is very fast
because the virtual DOM is faster than the real DOM.
Me: Why is it faster?
Candidate: Because... it is virtual.
(Every term is real. The understanding is not visible.)Me: How does React update the screen when state changes?
Candidate: When state changes, React calls the component
again to get a new description of the UI. It compares
that with the previous description and works out the
smallest set of real DOM changes, then applies them.
That comparison is called reconciliation.
For example, if only a product's price changes, React
updates that text node and leaves the image alone.
Should I go into how keys help it match list items?
The second answer still uses the word reconciliation, but only after explaining it. It also ends by offering a direction, which turns the answer into a conversation.
SECTION 02Explaining a hook out loud: the useReducer example
A common interview request is 'explain how this works' about a piece of code. Junior developers often read the code line by line in a flat voice, which tells me what the code says but not what it means. A better approach is to start with the purpose, then describe the flow of data, then point out one detail that matters.
useReducer is a good practice case because it has a clear flow: an event dispatches an action, the reducer calculates the next state, React re-renders with it. If you can explain that flow simply, you can explain most React code.
| Weak explanation habit | What it sounds like | Better habit | What it sounds like |
|---|---|---|---|
| Reading line by line | Here we import, here we define... | Purpose first | This manages a form with several steps |
| Naming without meaning | This is the dispatch | Describe the flow | Clicking Next sends a 'next' action |
| Skipping why | And then it returns state | Point out one key detail | It returns a new object, so React sees the change |
| Monologue | Five minutes without a pause | Check in | Want me to show how errors are handled? |
export const initialState = {
step: 1,
values: { name: "", email: "", plan: "basic" },
error: null,
};
export function signupReducer(state, action) {
switch (action.type) {
case "change":
return {
...state,
values: { ...state.values, [action.field]: action.value },
error: null,
};
case "next":
if (state.step === 1 && !state.values.email.includes("@")) {
return { ...state, error: "Enter a valid email" };
}
return { ...state, step: Math.min(state.step + 1, 3) };
case "back":
return { ...state, step: Math.max(state.step - 1, 1) };
default:
return state;
}
}
// In the component:
// const [state, dispatch] = useReducer(signupReducer, initialState);
// dispatch({ type: "change", field: "email", value: e.target.value });PURPOSE
'This reducer manages a three-step signup form:
which step we are on, the field values and an error.'
FLOW
'When the user types, the component dispatches a
change action with the field name and value. The
reducer returns a new state with that field updated
and clears any error. Clicking Next dispatches next.'
KEY DETAIL
'On step 1, next checks the email first. If it is
invalid, it stays on the step and sets an error
instead of moving on. All the rules live in one
place, which is why I chose useReducer over
several useState calls.'
CHECK IN
'Would you like me to show how I tested it?'
This four-part pattern of purpose, flow, key detail and check in works for any code explanation. Practise it on two hooks from your own project and it will come naturally under pressure.
SECTION 03Defensive replies and the I-versus-we problem
Two other habits cost junior React developers a lot. The first is getting defensive when the interviewer points out a problem: 'that is not a bug, it works on my machine' or a long justification. Interviewers often point out issues on purpose, to see how you take feedback. A calm 'good catch, here is how I would fix it' is one of the strongest moments in an interview.
The second is the 'we' problem. In team projects, many juniors say 'we built', 'we decided', 'we used Redux' for everything. I cannot tell what you did. Use 'we' for the team's decisions and 'I' for your own work, and be specific.
| Situation | Defensive or vague reply | Strong reply | What it shows |
|---|---|---|---|
| Interviewer spots a missing cleanup | It works fine in my testing | Good catch, the interval keeps running after unmount; I would clear it | Takes feedback well |
| Question about a team project | We built the whole dashboard | I built the filters and the charts; a teammate did auth | Clear ownership |
| Your approach is questioned | This is the correct way | I chose it because of X; would you approach it differently? | Open to other ideas |
| You do not know an API | I have used that, I think | I have not used it, but I would start with its docs and an example | Honesty |
// Interviewer: 'What happens to this timer if the
// component unmounts?'
function Clock() {
const [now, setNow] = useState(() => new Date());
useEffect(() => {
const id = setInterval(() => setNow(new Date()), 1000);
// missing: return () => clearInterval(id);
}, []);
return <TimeDisplay value={now} />;
}
// Strong reply:
// 'Good catch. The interval keeps running after
// unmount, so it leaks and tries to update a
// component that is gone. I would return a cleanup
// that calls clearInterval(id).'TEAM PROJECT ANSWER TEMPLATE
'This was a team of four building a college
events app.
As a team, we chose React with Vite and agreed
on a shared component folder.
I owned the event list and filters: I built the
filter bar, stored the selected filters in the URL
so links could be shared, and wrote tests for the
filter logic.
A teammate handled login, and another built the
admin forms.'
We = team decisions. I = your work.
Notice that the strong replies are short. Defensive answers tend to be long because they are trying to win an argument. Strong answers accept the point and move to the fix.
SECTION 04Conversation practice kit for React interviews
Good interview communication is a skill you can practise like coding. These three exercises target the habits on this page. Use them with a friend, or record yourself if you practise alone.
PLAIN-WORDS DRILL
For each term, explain it to a non-developer
in two sentences, then give a React example:
[ ] Reconciliation
[ ] Virtual DOM
[ ] Batching
[ ] Hydration
[ ] Memoisation
[ ] Props drilling
[ ] Controlled component
[ ] Side effect
Rule: you may say the term only at the END
of your explanation.CATCH DRILL (with a partner)
1. Partner reads one of your components.
2. Partner points out any issue, real or not.
3. You reply using only this pattern:
- 'Thanks' or 'Good catch'
- What the issue causes
- How you would fix it
- (If you disagree) your reason + a question
4. Partner scores: calm? short? specific?
Repeat with five different issues.EXPLAIN-THE-CODE DRILL
Pick one hook or component from your project.
Explain it aloud in under 90 seconds:
1. PURPOSE - what it is for, one sentence
2. FLOW - what triggers it, what changes
3. DETAIL - one decision worth pointing out
4. CHECK IN - offer a direction to go deeper
Record it. Listen for line-by-line reading
and for terms you did not explain.
SECTION 05Habits that make you easy to talk to
Interviewers remember how a conversation felt. These habits make it feel like talking to a future teammate.
- Let the question finish — Wait until the interviewer finishes speaking. Interrupting with an answer often means answering the wrong question.
- Answer the question asked — If asked about useReducer, do not drift into Redux middleware. Stay on target, then offer to expand.
- Use examples from your code — Phrases like 'in my events app, I...' make explanations concrete and believable.
- Say what you do not know — Honest gaps, followed by how you would learn, build more trust than vague guesses.
- Practise with real people — Speaking to another person is different from rehearsing alone. Uncodemy mock interviews give you that practice with feedback.
SECTION 06Interview Q&A — Talking in interviews
Q1Explain how React updates the DOM when state changes.
React calls the component again to get a new description of the UI, compares it with the previous one and calculates the minimum DOM changes needed, then applies them. That comparison is called reconciliation. Keys help React match list items between renders so it updates the right ones.
Q2When would you choose useReducer over useState?
When state has several related values and many ways to change them, such as a multi-step form or a cart. A reducer puts all the update rules in one function, which makes them easier to read and test. For a single toggle or input, useState is simpler.
Q3I see a possible bug in your code. What do you think?
Thank the interviewer, look at the code they point to and explain what the issue would cause and how to fix it. If you believe it is not a bug, explain your reason calmly and ask whether they see a case you missed. The tone matters as much as the answer.
Q4What was your role in this team project?
Describe the team decisions briefly with 'we', then your own work clearly with 'I'. For example: 'We chose React and Vite. I built the filter bar, stored filters in the URL and wrote tests for the filter logic.' Credit teammates for their parts.
Q5Is the virtual DOM always faster than direct DOM updates?
Not always. Carefully written direct DOM updates can be faster for a specific case. The benefit of React's approach is that you describe the UI declaratively and React works out the updates for you, which is usually fast enough and much easier to maintain.
SECTION 07Test yourself — Talking in interviews quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
How do I explain React concepts in an interview?
Explain the idea in plain words first, give a small example from your own code and then name the technical term. Stop and offer to go deeper rather than continuing for several minutes.
Is it bad to say 'I don't know' in a React interview?
No, as long as you follow it with what you do know and how you would find the answer. Honest gaps are far better than confident guesses that fall apart on the next question.
How do I talk about team projects in interviews?
Use 'we' for team decisions and 'I' for your own contributions, and be specific about what you built. Interviewers need to know your part to judge your skills.
What if the interviewer says my code has a bug?
Stay calm, thank them, explain what the issue would cause and how you would fix it. If you disagree, give your reason politely and ask if they see a case you missed.
How can I improve my communication for developer interviews?
Practise explaining your own code aloud with a purpose, flow, key detail and check-in pattern, record yourself, and do mock interviews with someone who asks follow-up questions.
How can I prepare for React Developer interview answers with a trainer?
Yes. Uncodemy's React JS Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise React Developer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Learn to explain React as well as you write it
Our React JS Training Course combines React projects with regular code walkthroughs and mock interviews, so explaining your work clearly becomes second nature.
Talk to a counsellor for current fees- Hands-on React projects
- Code walkthrough practice
- Mock interviews with feedback
- Weekday & weekend batches