React Interview Questions for Freshers

“React is a JavaScript library for building user interfaces out of components. With plain JavaScript, I have to find elements and change them by hand every time data changes, and in a bigger page that gets messy fast, because I have to remember every place that shows that data. In React I just describe what the screen should look like for the current state, and when the state changes React works out what to update in the DOM. The other big win is reuse. I write a card or a button component once, pass it different props and use it all over the app. It's worth saying it's mainly the view layer, so things like routing usually come from another library or a framework built on React.”

“JSX is a syntax that lets me write something that looks like HTML inside my JavaScript. The browser can't run it directly. The build tool, Babel or whatever Vite uses underneath, turns each tag into a normal JavaScript function call that creates a React element. Because it's really JavaScript, a few things change from HTML. I write className instead of class, because class is a keyword, and htmlFor instead of for. Event names are camelCase, like onClick, and they take a function, not a string. Every tag has to be closed, so an image is written with a self-closing slash. And inside curly braces I can put any JavaScript expression, like a variable or a map call, but not an if statement, so for conditions I use a ternary or &&.”

“A class component extends React.Component, has a render method that returns JSX, keeps state in this.state and changes it with this.setState. It uses lifecycle methods like componentDidMount for things that should happen after it appears on the page. A function component is just a function that takes props and returns JSX. Since hooks came in, functions can have state with useState and side effects with useEffect, so they can do almost everything a class can, with less code and no worrying about this. In a new project I'd write function components. I still learned to read classes, though, because a lot of existing code at companies uses them, and an error boundary still has to be written as a class unless you use a small library.”

“Each JSX tag becomes a function call, and a component, like any function, can only return one value. Two elements side by side would be two values, so the compiler throws an error before it even runs. I could wrap them in a div, but that puts an extra element in the page, which can break a table, where a div inside a table row isn't allowed, or mess up a flex or grid layout. A Fragment fixes that. I write the empty tags, open angle bracket close angle bracket, around the two elements, and React groups them without adding anything to the DOM. If I'm returning fragments from a map, I need the long form, Fragment with a key, because the short empty tags can't take attributes.”

“For my own projects I use Vite. I run the create command, pick the React template, then npm install and npm run dev, and it starts a local server that reloads as I save. Older tutorials use Create React App, but the React docs no longer recommend it for new projects. Inside, index.html has one empty div with the id root. The entry file, main.jsx, finds that div with getElementById, creates a React root on it and renders my App component. From there everything is components under src, each usually in its own file. package.json lists the dependencies and the scripts like dev and build. When I run the build script, it produces a folder of plain HTML, CSS and JavaScript that I can put on any static host.”

“The usual cause is StrictMode. Project templates wrap the App in StrictMode in main.jsx, and in development it deliberately calls my component function twice, and runs every effect, then its cleanup, then the effect again, right after the component first appears. It's not a bug in my app, and it doesn't happen in the production build. The point is to catch mistakes early. If my component changes something outside itself while rendering, or an effect opens a connection and never closes it, running things twice makes that show up as a visible problem during development. So I wouldn't remove StrictMode to hide the double log. If an effect breaks when it runs twice, I'd fix it by adding a proper cleanup.”

“A React app is usually a single-page app, so there's one HTML page and a router decides which component to show for the current URL. I'd use React Router. I wrap the app in a BrowserRouter, then list Routes, each with a path and the element to show. For products I use a dynamic path, slash products slash colon id, and inside the product page I read the id with the useParams hook and fetch that product. For navigation I use the Link component instead of a normal anchor tag. A plain anchor makes the browser request a whole new page, so the app reloads, everything in state is lost and all the JavaScript loads again. Link just changes the URL and lets the router swap the component, so it feels instant.”

“In JavaScript, && doesn't return true or false. It returns the left side if the left side is falsy, and the right side otherwise. When the cart is empty, cartCount is 0, which is falsy, so the whole expression gives back 0. React skips false, null and undefined, but it happily renders a number, so a 0 shows up on the page. The fix is to make sure the left side is a real boolean. I'd write cartCount greater than 0 && the badge, or use a ternary that returns null when there's nothing to show. I've seen the same thing happen with an array's length, so now I always compare explicitly instead of trusting a number to act like false.”

