Posts

Showing posts with the label Interview

Balancing Speed vs Quality

  🧠 Mindset: The Engineering Tightrope Speed and quality are not strict opposites — they exist on a continuum . Too much focus on speed → you risk technical debt, instability, burnout . Too much focus on quality → you risk slow delivery, missed opportunities, analysis paralysis . A senior engineer’s or tech lead’s job is to continuously rebalance the two — not to “pick one.” “Move fast, but don’t break things that matter.” ⚡ Speed: MVP (Minimum Viable Product) and Early Validation Purpose: Validate assumptions fast. Get feedback loops early from real users. Reduce the risk of building the wrong thing. Practices: Lean MVPs: build the smallest version that proves a concept. Rapid prototyping: disposable code is okay if it accelerates learning. Iterative releases: short cycles, small scope, frequent deploys. Example: Build only the core feature → measure usage → iterate or discard. Use mock APIs or feature toggles to simulate d...

Understanding How async and await Work in .NET — Under the Hood

 Asynchronous programming in .NET has become almost second nature to developers — we sprinkle async and await everywhere to make our apps responsive. But what really happens when you mark a method as async and use await inside it? Let’s demystify how the compiler, runtime, and threads work together behind the scenes. ⚙️ The Promise of async and await At first glance, async and await seem magical. You write code like this: public async Task FetchDataAsync () { var data = await GetDataFromServerAsync(); Console.WriteLine(data); } It looks sequential — first we fetch data, then we print it — but it’s actually asynchronous and non-blocking . The question is: how does the compiler make that possible? 🧩 The Compiler Trick — State Machine Transformation When you mark a method with async , the C# compiler rewrites it into a state machine — a hidden class that controls what happens before and after each await . Think of each await as a “checkpoint.” When ...