HR & Behavioural React JS Interview Questions

Situation: in my final year I built a hostel complaint portal with React, Vite and a Node API. Task: the complaint list became slow and buggy when filters changed. Action: I found I was storing filtered data in state and syncing it with effects, so I derived it during render with useMemo and fixed missing keys. Result: bugs disappeared, the page felt instant, and I learned to keep state minimal.

I follow the official react.dev blog and docs, read release notes for React, Next.js and the libraries we use, and try new features in a small side project before using them at work. For example, when React 19 introduced Actions and useOptimistic, I rebuilt a form in my practice app first, noted pitfalls, and then shared a short demo with my team before we adopted it.

Situation: a teammate wanted one large Table component with over twenty boolean props. Task: we needed a design that both of us and future developers could maintain. Action: I built a quick prototype using composition with Table.Header and Table.Row, and we compared both on two real screens. Result: the team chose composition, prop count dropped sharply, and we agreed to prototype before arguing in future.

Situation: a new joiner was putting almost all logic into effects, causing bugs. Task: help them build the right mental model. Action: I explained that effects sync with outside systems, while calculations go in render and user actions go in handlers. We refactored one of their components together and I shared the react.dev article on avoiding effects. Result: their next PR had no unnecessary effects.

Situation: a teammate proposed adding Redux to a small admin app. Task: decide whether it was worth the added complexity. Action: I listed our actual shared state, which was just the user and a few filters, and showed a prototype using TanStack Query for API data and one small context. Result: we shipped faster with less code, and agreed to revisit if requirements grew.

Situation: two days before release, the product owner asked to add a GST number field with validation to our checkout form. Task: deliver it without risking the release. Action: I estimated the impact, proposed shipping the field with basic format validation first and the full verification API in the next sprint, and added tests. Result: we released on time and the follow-up shipped a week later.

I would keep it simple: a pure client-side React page sends an almost empty HTML file, so some crawlers and social previews see little content and users on slow phones see a blank screen longer. Server rendering sends ready HTML, improving SEO and first load. I would back this with a Lighthouse comparison and search console data, and suggest a framework like Next.js only for pages that need it.

Situation: customers reported that the address form sometimes submitted an empty PIN code. Task: find the root cause quickly. Action: I reproduced it with browser autofill, which changed the DOM value without firing our onChange in a custom input. I switched to a native controlled input, added a schema check before submit and wrote a regression test. Result: the issue stopped and support tickets dropped.

Situation: our admin dashboard took about eight seconds to become usable on office laptops. Task: bring it under three seconds. Action: I profiled it, found a 2 MB bundle and a chart library loaded on every page, lazy loaded routes and charts, replaced moment with dayjs and virtualised a large table. Result: load time dropped to around 2.5 seconds and support complaints about slowness stopped.

Situation: a festive sale banner feature had to go live in two days. Task: ship safely without gold-plating. Action: I listed must-haves with the product owner, wrote tests for the critical checkout path, kept a simple implementation and logged clear tech-debt tickets for refactoring. Result: we launched on time with no incidents, and I cleaned up the code in the next sprint as planned.

Situation: I removed what looked like an unused prop in a shared Button component. Task: after release, the payment page's disabled state broke. Action: I owned it immediately, rolled back, then fixed it and added a test plus a TypeScript type so the prop could not be removed silently. Result: the issue was live for under an hour, and I now search all usages and rely on types before deleting code.

Situation: our React app had almost no tests and regressions reached production every release. Task: improve quality without slowing delivery. Action: I set up Vitest, React Testing Library and MSW, wrote example tests for two key screens, ran a short session for the team and added a rule that bug fixes include a test. Result: within three months, critical flows were covered and regressions dropped noticeably.

Situation: my first big PR received over twenty review comments. Task: address them and learn, not feel defensive. Action: I thanked the reviewer, fixed clear issues, asked questions on ones I did not understand and explained my reasoning politely on two where I had context. Result: the PR merged after one more round, and I created a personal checklist that reduced comments on later PRs.

Situation: QA reported that a filter reset on page refresh. Task: resolve it without friction. Action: I reproduced it, checked the acceptance criteria with QA and the product owner, and found the requirement was unclear rather than either of us being wrong. Result: we agreed to store filters in the URL, I implemented it in a day, and we added clearer criteria to future stories.

Situation: our project needed to switch from Jest to Vitest with a week's notice. Task: migrate around 300 tests. Action: I read the official migration guide, migrated one folder first to discover patterns, wrote a codemod for jest.fn to vi.fn replacements and documented gotchas for the team. Result: we finished in four days, test runs became much faster, and the guide helped others with later work.

I enjoy building things people use directly, and React lets me turn designs into fast, interactive screens. During my training I built three projects with React, TypeScript and APIs, and I liked how components make code reusable. React also has strong demand across startups and service companies in India, a large community and paths into Next.js and React Native, so I see long-term growth in this role.

Situation: our app ran on an unmaintained Create React App setup with slow builds. Task: move to Vite without stopping feature work. Action: I wrote a migration plan, fixed incompatible imports and env variables in a branch, ran both builds in CI for a week, and trained the team on differences. Result: we switched over a weekend, local start time went from over a minute to a few seconds, and nothing broke for users.

Situation: the orders API returned deeply nested data and no pagination, making our list screen slow. Task: get a better contract without blocking either team. Action: I shared a proposed response shape with the backend developer, explained the performance impact with numbers and built against a mocked API using MSW meanwhile. Result: they added pagination and flatter fields, and we integrated in two days with no rework.

When an item is deleted, every later item shifts to a new index, so React matches old state and DOM nodes to the wrong items. Uncontrolled inputs and component state stay attached to the index, not the data. The fix is to use a stable unique id from the data as the key. Index keys are only safe for static lists that never reorder, filter or delete.

StrictMode is a development-only wrapper that helps find bugs. It renders components twice to catch impure rendering, and mounts, unmounts and remounts components to check that effects clean up properly. This is why a fetch in useEffect may appear to fire twice locally. It does not happen in production. The fix is to write proper cleanup, not to remove StrictMode.