DEV Community: Emily Woods

I Left $40,000 on the Table in My First Tech Offer. Here Is Exactly What I Do Now

Emily Woods — Fri, 29 May 2026 00:03:55 +0000

The fear of negotiating a job offer is costing you more than a year of savings. A specific, tested framework for the 48 hours after the offer call.

When my first real tech offer came in, I said yes within the hour. I was so relieved to have the job that the idea of asking for more money felt like tempting fate. That was a $40,000 mistake measured over the two year tenure, because every raise, bonus, and equity refresh I received for the next two years was calculated as a percentage of that initial number. The offer is not a gift. It is an opening bid. Companies expect negotiation and they build room for it into their budget before they call you. The candidates who do not negotiate are not being humble they are subsidizing the ones who do. What follows is the exact framework I now use every time I receive an offer, including what to say, when to say it, what to never say, and how to handle the specific tactics recruiters use to close you fast.

The $40,000 mistake I made at 23
When I moved to New York, I had been through 23 interviews over about 14 months before I got an offer I was genuinely excited about. It came from a fintech startup in Midtown. The recruiter called me on a Thursday afternoon and told me the base salary. It was more than I had ever made. It was more than my mother had ever made. My immediate reaction was gratitude, and I said yes before she finished the sentence.

That number anchored everything for the next 2 years. My annual raise was calculated against it. My bonus target was a percentage of it. When I eventually got a competing offer and used it to negotiate a higher salary at a new company, the gap between what I was making and what the market was paying became visible in a way that made me genuinely angry at myself for not understanding the structure of the game at the start.

I have since gone through 8 more formal offer negotiations. I have also coached a significant number of friends through theirs. The pattern is nearly identical across all of them: the candidates who negotiate get more money, the process takes two to five business days longer than the people who skip it, and nobody has ever had an offer rescinded because they negotiated professionally. The fear that stops people from doing this is almost entirely unfounded.

Why you are afraid to negotiate and why that fear is irrational
The primary emotion most people feel when an offer arrives is relief. If the search has been long and exhausting and in 2026, most searches are the offer feels like the finish line. Asking for more money after crossing the finish line feels ungrateful, risky, and possibly dangerous.

This framing is wrong on every level.

Companies do not make offers to candidates they intend to walk away from. By the time the recruiter calls you, the hiring manager has already decided they want you. The calibration committee has already scored you. Legal has already reviewed the terms. The recruiter has a budget range and they are instructed to open at or near the bottom of it. This is not cynical. It is just how compensation planning works. The budget exists. The room exists. The question is only whether you ask for it.

The other piece of this that most candidates miss: if you accept the first number without any pushback, you have provided the company with information. You have told them that you either did not know you could negotiate or did not feel confident enough to do it. Neither of those signals reflects especially well on your sense of your own market value, which matters in an industry where your compensation trajectory is often tightly linked to the perception of how much others want you.

Negotiating does not make you greedy. It makes you someone who understands the market. Those are different things.

The 48 hours after the call

**
When a recruiter calls with a verbal offer, the single most important thing you can do in that moment is say nothing about the number itself. You acknowledge the offer, you express genuine enthusiasm for the role, and you ask for time.

Something like: I am really excited about this and I want to give it the thought it deserves. Can you send over the written details and give me a few days to review everything?

Every recruiter will say yes to this. Every single one. If they push back or try to get you to commit on the call, that is a yellow flag about the company’s culture, not a reason to capitulate.

Once you have the written offer and a few days, do not spend that time agonizing. Spend it gathering two pieces of information: what the market rate for this role actually is at this level and location, and whether you have any competing offers or near-term competing processes you can reference.

For market rate: Levels.fyi for total compensation at larger tech companies, LinkedIn Salary, and Glassdoor for smaller companies. Get familiar not just with the base salary range but the full comp picture like base, equity, signing bonus, annual bonus target because that is what you will be negotiating across.

For competing leverage: this is the single most powerful variable in any negotiation, and it has nothing to do with your performance in the interview. If you have a competing offer, you have leverage. If you have active processes at other companies that could plausibly produce an offer in the next two to four weeks, you have softer leverage. If you have neither, you are negotiating on the basis of market data alone, which still works but requires a different approach.

The counter

When you come back with your counter, do it in writing over email rather than on a phone call. There are two reasons for this. First, it gives you time to construct your reasoning carefully rather than responding to real-time pressure. Second, it creates a paper trail that protects both sides.

The structure of the counter email should be short and contain four things: a restatement of your excitement about the role, a specific counter number or range, a one-sentence rationale, and a collaborative close.

The rationale does not need to be elaborate. Citing market rate data from Levels.fyi for comparable roles at this level, with my current comp and a competing process I have active, a base of X feels more appropriate. That is enough. You do not need to write a brief. You do not need to explain your expenses, your student loans, or the cost of living in your city. None of that is relevant to the company and including it weakens the counter by making it emotional rather than market-based.

The specific number you ask for matters. Ask for more than you expect to get, but not so far above the market rate that it signals you have not done your research. A reasonable counter is typically ten to fifteen percent above the initial offer for a base salary, or a request to move to the top of the disclosed range if the company gave you a range. For equity, the lever is usually the number of shares or units, not the vesting schedule, since vesting schedules are often standardized.

If the company comes back with less than your counter but more than the initial offer, you have successfully negotiated. Most processes end here. If they come back at the same initial number with a statement that it is firm, you have two options: accept with a request to revisit at your six-month review, or attempt one more lever.

The levers most people do not use
Base salary is the most visible number but often not the most negotiable one. There are several components of an offer that have more flexibility and less visibility than base pay.

Signing bonus
This is frequently the easiest lever because it is a one-time cost to the company rather than a recurring expense. If they cannot move the base, a signing bonus of ten to twenty thousand dollars is a reasonable ask, particularly if you are leaving unvested equity at your current employer.

Equity
At growth-stage and public tech companies, the equity component often has more room than the base. If they gave you a range on the equity grant, you can ask to be positioned at the top of the range. If they gave you a specific number, you can ask for a refresh schedule that front-loads the vesting rather than the standard cliff structure.

Start date
This costs the company very little and occasionally costs you a meaningful amount if you have unvested equity that will cliff before you leave. Asking for a start date four to six weeks out is normal and expected.

Title
At companies with defined leveling systems, a title one band up can have compounding effects on your compensation trajectory that dwarf the immediate raise. If you were told during the process that you were being evaluated for two levels and they came in at the lower one, it is appropriate to ask whether there is flexibility on the level based on your interview performance.

The competing offer play
If you have a competing offer, use it. This is not a negotiation tactic but an honest information about your market value, and companies expect you to share it.

The way to use it is specific: you name the company if you are comfortable doing so, you state the total comp package, and you say that you prefer this role and would like to make it work at a comparable level. You are not threatening to leave. You are just providing market data in the form that companies find most credible, which is a real offer from a real competitor.

A few things to know about this. Companies will sometimes call your bluff, particularly if the competing offer is from a company in a different tier or a meaningfully different role. Let’s say, If you are negotiating at a Staff Software Engineer level at Stripe and your competing offer is from a Series B startup with significant equity risk, a sophisticated recruiter will factor in that the risk profiles are different. Be honest about the comparison and let them respond.

