React Interview Questions: Starvation in Concurrent Mode

🚀 iOS Interview Question 💡 What is the difference between Serial Queue and Concurrent Queue in GCD? 👉 Most developers say: “Serial = one task, Concurrent = multiple tasks” 👉 But that’s not enough for senior interviews. ⚙️ Core Concept In Grand Central Dispatch, queues decide how tasks execute, not just where. ✅ Serial Queue • Executes one task at a time • Maintains strict order (FIFO) • Next task starts only after previous finishes let queue = DispatchQueue(label: "serial.queue") queue.async { print("Task 1") } queue.async { print("Task 2") } ✔️ Predictable execution ✔️ Safe from race conditions ⚡ Concurrent Queue • Executes multiple tasks simultaneously • Order is NOT guaranteed • Optimized for performance let queue = DispatchQueue.global() queue.async { print("Task A") } queue.async { print("Task B") } ✔️ Faster execution ⚠️ Needs careful handling of shared data 🚨 Real Interview Trap 👉 Many miss this: queue.sync { print("Task 1") } queue.sync { print("Task 2") } ❗ Even on a concurrent queue, this runs serially 👉 Because sync blocks the thread 🔥 Key Understanding • Serial vs Concurrent → defines execution style • sync vs async → defines blocking behavior 👉 These are independent concepts (very important 🔥) 🧠 Senior-Level Insight ✔️ Use Serial Queue → data safety, sequencing ✔️ Use Concurrent Queue → performance ✔️ Use barrier for thread-safe writes in concurrent queues

