⚛️ Top 150 React Interview Questions – 125/150 📌 Topic: Why is key={Math.random()} Bad? ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? Using Math.random() as a key generates a new identity on every render. React uses the key to track elements between renders. If the key keeps changing, React assumes: 👉 “This is a completely new component.” So instead of updating the element, React destroys it and creates a new one. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY is it bad? 🚨 Performance Degradation React cannot efficiently diff elements. It unmounts and remounts everything. 💥 Loss of Component State All local state (useState) is lost. Examples: • Input values reset • Scroll position disappears • Checkbox states vanish 🎯 UX Glitches • Cursor jumps out of input fields • Animations break • Focus disappears You basically break React’s reconciliation system. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW to fix it? ❌ BAD (Unstable Key) {items.map(item => ( <input key={Math.random()} /> ))} Key changes every render → React remounts everything. ✅ GOOD (Stable Key) {items.map(item => ( <input key={item.id} /> ))} Use a unique, stable identifier like: • Database ID • UUID (stored once) • Unique slug React can now track elements correctly. ⚠️ Rule: Keys must be: • Stable • Unique • Predictable Never generated during render. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE does this matter most? ⌨️ Input Fields Prevents cursor from jumping while typing. 📜 Large Lists Avoids re-rendering hundreds of elements unnecessarily. 🧠 Stateful Components Preserves internal useState data. 🎬 Animated Lists Prevents broken transitions. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY (Easy to Remember) Think of a Library Card 📚 If your library card number changed every time you entered the building, the librarian (React) would think you are a new person every visit. They would delete your old record and create a new one from scratch. Stable key = Stable identity. Random key = Identity crisis. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone preparing for React interviews #ReactJS #ReactKeys #FrontendDevelopment #Performance #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━
React Interview Question: Avoiding Math.random() as a Key
More Relevant Posts
-
⚛️ Top 150 React Interview Questions – 130/150 📌 Topic: Diffing Algorithm Logic ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? The Diffing Algorithm is a heuristic O(n) strategy used by React’s Reconciler. It compares: 👉 Previous Virtual DOM vs 👉 New Virtual DOM And calculates the minimum number of changes required in the real DOM. Instead of rebuilding the entire UI, React updates only what actually changed. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY is it important? ⚡ High Performance Avoids expensive O(n³) tree comparison algorithms. 🎯 Efficient Updates Only changed nodes are patched in the real DOM. 🧠 State Preservation Keeps internal component state intact if structure doesn't change. 💻 Smooth UI Minimizes browser reflows and repaints. Without diffing → React would re-render everything. With diffing → React updates intelligently. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW does it work? (3 Core Rules) ✅ Rule 1: Different Element Types → Replace Entire Node // Old <div><Counter /></div> // New <span><Counter /></span> React tears down <div> and mounts <span> from scratch. Different tag → Full replacement. ✅ Rule 2: Same Element Type → Update Attributes Only // Old <div className="before" /> // New <div className="after" /> React updates only: • className No full DOM replacement. Same tag → Patch attributes. ✅ Rule 3: Keys in Lists → Smart Reordering <ul> <li key="a">Apple</li> <li key="b">Banana</li> </ul> New item added at start: <ul> <li key="c">Cherry</li> <li key="a">Apple</li> <li key="b">Banana</li> </ul> With keys: • React moves a and b • Does NOT recreate everything Without keys → Entire list re-renders. Keys give React identity tracking. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE is this critical? 📜 Dynamic Lists Adding, removing, sorting items. 🔄 Conditional Rendering Deciding whether to update or remount. 🧮 Frequent State Updates Avoiding unnecessary DOM operations. 📊 Dashboards Updating small widgets efficiently. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY (Easy to Remember) The Diffing Algorithm is like a “Spot the Difference” game 🔍 Instead of throwing away the entire drawing and repainting it, React compares old vs new sketches and changes only what is different — like recoloring a hat instead of repainting the whole person. Efficient. Smart. Minimal. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone preparing for React interviews #ReactJS #Reconciliation #DiffingAlgorithm #FrontendDevelopment #Performance #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━
To view or add a comment, sign in
-
-
Your portfolio gets you the interview. But here’s what actually gets you hired: how you talk about the work. I’ve watched designers present beautiful portfolios and lose the role in 5 minutes. Why? They can’t explain their decisions. They say “I designed this” but can’t answer: Why this solution over the others? What constraint shaped this direction? What would you change if you did it again? How did you know it was working? The pattern I see: Designers who only show final work can’t talk about process. Because they haven’t practiced articulating their thinking. Designers who show options, pivots, and failures? They have the language ready. They can defend decisions. They can explain tradeoffs. They can show judgment. And in 2026, this matters more than ever: AI can generate polished screens. But it can’t explain why option A works better than option B for your specific constraint. If you can’t articulate your reasoning, you’re just executing. And execution is getting automated. Your portfolio isn’t just showing work. It’s teaching you how to talk about design. If you can’t explain why you made the choices you made, the work doesn’t matter. What to include: Not just the rejected ideas. The why behind them: “Option A looked better but required 3 clicks to checkout. Option B was plain but converted. We shipped B.” “Engineering said 2 weeks max, so we dropped the custom UI and used what iOS already had.” “Tabs looked clean but users never explored them, switched to a single page instead.” These sentences prove you think strategically. The portfolio is your script. Write one that shows you can navigate complexity. Because the designers who survive aren’t the ones with the prettiest portfolios. They’re the ones who can explain their thinking better than AI can generate alternatives.
To view or add a comment, sign in
-
Interview mistakes I made as a developer 👇: 🔷If the interviewer asked you to build something, It means... The interviewer expects your to usually: ▫️Clarify the requirements ▫️Wants you to identify the edge cases ▫️Discuss your approach 🔷When a task is assigned to it , don't just straight way jump into writing code. first spend some time explaining your system design ideas : 🔹how you are going to structure the UI, 🔹what will be the folder structure 🔹what all are the possible APIs that you will need this conversation will convey that you are thinking beyond ,than just solving the problem. 🔷In a machine coding round if you didn't understand the expected behaviour of the code . Ask the interviewer to give some sample input and output,to understand the question better. (It is not a weakness!) ❌Interviews are not just about writing correct code. ✅They are about how you think, communicate, and design solutions. Cheers, Naresh Ravi
To view or add a comment, sign in
-
🚀 React Interview Questions That Test Real Understanding (Not Just Syntax) Sharing some practical React questions that often come up in interviews 👇 🟢 1️⃣ Multiple Components & App is Slow — Why? When many components render, performance drops mainly because: Unnecessary re-renders Large component trees Expensive calculations inside render Unoptimized props/state updates ✅ Fix: Use React.memo Split components properly Use useMemo / useCallback Avoid inline object/array props Use virtualization for large lists Remember: React re-renders on state or prop change — even if UI looks the same. 🟢 2️⃣ Dependency Array Exists But Still Getting Multiple Re-renders? Common reasons: Parent re-rendering State update inside useEffect New object/function reference each render Strict Mode double invocation (dev only) Solution mindset: Stabilize references using useCallback / useMemo and check what actually changes. 🟢 3️⃣ What is Hydration? Hydration happens in SSR apps (like Next.js). Server sends HTML → React attaches event listeners on client → Makes static HTML interactive. If server HTML ≠ client render → hydration mismatch error. Common causes: Using window during SSR Random values (Math.random, Date.now) Conditional rendering differences 🟢 4️⃣ Strict Mode: Development vs Production In development: React intentionally double-invokes certain lifecycle logic Helps detect side effects useEffect runs twice (dev only) In production: Runs normally (no double invocation) Important: Strict Mode does NOT affect production behavior. 🟢 5️⃣ Same Custom Hook, Two Siblings — Different Behavior? Each component using a hook gets its own isolated state. Example: Two components use useCounter() Each has its own separate state instance. Hooks are not shared unless: You lift state up Use Context Use external store (Redux/Zustand) 🟢 6️⃣ What is Memoization in React? Memoization prevents expensive recalculations or re-renders. Tools: React.memo() → prevents component re-render if props same useMemo() → memoizes computed value useCallback() → memoizes function reference Goal: Avoid unnecessary work. 🟢 7️⃣ What is useMemo? Why Still Re-rendering Even If Nothing Changed? useMemo caches a computed value: const memoValue = useMemo(() => heavyCalculation(data), [data]); But important: 👉 useMemo does NOT stop component re-render. It only prevents recalculating the value. Component still re-renders if: Parent re-renders State changes Context updates To stop re-render: Use React.memo + stable props. 🔥 React interviews today focus on: Rendering lifecycle Performance optimization Reference equality Reconciliation understanding Real-world debugging skills If you're preparing for React interviews, go beyond “what is useState” — understand WHY React behaves the way it does. #ReactJS #FrontendDeveloper #JavaScript #WebDevelopment #TechInterview #ReactInterview #PerformanceOptimization #NextJS #SoftwareEngineering #DeveloperLife
To view or add a comment, sign in
-
You can pass React interviews even if you’ve never built a massive React application. Most interviews don’t test how big your project was. They test whether you actually understand how React works, even when the code is written with the help of AI. Here are the kinds of React questions that show up repeatedly in interviews. ➤ Common React Interview Questions 𝗕𝗔𝗦𝗜𝗖 𝗟𝗘𝗩𝗘𝗟 1. What problem does React solve compared to vanilla JS? 2. What is JSX and how is it transformed under the hood? 3. What is the difference between props and state? 4. What is the purpose of the key prop in lists? 5. How does event handling work in React? 6. What happens when state updates in a component? 7. How does conditional rendering work in React? 8. What are fragments and when would you use them? 9. What are controlled inputs in React forms? 10. What is lifting state up and why is it useful? 𝗠𝗢𝗗𝗘𝗥𝗔𝗧𝗘 𝗟𝗘𝗩𝗘𝗟 11. What happens during a React re-render? 12. What is the difference between useMemo and useCallback? 13. When should you use React.memo? 14. What problems does the Context API solve? 15. What is prop drilling and how can you avoid it? 16. What is the difference between client-side routing and traditional routing? 17. How do you structure state in a medium-sized React application? 18. What is code splitting and how does React.lazy work? 19. How do you debounce expensive operations like search inputs? 20. What is the difference between controlled and uncontrolled components? 𝗔𝗗𝗩𝗔𝗡𝗖𝗘𝗗 𝗟𝗘𝗩𝗘𝗟 21. How does React reconciliation work? 22. What is the diffing algorithm in React? 23. How do you prevent unnecessary re-renders in large apps? 24. What are Server Components and when would you use them? 25. How does streaming SSR work in modern React frameworks? 26. What are error boundaries and where should they be placed? 27. How would you structure authentication and protected routes? 28. How do you manage global state in large React applications? 29. How do you debug performance issues in React? 30. How would you design a scalable folder structure for a large React codebase? 𝗔𝗜-𝗥𝗘𝗟𝗔𝗧𝗘𝗗 𝗤𝗨𝗘𝗦𝗧𝗜𝗢𝗡𝗦 (𝗡𝗼𝘄 𝗦𝗵𝗼𝘄𝗶𝗻𝗴 𝗨𝗽 𝗶𝗻 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄𝘀) 31. How do you use AI tools during development without blindly trusting generated code? 32. How would you verify if AI-generated React code is correct or performant? 33. What parts of a React workflow can AI realistically speed up? 34. What risks come from relying too heavily on AI-generated code? 35. How would you debug code that was generated by an AI assistant? These questions show up again and again across frontend interviews. That’s exactly why I created the Frontend Interview Playbook, a structured guide that covers React fundamentals, machine coding patterns, frontend system design, performance engineering, and how to use AI properly during preparation. You can check it out here: https://lnkd.in/d8vBd3_j Use code FRONT10 for 10% off.
To view or add a comment, sign in
-
React.js Interview Prep Checklist – What You Should Actually Revise 🚀 If you're preparing for a Frontend React.js interview, don’t just revise hooks randomly. Structure your preparation across layers: fundamentals → rendering → performance → architecture. Here’s a practical checklist to guide you 👇 🔹 React Core Concepts • What is React and why do we use it? • What is the Virtual DOM and how does it differ from the Real DOM? • How does reconciliation (diffing) work internally? • Why are keys important in lists? • What happens if you use array index as a key? • Props vs State — what’s the real difference? • Functional vs Class components — trade-offs? If you can’t explain rendering clearly, you’re not interview-ready. 🔹 Lifecycle & Rendering Behavior • Mounting, Updating, Unmounting — what actually happens? • Lifecycle equivalents using hooks • When should you use useEffect? • How does cleanup in useEffect prevent memory leaks? Most bugs in React apps come from misunderstanding effects. 🔹 React Hooks Deep Dive • useState — batching & async updates • useEffect dependency array logic • useContext — when to use and when to avoid • useRef — persistence without re-render • useReducer — complex state management • useMemo vs useCallback — real performance use cases • useLayoutEffect — when timing matters • Custom hooks — extracting reusable logic Hooks are easy to use, hard to master. 🔹 Performance & Optimization • What causes unnecessary re-renders? • How does React.memo work? • Code splitting & lazy loading • Suspense basics • Bundle size reduction strategies • Tree shaking Senior interviews heavily focus on performance thinking. 🔹 State Management • Context API fundamentals • Context vs Redux — real-world trade-offs • When Redux makes sense • Reducers, actions, store structure Architectural clarity > tool knowledge. 🔹 Advanced Topics • Error Boundaries • Higher Order Components (HOCs) • Event bubbling & delegation • Controlled vs Uncontrolled components • Debouncing vs Throttling • Virtualization for large datasets • API caching strategies • Web Workers — when to move work off the main thread These topics differentiate mid-level from senior engineers. 🎯 Final Advice Don’t just memorize definitions. Understand: • Why React re-renders • How scheduling works • How data flows • How performance degrades • How to debug production issues That’s what interviewers truly evaluate. Learn deeply. Build intentionally. Explain clearly. 👉 Follow Rahul R Jain for more real interview insights, React fundamentals, and practical frontend engineering content. #ReactJS #FrontendEngineering #JavaScript #WebDevelopment #TechInterviews #PerformanceOptimization #SoftwareEngineering #ReactDeveloper
To view or add a comment, sign in
-
⚛️ Top 150 React Interview Questions – 149/150 📌 Topic: ⏳ Starvation in Concurrent Mode ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? Starvation happens when low-priority updates are continuously delayed because the main thread is busy handling high-priority updates. Example: • High Priority → Typing, clicking • Low Priority → Rendering a huge filtered list If urgent updates keep coming, background work keeps getting postponed. That delay is called Starvation. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY does it happen? ⚡ Priority-Based Scheduler (React 18) React assigns priority levels to tasks. User interactions → Highest priority Background rendering → Lower priority 🧠 CPU Congestion Heavy calculations + rapid input = background work feels “stuck”. 🎯 Responsiveness First React prefers keeping the UI interactive instead of finishing heavy tasks. Better a delayed list than a frozen input field. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW does React handle it? React’s Scheduler assigns expiration times to tasks. If a low-priority task waits too long → React upgrades its priority automatically. That prevents permanent starvation. ✅ Example using useTransition const [isPending, startTransition] = useTransition(); const handleChange = (e) => { // 🔥 High Priority: Instant input update setVal(e.target.value); // 💤 Low Priority: May be delayed startTransition(() => { const data = heavyCalculation(e.target.value); setList(data); }); }; Typing stays smooth. Heavy list rendering runs in the background. If user keeps typing → list update may be postponed. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE does this matter? 🔎 Instant Search Typing fast while filtering thousands of results. 📊 Complex Dashboards Multiple widgets updating simultaneously. 🎞 Smooth Animations (60fps) Ensuring animations aren’t blocked by data processing. Concurrent Mode protects user experience first. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY Starvation is like a Busy Emergency Room 🏥 Doctors (React) treat heart attacks (User Input) first. Minor cold patients (List Rendering) must wait. If emergencies keep coming, the cold patient waits longer. But hospital rules (Expiration Time) ensure everyone eventually gets treated. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone mastering React 18 concurrency #ReactJS #ConcurrentRendering #React18 #WebPerformance #FrontendArchitecture #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━
To view or add a comment, sign in
-
-
React Interview Preparation Guide If you have a React interview coming up, make sure you review these key topics: 1️⃣ React Hooks • useState • useEffect • useContext • useReducer • useMemo • useCallback • useRef 2️⃣ Higher Order Components (HOC) • What, When, Why, and How 3️⃣ Component Lifecycle • Class Components • Mounting, Updating, Unmounting 4️⃣ State Management • State vs Props • Props Drilling • Context API 5️⃣ Redux / Zustand • How Redux works • When and why to use it • Redux Toolkit (RTK) 6️⃣ Custom Hooks • When to use them • Reusability and clean code 7️⃣ Lazy Loading • Code Splitting • Chunking • Suspense 8️⃣ Virtual DOM • Reconciliation • React Fiber • Diff Algorithm • Rendering process 9️⃣ SSR vs CSR • Differences • SEO and performance benefits 🔟 Routing • React Router • Protected routes • Query params • Dynamic routing 1️⃣1️⃣ Testing • React Testing Library • Unit testing 💡 Tip: Always mention that your code is testable. 1️⃣2️⃣ Async Tasks • API calls • Promises • Events • setTimeout 1️⃣3️⃣ Coding Best Practices • Reusability • Readability • Modularity • Testability 1️⃣4️⃣ Performance Optimization • Lazy loading • Asset optimization • Bundlers • CDN usage 1️⃣5️⃣ Styling • Tailwind • Bootstrap • Material UI • CSS / SCSS 1️⃣6️⃣ Accessibility, Performance, Testability, Security Stay prepared and keep building! 💻
To view or add a comment, sign in
-
-
Frontend Interview Breakdown (Technical + Design + Behavioral) 🚀 Recently reviewed an interview process structured across three strong layers: core fundamentals, architectural depth, and leadership mindset. Here’s what a serious frontend interview can look like 👇 🟢 Round 1 – Technical Foundations This round checks if your basics are truly solid. 1️⃣ Explain the JavaScript event loop. How are microtasks and macrotasks scheduled? What runs first and why? 2️⃣ Build a custom React hook to debounce user input. Do you understand closures, timers, and cleanup? 3️⃣ Create a reusable dropdown component. Should support search + multi-select. How do you manage state? Accessibility? Keyboard navigation? 4️⃣ Optimize rendering for 10k+ rows. Do you know virtualization, memoization, and stable keys? 5️⃣ Controlled vs uncontrolled components. When would you use each in real-world forms? This round filters out candidates who only “use” React but don’t deeply understand it. 🟡 Round 2 – Advanced Technical / System Design Now the focus shifts to architecture and scale. 1️⃣ How would you structure a dashboard app with 100+ pages? Folder structure? State boundaries? Routing strategy? 2️⃣ Code splitting & lazy loading. How do they reduce bundle size and improve TTI? 3️⃣ Handling API rate limits gracefully. Retries? Backoff strategy? UI feedback? 4️⃣ Hydration in Next.js. Why do hydration mismatches happen? How do you prevent them? 5️⃣ Designing a shared component library. Versioning? Documentation? Storybook? Design tokens? 6️⃣ CSR vs SSR vs SSG. Trade-offs for SEO, performance, and scalability. 7️⃣ Architecture for 1M+ daily users. Caching, CDN, rendering strategy, monitoring, error boundaries. This is where architectural thinking matters more than syntax. 🔵 Round 3 – Managerial / Behavioral Strong engineers are also strong collaborators. 1️⃣ Tell me about a production bug that broke the UI. How did you debug, communicate, and fix it? 2️⃣ How do you balance technical debt with feature delivery? 3️⃣ Handling disagreements with designers or backend teams. 4️⃣ Explaining complex technical decisions to non-technical stakeholders. This round evaluates ownership, clarity, and maturity. 🎯 Reality Check Modern frontend interviews are not about memorizing hooks. They test: ✅ JavaScript execution model ✅ Rendering behavior ✅ Performance awareness ✅ Architectural decisions ✅ Communication skills If you prepare across all three layers, you stand out immediately. 👉 Follow Rahul R Jain for more real interview insights, React fundamentals, and practical frontend engineering content. #FrontendEngineering #ReactJS #NextJS #SystemDesign #WebPerformance #JavaScript #TechInterviews #SoftwareArchitecture #CareerGrowth
To view or add a comment, sign in
-
Question for the floor: What are your thoughts on interviews run by thrid-party specialists? I recently had an interview for a Senior Front-End Developer position with an IT firm whose general mandate was to take contracts to fix obscure bugs or performance issues within existing client apps. I got the email saying that they were interested and was able to schedule a technical interview within the same day, which has never happened to me before. I didn't know what to think or what to expect. The interview itself was... odd. The best way I can describe it is that it was the most "engineery" interview I've ever had. It was a paired programming exercise, and the interviewer started by sequentially presented a series of questions which tested my knowledge of very specific JavaScript interactions (e.g. determining the order things were output to the console, the difference between "throttle" and "debounce"). He then went on to ask questions pertaining to my understanding of the company's workflow, which I had no prior introduction to, mentioning a website report card and then REALLY hammering home metaphors about it. if at any point my thought process differed from his, he would interrupt me and course correct, to the point where eventually I had to interrupt him and remind him that the whole point of a technical interview is to understand how the candidate thinks and solves problems. After that point he apologized and allowed me to narrate my thoughts, but he clearly had stopped paying attention and was quietly refactoring the code I had written for prior responses while I spoke. I found the whole experience to be deeply unsettling, and it wasn't until the end of the interview that he admitted that he didn't even work for the company I was supposedly interviewing with. He asked if I had any questions, but given that he didn't have any insight about the company he wouldn't have been able to answer any about the work culture, onboarding expectations, or salary. I doubt I'll hear back, to be honest, but at this point I'm fairly confident that it would not be a good fit in either direction. Is this normal? Did I just get a bad draw? I've never heard of this happening before.
To view or add a comment, sign in
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development