What you should never do is fabricate a competing offer or exaggerate one. Recruiters talk to each other. Offers can be verified. The downside risk of getting caught fabricating is dramatically larger than any salary upside, and it can cost you the offer entirely.

The exploding offer

Occasionally, a recruiter will tell you that the offer expires in 24 or 48 hours. This is a pressure tactic, and it almost never reflects a real operational constraint. Companies do not lose their headcount approval because a candidate took four days to decide. What they lose is psychological control of the conversation.

If you receive a very short deadline, acknowledge it and ask for an extension with a specific reason. Something like: I want to make this decision carefully and I have a call with my family this weekend that I need to include in that process. Is it possible to extend to Monday? In almost every case, they will extend. If they do not, you have learned something meaningful about how the company operates that is worth weighing before you accept.

What does not work
Citing your personal financial situation does not work. Citing what you were making at your last job does not work unless it supports a higher ask. Negotiating emotionally expressing that you feel the offer is insulting or unfair almost never works and frequently damages the relationship before it starts.

Being aggressive about equity at a late-stage public company does not work the way it does at an early-stage private one. At a public company, the equity is essentially cash with a vesting delay. At an early-stage startup, it is a lottery ticket. Treat them differently in negotiation.

And the tactic that backfires most often: asking for time repeatedly without eventually committing. If you have asked for two extensions and still have not responded, you are signaling uncertainty about the role itself, which makes the company nervous. Negotiate quickly, negotiate clearly, and commit when the process has run its course.

The compounding effect
The reason I care so much about this is not the immediate dollar amount. It is the compounding effect on everything that comes after it.

Your first-year performance review will reference your current compensation when determining your raise band. Your promotion will often come with a percentage increase on top of your current base. When you eventually negotiate your next offer at a different company, you will be asked what you are currently making in jurisdictions where that is legal, and even where it is not, your sense of your own market value will be shaped by the number you accepted the last time.

The $40,000 I left on the table at 23 compounded into something closer to $90,000 over the following five years when you account for the raises and equity refreshes that were calculated against it. That is not hypothetical math. I can trace it across my own compensation history.

Negotiation is not optional if you want to build real financial traction in this industry. It is a core skill, and like most core skills, it gets significantly easier the second and third time you do it.

What I use to prepare
The market rate piece of this knowing what the role actually pays at the specific company and level is the most important input into any negotiation. The more precisely you know that number, the more confident your counter will be.

For company-specific compensation data, Levels.fyi is the most reliable source for larger tech companies. For smaller companies and startups, Glassdoor and Blind give you a rougher picture. Where I have found PracHub useful is in calibrating my sense of which level a company was actually interviewing me at versus which one they offered because the interview experience and the offer level do not always match, and understanding the discrepancy is often the starting point for a meaningful conversation about whether the leveling is right.

Knowing your level, knowing the market rate for that level, and knowing where the company typically lands relative to market on each comp component is the combination that turns a vague counter into a specific, well-reasoned one.

Final thoughts

The offer call is not the end of the interview. It is the beginning of a different kind of conversation. Every company you will ever negotiate with has already decided it wants you by the time that call happens. The budget exists. The range exists. The question is only whether you are going to be the person who asks for their share of it.

Say thank you, then ask for time. Do your research. Come back with a specific number and a one-sentence rationale. Repeat once if necessary. Then commit.

That is the whole system. It takes 2–5 business days. The median outcome, in my experience and across the people I have coached through it, is somewhere between eight and twenty thousand dollars more per year than the initial offer. Over a five-year tenure, that number is not trivial.

After failing 23 times, I am sharing How I Actually Prepare for a Tech Interview Every Single Time Now.

Emily Woods — Mon, 25 May 2026 20:47:33 +0000

Not the sanitized version you read on LinkedIn. The real system, I am sharing the exact schedule, the anxiety in between, the sequence I follow from zero to offer.

Most interview prep advice is written by people who either never failed or have conveniently forgotten what it felt like to fail badly. As I have shared multiple times in my previous blogs that I failed 23 times before I cracked the process. What I built out of those failures is not a list of resources. It is a repeatable system with specific phases, daily time budgets, decision rules for when to move on, and a clear protocol for the final 72 hours before a loop. It works for me and It has worked for a number of people I have coached through it. But none of it resembles the advice that gets posted to the top of engineering subreddits, because that advice is optimized for upvotes, not for outcomes.

Why most prep advice fails you before you even start
The internet is full of interview prep advice. There are curated lists of the 75 must-solve LeetCode problems. There are YouTube channels dedicated to mock system design sessions. There are courses promising to turn you into a senior engineer in eight weeks. If information alone were enough, nobody would be failing technical loops.

The problem is not access to information. The problem is that most people approach interview prep the same way they approach a research project: they accumulate knowledge passively and assume that understanding something conceptually is equivalent to being able to produce it under pressure. But it is not as the cognitive demand of a live technical interview is fundamentally different from the cognitive demand of reading a blog post about the same topic. In a live interview, you are generating instead of consuming like basically you are talking and typing at the same time. You have a stranger watching you work. You have a timer running in the background of your head even when there is no visible timer on the screen. None of your accumulated knowledge is useful unless you have trained your brain to access it reliably under those conditions.

The second failure mode is treating prep as a binary: either you are preparing or you are not. People tend to go from zero preparation to intense cramming the week before an interview, which is exactly backwards. The skills that matter in a technical interview are clean problem decomposition, fast pattern recognition, confident architectural narration and those things can not be absorbed in 4–5 days. They are built over months of low-intensity consistent practice, the same way you build cardiovascular fitness. A week of intense running before a 10K does not substitute for months of regular training. The week before an interview should be light review for you.

The third failure mode, and the one I see most often, is practicing in the wrong format. Solving LeetCode problems silently on your laptop is not interview practice. It is homework. An interview requires you to simultaneously think, communicate your thinking out loud, write code, field clarifying questions, handle follow-up constraints the interviewer introduces mid-problem, and maintain composure when your first approach hits a dead end. If you have never practiced all of those things at the same time, you will struggle to do them under pressure even if you technically know the material.

What follows is the actual system I use. It is organized into phases. Each phase has a specific goal, a recommended time allocation, and clear signals for when you have done enough and should move forward.

Phase 0: The Inventory (Day 1, before anything else)
Before I touch a single LeetCode problem or open a system design resource, I spend half a day doing a complete honest inventory of where I actually am.

I open a blank document and work through four categories.

Technical depth. I list every major topic area that appears in technical interviews: arrays and strings, linked lists, trees and graphs, dynamic programming, system design fundamentals, concurrency and parallelism, database design, distributed systems, API design, object-oriented design.

For each one, I write a single word: Strong, Shaky, or Blank. Strong means I could solve a medium-difficulty problem in this area right now without looking anything up and explain my solution clearly. Shaky means I have seen this material before and would recognize patterns but would struggle to produce clean working code under time pressure. Blank means I would need to start from the beginning. I am honest about this even when the honest answer is embarrassing, because a false inventory leads to wasted prep time.

