What are the most asked React JS interview questions?

What are the most asked React JS interview questions?

React and React JS are the same library in fresher interviews. A panel that says “React JS questions” is asking about components, props, state, hooks, and how data flows one way. They are not asking about a second framework with a similar name. If you prepare this list, you have prepared both search phrases. The questions that decide a fresher round are practical: what a component is, why props are not state, what useState and useEffect do, why lists need keys, and how a controlled input works.

JavaScript still sits underneath. Closures, array methods, and async functions appear inside React answers. Revise JavaScript interview questions in the same week. The notes here are a preparation guide, not a promise that every company uses this order.

What is a component, and what is JSX?

A component is a function that returns a description of UI. You call it as if it were an HTML tag, with a capital letter so React can tell it from a real DOM tag. JSX is the syntax that looks like HTML inside JavaScript. It compiles to function calls. You can write React without JSX. You will not enjoy it, and interviews still expect JSX. One component should have one job. A page component can compose smaller ones. A component that fetches data, formats dates, and renders a table of two hundred lines is the one you offer to split when the interviewer asks how you would improve the file.

Props are the arguments. They are read-only inside the child. State is data the component owns and can change. If a child needs to change something the parent owns, the parent passes a function down. That is the one-way idea in a single sentence. You do not assign to props. You call the function the parent gave you, and the parent sets state.

When do you lift state?

Lift state when two children must share it or when a parent must coordinate them. The classic example is a selected id that a list and a detail panel both use. The parent holds the id. The list reports clicks. The panel reads the id. If only one component cares, leave the state there. Lifting everything to the top “for architecture” makes a page component that knows too much and children that cannot be understood alone. Say the rule you actually use: share it when it is shared, keep it local when it is local.

The follow-up is often “could context do this?” Context shares a value with a deep tree without passing props through every layer. It is a good fit for a theme, a logged-in user, or a language. It is a poor fit for a value that changes on every keystroke if the whole tree then re-renders. For a fresher project, props are enough until the prop drilling hurts. Say that. Do not introduce a state library you cannot explain to avoid passing two props.

How does useState work?

useState returns the current value and a function that asks React to render again with a new value. Setting state does not mutate the old object in place and magically refresh. You pass the next value. For objects and arrays, you create a new object or array with the change, usually with a spread. Mutating the existing array and then setting the same array can skip the update you expected, because React may see the same reference. This is the bug to describe with a todo list: you pushed into the array and the screen did not change, then you set a new array and it did.

If the next value depends on the previous one, use the function form, setCount(n => n + 1). Two rapid updates that both read the same count can lose an increment if you do not. You may never have hit it. You should still be able to say why the function form exists. It is a better answer than “I always use the function form” with no reason.

What is useEffect for, and what are its mistakes?

useEffect runs after the render, for work that touches the outside world: a fetch, a subscription, a timer, or the document title. The dependency array says which values the effect should watch. An empty array means run once after the first render, which is the usual place for an initial fetch if you are not using a data library. No array means run after every render, which is rarely what you want. Missing a dependency that the effect uses is how stale data survives. A fetch that sets state without a cleanup can update a component that has already gone away. Return a cleanup function for subscriptions and timers, and ignore a stale response if the id changed before the request finished.

Do not put an effect where an event handler belongs. A click should be an onClick. An effect that runs because you set a “clicked” flag is an extra loop. Interviewers listen for that distinction. Also do not fetch in a loop of effects because the dependency is an object you recreated every render. Pass a stable id. If you do not know the exhaustive-deps lint, say you would rather include the value than silence the warning without reading it.

Why do lists need keys?

A key tells React which item is which across renders. It should be a stable id from the data, not the array index, when the list can be reordered, filtered, or inserted into. Index keys make React reuse the wrong component state, so an input appears to follow the wrong row after a sort. If the list is static and has no state inside the row, index keys often work, and you can say that limitation. The default answer for a fresher project with ids is the id.

Keys belong on the element you return from the map, not on a child inside it only. And keys do not pass as a prop unless you also pass the id yourself. People read key={id} and then wonder why props.key is undefined. Say the key is a hint to React, and the child receives an explicit id prop if it needs the id.

