UI unresponsive during large data processing on main thread

WHAT THIS TESTS: Whether you understand that React Native maintains two distinct threads: the JavaScript thread where your business logic runs and the native UI main thread where drawing and native animations occur. The interviewer cares if you know that these threads communicate asynchronously, that updates to native-backed views are batched and sent over at the end of each event loop iteration, and that both sides must meet a 16.67ms deadline to maintain 60 frames per second.

A GOOD ANSWER COVERS: First, clarify thread responsibilities. The JavaScript thread is where state changes, API responses, and touch events are processed. The native main UI thread handles actual rendering, native stack navigator transitions, and ScrollView scrolling. Second, explain the frame budget. At 60fps you have at most 16.67ms to generate each frame. If a large data processing task consumes 200ms on the JavaScript thread, you drop roughly 12 frames. Third, describe the symptom chain. While the JavaScript thread is locked, batched view updates cannot be sent to the native side, and touch events dispatched from the main thread pile up unprocessed, so components like TouchableOpacity cannot command native view changes and the UI feels frozen. Fourth, outline the refactor. Break the synchronous data workload into smaller chunks that execute across multiple event loop iterations. This yields control back to the runtime so batched native updates can go out before each frame deadline. Fifth, mention release build verification and removal of console.log statements, since the reference identifies both as common sources of JavaScript thread slowdowns.

COMMON WRONG ANSWERS: Confusing the JavaScript thread with the native UI main thread and claiming the main thread is running your JavaScript data processing. Suggesting useMemo, useCallback, or React.memo as the primary fix without first addressing the root problem of a long-running computation monopolizing the thread. Proposing to move work to a web worker or background thread without acknowledging that standard React Native JavaScript is single-threaded and the solution must yield the event loop or use native modules. Ignoring the 16.67ms frame deadline entirely.

LIKELY FOLLOW-UPS: How would you profile whether the bottleneck is on the JavaScript thread or the native UI thread? What is the difference between a JS frame drop and a UI frame drop, and which one affects ScrollView scrolling? How does the New Architecture affect communication between these threads? When is it appropriate to move heavy computation into a native module instead of chunking it in JavaScript?

ONE CONCRETE EXAMPLE: Imagine a screen that receives ten thousand records and immediately runs a complex synchronous mapping function to transform them before calling setState. This blocks the JavaScript thread for two hundred milliseconds, causing twelve dropped frames. During that time the user touches a button, but the touch event cannot be processed because the thread is busy, so the opacity feedback never fires. To refactor, split the array into chunks of a few hundred records and process each chunk in a separate event loop turn, allowing the bridge to flush batched native updates and process touch events between chunks. Test the result in a release build with all logging removed to get an accurate measurement.