Behavioral story bank. I list every major project I have worked on in the past four years and for each one I write down: the specific technical challenge I personally owned, the specific decision I made and why, the measurable outcome, and any cross-functional conflict or ambiguity I had to navigate. I do not try to construct polished STAR answers at this stage. I am just surfacing raw material. If I have worked on ten major projects and cannot identify a specific personal technical decision from at least six of them, my behavioral prep is starting from close to zero regardless of how long I have been in the industry.

Target company research. I look up everything publicly available about the interview process at my target companies. I check Glassdoor, Blind, and Levels.fyi for recent interview reports. I look at what PracHub surfaces as the company-specific question patterns. I am trying to answer 3 questions: what is the difficulty distribution of their coding rounds, what is the scope and depth of their system design sessions, and how much weight does the behavioral round carry relative to the technical rounds. The answers vary dramatically across companies and dramatically change what I prioritize in my prep.

Time budget. I look at my calendar and figure out how many weeks I have before my target interview, and how many hours per week I can realistically commit. I divide the available hours across the phases I will describe below. If I discover I have 2 weeks and 4 hours per week, I adjust the plan accordingly rather than pretending I will somehow find twenty hours a week I do not actually have.

The output of Phase 0 is my behavioral material, my target company intelligence, and my weekly time budget. This document is what I return to every few days throughout prep to check whether I am actually moving in the right direction.

Phase 1: Foundation Repair (Weeks 1–2)
Phase 1 is about clearing the Blank and shoring up the Shaky items from my inventory before I touch anything else.

The specific sequence matters. I start with the topic areas that are foundational dependencies for everything else: arrays and strings, hash maps and sets, linked lists, trees, and basic graph traversal. These topics appear in roughly 70% of coding questions and underpin the more complex patterns in later phases. If these are weak, working on dynamic programming or advanced graph algorithms is premature and inefficient, because those problems build on pattern recognition that requires the fundamentals to be automatic.

Within each topic area, my practice loop is not simply to solve problems. It is to solve, explain, and diagnose.

After solving any problem, I narrate the full solution out loud as if I am explaining it to an interviewer who cannot see my screen. I describe the data structure I chose and why it was appropriate for this specific problem. I describe the time and space complexity and explain what constraint is driving each. I describe the edge cases I tested and why they are the ones that matter. If I cannot narrate the solution cleanly after solving it, I go back and solve it again the next day without looking at my previous work.

When I get a problem wrong or need more than thirty minutes to solve it, I do a specific diagnosis rather than just reviewing the answer. I write down one of three failure modes: I did not recognize the pattern, I recognized the pattern but made an implementation error, or I recognized the pattern and implemented it correctly but could not explain it clearly. Each failure mode has a different remedy. Pattern recognition failures mean I need more exposure to that category. Implementation errors usually mean I am thinking correctly but have a specific syntax or indexing habit that is producing bugs. Explanation failures mean my conceptual understanding is actually shallower than my solve rate suggests.

I keep a daily log in a simple spreadsheet. Columns are: date, problem name and difficulty, time taken, result (solved independently, solved with hint, did not solve), failure mode if applicable, and a one-sentence note of the key insight. This log is not for anyone else. It is for me, so I can look at it after two weeks and see whether I am improving, plateauing, or going in circles.

Phase 2: Pattern Saturation (Weeks 3–4)
Once the foundational topics are solid, I shift to pattern saturation. The goal is to develop the ability to look at a problem and immediately identify the category of approach it belongs to, without needing to work through the full brute force first.

The patterns I specifically focus on are the ones that appear most frequently in the difficulty range that matters: medium to hard. These include the two-pointer approach and its many variants, the sliding window technique, binary search on the answer space (not just on sorted arrays), BFS and DFS with state tracking, prefix sums, monotonic stack and queue applications, and topological sort for dependency problems. Within dynamic programming, I focus on the subset of problems that appear in actual interviews rather than the full academic taxonomy: 1D linear DP, grid DP, interval DP, and knapsack variants.

For each pattern, I do not just practice problems instead I try to write a pattern card. A pattern card is a half-page document that describes the trigger conditions for the pattern (what properties of the problem indicate this approach is worth trying), the standard template implementation, the common variations and how they modify the template, and the typical time and space complexity. Writing these cards from scratch rather than copying them from the internet forces active encoding. I have a folder of about twenty-five pattern cards that I review every three days during this phase.

The target for Phase 2 is that when I see a new medium-difficulty problem from any of these categories, I can identify the applicable pattern within the first two minutes of reading the prompt. I test myself on this explicitly: I read the problem, set a two-minute timer, and write down just the pattern name and the key data structure before looking at anything else. Over the course of two weeks, the time it takes me to pattern-match should compress noticeably.

Phase 3: System Design Depth (Weeks 3–5, overlapping with Phase 2)
I run system design prep in parallel with pattern saturation because they draw on different cognitive resources and the overlap prevents burnout from doing the same type of practice for too many consecutive hours.

My system design prep has 3 layers.

Write on Medium
The first layer is building blocks. I spend the first week making sure I have a deep, not superficial, understanding of the core components that appear in almost every system design interview: load balancers (Layer 4 vs. Layer 7, consistent hashing for session affinity), caching (cache-aside vs. write-through vs. write-back, eviction policies and when each breaks down), SQL vs. NoSQL databases (what ACID actually means and when you trade it away, horizontal sharding strategies and their specific failure modes), message queues (Kafka vs. RabbitMQ vs. SQS and what properties of the workload determine which you choose), and CDNs (pull vs. push origins, cache invalidation tradeoffs). For each building block, I want to be able to describe not just what it does but where it fails and what the operational cost of running it is.

The second layer is framework practice. I use a consistent structure for working through any design problem: establish the scale and constraints before drawing anything, identify the core read and write paths separately, design the data model before designing the API, identify the bottleneck in each path and address it explicitly, and handle failure modes and operational concerns in a dedicated section at the end. Practicing this framework on a wide variety of prompts builds the muscle memory to structure a design session confidently even when the specific prompt is unfamiliar.

The third layer is company-specific calibration. Different companies test system design very differently. What a Google L5 system design session looks for is genuinely not the same as what a Stripe E4 session looks for. Google tends to go broad and then probe the trade-offs at scale. Stripe tends to focus intensely on reliability, correctness, and what happens when the system is actively failing. Amazon layers in operational concerns and cost frugality in a way that other companies do not. Try to talk to folks at Amazon or specific companies or check on subreddits or blind or prachub specifically for this layer because it will help you with the actual question patterns with each company rather than generic architecture prompts. The difference between knowing general system design and knowing how a specific company tests it is the difference between a decent session and a hire decision.

Phase 4: Mock Loops (Week 5 onward, and every week until the interview)
Mock interviews are where most candidates underinvest, and it is the single most expensive mistake in the entire prep process.

Practicing alone is useful. It is not sufficient. The specific stressor that makes technical interviews hard is not the material. It is the performance pressure of producing in front of another person who is evaluating you. That pressure affects your working memory, your pattern recognition speed, and your ability to hold a thought while simultaneously typing and narrating. The only way to reduce the impact of that pressure is to practice under that pressure repeatedly until it becomes familiar.