What is a controlled input?

A controlled input takes its value from state and reports changes through onChange, which sets state. React is the source of truth. An uncontrolled input keeps the value in the DOM, and you read a ref when you need it. Controlled inputs are the default in interviews because validation and disabling the submit button are obvious: they read the same state the input shows. The bug is a value prop with no onChange, which freezes the field. If you type and nothing happens, that is the bug to name.

Forms with ten fields do not need ten anecdotes. Show one field, the state, the change handler, and one validation message. Then say you would extract a field component if the form grew. That is enough architecture for a fresher round.

What should you say about the virtual DOM?

React keeps a description of the UI. When state changes, it builds the next description, compares it with the previous one, and updates the real DOM where they differ. The comparison is the reconciliation people nickname the virtual DOM diff. You do not need the algorithm’s source. You need the consequence: do not rebuild huge trees with new component types every render, give lists stable keys, and do not assume every setState touches the whole document like a manual innerHTML replacement. The point of the model is that you describe the UI you want and React performs the edits.

A fresher who says “virtual DOM makes React the fastest” will be asked compared with what. A fair answer is that it makes updates predictable and often cheap, and a bad key or a huge context value can still make them expensive. Performance talk without a measured slow screen is guesswork. If your project was small, say it was small and the virtual DOM was not your bottleneck.

What are the rules of hooks?

Call hooks at the top level of a function component or a custom hook. Do not call them inside a loop, a condition, or a nested function. React relies on the call order to keep each hook’s state lined up across renders. A conditional useState shifts that order and corrupts state. You can still decide whether to run an effect’s body. You just do not decide whether to call the hook. Custom hooks are functions whose names start with use and that may call other hooks. They exist so you can reuse stateful logic, such as a data fetch, without copying the effect into every page.

If you wrote a custom hook, explain what state it hides and what it returns. If you did not, do not invent useFetch with features you cannot code. Say you kept the effect in the component because only one screen needed it. That is a valid design.

How do you present a React project?

Start at the screen the user sees. Name the state that screen owns. Point at one child and the props it receives. Trigger one event and show the state update. If you fetch, show where the effect lives and what you render while the request is in flight: a loading message, then the list, or an error. The bug to mention might be a missing key, a mutated array, an effect that fetched on every render, or a controlled input you accidentally froze. Then accept a live change. “Add a search box” should be a filter on the list you already have, not a new architecture.

Asmorix students can build that screen in React JS training in Pondicherry and pair it with JavaScript fundamentals. Full-stack roles also want an API story, which connects to Spring Boot or to a Python API, depending on the stack you actually wrote. Do not describe a backend you did not run. Say the frontend called a fake list, and say what the real endpoint would return.

The HR frame around the demo is on the most common interview questions page. Practise a two-minute project story and a five-minute code story. They are different lengths on purpose. The two-minute version is for the start of the interview. The five-minute version is for when they ask you to open the file.

How do you render nothing, a list, or a fallback?

A component can return null to render nothing, a fragment to return several nodes without an extra DOM element, or a conditional expression to choose between two trees. The loading state, the error state, and the empty state are three returns worth showing. Freshers often handle only the happy list. The interviewer who turns the API off wants the error branch. Write it. A fragment, the empty tag or Fragment, is how you group table cells or list items without a wrapper that would break the HTML. You do not need it everywhere. You need it when a wrapper would be invalid markup.

Conditional rendering with && has a trap. If the condition is the number 0, React will render 0. Use a real boolean when the value might be zero. This is the same falsy lesson as in JavaScript, and it is a good moment to show you connect the two.

What is client-side routing, at fresher depth?

A router picks a component from the URL without asking the server for a new document each time. A route for /orders shows the order list. A route for /orders/12 shows one order. The id comes from the URL, not from a global variable you hope is still set. If the user refreshes, the URL must be enough to rebuild the screen. That is the test of whether you used the router or a pile of boolean flags. Say which library you used, often React Router, and show one route. If your project was a single screen, say a second screen would be a route, not a second boolean called showDetails. Flags get tangled. URLs survive a refresh.

