Interview Insights · React Developer
Why React Developers Who Ask Questions Back Impress Me Most
Quick summary — Clarifying questions
Asking questions back shows that you build for real requirements, not for an imagined version of the task. Most React interview tasks are deliberately vague: build a search box, a modal, a paginated table. In real work, vague tickets are normal, and the developer who clarifies them early saves days of rework. When a candidate asks whether search should call the API on every key press, or whether the modal must trap focus, I learn that they think about users, data and edge cases. This page lists the questions that matter most and shows how each answer changes the component you write.
In this guide you will learn:
- Why interview tasks are vague on purpose
- The four question areas that cover most React tasks
- Code that changes depending on the answers
- Questions that hurt you, and how to avoid them
- A clarifying-question card to practise with
SECTION 01Why I leave React tasks vague on purpose
When I say 'build a search box that shows matching users', I leave out a lot: where the data comes from, how many users exist, what happens while results are loading, and whether the list should be keyboard navigable. This is not a trick. Real product tickets look exactly like this, and part of a React developer's job is turning a short ticket into clear behaviour.
A candidate who starts coding immediately has to guess all of these. Guesses lead to rework when I add a requirement halfway. A candidate who asks first builds the right thing once, and shows me how they will work with product managers and designers.
| Task as given | What is unstated | Risk of guessing | One good question |
|---|---|---|---|
| Build a user search box | Data source, size, timing | Hundreds of API calls while typing | Should I filter locally or call an API? |
| Make a reusable button | Variants, sizes, loading | A component nobody else can use | Which variants does the design system need? |
| Show a paginated table | Server or client paging | Loading every row at once | Is paging done by the API? |
| Build an image carousel | Autoplay, swipe, accessibility | Unusable on keyboard or mobile | Should it work with arrow keys and swipe? |
Me: Build a search box that shows matching users.
Candidate: (starts typing)
useEffect fetch on every change of query...
20 minutes later
Me: The API is rate limited. Typing 'ravi' sends
four requests. Can you fix that?
Candidate: (rewrites the effect, adds a timer,
loses track of loading state, runs out of time)Me: Build a search box that shows matching users.
Candidate: Two quick questions.
1. Is the user list small enough to filter on the
client, or do I call a search API?
2. If it is an API, should I wait until the user
stops typing before calling it?
Me: API, and yes, it is rate limited.
Candidate: Then I will debounce the query by about
300 ms and cancel stale requests so old results
do not overwrite new ones.
The second candidate spent twenty seconds on questions and then built the right solution once. That is the habit I want on my team.
SECTION 02How the answers change the component you write
The best way to understand why questions matter is to see the code each answer leads to. Take the search box. If the answer is 'call the API', you need a debounced value, request cancellation and loading and error states. If the answer is 'filter a small local list', you need none of that, just a derived value.
Interviewers notice when a candidate's code clearly follows from the answers they received. It shows deliberate thinking rather than a memorised pattern.
| Answer received | What you add | React tool used | What I check in your code |
|---|---|---|---|
| Call the API, rate limited | Debounce the query | Custom useDebouncedValue hook | Timer cleared on every change |
| Old results can arrive late | Cancel stale requests | AbortController in effect cleanup | Abort errors ignored, not shown |
| Small local list | Filter during render | Plain derived value, maybe useMemo | No extra state for filtered list |
| Must work with keyboard | Arrow key navigation | onKeyDown and an active index state | Enter selects, Escape closes |
import { useEffect, useState } from "react";
export function useDebouncedValue(value, delay = 300) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const id = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(id); // reset on every keystroke
}, [value, delay]);
return debounced;
}import { useEffect, useState } from "react";
import { useDebouncedValue } from "./useDebouncedValue";
export function useUserSearch(query) {
const q = useDebouncedValue(query.trim(), 300);
const [state, setState] = useState({ status: "idle", users: [] });
useEffect(() => {
if (!q) {
setState({ status: "idle", users: [] });
return;
}
const controller = new AbortController();
setState((s) => ({ ...s, status: "loading" }));
fetch(`/api/users?search=${encodeURIComponent(q)}`, {
signal: controller.signal,
})
.then((res) => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
})
.then((users) => setState({ status: "done", users }))
.catch((err) => {
if (err.name !== "AbortError") {
setState({ status: "error", users: [] });
}
});
return () => controller.abort(); // cancel stale request
}, [q]);
return state;
}
Notice how directly the code follows the two questions: debounce because of the rate limit, abort because old responses can arrive late. When I ask 'why is this here?', the candidate can point back to my own answer.
SECTION 03Questions that help you, and questions that hurt
Not every question impresses. Some questions make you look unprepared, such as asking what useState does in a React interview, or asking for the answer in disguise. Others waste time because their answer would not change anything. And some candidates ask ten questions before writing a line, which can look like stalling.
A good rule is two to four focused questions, each covering a different area: users, data, edge cases and scope. Then state any remaining assumptions and start building.
| Question asked | Why it hurts or helps | Better version | Area covered |
|---|---|---|---|
| How do I use useEffect? | Shows a gap in basics | Make the effect and explain the dependencies | None |
| Is this the right way? | Asks for approval, not facts | I plan X because Y. Any constraint I am missing? | Approach check |
| What colour should the button be? | Answer barely changes the code | Assume a neutral style and move on | Low value |
| What should happen when the API fails? | Changes UI states and code | Show a retry, or just a message? | Edge cases |
Task: Build a reusable Modal component.
Strong questions:
- Should it close on Escape and on backdrop click?
- Should focus move into the modal and return to the
trigger button when it closes?
- Will it be controlled by the parent (open prop)
or manage its own open state?
Answers shape the props:
Modal({ open, onClose, title, children,
closeOnBackdrop = true })
Usage stays simple:
return open ? (
<Modal open={open} onClose={() => setOpen(false)} title="Delete item?" />
) : null;When you run out of useful questions, state assumptions:
'I will assume:
- the list has under a few hundred items
- dates come as ISO strings
- we support the latest Chrome and Firefox
- no design system is available, so plain CSS.
Tell me if any of these are wrong.'
This gives the interviewer a quick chance to
correct you, without a long question session.
Saying assumptions aloud is the partner habit to asking questions. Together they show me that you know which details matter, without slowing the round down.
SECTION 04Clarifying-question card for React tasks
Keep this card in mind for machine coding and take-home tasks. Practise picking two to four questions from it for each new task, out loud, before you code.
BEFORE YOU CODE A REACT TASK
USER
- Who uses it, on which devices?
- Keyboard and screen reader support needed?
DATA
- Where does data come from: props, API, local?
- How large can it get? Paging or filtering on server?
EDGE CASES
- Empty state? Loading state? Error state?
- Slow network or duplicate clicks?
SCOPE
- What matters most in the time we have?
- Can I use a library, or plain React only?DAILY DRILL (15 minutes)
1. Pick a vague task: star rating, tabs, accordion,
infinite list, file upload, OTP input.
2. Write 6 possible questions.
3. Circle the 3 whose answers change the code.
4. For each, write how the code changes:
'If yes -> I need ___ state / ___ effect.'
5. Say the 3 questions aloud in under 30 seconds.
After two weeks you will ask the right questions
without thinking about the card.FOR TAKE-HOME TASKS
You may not get to ask live, so:
[ ] Email 2-3 short questions early if allowed
[ ] Otherwise write an ASSUMPTIONS section
in the README:
- Search calls the API with a 300 ms debounce
- Results are limited to 20 per page
- Empty query shows recent users
[ ] Explain what you would change if an assumption
turns out to be wrong
SECTION 05Habits that make your questions land well
How you ask matters as much as what you ask. These habits keep questions short, useful and confident.
- Ask in one breath — Group your questions and ask them together, rather than interrupting yourself every few minutes.
- Offer a default — Say 'I will debounce by about 300 ms unless you prefer otherwise'. It shows initiative and still invites correction.
- Write the answers down — Note each answer at the top of your file as a comment. It keeps you consistent and shows the interviewer you listened.
- Ask again if the task grows — When the interviewer adds a requirement mid-round, ask one quick question about it before changing code.
- Use questions in the end too — When you finish, ask what they would change. It turns the end of the round into a short review conversation.
SECTION 06Interview Q&A — Clarifying questions
Q1Build a search box for users. Any questions before you start?
Ask whether filtering happens locally or through an API, whether calls should wait until typing stops, and what should show for empty, loading and error states. Then state your plan: debounce the query, cancel stale requests and render each state clearly.
Q2Why did you add an AbortController in your effect?
Because responses can arrive out of order. If the user types 'ra' then 'ravi', the slower 'ra' response could overwrite the newer results. Aborting the previous request in the cleanup function makes sure only the latest query updates state, and I ignore AbortError so it is not shown as a failure.
Q3Should a reusable Modal be controlled or uncontrolled?
Usually controlled, with an open prop and an onClose callback, because the parent often needs to know whether it is open, for example to reset a form. I would ask the team's preference, since some libraries offer both patterns.
Q4What would you do if requirements are unclear on a real ticket?
Ask the product owner or designer a few focused questions early, write the agreed behaviour on the ticket, and state any remaining assumptions in the pull request description so reviewers can catch mismatches.
Q5How many questions should I ask in a machine coding round?
Usually two to four, each covering a different area such as data source, edge cases and scope. Then state your remaining assumptions aloud and start coding. Too many questions can look like stalling.
SECTION 07Test yourself — Clarifying questions quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Is it okay to ask questions in a React coding interview?
Yes. Interviewers usually welcome clarifying questions about requirements, data and edge cases. Keep them focused, ask them before you start, and state assumptions for anything else.
What questions should I ask in a machine coding round?
Ask about the data source and size, required states such as loading, empty and error, keyboard or mobile support, and what to prioritise in the time available. Choose questions whose answers change your code.
Does asking questions make me look less skilled?
Not when the questions are about requirements. Asking how a basic hook works can raise doubts, but asking whether search should be debounced shows experience with real product work.
What is a machine coding round for React developers?
It is a timed round where you build a small working feature, such as a search box, carousel or form, often in a live editor. Interviewers look at component structure, state handling, edge cases and code clarity.
How do I practise clarifying questions at home?
Take simple UI tasks, write possible questions, keep only those that change the code and say them aloud before building. Practising with a friend who answers differently each time helps even more.
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 clarify, then build, in React
Our React JS Training Course includes machine coding practice and code reviews, so asking the right questions before coding becomes a natural habit.
Talk to a counsellor for current fees- Machine coding practice
- Custom hooks and state
- Code reviews by trainers
- Weekday & weekend batches