I schedule at least 2 mock coding sessions and one mock system design session per week during Phase 4. My preference is to do these with peers who are also actively interviewing, because they are calibrated to the current difficulty bar and have genuine motivation to give useful feedback. When peer mocks are not available, I use structured solo simulation: I set a hard timer, open a problem I have not seen, narrate everything I am doing out loud into a voice memo, and do not pause the timer if I get stuck. Reviewing the voice memo afterward is uncomfortable in the same useful way that watching yourself on video is uncomfortable. You hear the filler words, the moments of silence that reveal where you lost the thread, the times you jumped to code before establishing the approach.

The feedback protocol for mock sessions matters as much as the sessions themselves. I do not ask my mock partner for a general impression. I ask for 4 specific pieces of information:

where my communication dropped (times when I was thinking silently instead of narrating),
whether my approach to each problem was reasonable before I started coding,
whether my code was readable without explanation, and
whether my complexity analysis was accurate.
These four dimensions are roughly what a real interviewer is scoring.

Phase 5: The Final 72 Hours
The 72 hours before an interview loop are not for learning new material. If something is not already in my head by this point, it will not be reliably accessible under pressure. Trying to cram new concepts in the final 72 hours degrades the retrieval of existing knowledge by introducing interference.

What I do in the final 72 hours is calibration and logistics.

On the 3rd day before the interview, I do a light review pass through my pattern cards and my behavioral story document. I am not testing myself, just refreshing. I solve one or two easy problems in the language I will use in the interview, purely to warm up the syntax recall.

On the 2nd day before, I do a single full simulation of a complete interview loop: one coding problem, one system design problem, behavioral narration for three stories. I treat this simulation as close to real as I can make it: same time limits, same format (whiteboard for design, IDE for coding), same narration discipline. After the simulation, I sleep. Deliberately. The research on sleep and memory consolidation is not subtle. Sleeping after a comprehensive review session is significantly better for retention than doing another review session.

On the day before, I do nothing technical. I confirm the logistics: the Zoom link, the time zone, whether there is a specific coding environment they want me to use and whether I have tested it. I eat well. I go for a long walk. The single biggest performance variable in the final 24 hours is physiological, not intellectual.

On the morning of the interview, I have a short warm-up. I solve one easy problem in the language I will be using, just to activate the pattern-matching circuits. I read through one behavioral story. I do not try to review system design components or refresh algorithm patterns. The window is too narrow and the activation cost is too high.

The harder part nobody writes about
Everything above is the mechanical system. The harder part is managing the emotional arc of a multi-week prep process.

Interview prep is psychologically bruising in a way that regular work is not. Regular work gives you constant feedback through shipped features, merged pull requests, and team responses. Interview prep gives you minimal feedback and a lot of silence. You solve problems in isolation. You do not know whether your approach would satisfy a real interviewer. You have no idea whether the company you are targeting has already filled the role internally. The uncertainty is constant, and the only antidote to it is trusting the process enough to keep going.

The specific thing I do to manage this is to measure effort rather than outcomes during the prep phase. I do not try to evaluate how ready I am by asking myself whether I feel ready, because that feeling is almost completely uncorrelated with actual performance. Instead I track concrete process metrics: how many problems I solved this week, whether I completed my scheduled mock sessions, whether I updated my behavioral document. These are the things I control. The outcome of the interview is not something I control, so I do not spend cognitive energy there during prep.

After the interview, I do a structured retrospective regardless of outcome. I write down every question I was asked, my initial reaction to each, where I felt confident and where I struggled, and what I would do differently. If I get an offer, this retrospective is still valuable because it shows me what actually worked, not what I thought was working. If I do not get an offer, the retrospective is the material that makes the next attempt better.

What I actually use
Throughout all five phases, the platform I return to most consistently for company-specific preparation is

For the first three phases, the core tools are free and widely available: LeetCode for coding practice, the NeetCode roadmap as a structured topic guide, Designing Data-Intensive Applications for foundational system design reading, and Glassdoor or Blind for surfacing recent interview reports from real candidates at specific companies.

The one paid tool I use, specifically for the company calibration layer in Phase 3, is prachub. I landed on it not because I was looking for a platform to recommend but because the specific problem it solves mapping real interview questions to specific companies and levels is tedious and time-consuming to do manually from forum posts and Glassdoor reports. Whether that particular problem is worth solving with a tool is a personal call that depends on how much prep time you have and how targeted your company list is. For me, with two or three target companies and a finite prep window, it saved meaningful time during Phase 3. It is not a substitute for knowing the material. It is closer to a study guide that tells you which chapters to prioritize before a specific exam.

If your budget is literally, the manual version works. You compile recent interview reports from Blind and Glassdoor, sort them by recency, look for patterns in the follow-up questions interviewers asked, and use that to weight your study time toward the failure modes that company actually probes. It is slower, but the information is largely there if you are willing to dig.

The system works when you follow all of it, including the parts that feel unnecessary. The inventory matters because it forces honesty. The pattern cards matter because writing them is different from reading them. The mocks matter because solo practice is not representative of the actual task. The final 72 hour protocol matters because most people spend those hours doing the wrong things.

You do not need to be the most technically gifted engineer in the room. You need to be consistently prepared, consistently communicative, and consistent enough in your process that a bad morning or a confusing prompt does not unravel everything you have built. That level of consistency is achievable. It just requires treating preparation as a craft rather than an event.

Roast my approach to solve this question: Coffee Ordering System (Salesforce interview question)

Emily Woods — Thu, 21 May 2026 01:59:06 +0000

I've been practicing system design by turning my solutions into visual diagrams (helps me think + great for review later).

Here's my attempt at the Salesforce Coffee Ordering System question that's been popping up in interviews:

[Infographic attached]

The question asks you to design:
Menu browsing + order placement (pickup/in-store)

Customizations (size, milk, add-ons) with price calculation
Payment processing
Barista queue with status updates (PLACED → IN_PROGRESS → READY)
Real-time status for customers
Scale from 1 store → thousands of stores

What I covered:

Microservices split (Menu, Order, Payment, Notification)
Event-driven architecture with message queue
PostgreSQL for orders, NoSQL for menu (read-heavy + cached)
WebSocket for real-time customer updates
Idempotency keys, retries, dead letter queue, saga pattern

Where I'm unsure:

Should payment be synchronous or async?
Is sharding by storeId enough, or should I also consider time-based partitioning for order history?
How would you handle a barista tablet going offline mid-shift?

Be brutal, what did I miss?

Question source: PracHub. Making more of these if people find them useful. Let me know in comments if you want the link.

Everyone is vibe coding but nobody is maintaining the vibe code.

Emily Woods — Mon, 18 May 2026 01:15:02 +0000

Six months after the AI-generated prototype ships to production, the engineer who wrote zero of it is on call at 3 AM trying to understand it.

Vibe coding is real and it works for what it is. You can describe a goal in plain English and get working software in an hour that would have taken a week to build manually. The demos look incredible. The prototypes are impressive. The problem is that software does not live in the demo. It lives in production, where it degrades, gets extended by new requirements, fails in edge cases that the original prompt never described, and eventually gets handed to an engineer who has to understand what it does and why. The industry right now is extremely good at generating vibe code and almost completely unprepared for the part that comes after.