Links should use the router’s link, not a manual location hack, so the app does not reload the whole page. A form that navigates after a successful save can push the list route. Mention that if you built it. If you did not, do not describe a protected-route system with roles you never coded.

When would you mention memo, useMemo, or useCallback?

Only after you have a reason. These tools skip work when inputs are the same. They are not a default sprinkle for speed. useMemo caches a calculated value. useCallback caches a function so a child that depends on that function does not see a new one every render. memo skips a child render when its props are unchanged. The cost is complexity and the memory of the cache. A fresher project that lists fifty rows does not need them. Say that. If a parent passed a new inline function and a memoised child still re-rendered, you have a real story and you may mention useCallback. If you have no story, the stronger answer is: “I would measure a slow screen before I cache.”

The related mistake is creating an object prop inline, so memo never helps because the object is new every time. Pass stable values. This is another form of the “do not change the reference by accident” lesson from useState. Connecting them makes the round feel like one subject, which it is.

What is a small accessibility answer that still counts?

A button should be a button, not a div with a click handler, so the keyboard and the screen reader get the behaviour for free. An input needs a label. An image that carries meaning needs alt text. An image that is decoration can have empty alt. You do not need a full audit. You need one fix you made or would make. Panels that build product UI listen for this because it is a habit, not a library. If your project is a dashboard of divs that only work with a mouse, say you would replace the clickable div with a button first. That is a concrete next step.

A live-change drill before the React round

Open your project. Add a search box that filters the list you already render. Keep the filter in state. Do not mutate the original array. Give the rows a stable key. This drill is the change interviewers actually request, and doing it once the day before makes the live version calm. If the filter is case-sensitive, say so, and offer a lower-case comparison. If the list is empty after a filter, show a sentence instead of a blank page. Those two details take a few lines and they look like product sense.

Then refresh the browser on a detail route if you have one, and confirm the URL rebuilds the screen. If you have no router, do not add one an hour before the interview. Explain the single screen clearly. A new router with a broken refresh is a worse demo than a solid one-page app. After the drill, read the JavaScript page’s event-loop order once. React questions often start there when a fetch inside an effect misbehaves. You want the language answer ready before you talk about the dependency array.

A live-change drill before the React round

Open your project. Add a search box that filters the list you already render. Keep the filter in state. Do not mutate the original array. Give the rows a stable key. This drill is the change interviewers actually request, and doing it once the day before makes the live version calm. If the filter is case-sensitive, say so, and offer a lower-case comparison. If the list is empty after a filter, show a sentence instead of a blank page. Those two details take a few lines and they look like product sense.

Then refresh the browser on a detail route if you have one, and confirm the URL rebuilds the screen. If you have no router, do not add one an hour before the interview. Explain the single screen clearly. A new router with a broken refresh is a worse demo than a solid one-page app. After the drill, read the JavaScript page’s event-loop order once. React questions often start there when a fetch inside an effect misbehaves. You want the language answer ready before you talk about the dependency array.

If they ask you to lift state during the live change

Move the search string to the parent and pass the filtered list or the setter down. Say why you lifted it: a sibling needed the same string. If no sibling needs it, keep it local and say that too. Either decision is acceptable when the reason is real. What fails is a context provider added in the interview for a single input. Finish the filter, show the empty message, and stop. A finished small change is the demonstration. A half-migrated architecture is a broken demo. Repeat the key on the filtered rows, because a filter that drops items is exactly when index keys show the wrong input. Use the id. Then type one character and show the list shrink. That visible shrink is the end of the answer.

After the list shrinks, clear the box and show the full list return. That second click proves the state, not only the filter, is under your control.

Related reading: JavaScript interview questions, Spring Boot interview questions, Most common interview questions, Java interview questions.

These answers are a preparation guide for students and freshers, including learners at Asmorix in Pondicherry. A company may ask a different follow-up. This page is not a leaked paper and it is not a promise of a result. Say the short answer, show one example, and revise the same day any question you could not code or click.