React Developer Interview Questions for AI Training Work

I keep state local by default and only lift it when multiple components genuinely need to read or update it, rather than centralizing state preemptively. Over-centralizing state that's only relevant to one component makes the codebase harder to trace and adds unnecessary re-renders elsewhere.

I check what props or state are actually changing on each render using the React DevTools profiler rather than guessing, since unnecessary re-renders often come from a new object or function reference being created on every render rather than an actual meaningful data change. I look at memoization only after confirming the re-render is genuinely a problem worth fixing.

I use an effect with a dependency array scoped precisely to the values that should trigger the effect, being careful not to omit a dependency that would cause stale data or include one that would cause unnecessary refetches. I also make sure to handle cleanup, like canceling an in-flight request, if the component unmounts or the dependency changes again before the effect finishes.

I'd point to closures and how they interact with asynchronous code, since a lot of subtle React bugs, like stale state in a callback, come from a closure capturing a value that's since changed. Understanding how the event loop and asynchronous execution actually work also helps explain why certain state updates don't behave the way someone might expect at first glance.

I break components down by responsibility rather than by size alone, keeping presentational components separate from ones managing significant logic or state, so each piece stays easier to reason about and test independently. I also avoid prop drilling through many layers by using context or a state management tool once the drilling gets deep enough to hurt readability.

I'd check for differences between environments first, like environment variables, build optimizations, or data that behaves differently in production, since a production-only error often stems from an assumption that held in development but not in the real environment. I'd use error monitoring to get the actual stack trace and reproduce the specific conditions rather than guessing.

I'd assess whether I can add the feature cleanly within the existing structure or whether the existing state management is tangled enough that it's worth refactoring first, rather than adding more complexity onto an already fragile foundation without addressing the underlying issue. If a full refactor isn't in scope, I'd at least isolate the new logic as cleanly as possible to avoid making the tangle worse.

I'd map each lifecycle method to its hook equivalent carefully, since methods like componentDidMount and componentDidUpdate can both map to a single effect but with different dependency behavior, and getting that mapping wrong is a common source of subtle bugs during migration. I'd migrate and test incrementally rather than rewriting the whole component at once.

A list component was re-rendering every item whenever any single item's state changed, which caused visible lag on longer lists. I identified that the parent was passing a new inline function to each child on every render, which broke memoization, and fixing the reference stability resolved the unnecessary re-renders without needing a broader architectural change.

A bug caused by tangled state updates across multiple components could have been patched with a quick workaround, but I recognized the underlying structure would keep causing similar bugs. Given the timeline, I applied the quick fix to resolve the immediate issue but flagged the structural problem clearly and scheduled the refactor as a separate, prioritized piece of work rather than letting it get silently deprioritized.