What vibe coding actually is
Andrej Karpathy coined the term in early 2025 and the internet ran with it. The core idea is simple: instead of writing code manually, you describe what you want in natural language. The model handles the implementation.

You review the output, refine the prompt, iterate quickly, and end up with a working product without touching the actual syntax.

If you have used Cursor with agent mode or Claude Code with a well-structured prompt, you have done this. You describe a feature, the agent reads your codebase, writes the new code, runs the tests, fixes the failures, and opens a pull request. The experience feels like pair programming with someone who types at 400 words per minute and never needs to look up syntax.

For certain categories of work, it is genuinely transformative. Building a proof of concept in a weekend. Generating a test suite for legacy code that has none. Writing the boilerplate for a new microservice when you already know exactly what the interface needs to look like.

The vibe coding evangelists are not wrong about any of that.

The production gap
Here is the thing they are not talking about.

Software in production is not the same object as software in a demo. The demo version works because you gave it a clean prompt, a clear requirement, and a controlled environment. The production version exists inside a system with fifteen years of accumulated decisions, most of which are not in the codebase and are not in any document. They live in the memory of engineers who have already left, in Slack threads from 2021 that nobody archived properly, in the institutional knowledge of why this particular function is written in a way that seems wrong but is actually protecting against a bug in a third party library that broke everyone in 2022.

When a vibe-coded feature gets deployed and then behaves incorrectly in some edge case nobody anticipated, the debugging process requires understanding not just what the code does but why it was structured a certain way. If you did not write it, if you did not make the architectural decisions, if you did not understand the constraints the model was working within, you are going to spend a very long time reading AI-generated code trying to build a mental model of a system you never actually understood.

I have reviewed pull requests in the past few months that were clearly generated by agents, with comments left in by the model that were confident and wrong. The code was syntactically clean. It compiled. Tests passed. It also quietly violated a transaction boundary assumption that the rest of the system depended on. The engineer who submitted it had not caught it because they were reviewing AI output rather than reasoning through the logic themselves. We found it in code review, but only because a senior engineer who had written the original transaction layer happened to review it.

What happens to the junior engineer
Here is the part of this conversation that makes me genuinely uncomfortable.

The fastest path into software engineering has always been: get hired as a junior engineer, get assigned work that is a bit over your head, struggle with it, and slowly build the mental models that turn into competence. You write bad code. You get it back in review with comments. You write it again. Over a year or two of this, you develop an intuition for how systems behave that you cannot get from reading documentation.

Vibe coding is compressing this loop to the point where the learning disappears entirely. A junior engineer who can generate a working feature in three hours from a prompt is not building the intuition that will let them debug that feature when it breaks in six months. They are getting the output without going through the process that would let them understand the output.

Companies are also noticing that vibe coding lets you hire fewer juniors, because one mid level engineer with good prompt skills can ship the volume that used to require two or three people. So the junior positions are shrinking at exactly the moment when junior engineers have access to tools that make them look like mid level engineers from the outside, which makes it easier for companies to justify not hiring as many of them.

The industry is quietly eliminating the apprenticeship layer. In ten years, when the current senior engineers have moved into management or retired, we are going to want to know where the next generation of people who understand systems came from. I do not have a good answer to that question.

What actually changes and what does not
The skill that vibe coding eliminates: translating a clear, well-understood requirement into syntactically correct code. That skill is gone. The model does it better and faster than almost any human.

The skill that vibe coding does not touch: understanding what the requirement should have been before you wrote the prompt. Knowing when the code the model generated is technically correct but contextually dangerous. Debugging a production failure that involves five different services and a race condition that only shows up under load. Making the architectural decision that determines whether your system needs a message broker or whether a simple database trigger would work fine.

Every skill that was already about judgment rather than execution is still about judgment. Vibe coding just eliminated the execution bottleneck, which means judgment is now essentially the entire job.

The MCP piece
Model Context Protocol is the infrastructure layer that is making vibe coding more powerful in 2026. If vibe coding is describing what you want, MCP is giving the model direct access to the tools it needs to execute on that description. The model can now call your internal APIs, query your database, read from your file system, and commit back to your repository, all within a single agentic loop.

This means the scope of what an agent can autonomously handle is expanding significantly. You can now describe a data migration and let the agent write the migration script, test it against a staging database, review the row counts, and flag discrepancies, without a human being in the loop for each step.

That is genuinely useful. It is also genuinely scary if you have not thought carefully about what guardrails your organization needs around what agents are allowed to touch.

The engineers who will be valuable in 2026 and beyond are the ones who understand how to design those guardrails. Who understand what an agent should be allowed to do autonomously versus what requires a human in the review loop. Who can look at an MCP-connected agentic workflow and identify where the failure modes are.

That is a senior engineering skill. It is not a vibe.

I personally feel vibe coding is not a threat to engineers who understand what they are doing. It is a threat to engineers who measure their value in lines of code per day. If you are the person on your team who can debug the system, make the architecture call, and tell the product manager that a feature is going to break something in a way that is not immediately obvious, you are not replaceable by a prompt.

If your main contribution is translating tickets into code with minimal mistakes, the vibe is already coding that part.

If you are looking for structured approach to for technical interviews and want to practice questions that will be asked in your interviews, don’t forget to check out, PracHub. It has updated lists of questions with their follow-ups with company specific options.

I over-engineered the system design and it cost me the offer.

Emily Woods — Sat, 16 May 2026 20:29:36 +0000

Why trying to sound senior by adding complexity is the fastest way to fail a technical interview.

In one of my interview out of 23 I gave last year, I was asked to design a simple notification system for a startup. I wanted to look like a senior engineer, so I started drawing boxes for Kafka clusters, stream processing engines, and multi-region database replication. I thought I was showing depth. In reality, I was showing that I didn’t understand how to solve a problem with the least amount of complexity required. The interviewer didn’t want a system that could handle the traffic of Netflix. They wanted a system that could be built in a week and maintained by 2 people. I learned that senior engineering is all about when to not use tools.

Here’s what they asked
The company was a series B fintech startup in the Flatiron district. The round was system design. The interviewer, a guy named Mark who looked like he hadn’t slept since the series A, gave me a straightforward problem.

“We need a service that sends transactional emails and push notifications,” Mark said. “Things like password resets, order confirmations, and marketing alerts. We have about fifty thousand users right now, and we might double that in a year. How would you build this?”

I had spent the entire weekend reading about distributed systems. I had watched every YouTube video on “How to design Twitter” and “How to scale to a billion users.” I was ready to be a senior architect.

The over-engineered architecture
I didn’t start with the requirements. I started with the buzzwords.

I drew a Kafka cluster right in the middle of the whiteboard. I told Mark that we needed to decouple the producers from the consumers to ensure maximum throughput and durability. I suggested using a stream processing engine like Flink to handle the notification logic because we might want to do real time analytics on the delivery rates.

For the database, I proposed a globally distributed NoSQL store. I argued that as the company expanded internationally, we would need low latency access to user preferences across different regions.