“I'd take the students array as a prop and filter it first, keeping those with marks of 40 or more. I don't store that filtered list in state, because I can work it out from the prop on every render and it's always in sync. Then I check the length. If it's zero, I return a paragraph saying No results, so the user isn't left looking at an empty box. Otherwise I map each student to a list item, showing the name and marks, and give each one the student's id as the key, since ids don't change when the list changes. The whole thing is a few lines, and it's easy to change the pass mark to a prop later if needed.”

“Typing updates state in Page, so Page renders again. Because SearchInput is declared inside Page's body, a brand new SearchInput function is created on every render. React decides whether to keep a component by comparing its type with last time, and a new function is a different type, even if the code is identical. So React removes the old SearchInput, with its input element, and mounts a new one. Any state inside it is reset and the input you were typing in is gone, which is why focus drops after each letter. The fix is to move SearchInput out to the top level of the file and pass it the value and the change handler as props. Then it's the same type every render and React just updates it.”

“onClick needs a function that React will call later, when the button is clicked. With the parentheses there, I'm not passing a function, I'm calling setCount right now, during rendering. Setting state asks React to render again, and that render calls setCount again, so it loops until React stops it with the too many re-renders error. The fix is to wrap it in an arrow function, so onClick gets a function and the setter only runs on a click. The same idea applies when a handler needs an argument, like deleting a specific item. I write an arrow function that calls removeItem with the item's id. If a handler needs no arguments, I can just pass its name, handleClick, without the parentheses.”

“Props only go down, so a child can't reach up and change its parent's state. Instead, the parent passes the child a function as a prop, usually named with on in front, like onSelect. When the user clicks an item, the child calls onSelect and passes the item. The function was written in the parent, so it can call the parent's own state setter. The parent updates its state, renders again, and passes the new selected item back down as a prop. I like this because the child stays simple and reusable. It doesn't know what the parent does with the click. One page might open a detail panel with it, another might add it to a cart, and the list component doesn't change at all.”

“Anything I put between a component's opening and closing tags is passed to it as a special prop called children. So in Card I destructure title and children from props, draw a div with the card class for the border, show the title in a heading, and then render children below it. That content could be a paragraph, a form, even another component, and Card doesn't need to know which. For the title, I'd give a default right in the destructuring, say Details, so the card still looks right if someone forgets to pass one. This is how most layout pieces in a real app work, like modals, panels and page sections: the wrapper owns the look and the page fills in what goes inside.”

“I'd keep the count in state starting at zero. For plus and minus I use the updater form of the setter, passing a function that gets the current count, so every change starts from the latest value. For minus, I return the larger of zero and count minus one, so it can never go negative even if someone clicks fast. Reset just sets it back to zero. I'd also disable the minus button when the count is already zero, because that tells the user why nothing happens, rather than a button that silently does nothing. If they wanted a maximum as well, I'd take the min and max as props so the same counter works for things like a quantity picker in a cart.”

“State in React works like a snapshot. When the component renders, name is just a constant for that render. Calling setName doesn't change that constant. It tells React to render the component again, and in that next render useState will hand back Maya. My click handler is still running inside the old render, so on the next line name is still the old value. That's expected, not a bug. If I need the new value right away, say to send it to an API in the same handler, I put it in a local variable first, pass that to the setter and use the same variable for the API call. If I just want to see it change, I log it in the component body or check it in the React dev tools.”

“I don't change the object in state directly. I make a new object by spreading the old one and then overwrite the one field. The setter replaces the whole value, so if I passed only the email, name and city would disappear. So the new object has to carry the other fields along. To avoid three nearly identical handlers, I give each input a name attribute that matches the key, like email. In one handleChange I read the name and value from the event and use square brackets to set that key. I use the updater form so it always starts from the latest form. One thing to watch: spread only copies one level, so if the form had a nested address object, I'd spread that too.”