⚛️ Top 150 React Interview Questions – 146/150 📌 Topic: 🧹 Cleanup Function Importance ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHAT is it? The Cleanup Function is the function returned inside useEffect. It runs: • Right before a component unmounts • Before the effect re-runs (when dependencies change) Its job is to undo side effects created by the effect. Think of it as a reset mechanism. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHY is it critical? 🧠 Prevents Memory Leaks Stops timers, subscriptions, or listeners from running after unmount. ⚠️ Avoids Illegal State Updates Prevents “Cannot update state on an unmounted component” errors. 🔒 System Integrity Releases global resources like WebSockets and browser listeners. Without cleanup → background chaos. With cleanup → controlled environment. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 HOW does it work? React automatically executes the returned function. ✅ WebSocket Cleanup useEffect(() => { const socket = connect(id); // CLEANUP return () => socket.disconnect(); }, [id]); When id changes or component unmounts → connection closes. ✅ Abort API Request useEffect(() => { const controller = new AbortController(); fetch(url, { signal: controller.signal }); return () => controller.abort(); // Cancel request }, [url]); Prevents updating state after navigation. ━━━━━━━━━━━━━━━━━━━━━━ 🔹 WHERE is cleanup mandatory? 🔌 Subscriptions WebSocket, Firebase, Chat APIs. 🌍 Browser APIs window.addEventListener (scroll, resize). ⏱ Timers clearTimeout / clearInterval. 📡 Async Requests AbortController for pending fetch calls. Any persistent side effect → requires cleanup. ━━━━━━━━━━━━━━━━━━━━━━ 📝 SUMMARY The Cleanup Function is like Checking Out of a Hotel Room 🏨 Before leaving (Unmount), you must turn off lights and close taps. If you don’t, the hotel (Browser) keeps wasting resources. Cleanup ensures nothing is left running after you leave. ━━━━━━━━━━━━━━━━━━━━━━ 👇 Comment “React” if this series is helping you 🔁 Share with someone mastering useEffect #ReactJS #useEffect #MemoryLeaks #FrontendBestPractices #WebPerformance #Top150ReactQuestions #LearningInPublic #Developers ━━━━━━━━━━━━━━━━━━━━━━

This is the third article in my series on iOS interview preparation, where I break down topics that come up regularly and try to explain them in a way that reflects how they work in real applications. This time I focused on the app launch process, specifically what happens between tapping the icon and seeing the first screen. It is one of those topics that sounds simple until you start unpacking it. A typical explanation begins with the difference between cold start, warm start, and resume. In a cold or warm start, the system creates a new process. In a resume, the process already exists and the app returns to the foreground without going through the full launch path. From there, the system initializes the process and hands control to the dynamic linker. This is where the executable and its dependencies are loaded into memory. A significant portion of launch time is spent before any application code runs, which makes pre-main behavior an important part of performance discussions. After pre-main completes, execution reaches main, which calls UIApplicationMain. UIKit creates the UIApplication instance and the AppDelegate, then begins delivering lifecycle events. At this stage, the application starts participating in its own launch. In modern apps that use scenes, UI setup moves into the scene lifecycle. The system connects a scene, creates a window, assigns a root view controller, and prepares the view hierarchy. Once layout and rendering complete, the first frame appears on screen. From a performance perspective, it helps to think in terms of phases. Pre-main work includes dyld and runtime initialization. Post-main work includes delegate callbacks, scene setup, and UI rendering. Understanding where time is spent makes optimization decisions much more straightforward. I go into more detail in the article, including how launch time is affected by dependencies, static initialization, and early UI work. Link in the comments.

Most engineering managers don't know how to run a system design interview. At Meta, I learned the real interview starts after the candidate finishes their initial design. Here's how it works: Let's say a candidate designs a URL shortener. Cool. Now ask: "Walk me through the last incident that happened with a system like this." The best candidates have stories ready. "Our cache size was too small. We cached too many things. Under high load, the cache itself went down. Everything collapsed after." Some candidates haven't seen it yet, but they can reason through it. "I can imagine the cache becoming a bottleneck if we're not careful about what we cache." Others freeze - likely because they've never really operated systems under stress. Then make them redesign. "Okay. Knowing what you learned from that cache incident, how would you design this Reddit list view differently?" You should be paying attention to things like: - Can they transfer lessons across domains? - Do they think about failure modes upfront? - Can they make explicit trade-offs? The goal is testing if they can think critically when a good design breaks. Stop asking interview questions that get people to regurgitate what they memorized. Ask them about real production issues they've dealt with. You need people who can figure things out, not just recite textbook answers.

🚀 React Interview: How I would answer this question step-by-step Question: 👉 “How would you optimize a slow React application?” Most developers jump straight to answers. But here’s how I approach it 👇 --- 🌲 Step 1: Understand the problem Is it slow on initial load or during interactions? --- 🌲 Step 2: Identify bottlenecks Use React DevTools Profiler to find unnecessary re-renders --- 🌲 Step 3: Fix re-render issues Use React.memo, useMemo, useCallback where needed --- 🌲 Step 4: Optimize rendering Apply code splitting and lazy loading --- 🌲 Step 5: Handle large data Use virtualization (react-window / react-virtualized) --- 🌲 Step 6: Optimize API calls Debounce, throttle, and cache responses --- 🌲 Step 7: Check bundle size Remove unused libraries, use tree-shaking --- 💡 Most candidates fail because they don’t structure their answers like this. 👉 Interviews are not just about knowledge, but clear thinking Curious to know 👇 👉 How would YOU approach this question? If you're preparing for Frontend / React interviews, I also help with: ✅ Mock Interviews ✅ Resume Review ✅ Interview Preparation Strategy ✅ Real-world React concepts Book a session here 👇 🚀 Topmate: https://lnkd.in/d9EuJiwV

80% of developers fail the first 60 seconds of an interview. Not because they lack skills. Because they sound exactly the same. “I’m a Senior Developer with 7+ years of React and TypeScript.” I’ve reviewed hundreds of interviews this year. That sentence is everywhere. And it kills momentum instantly. The interviewer already read your resume. They are not asking for your tech stack. They are asking one thing: “Is this person worth listening to?” Here’s the pattern that actually works. Strong candidates don’t describe themselves. They describe impact. Instead of listing tools, they say: “I rebuilt a checkout flow that dropped load time from 3.2s to 900ms and increased revenue by 12%.” Now the interviewer is leaning forward. Here is what I find interesting. When you give one specific story with one number, the entire interview changes. The next 3–4 questions are no longer random. They are about your strongest work. You stop being evaluated. You start leading the conversation. This is the real shift. In 2026, with 600 applicants per role, nobody wins by being complete. You win by being memorable. Most developers try to say everything. The best ones choose one thing and say it well. That decision alone separates callbacks from rejections. Repost if you’ve ever heard “tell me about yourself” and realized halfway through you already lost the room.

You are in a system design interview at Meta for an IC4 role. The interviewer leans in and asks: "If a photo is already on my phone, how can WhatsApp still delete it when the sender taps Delete for Everyone?" Here is how you should break it down 👇 A lot of people think “Delete for Everyone” means WhatsApp somehow reaches into your gallery and erases a file from your device. That is not really what is happening. Btw, if you’re preparing for system design/coding interviews, check out my free mock interview tool on Layrs. You can use it for free here: https://lnkd.in/gpCn7t2T The real answer depends on where the photo is stored, how the chat app references it, and what exactly the app is allowed to delete. 1. First clarify the product behavior Before jumping into architecture, say this clearly in the interview: There are two different cases here. a) The photo exists only inside the chat app’s managed storage b) The photo has already been saved to the user’s gallery / camera roll / filesystem This distinction is everything. If the photo is only inside WhatsApp’s controlled storage, the app can remove the local file and remove the message reference from the chat UI. If the photo was exported or auto-saved to the gallery, WhatsApp usually cannot reliably delete that copy, because that file is now outside the app’s normal ownership boundary. So “Delete for Everyone” is mostly about: - deleting the message record - deleting the media attachment reference - deleting any app-managed cached copy - syncing that deletion event to all participants It is not magic remote file deletion across the whole phone.  2. High-level idea The clean way to think about this is: A chat message is metadata plus optional media. For a photo message, the system usually has: - message_id - chat_id - sender_id - media_id - timestamp - status - optional encryption metadata And the actual photo itself may live in: - encrypted object storage on server for temporary delivery - app sandbox / local database / media cache on device - optionally the user’s gallery if exported When sender taps Delete for Everyone, the system does not chase every byte everywhere. It sends a deletion command tied to the message_id.  3. What happens when the photo is first sent Here is the send flow: 1. User picks a photo 2. App encrypts media and prepares message metadata 3. App uploads encrypted media blob or sends it through media pipeline 4. App sends message metadata referencing that media 5. Receiver downloads the encrypted media 6. Receiver stores it locally in app-managed storage 7. Chat UI shows the message by resolving message_id -> media_id -> local file Read rest of the post: https://lnkd.in/gpv-wGze

75% of employers use behavioral interviews to predict your future success. But most senior engineers fail because they overcomplicate their answers. Save this post for your next behavioral interview. Check the attached whiteboard breakdown to see exactly how the 4-step process works. Here is how to apply those rules in a real interview setting. The why • My e-commerce team saw a sudden drop in checkout conversions. • Rates fell from 65% to 48% in one week. • We found the payment page load time had jumped from 1 second to 4 seconds. • Users were frustrated and abandoning their carts.    The what and how • I checked our frontend metrics using New Relic and DevTools. • I found a new third-party analytics library blocking the page render. • I proposed a fix to defer the script using lazy loading. • I collaborated with QA and Legal to ensure we stayed compliant. • I rolled the fix out slowly using a feature flag to monitor errors.    The impact • Page load times dropped back down to 1.2 seconds. • Our conversion rate recovered to 66% within three days.    Notice the pattern? Zero complex frameworks. Just a clear business problem, my specific actions, and hard numbers. If you are preparing for mid-senior/staff SDE, EM behavioural interviews, and need help, DM me COACH.

The "Performance First" Interview Framework 🚀 Headline: Stop guessing. Start Measuring. 📉 When an interviewer asks: "How do you optimize a slow React app?" The worst answer is: "I use useMemo, React.memo, and Lazy Loading." Why? Because you’re prescribing medicine before diagnosing the disease. Here is the 5-Step Framework I use to handle performance questions (and real-world bottlenecks): 1️⃣ The Discovery (The "What") Don't touch the code yet. Observe the symptoms. Is it a Load-time issue (LCP/FCP)? Is it a Runtime issue (Laggy scrolling, slow inputs)? Use the Lighthouse or Web Vitals extension to identify the "Red" zones. 2️⃣ The Analysis (The "Where") Now, go deep. Open the Chrome DevTools Performance Tab. Record a trace while interacting with the "slow" part. Look for Long Tasks (anything >50ms). Check the Bottom-Up tab: Is it a heavy JS execution, a massive Re-render, or a Layout Shift? 3️⃣ The Baseline (The "Benchmark") Before you fix a single line, Take a Snapshot. * Record your current metrics (e.g., INP is 450ms). Without a benchmark, you can’t prove your optimization actually worked. You’re just "hoping" it’s faster. 4️⃣ The Execution (The "How") Apply the surgical fix. If it’s JS: Optimize loops or move heavy logic to a Web Worker. If it’s Rendering: Implement Virtualization (like react-window) or fix "Prop Drilling" causing deep tree updates. If it’s Assets: Compress images or implement a smarter CDN strategy. 5️⃣ The Validation (The "Proof") Run the benchmark again. Compare the "Before vs. After" report. Did the INP drop from 450ms to 80ms? That is your success story. The Pro-Tip for Interviews: Interviewers love numbers. Don't say "It got faster." Say: "By identifying a bottleneck in the main thread and implementing virtualization, I reduced the Interaction to Next Paint (INP) by 65%." Engineering is about data, not intuition. 🧠 What’s your favorite tool for hunting down performance bottlenecks? Let’s share tips below! 👇 #FrontendDevelopment #WebPerformance #ReactJS #CodingInterviews #SoftwareEngineering #WebArchitecture #TechTips

Hired someone with a stunning portfolio. Stakeholders in the interview: "Wow. This is incredible" 3 months later when the product needed strategic thinking and fast decisions with limited engineering capacity, they kept designing pixel-perfect flows for a team that had no time to build them. Wrong person for the moment. Portfolio was real but the context behind it wasn't transferable. Hired someone else – portfolio was modest. They worked on boring software for years so nothing to "wow" anyone in a room. – one of the best designers I met. What I learned is: portfolio reflects the _product_ Thinking reflects the _person_ Some exceptional designers spent years in products that didn't let them shine. There could be many reasons: - constrained by engineering capacity - legacy systems - limited roadmaps Their portfolio looks like the company failed them. Their thinking is extraordinary. One of the interview questions to help evaluate that: "Walk me through a decision where you had to work within constraints you couldn't control" Polished portfolio people describe what they built but exceptional thinkers describe how they navigated