I even suggested breaking the service into four separate microservices: one for the API, one for the email worker, one for the push worker, and one for the analytics aggregator.

I felt great. I looked at the board and saw a masterpiece of modern engineering. I looked at Mark and expected him to be impressed.

He was just staring at the Kafka box with a look of profound exhaustion.

The interviewer’s reality check
Mark asked one question:
“How many engineers do we have to manage this Kafka cluster?”

I didn’t have an answer. I said we could use a managed service.

“Okay,” he said.
“The managed service costs five hundred dollars a month. Our total notification volume is about three thousand messages a day. Most of those are password resets. Do we really need a distributed log for three thousand messages a day?”

I started talking about future scale.
I said we needed to be ready for when we hit a million users.

“If we hit a million users, we’ll have a different set of problems,” Mark replied.

“Right now, we need a system that works tomorrow. You just proposed an architecture that requires three different infrastructure platforms and a dedicated DevOps engineer to keep it running. Can you build this with just the tools we already have?”

I realized then that I had failed. I had ignored the most important constraint in any engineering project: the human cost of maintenance.

What a senior answer actually looks like
A senior engineer doesn’t solve for the scale of a billion users unless they are actually at a company with a billion users. They solve for the requirements they have, with a clear path for when those requirements change.

If I were to do that interview again, my answer would be much shorter and much more boring.

I would start with a simple background job library like Sidekiq or Celery, using the Redis instance the company probably already has. The notification requests go into a queue. A few workers pull from the queue and hit the SendGrid or Twilio API. If the API is down, the worker retries with exponential backoff.

For the data, I would use a single table in the existing Postgres database to store the notification logs and user preferences. No microservices. Just a well structured module within the main application.

This system can handle fifty thousand users without breaking a sweat. It can handle five hundred thousand users with about ten minutes of vertical scaling. It takes one engineer two days to build and requires zero additional infrastructure management.

That is the senior answer. It shows that you value the company’s time and money more than your own desire to play with cool technology.

The lesson
I used to think that Senior Software Engineer was a title given to people who knew the most complex patterns. I was wrong. It is a title given to people who can be trusted not to build complex things when simple things will do.

Complexity is a tax. Every box you draw on a whiteboard is a box that someone has to debug at three in the morning. If you can solve a problem with a simple SQL query and a cron job, you should do that. Only move to the distributed systems and the stream processing when the simple solution literally cannot handle the load anymore.

If you are walking into a system design interview, your goal is not to show off. Your goal is to show that you are a pragmatist.

Final thoughts
I stopped reading about scale and started reading about maintenance. It changed how I approached every interview after that. I stopped trying to sound like an architect and started trying to sound like a colleague. Remember whenever you make mistakes in any of your interview, do not forget that.. keep that mistake in the list, work on it and try not to make the same mistake again.

If you want to practice system design in a way that focuses on these realistic trade offs rather than just drawing boxes, PracHub has real interview questions that specifically test for over-engineering. They provide the constraints that force you to choose the simplest viable solution, which is exactly what top tier engineering teams are looking for.

Are all coding agents ruining the technical roles?

Emily Woods — Fri, 15 May 2026 19:14:23 +0000

AI agents are not replacing senior engineers, but they are absolutely destroying the entry level roles we used to rely on to train them.

Everyone is arguing about whether AI coding agents will replace software engineers. They are missing what is actually happening. Claude Code, Cursor, and Codex are not replacing senior architects. They are replacing the specific, repetitive tasks that we historically assigned to junior engineers, QA testers, and entry level data analysts. The industry is currently hollowing out the bottom of the career ladder. We are getting very good at generating boilerplate code and automated test coverage, but we have no plan for where the next generation of senior engineers is supposed to come from if nobody is allowed to be a junior engineer anymore.

The death of the junior ticket
Five years ago, when we hired a junior backend engineer, we had a specific process for onboarding them. We gave them simple tickets. They would update API endpoints, write unit tests for existing modules, and fix minor bugs that the senior team did not have time to prioritize.

That was how they learned the codebase. They spent a year doing the grunt work, making mistakes in safe areas, and slowly understanding how the system fit together.

Today, those tickets do not exist. Or rather, they exist, but they are not assigned to junior engineers. They are assigned to Claude Code.

If I need unit tests generated for a new service, I do not hand that to a new hire. I point an agent at the directory and get a ninety percent complete test suite in four minutes. If I need a basic CRUD API endpoint added to an existing monolith, Cursor handles it faster than I can write the Jira ticket explaining it to a junior developer.

The economic reality is that paying a junior engineer to spend 3 days figuring out how to write a database migration is no longer justifiable when an agent can draft it in seconds. But without those three days of struggle, that junior engineer never builds the mental models required to become a mid level engineer.

QA is becoming an algorithm
The shift is even more aggressive in Quality Assurance.

Manual QA testing has been dying for a decade, replaced by automated test suites. But writing and maintaining those automated test suites was still a massive human effort. You needed QA engineers who understood Cypress or Selenium to write the integration tests.

Now, agents are perfectly suited for this. You can feed an agent the user story and the frontend code, and it will generate the end-to-end testing scripts. When the UI changes and the tests break, you do not need a QA engineer to spend an hour tracking down the broken selector. The agent reads the error log, looks at the new DOM structure, and fixes the selector automatically.

The role of a QA engineer is shifting from writing tests to reviewing the tests that agents write. But reviewing tests requires a deep understanding of what exactly needs to be tested, which is a senior skill. The entry level QA role, where someone just runs scripts and logs bugs, is evaporating.

Data science and the end of the query monkey
Data science is seeing the exact same hollowing out.

Join The Writer's Circle event
The classic entry level data analyst job was essentially translating business questions into SQL queries. The marketing team would ask for a report on churn rates by demographic, and the junior data analyst would spend the afternoon writing the JOIN statements and formatting the output.

Agents have completely commoditized this. If you have a clean database schema and you give an agent read access, any product manager can type a natural language question and get the SQL query, the execution results, and a generated chart.

The data science jobs that survive are the ones that agents cannot do. Designing the data warehouse architecture. Defining the statistical validity of an A/B test. Figuring out why the business logic in the billing system does not match the data in the event logs. Those are senior problems. The query writing was the training ground, and the training ground is closed.

What happens in five years
This hollowing out creates a massive structural problem for the tech industry.

Right now, companies are enjoying a massive productivity boost. Senior engineers are using agents as force multipliers, doing the work of three people because they no longer have to write boilerplate or manually debug simple errors. Profit margins look incredible because companies are freezing entry level hiring while maintaining output.

But senior engineers do not appear out of thin air. They are junior engineers who were allowed to break things for five years.

If we remove the junior layer of the industry because agents are cheaper, we are cutting off the supply chain of senior talent. In five years, the current senior engineers will move into management or retire, and there will be a massive shortage of mid level engineers who actually understand how to design systems from scratch. You cannot become an architect by just reviewing AI generated code for five years. You have to have felt the pain of maintaining your own bad code.

The value of a software engineer is shifting rapidly. The value used to be in the typing. How fast could you translate a requirement into syntax?