“fullName isn't new information. It's just firstName and lastName joined with a space. Keeping it as its own state means every handler has to remember to update it, and the first time someone forgets, say in a new reset button, the screen shows a full name that doesn't match the two fields. It's also extra code for nothing. I'd delete that state and work it out in the component body: a normal constant that joins the two names. It's recalculated on every render, which costs almost nothing, and it can never be out of date. The rule I follow is that state should hold only what I can't work out from other state or props. Filtered lists, totals and counts can usually be worked out the same way.”

“I keep two pieces of state: the tasks array, where each task has an id, the text and a done flag, and the text in the input. Adding happens in the form's submit handler. I call preventDefault so the page doesn't reload, skip empty text, then set the array to a new one: the old tasks spread in, plus a new task with a unique id, and clear the input. For toggling, I map over the tasks and, for the matching id, return a copy with done flipped; every other task comes back unchanged. Deleting is a filter that keeps everything except that id. I never push into or edit the existing array, because React only notices a new array. The id also serves as the key, so ticking and deleting never mix up rows.”

“I put the handler on the form's onSubmit, not on the button's click, so pressing Enter in a field also submits. The first thing the handler does is call preventDefault, because a normal HTML form reloads the page and I'd lose everything. The email and password are kept in state and bound to the inputs. Then I check the fields: if the email has no at sign I set an error message, if the password is shorter than eight characters I set a different one, and I stop there. If both pass, I clear the error and call the login function. The error shows in a paragraph with role alert, so screen readers announce it. And I'd mention that these checks are only for a nicer experience; the server has to check everything again.”

“I keep three pieces of state: users starting as an empty array, loading starting as true, and error starting as null. In a useEffect with an empty dependency array, I define an async function and call it, because the effect function itself can't be async. Inside, I await fetch, and then I check res.ok. That's the part people miss: fetch only rejects on a network failure, so a 404 or a 500 comes back as a normal response and I have to throw an error myself. If that passes, I parse the JSON into users. A catch stores the error message, and finally sets loading to false either way. In the JSX I return Loading while loading, the error if there is one, and otherwise the list.”

“The API working isn't enough, because the component renders once before the fetch finishes. On that first render the state is still whatever I gave useState at the start. If I wrote useState with nothing in it, the value is undefined, and calling map on undefined crashes. The fix is to start with an empty array, so the first render just maps over nothing, or to show a loading message until the data arrives. The second thing I'd check is the shape of the response. Often the API returns an object with the list inside it, like a data or items key, and I've stored the whole object and then tried to map over that. Logging the parsed response once, or looking in the Network tab, shows it straight away.”

“In my final year, three of us built a room-booking app for our college labs, and I did most of the React side. I split it into a page for each lab, a WeekGrid showing the time slots, a Slot component for each cell and a BookingForm in a modal. At first I kept the bookings inside each Slot, which went wrong fast, because booking one slot didn't update the others or the counts at the top. So I moved the bookings up to the lab page and passed each Slot its data and an onBook function. That was the moment lifting state really made sense to me. Looking back, I'd add loading and error messages from day one, because on the demo day the college Wi-Fi was slow and the page just looked empty.”

“For our semester project, a small events site, there were four of us. We split it by page, so I owned the event list and the event detail page, and one friend owned the sign-up flow. What saved us was agreeing early on a few shared pieces: one Button and one Card component in a common folder, and the shape of an event object, so we weren't guessing at prop names. Each of us worked on a branch and opened a pull request that someone else had to look at before merging. We still had one bad moment when two of us changed the shared Card at the same time and broke each other's pages. After that we agreed that changes to shared components needed a quick message in our group chat first.”

“First I'd get the app running on my machine and open the page in the browser, so I know exactly what I'm changing. To find the code, I'd search the project for a heading or label that's visible on that page, or use the React dev tools to click on the area and see the component's name. Before writing anything, I'd look for a button the codebase already uses and any similar feature, like an existing download, and follow the same patterns, so my change looks like the rest of the code. I'd give myself a fixed amount of time to work things out, and if I'm stuck I'd ask my mentor a specific question, like where the page's data comes from, not a vague 'how does this work'. Then I'd keep the first pull request small.”