The typing is now free. The value is entirely in the judgment. The value is knowing which requirements are logically impossible. The value is knowing that adding a specific feature will destroy the database throughput. The value is knowing when the AI generated code is technically correct but contextually disastrous.

If you are entering the industry right now, you cannot compete with agents on syntax. You will lose and then you have to compete on context. You have to learn system design, architecture, and business logic faster than any previous generation, because the shallow end of the pool is gone.

If you want to focus on the judgment skills rather than the typing skills, PracHub forces you to practice the architectural trade-offs and edge case detection that agents consistently fail at and all the questions are actually getting ask in interviews.

At the last, I would say the code generation is solved but the thinking is still up to you.

I used AI coding agents for a week at work. Here is what actually happened.

Emily Woods — Fri, 08 May 2026 20:17:14 +0000

I used AI coding agents as my first approach for every task during a full work week. My raw line output went up about 40 percent. The amount of code that actually shipped to production without needing significant rework stayed roughly the same. The agents were fast at the repetitive parts. They could not help me with the parts that were actually hard, which are the parts where you need to understand why a system was built a certain way by someone who is no longer on the team, or whether adding a new component is worth the operational cost your team can barely handle right now. The bottleneck was never typing.

Why I did this?

Every engineering Slack channel and substack newsletter I am reading is all about fighting about AI coding agents since early 2025. One side says software engineering is basically over and that agents will be writing most production code. The other side says the agents are fancy autocomplete and the real work of engineering, making decisions when you do not have all the information, is still a human problem.

I kept going back and forth depending on which demo I had most recently watched, which is a bad way to form an opinion about anything. So I stopped watching demos and decided to collect my own data. One full work week, leaning on the agents as heavily as I could for my actual job, and tracking what happened.

What I used
The codebase is a mix of Python and Go and the current work involves maintaining a handful of microservices, dealing with message queues, Postgres, Redis, and a set of third party API integrations that each have their own authentication quirks.

For the experiment I used Cursor with agent mode turned on for code generation across files, Claude Code for longer reasoning tasks where I wanted the model to look at an entire service and suggest changes, and a custom internal tool our team built that reads Jira tickets and suggests implementation plans.

The rule was simple and If I would normally open a file and start writing, I would instead describe what I wanted to the agent and let it go first. Then I would review and correct rather than writing from scratch.

Where the agents were actually useful
On Tuesday I needed to spin up a new service. Kafka consumer, schema validation, some business rules, write results to Postgres. I have built this kind of thing enough times that the structure is predictable. I described the requirements and Cursor generated about 80 percent of it in around 12 minutes. The consumer setup, the Pydantic models, the SQLAlchemy layer, the error handling. It was clean and mostly correct however I adjusted the logging to match our team conventions and it was ready.

That kind of work, the repetitive structural stuff that follows a pattern you already know, is where the agents are genuinely good. They are fast and they do not make the dumb typos that I make at 4 PM on a Tuesday.

Test writing was also surprisingly good. I had a backlog task to add test coverage to a service that had been shipped quickly with minimal tests. I pointed Claude Code at the directory and asked for unit tests on the core modules. It produced a solid suite that covered the main paths, caught a boundary condition I had missed in one of the validation functions, and only needed three tests adjusted because it made wrong assumptions about how we mock the database layer. That would have been most of my Wednesday afternoon done manually. The agent did it in twenty minutes.

And also it did the documentation. I needed to onboard a new teammate onto a service I wrote six months ago. Instead of spending an hour writing up a walkthrough, I had Claude Code analyze the service and produce an explanation of the architecture and the data flow. It was about 90 percent accurate and gave the new engineer something to read before asking me questions, which meant I spent the onboarding time on their actual questions instead of on prose.

Where they fell apart
Monday morning we had an incident. A downstream service was getting malformed data from one of our endpoints. The root cause turned out to be an interaction between our serialization layer and a schema change that another team had made. Figuring that out required reading the Git history of two repos, finding a Slack thread from three weeks earlier that explained why the schema change had been made, and then reasoning about how the serialization would behave differently under a specific race condition between the old and new versions.

I tried to use Claude Code for this and gave it the relevant files and the error logs. It generated several guesses that were plausible but wrong, because the actual answer depended on context that is not in the code. It was in conversations, in commit messages, in the organizational memory of why someone made a decision three weeks ago. The agent could read the code. It could not read the room.

On Wednesday I had to decide whether to add a cache to a service that was slow under load. The textbook answer is yes, obviously, add a cache. The agent gave me the textbook answer. But the textbook answer did not account for the fact that we had just shrunk our on call rotation and nobody had time to babysit another cache layer. It did not know that the database team had a query optimization sprint planned for next month that might fix the latency at the source. And it definitely did not know that our last caching attempt had caused a consistency bug that took two weeks to untangle.

The agent produced a technically correct recommendation that would have been the wrong decision in our specific situation. That gap between the general answer and the right answer for this team at this moment is where the human work actually lives.

On Friday I was implementing billing logic. Proration across subscription tiers, timezone handling for billing cycles, grandfathering rules for legacy customers. The business rules lived across three spec documents and two Slack threads with the product manager. The agent could generate the structure, but it kept getting the edge cases wrong where the rules interacted with each other. Every fix I made introduced a new regression somewhere else. After ninety minutes of going back and forth with the agent, I closed the tool and wrote the logic myself in about the same amount of time, because at that point reviewing and correcting was costing me more than just thinking through the problem on my own.

Numbers
At the end of the week I compared my Git activity to a normal week.

Lines committed were up about 40 percent. Almost all of that came from the new service and the test generation, both of which produce a lot of code quickly.

Pull requests merged went from my usual four to five. The extra one was the new service.

I spent roughly three hours across the week reviewing and correcting agent generated code, which ate into some of the time I saved by not writing it myself.

No production incidents from code I shipped that week, but that was because I reviewed everything carefully before merging. If I had trusted the output without checking, at least two sections would have caused problems based on the errors I caught during review.

What I actually think after doing this
The agents are good at the parts of the job that were already the easiest parts. Repetitive service setup, test boilerplate, documentation that summarizes code you already wrote. They are fast at those things and they produce reasonable output.

They are not good at the parts that make engineering hard. Understanding why a system was built the way it was. Knowing the team well enough to factor operational capacity into an architecture decision. Debugging across service boundaries when the root cause is in a Slack thread, not a stack trace. Writing business logic where the rules contradict each other in ways that only show up at the edges.

The people who should be worried are the ones whose main contribution has been cranking out predictable code on well understood problems, because the agents can now do that faster. The people who should not be worried are the ones who spend most of their time in the messy middle, making judgment calls that depend on context the agents cannot access.

I do not think the agents are replacing engineers. I think they are replacing the part of engineering that engineers already did not find very interesting. The part that is actually hard, the part that makes you stare at your screen and think for twenty minutes before typing anything, is still yours.

If you are anxious about AI agents taking your job, run this experiment yourself. Use the tools hard for a week. See what they speed up and where they stall out. Form your own opinion from your own data instead of from someone else’s demo video or Twitter takes.

My take after the week is pretty simple. I type less now. (Also Whispr Flow is blessing where you need to type less and speak more) I think the same amount.

If you are in an active interview process and want to make sure you are practicing effectively for the technical rounds that come after the recruiter stage, PracHub has company specific questions organized by role and round type that let you prepare for the exact format each company uses. But all of that preparation is wasted if you never reach the technical rounds because your recruiter emails communicated that you were difficult to work with before anyone had the chance to evaluate your code.

I will never walk into a backend interview without solving these 20 questions.

Emily Woods — Tue, 05 May 2026 23:14:59 +0000

I failed more than 20 interviews in last 10 months

I saw many time my approach fell apart as soon as the interviewer asks a follow up question about what happens inside those boxes when traffic spikes.

I compiled this list based on the questions that actually get asked in real rooms. I failed many interviews because I did not know the answers to these. I ask them now because they are excellent filters and I think they separate the people who only know the vocabulary from the people who know how the systems behave under pressure.

You just need to understand the underlying mechanics well enough to discuss them conversationally.

Databases and query performance
Databases are where most applications spend most of their time. You need to know how to get data in and out efficiently when the tables get large.

1. What happens when you put an index on a random UUID column
A lot of developers use UUIDs for primary keys because it makes distributed generation easy. But standard UUIDs are random. Inserting random values into a B-tree index causes massive page fragmentation and forces the database to write to disk constantly. You should know why sequential IDs or time sorted UUIDs fix this.

2. How do you paginate through 50 million rows without using OFFSET?
Using OFFSET and LIMIT works for the first few pages. By page ten thousand, the database is scanning and discarding huge numbers of rows before returning your data. You need to be able to explain keyset pagination (cursor based pagination) and why it keeps query times flat regardless of the page depth.
**

When would you use a composite index instead of two separate indexes?** If you frequently query a table using two columns together, creating an index on column A and an index on column B is usually the wrong move. The database typically only uses one index per table scan. You need to understand how a composite index on (A, B) works and why the order of the columns matters.

4. What is the N+1 query problem and how do you fix it?
This is the most common performance bug in modern applications that use ORMs. You query a list of users, and then as you loop through the users, the ORM fires a separate query to fetch each user’s profile. You need to be able to explain how to fix it using explicit joins or eager loading.

Concurrency and transactions
Distributed systems do things at the same time. Bad things happen when you do not manage that timing.

5. How do you prevent double booking a ticket in a distributed system
Checking if a seat is available and then booking it creates a race condition. You cannot solve this with a mutex in your application code if you are running multiple servers. You need to know how to use database level locks, like a SELECT FOR UPDATE statement, or an optimistic locking strategy with version numbers.

6. What is the difference between repeatable read and serializable isolation levels?
You do not need a PhD in database theory. But you do need to know that the default isolation level in Postgres allows certain types of race conditions, and you need to know when you have to crank the isolation level up to serializable to guarantee absolute correctness.

7. How do you implement a distributed lock without creating a single point of failure?
If multiple workers need exclusive access to a resource, they need a distributed lock. Using a single Redis instance works until that instance goes down. You should be familiar with algorithms like Redlock or systems like ZooKeeper that handle distributed consensus.

8. How do you implement idempotency for a payment retry endpoint?
Mobile networks drop connections. Clients will retry requests. If a client retries a payment request because they did not receive the success response, you cannot charge their card twice. You need to explain how to use idempotency keys and where to store them to guarantee exactly once processing.

Caching strategy
Everyone knows caching makes things faster. Interviewers want to know if you understand how caching makes things break.

9. What causes a cache stampede and how do you prevent it?
When a highly requested cache key expires, thousands of requests miss the cache simultaneously and hit the database at the exact same moment. The database falls over. You need to know how to prevent this using probabilistic early expiration or a lock to ensure only one thread regenerates the cache.

10. If you cache a user profile, how do you invalidate it when they update their email?
Cache invalidation is a genuinely hard problem. You need to explain the difference between a write-through cache and a cache-aside pattern, and discuss the tradeoffs of setting a short time-to-live versus explicitly deleting the key on every update.

11. Why might putting Redis in front of your database actually slow your system down?
Adding a network hop to check a cache takes a few milliseconds. If your cache hit rate is terrible, you are paying the network penalty on every request just to find out the data is not there, and then hitting the database anyway. You should know how to monitor and calculate cache hit ratios.

12. What eviction policy makes sense for a session store versus a content feed?
Caches run out of memory. When they do, they have to delete something to make room. Least Recently Used makes sense for a content feed. It is a terrible choice for a session store where you might log active users out randomly.

APIs and network architecture
Your API is a contract. You have to know how to change it safely and protect it from abuse.

13. How do you safely change the payload of a live API without breaking existing mobile clients?
Mobile apps live on user devices for years without being updated. If you change a response format and remove a field, old apps will crash. You need to understand API versioning via headers or URLs, and how to maintain backwards compatibility.

14. What is the difference between a sliding window log and a fixed window counter for rate limiting?
A fixed window counter lets clients burst double their allowed limit right at the boundary between two minutes. A sliding window smooths out the limit. You should be able to explain the mechanics and the memory tradeoffs of both approaches.

15. How do you design an endpoint that needs to upload a 5GB video file?
You cannot read a 5GB file into memory on your application server. It will kill the process. You need to explain streaming uploads, multipart chunking, or using pre assigned URLs to let the client upload directly to cloud storage.

16. How do you handle long running tasks in a synchronous API request?
If an endpoint triggers a PDF generation that takes forty seconds, the client connection will likely timeout. You need to explain the asynchronous worker pattern. The API returns a 202 Accepted with a job ID immediately, and the client polls a separate endpoint to check the status.

Message brokers and asynchronous processing
Real systems decouple work. You need to know what happens when those decoupled pieces fail.

17. Why would you choose RabbitMQ over Kafka, or vice versa?
They are not interchangeable. Kafka is a distributed log built for high throughput and replayability. RabbitMQ is a smart broker built for complex routing and task queues. You need to know which one fits your use case.

18. What happens if your Kafka consumer reads a message but fails to commit the offset?
The consumer will read the same message again when it restarts. Your processing logic has to be idempotent, or you will process the data twice.

19. How do you handle poison messages that repeatedly crash your workers?
If a malformed message causes a null pointer exception in your worker, the worker crashes, the message goes back to the queue, and another worker picks it up and crashes. You need to explain Dead Letter Queues and retry limits.

20. How do you ensure messages are processed in the exact order they were sent?

In a distributed queue with multiple consumers, order is almost impossible to guarantee because consumer A might take longer to process message 1 than consumer B takes to process message 2. You need to explain partitioning or routing keys that ensure related messages go to the same single consumer thread.

This list looks intimidating if you try to memorize it in a weekend but I think it is completely manageable if you take the time to understand the problems these concepts solve.

Every single one of these questions is about dealing with scale, failure, and reality. The database gets slow. The network drops. The users send bad data. Senior engineers spend their days mitigating these exact problems. For practicing questions, i generally do LCs, and some from here. and mainly brush up on basics like bytebytego and system design primer.

I would say try to understand the pain points. When you understand the pain points, the answers make sense.