DEV Community: Emily Woods

Backend Interview Question: Your API Takes 900 ms. SQL Takes 40.

Emily Woods — Thu, 12 Nov 2026 21:55:04 +0000

Before adding a cache, build a request timeline and find the work your user is actually waiting for.

Someone says the API is slow, and suddenly the room has six solutions. Add Redis, add an index, add more servers, rewrite the endpoint, parallelize everything, or blame the network and hope nobody asks a follow-up.

Meanwhile, we still have not explained where the time went.

I like a much smaller starting point. Give me one slow request, the boundary we are timing, and enough evidence to account for its elapsed time. Then we can have a useful conversation about what to change.

For this original backend interview exercise, imagine a product-details API that takes 900 milliseconds from gateway arrival to completion of the response. Its SQL query uses 40 milliseconds. Those numbers are a synthetic fixture, not a production incident or a claim about a particular company.

Our job is to improve the experience without accidentally making the answer less correct. A faster response containing the wrong price is not the little victory we are looking for.

Choose the stopwatch before choosing the fix

First, clarify where the measurement starts and stops. Browser click to usable screen, gateway arrival to completed response, and database query execution are different intervals.

For our example, we are timing the server path from the gateway receiving the request until the response finishes there. We are not yet measuring DNS, connection setup before arrival, the network trip back to the browser, or rendering in the client.

That boundary matters because a beautiful server trace cannot explain time it never measured.

Next, make the complaint specific. Is this one route, one region, one tenant, or every request? Did the slowdown begin after a deployment, appear only during busy periods, or affect unusually large responses? Compare successful and failed requests separately so fast failures do not make the service look reassuringly quick.

Google’s SRE guidance on monitoring distributed systems emphasizes latency alongside traffic, errors, and saturation. Those signals help us describe the symptom before choosing a remedy.

For this exercise, start with one successful slow request. Treat it as a clue to investigate, not proof that every user has the same problem.

Give every part of the 900 ms a place on the page

Imagine our instrumentation gives us the following non-overlapping stages. In this deliberately simple fixture, they happen sequentially.

The request waits 120 ms before an application worker starts.
Authentication takes 40 ms.
The SQL query takes 40 ms.
An outbound dependency call takes 600 ms as observed by our service.
Serialization and response completion take the remaining 100 ms.

Together, those stages account for all 900 ms. We are assuming that the measurement includes the queue and that no relevant interval is missing.

If your real trace does not add up, resist the urge to name the missing time network overhead and move on. It could be uninstrumented work, a gap between spans, or a boundary you misunderstood.

OpenTelemetry’s explanation of traces and spans is useful here. A trace connects operations through a request, while spans describe individual operations with timing and context. That structure helps you ask where the request went, but it cannot reveal work you never instrumented.

Also check what the 600 ms actually measures. An HTTP client span can include time spent acquiring a connection, connecting, waiting for the remote service, and receiving its response. It is evidence that this interval is expensive, not proof that the remote application spent 600 ms computing.

Honestly, this is where the investigation starts becoming interesting. We have narrowed the search without pretending we already know the answer.

Put an upper bound on your favorite optimization

Suppose the first suggestion is to cache the SQL result. Even if that eliminated the entire 40 ms query at zero added cost, our fixed trace would still take 860 ms.

That is a maximum saving of about 4.4% for this example, with every other stage held constant. It is not a prediction of a real cache’s performance, and it says nothing yet about cache misses, invalidation, or freshness.

By comparison, reducing the dependency interval from 600 to 200 ms would bring this same simplified timeline to 500 ms. That is a hypothesis worth investigating because the potential impact is much larger.

This does not mean caching is always the wrong answer. Under load, removing database work might reduce contention and shorten other waits too. Our one-request calculation deliberately holds those effects constant, so a load experiment could reveal a different outcome.

What the calculation does give us is a disciplined question. What mechanism makes this change reduce the delay we actually observed, and how much improvement is plausible if that mechanism works?

I prefer answering that before introducing another service we will need to operate.

Follow the waiting time instead of blaming the biggest box

Take the 600 ms dependency interval and split the next investigation into possibilities. Maybe the local client waits for a connection. Maybe connection setup is slow. Maybe the remote service is slow. Maybe a large response takes time to arrive.

Each explanation needs different evidence and suggests a different change.

For example, if connection acquisition dominates, inspect pool occupancy, pending requests, and connection lifetime. Increasing the pool size is only a proposal; it might overload the downstream service or move the queue somewhere else.

If remote processing dominates, correlate the outbound request with the downstream trace when available. If payload transfer dominates, inspect response size and whether the caller needs every field. Keep missing evidence visible rather than promoting a plausible explanation into a fact.

Do the same for the 120 ms before the application worker starts. Low CPU does not rule out waiting on a constrained resource. On the other hand, a single queued request does not prove the service needs more workers.

Your next measurement should distinguish between competing explanations. Adding ten dashboard screenshots that all say slow is not the same as narrowing the cause.

Parallel work changes the arithmetic

Now change the example. Suppose two independent downstream calls start together, one taking 400 ms and the other 300 ms. The response needs both results, followed by 100 ms of response work.

Ignoring other overhead, elapsed time is 500 ms because the response waits for the slower branch and then finishes its own work. Adding 400, 300, and 100 to report 800 ms would double-count overlap.

That also changes which optimization matters. Making the 300 ms branch take 100 ms would not shorten this particular response while the 400 ms branch still determines the join. It could reduce resource use, but that is a different claim.

Before parallelizing real calls, establish that neither depends on the other’s result and that concurrency will not violate ordering or overload a shared dependency. Parallel is a scheduling decision, not a synonym for faster in every situation.

Read a request timeline as a set of dependencies. Find the chain that determines when the response can finish, and avoid adding parent spans to the child spans already contained within them.

Write the experiment before celebrating the improvement

For our synthetic request, a useful investigation note might say that the dependency interval is 600 ms, connection-pool waiting is one possible explanation, and acquisition timing is the next evidence needed. That is a plan somebody else can question and reproduce.

Once the evidence supports a change, compare equivalent requests under equivalent conditions. Keep the route, payload, authorization context, data shape, and load profile clear. Separate warm and cold behavior when they differ.

Check end-to-end latency along with errors, correctness, completed throughput, and the resource you changed. Include slow requests in the comparison rather than relying only on the average, and record the sample size and measurement window. An average improvement can hide a worse experience for a smaller group.

A patch that returns early by skipping required work is a behavior change, not a free optimization. If the product accepts a partial response or stale data, state that contract explicitly and test it.

For another practice round, use this shopping cart latency problem. Draw the current request path before proposing improvements, then identify which work must finish before the user can see a correct cart. Treat stock freshness as part of the result you must preserve.

Before moving on, leave yourself a short investigation note with the measurement boundary, the observed timeline, one hypothesis, the next piece of evidence, and the result that would count as success.

That is the interview answer I want to practice. We can absolutely talk about caches and indexes, but first let’s make every millisecond in the complaint earn its place on the page.

~ Emily

System Design Interview: Your 100-Request Limit Just Allowed 200

Emily Woods — Thu, 12 Nov 2026 05:17:08 +0000

One boundary example, a small Python model, and a better way to explain what your rate limiter actually promises.

You set the limit to 100 requests per minute, check that request 101 gets rejected, and feel pretty good about the implementation.

Then someone sends 100 requests just before the minute ends and another 100 just after the next minute begins. Your service accepts all 200, even though only a fraction of a second has passed.

Nobody hacked the counter. It followed the rule you implemented, which may not be the rule you meant.

I like this system design exercise because the interesting part arrives before Redis, sharding, or a beautifully drawn API gateway. We have to decide what per minute means, and that tiny phrase changes almost everything that follows.

Make the timing awkward before making the architecture impressive

Use an original practice scenario with one authenticated client and one endpoint. Every admitted request costs one unit, and rejected attempts do not consume this particular quota. Other abuse controls may count attempts differently.

Suppose the implementation uses fixed windows from 0 to 60 seconds, then 60 to 120 seconds. Each window has its own counter, capped at 100.

At 59.9 seconds, the client sends 100 requests. At 60.1 seconds, it sends another 100. Both windows remain within their individual limits, but the service has admitted 200 requests across 0.2 seconds.

That behavior is not automatically a defective fixed-window implementation. It is a mismatch if the product promise was at most 100 admissions during any rolling 60-second interval.

For our exercise, choose that rolling promise explicitly. At decision time t, count admissions in the interval (t − 60 seconds, t]. An admission exactly 60 seconds old has expired. A request arriving now belongs to the interval if we admit it.

Honestly, writing down that boundary is more useful than listing five algorithm names and hoping one sounds senior enough.

Keep a little history instead of resetting the calendar

A sliding log stores the timestamps of admitted requests. Before deciding on a new request, remove expired entries, count what remains, and admit only if there is room. Record the new timestamp only after that decision.

In our 59.9-second example, the first 100 timestamps are still recent at 60.1 seconds. The second burst is rejected. Those entries expire at 119.9 seconds under the boundary rule we chose.

Redis’s rate-limiting walkthrough explains the different algorithms and their trade-offs. I prefer using a concrete timeline like this before selecting one, because an implementation can be correct for one policy and unsuitable for another.

Here is a small reference model for one quota key. It uses integer milliseconds and caller-supplied, nondecreasing decision times so the boundary is easy to test without waiting for a real clock.

from collections import deque
class RollingLimit:
    def __init__(self, limit=100, window_ms=60_000):
        if limit <= 0 or window_ms <= 0:
            raise ValueError('limits must be positive')
        self.limit = limit
        self.window_ms = window_ms
        self.admitted = deque()
        self.last_time = None
    def allow(self, now_ms):
        if self.last_time is not None and now_ms < self.last_time:
            raise ValueError('time must not move backward')
        self.last_time = now_ms
        cutoff = now_ms - self.window_ms
        while self.admitted and self.admitted[0] <= cutoff:
            self.admitted.popleft()
        if len(self.admitted) >= self.limit:
            return False
        self.admitted.append(now_ms)
        return True

The less-than-or-equal comparison is doing real work. Changing it to a strict less-than would keep a request exactly one window old and enforce a different boundary.

This model assumes sequential calls in one process. It is not thread safe, distributed, persistent, or a production middleware. Its job is to make the admission rule executable before we add those responsibilities.

Each admitted timestamp enters and leaves the deque once, giving amortized constant time per call over a sequence of calls. One call can still remove up to the limit’s worth of expired timestamps. Stored history is bounded by the admission limit for this one key.

Test the edge without sleeping for a minute

You can run these checks immediately after the class. They separate the fixed-window boundary burst from the exact point when old admissions expire.

limiter = RollingLimit()
assert sum(limiter.allow(59_900) for _ in range(100)) == 100
assert sum(limiter.allow(60_100) for _ in range(100)) == 0
assert not limiter.allow(119_899)
assert limiter.allow(119_900)
edge = RollingLimit(limit=1)
assert edge.allow(0)
assert not edge.allow(59_999)
assert edge.allow(60_000)

Also try multiple requests with the same timestamp. Time equality must not make distinct requests disappear. In this deque they remain separate entries; if you later use a sorted set, a timestamp alone is not a safe unique member identifier for all requests arriving at that time.

Keep the test clock under your control. Sleeping introduces scheduling noise while teaching very little about the contract you are trying to verify.

Three servers quietly change the meaning of your limit

Now create three independent copies of the model behind a load balancer. If the same client reaches all three, each copy can admit 100 requests. You have implemented three local allowances, which can add up to 300.

Our original promise applied to the client’s total traffic, so local correctness is no longer enough.

One design is to route decisions for a quota key to authoritative shared state. The sequence that removes expired entries, checks the count, and records an admission must execute atomically. Separate network calls can let two requests both observe the final free slot and both take it.

A short Redis script is one implementation option. Redis documents atomic script execution, but a script is not a complete availability strategy. Keep its work bounded, and decide what state loss or failover means for the quota.

In a sorted-set version, timestamps can be scores while distinct admission identifiers are members. Partition by the quota key so the state needed for one decision stays together. A particularly busy key can still become a hot spot; adding shards does not split an indivisible decision for free.

Client identity needs care too. A browser-provided string should not let someone choose a new quota whenever they want. Tie this example’s key to the authenticated account and endpoint policy. In a multi-tenant service, include the tenant boundary rather than accidentally sharing somebody else’s allowance.

Decide what happens when the limiter cannot decide

If the shared store times out, there is no magical response that preserves every desirable property.

Failing open admits traffic while the quota cannot be checked, which sacrifices strict enforcement. Failing closed protects that boundary by refusing traffic, which also affects legitimate clients. A reduced local allowance is another explicit compromise, but it is not equivalent to the original global promise.

For this practice scenario, assume the endpoint triggers expensive work and strict admission control matters more than serving through a limiter outage. We will refuse new work when the limiter is unavailable, and distinguish that infrastructure failure from a known quota rejection in the response and metrics. Different product priorities can justify another decision.

Use a consistent time authority for distributed decisions and define behavior for clock corrections. The monotonic sequence we supplied to the Python model does not appear automatically when several machines contribute timestamps.

A rolling quota still allows a burst, and that may be the next question

Our model admits 100 requests at the same instant when the history is empty. It prevents the 200-request boundary trick, but it does not spread those first 100 requests evenly over a minute.

That distinction matters if each request launches expensive work. A separate concurrency cap limits how much work is active at once; a rate quota controls admissions over time. Neither one automatically replaces the other.

If the desired policy is a controlled burst plus a sustained refill rate, discuss a token bucket instead. If precise rolling counts are unnecessary, a simpler counter may be appropriate. Choose the promise first and explain the cost of keeping it, rather than calling one algorithm universally best.

To rehearse the full conversation, use this rate-limiter design prompt and change one assumption at a time. Start with one client, then add several servers, then make the shared store unavailable. Keep your original promise visible while explaining which part survives each change.

Before closing your notebook, write the interval boundary, the quota key, the atomic decision, and the failure policy in ordinary sentences. If any of them remains vague, you have found the next thing to practice.

I care much more about that explanation than whether the diagram contains the trendiest database. A counter can be perfectly implemented and still enforce the wrong agreement.

~ Emily

Before Your Next System Design Interview, Open These 3 Free Resources

Emily Woods — Wed, 11 Nov 2026 17:52:31 +0000

Google, AWS, and PostgreSQL reading paired with small exercises that leave you with something better than another bookmark.

You can recognize every box in a system design diagram and still get uncomfortable when someone asks why it belongs there.

A cache makes sense until somebody asks how stale the result can be. Retries sound sensible until the first request succeeds and its response disappears. An index looks helpful until you have to explain whether the database actually uses it.

Honestly, this is where I want preparation to become a little less decorative.

I like a resource more when it helps me produce a decision I can defend. Reading a chapter is a perfectly nice afternoon, but writing down what counts as a good outcome, drawing a retry timeline, or inspecting a query plan gives the reading somewhere to land.

These three resources are publicly readable without buying a course. They cover different pieces of the conversation, and each comes with a small practice task of my own. You do not need an AWS account or paid cloud infrastructure for the exercises below.

Start with Google’s SRE Workbook when reliable feels too vague

Open Implementing SLOs in Google’s SRE Workbook, particularly the discussion of what to measure and the distinction between an indicator and an objective. It is useful for turning a broad reliability aspiration into a measurable service promise.

You do not need to read the whole book before making this practical. Pick one user journey and decide which outcomes belong in the calculation.

For an original exercise, imagine a small document app. A signed-in user opens a document they are allowed to read. Our illustrative proposal is that 99.5% of eligible load attempts return the correct document within 500 milliseconds over a rolling 28-day window.

The percentage and timing are practice assumptions, not targets Google recommends for every product. Write down why the user would care about them and what evidence you would need before adopting them.

Now make the denominator less slippery. An eligible attempt in this exercise is a valid request from an authorized user for an existing document. Server errors and timeouts on those attempts remain in the denominator. Removing them would make the service look healthier by hiding the very failures we care about.

For the exercise, measure elapsed time from the user action until the document is usable in the client. Record a timeout as a bad outcome at the agreed timeout threshold. This is different from timing only the database query or only a successful server response.

Try a tiny counting check. If 20,000 eligible attempts occur, a 99.5% target leaves room for 100 bad outcomes. That is a request-count calculation; it does not translate directly into a fixed number of outage minutes.

Your output is a short service promise card containing the journey, eligibility rule, good-outcome rule, measurement point, and window. Then explain one case your proposed telemetry could miss. That last part keeps a tidy definition from becoming false confidence.

Use the AWS Builders’ Library when retry sounds like the whole answer

Next, read Making retries safe with idempotent APIs. Focus on caller-provided request identifiers, late requests, and the distinction between reusing an identifier and expressing a new intent.

This is a good companion to the first exercise because a reliable-looking response is not enough if repeating the operation creates an extra resource.

Keep the same document app. Imagine the user creates a document, the server commits it, and the response is lost. The client cannot tell whether creation happened, so it retries.

For our practice contract, the client sends a key called K7. The server records that K7 belongs to document D42 for this account and this request intent. A repeated request with the same key and intent resolves to that same operation. A genuinely new document needs a new key, even if its title happens to match.

Draw three attempts on paper, including the lost response. Under each attempt, write the document count and the identity returned to the caller. We want one document, not three successful-looking acknowledgements for three accidental creations.

Then make the exercise less polite. Send the same key with different contents and decide the conflict response. Let two identical requests arrive concurrently and explain how the server prevents both from independently creating a document. Finally, let a retry arrive after the stored key has expired and state what the contract can still guarantee.

Keep these as explicit design questions rather than quietly assuming a dictionary solves them. In a real implementation, coordinating the key record with the resource creation and handling in-progress operations require deliberate storage semantics.

Your output is a retry timeline with expected outcomes and unresolved decisions. You can do this entire exercise with a notebook. The reading contains cloud examples, but reproducing their infrastructure is not necessary for this practice task.

Open PostgreSQL’s EXPLAIN guide when add an index becomes a reflex

Use the PostgreSQL documentation on Using EXPLAIN. Start with the basics and the EXPLAIN ANALYZE section. The important distinction is between a planner’s estimates and measurements gathered by actually executing a query.

This exercise assumes you already have a local PostgreSQL database and understand basic SELECT queries. Reading the guide is free; the hands-on part needs a local installation or another environment you control.

Return to the document app. Its recent-documents view filters by owner, orders by update time, and shows the first twenty results. Sketch the query and predict where the work will happen before inspecting a plan.

For your own fixture, choose an owner distribution and enough rows to make the experiment meaningful. Keep the fixture disposable. A table with ten rows may quite reasonably make an index look unnecessary, so record the dataset size rather than treating any one plan as universal.

Here is a manageable experiment you can repeat.

Save the query, dataset description, PostgreSQL version, and initial plan.
Propose one index that matches the filter and ordering, and explain the work you expect it to reduce.
Refresh relevant statistics after loading the fixture, then compare plans and results under the same conditions.
Check both correctness and the measured work, including whether the improvement remains useful for a different owner with many more documents.

Use EXPLAIN ANALYZE only on a safe local query you intend to execute, because it runs the statement. Planner costs are not milliseconds, and one faster timing is not enough to establish a reliable improvement. Cache state and the data distribution can affect your observation.

Your output is a before-and-after comparison with actual measurements. If the plan does not change, that is still useful evidence to investigate. The goal is not to persuade PostgreSQL to validate your first guess.

Bring the three pieces back into one explanation

These resources become more useful together because they make you discuss the same app from different directions.

The service-promise card describes the experience you care about. The retry timeline describes what must remain true when communication fails. The query comparison gives you evidence about one piece of the performance story.

None of them replaces a full system design. Together, though, they make it harder to hide behind a diagram full of familiar components.

Close the source tabs and explain the app aloud for five minutes. Start with the user action, describe the promise, walk through the lost response, and explain what the query experiment did or did not demonstrate. If a statement depends on an assumption, say the assumption.

For another round, choose a problem from this interview practice collection and bring just one of these exercises into it. A small, relevant application is more useful than trying to squeeze every chapter into every answer.

I prefer finishing with three imperfect artifacts I can discuss over thirty pristine bookmarks I have not used. An unanswered question written beside a real example gives the next practice session a useful starting point.

Save the resources, absolutely, but give yourself something to explain before collecting the next three.

~ Emily

Backend Interview Question: Two Buyers Want the Last Seat. Who Gets It?

Emily Woods — Wed, 11 Nov 2026 17:52:28 +0000

A small PostgreSQL example, a deliberately broken timeline, and the follow ups that turn a working demo into a defensible answer.

Both buyers saw the same available seat. Both clicked the button and both received a confirmation, and now somebody has a very awkward email to write.

Nothing about this requires a million requests per second. Two requests arriving in the wrong order are enough.

That is why I like this backend practice problem. You can draw an impressive architecture around it, but eventually somebody has to explain which operation is allowed to say that seat A7 belongs to one buyer.

Let’s work through an original interview style exercise, without pretending it came from a particular company. We control the inventory, use one PostgreSQL database for claims, and start with a single seat for a single event. Payment and expiring holds come later because they add different promises.

Start with the promise, because available is only an observation

Our first rule is that a seat can have at most one committed owner. We also need the application to avoid telling two different buyers that each owns it.

Those are related, but they are not identical. A database row can end up with one owner even after the application has sent two contradictory success messages.

For this exercise, a claim is final once committed. We are not implementing cancellation, seat transfers, or checkout timeouts yet. Buyer identity comes from the authenticated request, and the seat is identified by both event and seat number.

I prefer making those assumptions visible before reaching for a lock. Otherwise, we can spend ten minutes solving a reservation problem when the interviewer meant a temporary hold.

Watch the version that looks perfectly reasonable in a demo

Imagine the application reads the row, sees no owner, and then sends a separate update that assigns the buyer. Its update identifies the seat but does not require the owner to remain empty.

Buyer A reads the empty owner. Before A writes anything, buyer B reads that same empty owner. A assigns the seat to A and receives a success response. B then assigns the seat to B and receives another success response.

The final row contains B. That does not rescue A’s confirmation.

Wrapping this exact read-then-unconditional-write sequence in transactions is not, by itself, the missing explanation. You still need to explain how competing transactions are prevented from acting on the same earlier observation.

Disabling the button in the browser cannot coordinate two buyers either. Neither can a lock inside just one application process when requests can land on different instances.

Put the condition where ownership changes

Here is a deliberately small schema for the exercise. Each event seat pair has exactly one row, and an empty owner means unclaimed.

CREATE TABLE seat_claims (
  event_id bigint NOT NULL,
  seat_no text NOT NULL,
  buyer_id bigint,
  PRIMARY KEY (event_id, seat_no)
);

INSERT INTO seat_claims (event_id, seat_no)
VALUES (42, 'A7');

Buyer 101 attempts this conditional update. Buyer 202 runs the same statement with their own authenticated identity.

UPDATE seat_claims
SET buyer_id = 101
WHERE event_id = 42
  AND seat_no = 'A7'
  AND buyer_id IS NULL
RETURNING event_id, seat_no, buyer_id;

Now the requirement that the seat is unclaimed belongs to the write itself. We have removed the gap between trusting an earlier check and assigning ownership.

Under PostgreSQL’s Read Committed behavior, competing updates to the same row coordinate through the database. If A holds the row while B attempts the update, B waits. When A commits, B checks its condition against the updated row. The owner is no longer empty, so B changes zero rows. PostgreSQL documents this rechecking behavior for concurrent updates.

One returned row means this statement assigned the seat in its transaction. Zero returned rows means it did not claim the seat. In our fixed fixture the seat exists, so zero means it is already claimed; a real endpoint must also decide how to handle missing or inaccessible seats.

This is a narrow solution for a narrow rule. Every ownership-changing path must respect the same rule. An administrative endpoint that blindly overwrites buyer_id would undo the guarantee we are trying to offer.

Also, concurrency safety does not promise fairness. We have not established that the person who clicked first will win. Either buyer can win depending on execution order.

Keep the celebration on the other side of COMMIT

Honestly, this is the part I want written beside the code in big letters.

If the statement runs inside an explicit transaction, receiving a returned row is not the same as committing that transaction. A later error can still cause a rollback. The application must not confirm ownership before it knows the commit succeeded.

Suppose a booking record must accompany the claim. Write both in one database transaction and roll back together if either operation fails. Our tiny example uses the seat row as the ownership record, so it intentionally leaves that extra table out.

Now let the commit succeed but lose the response on its way to the client. The buyer retries and the conditional update returns nothing because the seat is already owned. That does not necessarily mean their first attempt failed.

For a production contract, give the operation a durable identifier scoped to the authenticated buyer, persist its result with the claim, and let a retry recover that same result. Reusing an identifier with different intent needs a defined conflict response. The ownership predicate prevents competing claims; identifying the original operation resolves an ambiguous retry. Our short SQL statement implements the first part, not the entire retry contract.

Make the race happen deliberately in two terminals

Do this in a disposable local database with two independent connections, using Read Committed. The sequence below is a reproducible practice exercise with expected outcomes, not a claimed production benchmark.

In connection A, begin a transaction and run the conditional update as buyer 101. Leave the transaction open after it returns A7.
In connection B, begin another transaction and run the same update as buyer 202. It should wait while A holds the conflicting row lock.
Commit A. B should finish without returning a row, and you can then commit B. Inspect the stored owner and expect 101.
Reset the fixture after both transactions finish, then repeat with A rolling back instead. B should now be able to claim A7, and committing B should leave owner 202.

Keep the waiting transactions short, and clean up both connections if you interrupt the exercise. A lock timeout or another database error is an error path to handle, not evidence that somebody successfully acquired the seat.

Check what the database stores and what each caller is told. Two green HTTP responses are not a correctness test, and one final row is not proof that every earlier response was truthful.

Let the follow-up change the design instead of adding random boxes

An expiring hold changes our state model. Now we need a hold identity, an owner, an expiry rule, and a guarded transition to confirmed. An old timeout task must not release a newer buyer’s hold, so its update needs to identify the exact hold it is expiring.

Payment introduces another boundary. A database transaction cannot roll back a charge performed by an external payment provider. Avoid holding the seat’s database lock open while waiting for that network call. Design the hold, payment result, confirmation, and recovery rules explicitly, including what happens when payment succeeds after the hold expires.

For a useful variation, try this inventory design problem. Begin by deciding whether the service actually controls the stock. A reservation in your database cannot stop an unrelated shopper from taking an item off somebody else’s store shelf.

That is the habit I want this little seat example to build. Name the promise, find the exact write that protects it, and make two callers challenge it at the same time.

Before moving to your next problem, explain what changes when A rolls back and when A commits but loses the response. If those two stories sound different in your answer, you are practicing something much more useful than memorizing the word transaction.

~ Emily

Before You Solve Another Interview Question, Try This 45 Minute Mock

Emily Woods — Wed, 11 Nov 2026 03:37:26 +0000

One complete attempt, a useful debrief, and a much clearer idea of what to practice tomorrow.

Finishing a practice question can feel wonderfully reassuring, especially when the green checkmark arrives before your coffee gets cold.

But close the solution tab, start a timer, and explain your decisions out loud, and suddenly you are practicing something a little different.

Now you have to notice an ambiguous requirement, choose an approach, recover from a wrong turn, and leave enough time to check your work. Nobody has conveniently highlighted the part where your reasoning went sideways.

That gap interests me much more than the number beside a solved-problems counter.

Before adding another question to the pile, I prefer one practice session that leaves behind evidence of what actually happened. You can run it alone, and you do not need an elaborate setup or a friend who is free at exactly the right time.

Give yourself 45 minutes for the attempt, then another ten for the review. Those timings are a practice proposal, not a company’s interview format or a pass/fail rubric.

Set up a session you cannot accidentally turn into a tutorial

Choose a problem you have not recently solved, in a language you already use. Something modest is fine. An unfamiliar implementation of a familiar idea can reveal more than a famously difficult problem whose solution you remember.

Open a blank editor and a scratchpad. Decide which tools are allowed before starting, ideally using the rules for your upcoming interview. For an unaided baseline, keep AI assistance and solution tabs closed. If you use a reference or hint, record what it supplied instead of quietly rewriting the story afterward.

Talking through your decisions helps make the attempt reviewable. A private audio recording is optional; timestamped notes work too. You only need to capture moments such as when you settled the contract, chose an approach, found a bug, or changed your mind.

Microsoft’s technical interview guidance explicitly discusses clarifying ambiguity, planning a solution, and testing it. So this practice includes the work around the code, too.

For an accessible practice option, this session-log exercise asks you to count sessions per user from possibly unsorted event logs. Its full prompt, constraints and examples are publicly readable. You can use it with the timing plan below and review your attempt against its own rules.

The worked examples below use a separate sign-in/sign-out exercise, which you can attempt directly from this prompt. Given chronological log records of the form user_id timestamp action, with integer user IDs, integer timestamps in seconds and actions sign-in or sign-out, return each user who has at least one completed session lasting at most a nonnegative duration limit, once, in ascending numerical order. Each user can have several sessions, has at most one open session at a time, and every sign-in has a matching sign-out. Events from different users can overlap. Return an empty list when nobody qualifies.

For a clean attempt, choose either the linked counting exercise or the self-contained sign-in/sign-out exercise and run the mock before reading the worked debrief below. The sign-in/sign-out details in that debrief apply to the self-contained exercise. If you already know the problem you chose, pick a different one rather than timing your memory.

Give each part of the attempt a visible finish line

Minutes 0–5 should leave you with a contract

Write down the input, output, and a rule that could change the answer. Then predict the result of one tiny example before touching the keyboard.

For the session exercise, users qualify when any completed session is short enough. That is different from requiring every session to be short. Results must contain each qualifying user once, in ascending numerical order.

Also notice what the prompt already guarantees. Logs arrive chronologically, and each user’s sign-ins and sign-outs are well formed. You can mention those assumptions without spending your practice time designing a repair system for malformed logs.

By minute five, another person should be able to read your notes and understand what your function promises.

Minutes 5–12 should leave you with an explainable plan

Describe a straightforward approach first, even if you expect to improve it. Walk through a small input and say what information must survive from one step to the next.

For this exercise, ask yourself how an overlapping session from a second user affects the information you need to remember. Explain why the state belongs to a particular user rather than to the log as a whole.

Do not settle for naming a data structure. Explain what one entry means and when it changes. That sentence is often where a fuzzy plan becomes a plan you can implement.

If you are stuck, write down the exact obstacle. Being unsure how to match events needs a different next step from being unsure how to sort the result.

Minutes 12–30 should leave you with a working path

Implement the approach you can currently defend. Keep the function close to the contract and resist building helpers for situations the prompt explicitly excludes.

When something breaks, describe the smallest input that exposes it before changing the code. Otherwise, a quick fix can become a little guessing game with very convincing variable names.

If you need a hint, pause long enough to note the missing idea. Continue afterward, but mark that part of the attempt as assisted. There is useful information in both an independent solution and a solution completed with one well-chosen nudge.

Minutes 30–40 should leave you with justified tests

Predict expected outputs before running the cases. A program agreeing with your intuition is not much evidence if your intuition made the same mistake as the program.

Start with the smallest meaningful boundary, then use a case that distinguishes two plausible interpretations. For the session problem, equality with the duration limit matters, and so does a user who has a long session followed by a short one.

If the implementation is unfinished, test the completed part or trace the intended behavior. Do not erase ten minutes of review just to make the function look finished.

Minutes 40–45 should leave you with an honest explanation

Explain why the approach works, its time and memory costs, and one limitation that comes from the assumptions. Include the cost of producing the required output rather than stopping your analysis at the main loop.

Finish by stating what remains unverified. That might be a boundary case, an incomplete branch, or a complexity claim you have not worked through yet.

When the timer ends, preserve the code as it is. You can improve it afterward, but save the original attempt so the review has something real to examine.

Review the first wrong turn, not just the final answer

Here is why I like the session exercise for a debrief. Suppose the limit is five seconds and user 2 has sessions lasting 18 seconds and two seconds.

That user qualifies because the second session satisfies the rule. If your implementation excludes them, another hour of typing faster will not repair the original misunderstanding.

Now trace a few other claims independently.

A session from time 10 to time 10 qualifies when the limit is zero, because its duration is zero.
A session lasting exactly five seconds qualifies when the limit is five, so a strict less-than comparison is wrong.
Two qualifying sessions for the same user still produce one user ID.
If user 7 qualifies before user 2, the output must still place 2 before 7.

These cases help locate the break. Misreading the rule is a contract problem. Understanding the rule but writing the wrong comparison is an implementation problem. Never checking equality is a testing gap. They can produce similar symptoms, but they deserve different practice.

For a typical dictionary-and-set solution, scanning n events takes expected O(n) time, while sorting k qualifying IDs adds O(k log k). Storage grows with the users tracked and the qualifying IDs. If your explanation stopped at linear time, the output-order requirement gives you something precise to revisit.

Replace your verdict with three pieces of evidence

Please do not finish this session by declaring yourself terrible at interviews. That is an enormous conclusion to squeeze out of one function and a timer.

Use ten minutes to write three short notes instead. Each note should connect an observation to a next action.

Record the moment. Perhaps you spent 12 minutes discussing approaches before tracing a single example, or only noticed the output needed sorting after the timer ended.

Name the skill involved. Was the missing piece contract reading, choosing state, implementing a known plan, testing boundaries, or explaining complexity? Treat this as a working diagnosis, not a permanent label.

Choose a smaller repair. If you missed the word any, spend the next session turning requirements into examples and counterexamples. If dictionary operations interrupted your reasoning, practice those operations in your chosen language before another full mock.

For instance, an illustrative review note could say that at minute 34, a zero-duration test failed because the comparison excluded equality. The next action is to write boundary cases before implementation on an unfamiliar problem.

That note gives tomorrow a job. Feeling disappointed, unfortunately, does not.

Make the next attempt answer one question

Fixing today’s code is useful, but solving it again immediately mostly tells you whether you remember the repair.

After working on the gap, choose a fresh problem that uses the same skill in a different setting. If contract reading caused trouble, pick a prompt where exactly one, at least one, or all changes the result. If testing was weak, prepare expected outputs before execution and check whether you actually did so.

Keep a tiny practice record with the problem, the observed gap, the repair, and the evidence from your next attempt. There is no need to turn your evening into a project-management ceremony.

Also be fair about what a solo mock can tell you. It cannot reproduce another person’s interruptions or judge every aspect of your communication. A partner can help with those later. What you can inspect alone is whether you made assumptions visible, defended your choices, and checked the behavior you promised.

I want preparation to leave me with more than a comforting counter. A finished session should make the next one easier to choose.

So before opening another random question, save one honest attempt and find the first place where your reasoning needed help. Then give that specific gap your attention, because now you actually know what you are practicing.

~ Emily

I Won’t Start My Next System Design Interview With a Load Balancer

Emily Woods — Wed, 11 Nov 2026 03:37:25 +0000

First 10 minutes are a chance to make the problem smaller before making the diagram bigger.

Your blank whiteboard can make a load balancer look strangely comforting. You know where to put it, you know what connects to it, and within thirty seconds your answer looks like a system design answer.

Then someone asks what happens when the user is offline, and suddenly the boxes are less helpful than they looked.

I love a tidy diagram, but I don’t want it making decisions on my behalf. Before reaching for familiar components, I want a smaller thing settled. What does this system owe the person using it?

Try a quick exercise with me. Imagine the prompt is to design a notification system. Write down what should happen when someone replies to your post while your phone is offline. When you return an hour later, should that notification still exist?

If your answer is yes, you have already identified a requirement that a live connection alone cannot satisfy. You need a durable way to recover the missed notification. We have a design decision before drawing our first infrastructure box, which is a lovely place to start.

Pick one moment worth designing properly

Notification system can mean an unread bell, an emergency pager, a marketing email service or a mobile push platform. Starting with all four gives you an impressive amount of work and very little agreement about what matters.

For this practice example, let’s choose an in-app inbox. A reply creates a notification for one recipient. That person can see recent notifications and mark them as read. An offline user can return and retrieve what they missed. Email, SMS and scheduled campaigns stay outside our first pass.

Those are proposed boundaries, so in an interview I’ll confirm them before treating them as facts. If the interviewer wants emergency alerts, the discussion needs to change immediately.

Write one user action and one visible outcome before naming a technology. For our example, a person returns to the app and can find the reply notification even though they were disconnected when it arrived.

This is much more useful than asking whether the system should be scalable. Almost any interviewer can say yes to that, and neither of you learns very much.

Agree on the promise hiding inside success

Now we need to be a little picky about the word delivered. Does it mean the service accepted an event, the inbox contains a notification, an online device received an update, or the person actually opened it?

Those are different events. Treating them as one vague success flag makes the design sound simpler while leaving the important part unresolved.

For our first version, propose that an accepted notification is durably recorded before we acknowledge success. An online client should see a new item soon after it becomes available, while a reconnecting client fetches missed items from durable storage. Read state changes when the user takes the relevant action, not merely because the server sent an update.

We also need an answer for repeated input. If a producer retries the same reply event, should the user see two identical notifications? Assume no, and define an identity such as the event ID together with the recipient ID. Creating the same logical notification twice must resolve to the same stored item.

Notice that we haven’t promised that every network delivery happens exactly once. We have defined the user-visible outcome and left room to choose the mechanism that protects it.

My notes at this point can be wonderfully plain. Keep accepted work, recover after disconnection, suppress duplicate inbox items, and keep read state meaningful. Each of those statements will give a later box a job.

Ask for a number only when it changes a decision

Capacity estimates can become a small performance of their own. You multiply a few large numbers, say a storage unit with confidence, and then choose the architecture you were going to choose anyway.

I prefer asking what the estimate will help us decide before doing the arithmetic.

Suppose our illustrative workload has 100,000 active users, each receiving ten notifications a day. That gives us one million inbox writes daily, or roughly twelve per second on average. This is a practice assumption, not traffic data from a real company.

Twelve writes per second tells us surprisingly little about the hardest moment. If one announcement targets all 100,000 users, materializing a separate inbox item for each recipient creates 100,000 writes from one event. Now we have a reason to discuss bursts, background work and whether broadcast messages need a different representation.

Reads deserve their own estimate too. A badge fetched on every page view can have a different workload from an inbox opened twice a day. Ask about those access patterns rather than deriving every request from the same daily-user number.

Retention changes the storage discussion. At one million notifications per day, thirty days means thirty million notification records before accounting for indexes, replication or metadata. That does not tell us which database to choose, but it makes the retention assumption worth confirming.

An estimate earns its place when it changes what you build, what you defer, or what you need to ask next. Otherwise it is arithmetic wearing an interview outfit.

Draw one complete path before adding the clever parts

We can finally draw, and honestly, the diagram is easier now because the requirements have started choosing its responsibilities.

Begin with a producer submitting an event. An ingestion path validates it and records the accepted work durably. A worker creates the recipient’s inbox item using the notification identity to handle retries. An inbox API serves stored notifications and updates read state. A live-update path lets connected clients learn that something changed, while reconnecting clients fetch missed items.

That is a starting design, not a finished architecture. It gives us a concrete path to challenge rather than a collection of products to admire.

If the producer times out after the service commits the event, its retry must not create another logical notification. If a worker stops halfway through, pending work must remain discoverable. If the live connection drops, the inbox should still contain the item. Each failure sends us back to one of the promises we already wrote down.

Be careful around the handoff between a database and a queue. Recording work in one place and separately publishing a message can leave a gap if the process stops between those actions. A transactional outbox is one possible way to make committed pending work discoverable; a durable queue can also be the acceptance boundary in a design built around that contract. The choice needs an explanation, not just another arrow.

Load balancing may absolutely belong in this system. So may caching, partitioning and a particular messaging technology. I just want to introduce them when there is a responsibility or bottleneck to explain, instead of letting them become the opening sentence.

Give your opening a shape you can practise

For a ten-minute rehearsal, use four loose stages. These timings are my practice proposal, not a rule for every interview. Follow the interviewer’s direction when they want to move faster or explore a different area.

Use the first two minutes to choose the user moment. Describe the action, the expected outcome and the boundaries you are proposing. Confirm them rather than quietly shrinking the assignment.
Use the next two to define success and failure. Establish what accepted means, which work must survive, and what duplicates or delays the user can tolerate.
Spend two minutes estimating the work. Separate average traffic from bursts, and connect each number to a decision. Keep unanswered assumptions visible.
Use the remaining four to draw one complete path. Trace an event through it, identify where durable state lives, and choose a failure case to explore next.

If you want a concrete starting point, use this in-app notification-center prompt. Stop after the opening discussion and first path instead of rushing to reproduce a full solution. Our workload numbers and proposed boundaries above are practice choices to test against the prompt, not facts supplied by it.

Then close the notes and record a two minute explanation. Listen for places where a component appears without a reason, where an assumption quietly becomes a fact, or where you say reliable without explaining what survives a failure.

You can repair one of those gaps and repeat the opening without solving an entirely new question. That makes the session small enough to finish and specific enough to learn from.

Let the diagram show decisions you actually made

An opening full of questions can still go nowhere if the answers never affect the design. After each clarification, say what it changes. Offline access creates a recovery requirement. Repeated events require a stable identity. Large fan-out raises a workload question that an average request rate hides.

That is the thread I want running through my answer. A reader should be able to point at a box and explain which requirement put it there.

For the next practice session, leave the infrastructure names off the page for a few minutes. Pick the user moment, make the promise concrete, and follow the work.

When the load balancer finally arrives, it can have a job instead of being there to make the whiteboard feel less empty.

~ Emily

System Design Interview: Your Queue Is Growing. Will More Workers Actually Help?

Emily Woods — Tue, 10 Nov 2026 18:05:16 +0000

A small backlog calculation that makes scaling, downstream limits, and recovery time much easier to explain.

You add a queue to the architecture, draw a few workers behind it, and feel the design becoming pleasantly sensible. Requests no longer wait for every background task, and a traffic spike has somewhere to go.

Then someone asks what happens when jobs arrive faster than the workers can finish them.

Adding workers sounds like a perfectly reasonable answer. Sometimes it is exactly the right answer. But if every worker is waiting for the same overloaded database, you may have drawn a larger crowd around the same small door.

I prefer doing a little arithmetic before adding another box to the diagram. It tells us whether the proposed fix can actually close the gap, which is rather helpful when the gap is growing every second.

Let’s use an original practice scenario with simple numbers. No company interview claim, no imaginary production incident, and no queueing-theory exam hiding around the corner.

Give the queue a job and the user a promise

Imagine a service that accepts background jobs to generate customer reports. Once accepted, a job must remain recoverable until it succeeds or reaches an explicit failed state that the user can see.

Acceptance does not mean the report is ready. The interface returns a job ID, and the user checks its status or receives a completion notification. We also need to agree how long waiting is acceptable, because a successfully queued report can still arrive too late to be useful.

For the arithmetic, assume equal-cost jobs, steady rates, no retries, no duplicates, and no startup delay. Count unfinished work across the queue and workers, rather than pretending that fetching a message means completing it. These assumptions make the example easy to check; real measurements will be messier.

Our incoming rate is 1,200 jobs per second. We have 40 workers, and each can complete 20 jobs per second when its dependencies are healthy. The database can support at most 1,000 completed jobs per second for this workload.

That last number is part of this hypothetical scenario, not a general database limit.

Find the gap before choosing the fix

Forty workers completing 20 jobs each gives us 800 completions per second. With 1,200 new jobs arriving, unfinished work grows by 400 jobs every second.

After five minutes, the additional backlog is 400 multiplied by 300, or 120,000 unfinished jobs.

The queue has done something useful by holding the work. It has not created the capacity to finish it.

This is why a healthy enqueue endpoint is not enough evidence that the overall service is healthy. Our API can keep accepting jobs quickly while the completion promise gets further away.

For this simple model, write the relationship as backlog growth per second equals arrivals minus successful completions, while a backlog exists. Keep every rate in the same units and count real completed jobs, not polling calls or processing attempts.

Already, the discussion has become more specific. We need to close a 400 job per-second gap before we can even begin catching up.

Double the workers, then check what they share

Now double the fleet to 80 workers. Their standalone potential is 1,600 jobs per second, which looks comfortably above the arrival rate.

Unfortunately, every completed report still needs the database, and our assumed database ceiling remains 1,000 jobs per second. Under this simplified model, effective capacity is limited by the smaller of worker capacity and downstream capacity.

So scaling helps us move from 800 to 1,000 completions per second. That is an improvement, but it still leaves a 200-job-per-second deficit against 1,200 arrivals. The backlog grows more slowly; it does not drain.

In a real service, pushing past a dependency’s useful concurrency can also increase contention or timeouts. The neat ceiling in our example is generous enough to keep that complication out of the calculation.

Before scaling, inspect where workers spend time. Are they doing CPU work, waiting for database connections, hitting an external rate limit, or sitting behind a hot partition? More workers are a proposal about the limiting resource, so the answer needs evidence about that resource.

If the database is the limit, possible changes include reducing the work each job asks it to do, changing the access pattern, or increasing its usable capacity. Each needs its own correctness and performance check. A larger worker fleet cannot substitute for that investigation.

Catching up is a different calculation from keeping up

Suppose we start recovery with the 120,000 unfinished jobs calculated earlier. Traffic now falls to 700 jobs per second, and the scaled system can sustain 1,000 successful completions per second.

It is tempting to divide 120,000 by 1,000 and declare that we will recover in two minutes. That calculation quietly assumes new work has stopped arriving.

But 700 of those 1,000 completions are needed just to keep up with new arrivals. Only 300 per second are available to reduce the backlog.

Our estimated catch-up time is therefore 120,000 divided by 300, or 400 seconds. That is six minutes and forty seconds in the constant-rate model.

If arrivals stayed at 1,000 per second, there would be no spare capacity to clear the accumulated work. If they remained above 1,000, the backlog would continue growing.

This estimate describes when the total backlog clears. It is not a prediction of an individual report’s waiting time or a p99 latency promise. Job sizes, scheduling, bursts, and startup delays all affect what particular users experience.

Try changing one assumption before moving on. If new arrivals fall to 400 per second, spare capacity becomes 600 and the same backlog clears in 200 seconds. I like this follow-up because it checks whether the reasoning survived after the first set of numbers disappeared.

Decide what happens before the backlog becomes a broken promise

Once we know the gap, we need a policy for work the system cannot finish on time. That decision belongs beside the capacity calculation, not after an optimistic autoscaling arrow.

For our report service, a reasonable starting proposal is to limit admission when the estimated delay exceeds the product’s agreed budget. A rejected request must receive a clear response rather than an accepted job ID that will never be honored. Already accepted reports still need a recoverable outcome.

Some products prefer to keep accepting work and tolerate longer delays. Others allow obsolete work to be cancelled or coalesced. Those choices depend on the contract; throwing away accepted work merely because a graph looks uncomfortable is not a recovery strategy.

Amazon’s discussion of queue backlogs describes the recovery risk of accumulated work and the importance of measuring message age. It is useful context for why a queue’s durability does not remove its latency trade-off.

For the report example, I want a small operational picture that answers concrete questions.

Track arrivals and successful completions in jobs per second so the widening or narrowing gap is visible.
Track the age of the oldest waiting job and end-to-end completion latency so waiting users do not disappear behind a depth chart.
Track queued, in-flight, and failed work separately so moving messages around does not look like finishing them.
Track dependency latency and saturation alongside worker utilization so scaling follows the actual constraint.

A queue of 1,000 tiny reports and a queue of 1,000 huge reports are not equivalent. Count is useful, but the amount of work and the age of that work matter too.

Bring retries back into the picture carefully

We excluded retries from the arithmetic because they deserve their own line in the answer. A failed attempt still uses resources, and a retry can use them again without adding a new user job.

Suppose the database starts timing out and workers immediately retry. Attempt traffic can rise even while successful completion throughput falls. Looking only at how busy the workers are would be terribly flattering to the wrong metric.

Bound retry attempts or elapsed retry time, apply suitable backoff, and keep failures visible. If a job is moved to a dead-letter queue for investigation, it has not become a successfully generated report. Define who owns recovery and what the user sees.

Also separate throughput from correctness. If delivery can happen more than once, the report’s externally visible effects still need duplicate protection. Processing the same job twice does not create two units of useful customer progress.

Practise the explanation without hiding behind the diagram

Take one background-processing problem from this interview question collection, then add your own explicit arrival rate, worker rate, and dependency ceiling. Keep your assumptions separate from the original prompt.

Explain how fast unfinished work grows, whether scaling changes the limiting resource, and how long recovery takes while new work continues to arrive. Finish by describing what happens to accepted jobs when the waiting-time budget is exceeded.

For our scenario, the answer is concrete. Forty workers finish 800 jobs per second, so five minutes at 1,200 arrivals creates 120,000 unfinished jobs. Doubling workers helps, but the database caps completions at 1,000. When arrivals fall to 700, the backlog takes 400 seconds to clear under our assumptions.

That is a much more defensible design conversation than adding workers and hoping the queue feels better about it.

I still want the queue in the architecture when it serves the contract. I just want the recovery calculation beside it, because storing a promise and keeping it are two different pieces of engineering.

~ Emily

I Don’t Trust AI-Written Tests Until They Fail for the Right Reason

Emily Woods — Tue, 10 Nov 2026 07:08:38 +0000

A small way to check whether your tests protect the requirement or simply agree with the code in front of them.

Your coding assistant finishes the function, writes the tests, runs them, and hands you a lovely green result. Honestly, that is a very tempting moment to close the tab and feel productive.

But I want to know what would make those tests turn red.

If the implementation misunderstood the requirement and the tests repeated that misunderstanding, they can agree with each other beautifully. Meanwhile, the user still gets the wrong result. A second file is not automatically a second opinion.

This is not a reason to stop asking AI for tests. It is a reason to give those tests something specific to disagree with.

Before trusting a passing suite, deliberately introduce one small, meaningful mistake and check whether the right assertion catches it. Then restore the correct code and run the tests again.

Let’s make that less abstract with a shipping calculation small enough to check without trusting anyone’s confident explanation, including mine.

Start with the rule before reading the implementation

For this original example, imagine a shop with a deliberately simple shipping policy. Orders below 5,000 cents pay 499 cents for shipping. Orders at or above 5,000 cents receive free shipping. Negative subtotals are invalid and must raise ValueError.

Assume the input is already an integer number of cents. Currency conversion, discounts, taxes, and input parsing are outside this little function’s job.

Notice that the rule gives us an expected answer at exactly 5,000 cents. Free shipping starts there, not one cent later.

I prefer writing that down before looking at the generated code because it keeps the code from quietly becoming the specification. If the policy is unclear, resolve the ambiguity first; no testing trick can decide what the business meant.

Here is a correct implementation for the stated rule.

def shipping_cents(subtotal_cents):
    if subtotal_cents < 0:
        raise ValueError('subtotal must be nonnegative')
    return 0 if subtotal_cents >= 5000 else 499

Now imagine the proposed tests check that a 1,000-cent order pays 499 cents and a 6,000-cent order pays zero. Both pass, as they should.

Those tests are useful, but they leave a particularly interesting customer standing between them.

Change one character and watch what stays green

In a disposable local copy, change the final comparison from >= 5000 to > 5000. Leave everything else alone.

The 1,000 cent test still passes. So does the 6,000-cent test. Neither input asks the function what happens exactly at the threshold.

But a customer spending 5,000 cents now pays 499 cents when the policy promises free shipping. We introduced a real behavior change, and the original pair of tests did not object.

This is the part I find useful. We have moved from vaguely wanting better tests to naming an exact mistake the tests currently allow.

Add an assertion whose expected result comes from the policy.

assert shipping_cents(5000) == 0

Run it while the incorrect comparison is still present. It should fail because the returned fee is 499 instead of zero. Then restore >= and confirm that the same assertion passes.

A syntax error, broken import, or missing dependency would also produce a red run, but none of those would show that our boundary assertion caught the shipping bug. Read the failure, not just its color.

One caught bug is evidence, not a certificate

Now try a different intentional mistake, again starting from the restored correct implementation. Remove the negative-subtotal guard.

The original two tests still pass. Even the new 5,000-cent test passes. A boundary test for free shipping does not automatically protect invalid-input behavior.

So add a separate check that a negative subtotal raises the promised exception. Here is a compact version using Python’s standard test library, alongside the nearby valid values.

import unittest
class ShippingTests(unittest.TestCase):
    def test_fees(self):
        for subtotal, expected in [(0, 499), (4999, 499),
                                   (5000, 0), (5001, 0)]:
            with self.subTest(subtotal=subtotal):
                self.assertEqual(shipping_cents(subtotal), expected)
    def test_negative_subtotal(self):
        with self.assertRaises(ValueError):
            shipping_cents(-1)

Put this below the function in a file named test_shipping.py, then run python -m unittest -v test_shipping. Keep the function and test class at the top level of the file.

The expected values are intentionally written out. Calculating them with another copy of the production comparison would risk reproducing the same mistake inside the test.

I checked these outcomes against the original and both altered versions. The original pair of tests misses both mistakes. The expanded checks catch the threshold change and the removed guard, while passing against the correct version.

That is a result for this tiny fixture, not a claim about every AI assistant or a guarantee that the function has no other problems. Different mistakes need different evidence.

Give the assistant a review task with an observable finish

An instruction to add comprehensive tests sounds reassuring, but comprehensive is doing an awful lot of work there.

Try a more concrete brief instead. Give the assistant the requirement, ask it to list expected outcomes before inspecting the implementation, and ask which plausible incorrect implementations each test would reject.

For the shipping example, the review brief can be this small.

Derive the expected fees at 4,999, 5,000, and 5,001 cents from the written policy.
Check that a negative subtotal raises ValueError without depending on the exact wording of the message.
Change only the threshold comparison and identify the assertion that fails because of it.
Restore the function, remove only the negative-input guard, and identify the exception check that fails.
Restore the correct version again and show the final passing test output.

You still need to inspect the proposed expectations and the actual result. An assistant saying it verified the change is not the same as seeing which command ran, which test failed, and why.

For a bug fix, this can be even simpler. Run the regression test against the known buggy version and the fixed version. It should expose the intended bug in the first and pass in the second. Make sure it fails for the behavior you meant to fix, rather than for an unrelated incompatibility between versions.

Keep the experiment small enough to understand

This approach is closely related to mutation testing, where tools deliberately alter code and check whether tests detect the changes. PIT’s explanation also makes an important distinction between a detected mutation, a surviving mutation, and code that no test reached.

Some mutations do not change the behavior that matters, so a survivor is a reason to investigate rather than an automatic demand for another test. Chasing a perfect score can become a very elaborate way to avoid thinking about the requirement.

You do not need to install a mutation-testing tool to try the manual version on one small function. Tooling becomes more useful when you want to repeat the process across more code; the small example is about learning what evidence to look for.

Keep each fault isolated. Start from a passing baseline, make one change, inspect the result, and restore the original before trying the next one. Use a local practice copy or a disposable branch so an intentionally broken version cannot slip into your actual work.

For a first session, choose one small function with a clear output. Check a boundary, an invalid input, and one meaningful alternative result. Stop once you can explain what each assertion protects; a growing test count is not the goal.

If you need a fresh starting point, choose a small problem from this practice question collection and write the expected outcomes before opening a solution. Then make one plausible mistake and see whether your own checks notice it.

Leave with a review note you can defend

For this example, the useful summary is that the original checks missed the exact threshold and negative-input behavior. The added assertions caught those two deliberate faults, and the restored implementation passed them.

That says considerably more than tests added, all green.

In an interview, this gives you a concrete way to explain your verification. During a code review, it gives the next person a reason to trust the specific behavior you checked. Neither requires pretending that a handful of tests proves the entire system correct.

I still want AI to help with the repetitive parts. I just want the final green result to mean more than the implementation and its tests agreeing with each other.

Give the tests a believable mistake to catch, and make them earn a little of that confidence.

~ Emily

SQL Interview Question: MAX(created_at) Doesn’t Return the Latest Order

Emily Woods — Tue, 10 Nov 2026 07:08:37 +0000

Finding the newest timestamp is easy. Keeping the right row, handling ties, and putting the filter in the right place takes a little more care.

Someone asks for the latest order for each customer, and your brain happily reaches for GROUP BY and MAX.

Honestly, fair enough. The question practically waves a little flag at an aggregate function.

Then the interviewer asks for the order ID, its status, and the amount. Two orders have the same timestamp, and one customer’s newest order is cancelled. Suddenly, finding the latest time is only a small part of the job.

I prefer treating this as a row-selection problem before treating it as a SQL problem. We need to decide which complete record wins, not collect impressive-looking values from different records.

Let’s work through a small original example, then change one sentence in the requirement and watch the answer change with it. There is no giant dataset to hide behind here, which is rather convenient for catching our own assumptions.

Give yourself five rows that refuse to cooperate

Our orders table contains customer_id, id, created_at, status, and total_cents. Each order has a unique ID. Customer IDs, timestamps, and statuses are non-null, and all times shown below are on the same date.

Customer A has three orders. Order 11 was paid at 09:00 for 9,000 cents. Orders 12 and 13 both arrived at 10:00; order 12 is paid for 2,000 cents, while order 13 is cancelled for 3,000 cents.

Customer B has one paid order, ID 21. Customer C has one cancelled order, ID 31.

For the first requirement, return exactly one latest order for every customer represented in this table, regardless of status. If timestamps tie, choose the larger order ID. That tie-breaker is an agreed rule for this exercise, not a claim that a larger ID always represents a later real-world event.

Before writing anything, the expected winning IDs are therefore 13, 21, and 31.

Having that answer on paper makes the query much easier to judge. A plausible result is not enough; we already know which rows the contract requires.

MAX gives you a value, not the rest of its row

This query correctly answers which timestamp is greatest for each customer.

SELECT customer_id, MAX(created_at) AS latest_at
FROM orders
GROUP BY customer_id;

It does not answer which complete order to return. For customer A, two rows share that maximum timestamp.

Joining the result back to orders on customer and timestamp can return both. That may be correct if the request is to return every order tied for latest, but it does not satisfy our exactly-one-row rule yet.

Another tempting repair is to add MAX(total_cents) to the grouped query. Please trace that against customer A before trusting it. You get 10:00 and 9,000 cents, even though no order in the input contains that combination.

Each maximum was calculated independently. The result has quietly assembled a record that never existed, which is quite an achievement for such a short query.

Adding ordinary non-grouped columns is not a reliable solution either. PostgreSQL rejects this form when those columns are not functionally determined by the grouped columns. We need an explicit rule for selecting a row.

Rank the complete records, then keep the winner

Use a window function to number each customer’s orders. The first ordering field defines latest; the second resolves a tie.

WITH ranked AS (
  SELECT customer_id, id, created_at, status, total_cents,
         ROW_NUMBER() OVER (
           PARTITION BY customer_id
           ORDER BY created_at DESC, id DESC
         ) AS rn
  FROM orders
)
SELECT customer_id, id, created_at, status, total_cents
FROM ranked
WHERE rn = 1
ORDER BY customer_id;

For customer A, order 13 receives row number one, order 12 receives two, and order 11 receives three. The other customers each have one row, so their numbering starts at one too.

All the selected fields now come from the same record. We have not asked the database to guess which status belongs beside an aggregate timestamp.

PostgreSQL’s window-function tutorial explains that ROW_NUMBER numbers rows within a partition and that tied rows have an unspecified numbering order. That is why our unique ID belongs in the ordering clause when exactly one deterministic winner is required.

Also notice the final ORDER BY customer_id. Ordering inside the window decides how to assign row numbers; it does not promise the presentation order of the final result.

If the requirement changes to returning every row tied at the latest timestamp, the ranking rule changes too. A rank based on created_at alone can preserve those ties. Adding a unique ID to that ranking would separate the very ties you were asked to retain.

Moving one filter changes the question

Now suppose the request becomes latest paid order per customer.

We should exclude cancelled rows before ranking, so the eligible population contains only paid orders. In the previous query, add WHERE status = 'paid' immediately after FROM orders inside the CTE.

Customer A now returns order 12. Customer B still returns order 21. Customer C has no paid order, so C has no result under this version of the contract.

But here is a different request that sounds dangerously similar. Return each customer’s latest order, only when that latest order is paid.

This time, rank all orders first. Then use WHERE rn = 1 AND status = 'paid' in the outer query. Customer A disappears because A’s winning row is cancelled. Only customer B remains.

Both queries run. Neither needs to throw an error. They answer different questions because one filter determines who may compete, while the other checks the winner after the competition.

That is the sentence I want to be able to explain in an interview. Memorizing the window-function syntax helps, but it cannot decide which population the business meant.

Keep the missing customer when the requirement asks for them

So far, our population comes from orders. A customer with no orders is invisible, and a customer with no eligible paid order disappears when we filter before ranking.

If the output must contain every customer, start from a separate customers table and left join the selected order onto it. Keep rn = 1 in the join condition or in a prefiltered winners relation.

Putting WHERE ranked.rn = 1 after that left join removes the null-extended rows, so customers without a match disappear again. That would undo the inclusion rule you were trying to implement.

Decide how to represent the absence of an order. Null order fields mean no match; a made-up zero amount would blur that distinction with a real zero-value order.

If timestamps can be null in the actual dataset, define their meaning before removing our non-null assumption. Unknown time is not automatically the oldest or newest event, and default null ordering differs across databases.

Make the counterexamples do the reviewing

The quickest useful check is to compare the exact selected IDs and their associated values, not just the number of output rows.

For this dataset, the three versions should produce these results.

Latest order regardless of status returns A → 13, B → 21, C → 31.
Latest paid order returns A → 12 and B → 21.
Latest order, only if paid, returns B → 21.

Then add a customer with no orders, create another timestamp tie, and change which tied row is paid. If your query still matches the written rule, you have better evidence than a clean run on a perfectly polite dataset.

For production data, inspect the execution plan rather than promising that a window function is automatically cheap. An index beginning with (customer_id, created_at DESC, id DESC) may help the ordering access path, but filters, row counts, selected columns, and the database planner still matter. This all-customer query may process many rows even when it returns few.

For a useful next variation, try this salary-history and top-earner exercise. It asks you to identify the latest employee-department record before choosing the highest-paid employee in each department. That adds a second selection stage, so getting the first population right becomes even more important.

I like leaving this kind of practice with a small question I can reuse. Am I calculating a property of a group, or selecting a particular member of that group?

Once that distinction is clear, the query becomes much easier to explain. More importantly, every timestamp, status, and amount in the answer can point back to the row that actually earned its place.

~ Emily

Backend Interview Question: Why Does Page 2 Repeat an Order From Page 1?

Emily Woods — Tue, 10 Nov 2026 07:08:36 +0000

One new order can break an apparently correct endpoint. Here is how to trace the bug, write a cursor query, and explain the guarantee honestly.

You open an orders page, read three rows, and click Next. One of those orders appears again.

Naturally, you suspect the frontend. Maybe the component appended the wrong response, or perhaps a retry slipped through. Those are reasonable possibilities, but imagine the network response itself contains the repeated order.

Now the backend gets its little moment of attention.

Both requests succeeded. Both queries returned three rows. Nobody inserted a duplicate order into the database, and yet the customer is looking at one twice.

This is the kind of interview problem I like because the SQL can look completely reasonable while the behavior is wrong. The interesting question is what page two means when the data changes after page one.

Let’s use an original practice scenario with a tiny order history, then build an answer that handles the follow-ups without pretending a cursor freezes time.

First, make the bug small enough to see

Suppose we list a customer’s orders newest first, three at a time. Initially, their IDs appear in this order.

106, 105, 104, 103, 102, 101

For this first illustration, larger IDs happen to belong to newer orders. We will use an explicit timestamp and ID together in the actual query.

Page one returns 106, 105, 104. The next request uses LIMIT 3 OFFSET 3, which means skip three rows in the result available to that request, then return three.

Before that request runs, a new order arrives at the front.

107, 106, 105, 104, 103, 102, 101

Skipping three now skips 107, 106, 105. Page two returns 104, 103, 102, so order 104 makes another appearance.

The database followed the instruction correctly. We asked it to skip positions in a changing list, not continue after the order the customer had last seen.

Deletion produces the opposite surprise. Start again with the original six rows and the same first page. If order 106 disappears before the next request, skipping three rows in the remaining list skips 105, 104, 103. Order 103 never reaches the customer.

Deduplicating responses in the browser can hide the repeated order, but it does not recover that missing one. Before adding a client-side patch, find out which guarantee the API is supposed to provide.

A stable order fixes one problem, not both

Every page needs a predictable order. Sorting only by creation time leaves a tie whenever two orders share that timestamp.

Use a unique tie-breaker, such as ORDER BY created_at DESC, id DESC, and define both fields as non-null. For this example, creation time and ID are immutable, and ID is unique.

PostgreSQL’s LIMIT and OFFSET documentation explains why a predictable ordering matters and notes that skipped rows still have to be computed. Deep offsets can therefore add work as well as create awkward navigation behavior.

However, even a perfectly deterministic order does not prevent rows from moving to different positions after an insertion. The repeat we just traced survives the tie-breaker because the list itself changed.

I like separating those two issues in an interview. We need an unambiguous order, and we need a continuation rule that does not depend on how many rows happen to precede us now.

Continue after the last row you actually returned

For forward browsing, save the ordering values of the last returned row. If that row has creation time 10:00 and ID 104, the continuation boundary contains both values.

The next page asks for rows strictly after that boundary in our descending order. That means an earlier timestamp, or the same timestamp with a smaller ID.

Here is a PostgreSQL query using bound parameters. $1 is the authenticated customer's ID, $2 and $3 are the decoded cursor timestamp and ID, and $4 is the server-validated page size plus one.

SELECT id, created_at, total_cents
FROM orders
WHERE customer_id = $1
  AND (created_at, id) < ($2, $3)
ORDER BY created_at DESC, id DESC
LIMIT $4;

The tuple comparison matches the descending ordering because both columns use the same direction. If you change the sort directions or allow nulls, revisit the predicate rather than copying this one unchanged.

For the first page, omit the boundary condition. With a page size of three, fetch up to four rows. Return the first three; the extra row tells you whether another result existed at that moment.

Build the next cursor from the last row returned, not from the extra row you withheld. Otherwise, the next request skips a row before the customer has ever seen it. A later request may still be empty if data was deleted meanwhile, so has_more is not a reservation of future results.

In our insertion example, a new order before the saved boundary no longer changes which older orders follow it. Page two continues with 103, 102, 101.

Also, deleting the boundary row does not have to break navigation. The cursor holds its ordering values, so the query can compare against them without finding that row again.

Make the cursor a continuation token, not a permission slip

The token needs enough information to preserve the traversal. Include a format version, the timestamp at its original precision, the ID, and the relevant filter and sort identity. Treat large IDs carefully when encoding them for clients that cannot represent every integer exactly.

If the customer changes a filter, start a new traversal or reject a cursor from the old one. Continuing a paid-orders query with a cursor created for all orders is a different contract, even if the SQL still runs.

An opaque, integrity-protected token can prevent clients from casually changing its contents. Base64 alone is only an encoding. Regardless of the token format, derive the customer scope from authentication and apply authorization on every request; do not trust a customer ID inside a cursor as access permission.

For this query, a candidate B-tree index is (customer_id, created_at DESC, id DESC). It puts the customer restriction before the ordered boundary, allowing an appropriate plan to seek near the cursor instead of walking through a large offset.

That is a design candidate, not a promise that every production query will be fast. Check the query plan and representative data, especially if extra filters discard many rows. Selecting wide columns or adding joins changes the work too.

Offset pagination still has a place when the dataset is small or stable and jumping directly to a numbered page matters. A forward cursor does not offer cheap arbitrary page jumps. Choose the navigation behavior deliberately instead of treating one technique as universally superior.

A cursor cannot promise a snapshot it does not have

Here comes the follow-up that makes the answer more useful.

Suppose the product team now wants a complete export of every order that existed when the user started. No additions, no disappearances, and values as they were at that moment.

Our live cursor does not provide that.

With immutable sort keys and fixed filters, keyset pagination avoids the position-shift duplicate we traced. But a newly inserted, backdated row behind the cursor can still appear later. A new row ahead of the cursor will not appear during the remaining forward traversal. Deleted rows can disappear.

If you instead sort by a mutable field such as last-updated time, an existing row can cross the boundary. Depending on the direction of that move, it may be missed or returned again.

For a fixed export, define a snapshot mechanism or materialize the result the job will export. Saving only IDs preserves membership, not necessarily the original values; a point-in-time export needs those values or a way to retrieve their historical versions too.

A start-time cutoff can exclude some later inserts, but it is not a complete snapshot when timestamps can be backdated, rows can be deleted, or values can change. Long-lived database snapshots also have operational costs, so avoid holding a transaction open simply because a human might click Next eventually.

This is why I prefer explaining the browsing promise before choosing a pagination strategy. A live order history and a reconciliation export can look almost identical on a screen while requiring very different guarantees.

Test the boundary instead of staring at the happy path

Start with six rows, fetch a page, and save its cursor. Then change the data before asking for the next page.

Insert a newer row and confirm that the original first-page rows do not repeat during forward traversal.
Give multiple rows the same timestamp and confirm that the ID tie-breaker returns each eligible row in the correct order.
Delete a row before the boundary, then delete the boundary row itself in a separate test. Neither case should require guessing a new offset.
Change the filter and verify that the API resets the traversal or rejects the mismatched cursor according to its contract.

Also test an empty result and an exact page-size result. The latter should not advertise another page merely because you returned three rows; that is why we fetched the extra one.

For practice, extend this paginated list and API exercise with the same tiny dataset. Define what its second page promises while you test insertion, deletion, and ties, then add loading states and backward navigation. This walkthrough covers the forward-query contract; the full exercise gives you room to design the surrounding UI too.

My goal is to leave the conversation with an explanation of what the user will observe, not just a query containing the word cursor somewhere nearby.

Once you can trace that repeated order all the way from the data change to the response, pagination stops being a small UI detail. It becomes a clear, testable agreement about how someone moves through changing data.

Follow along for learning more questions and how to actually solve them.

~ Emily

System Design Interview: Your Cache Is Fast. Is It Allowed to Be Wrong?

Emily Woods — Tue, 10 Nov 2026 07:08:34 +0000

Before drawing Redis into another architecture, trace one price change through the system. The interesting part happens after the write succeeds.

Imagine finishing a beautiful system design diagram, complete with a cache that makes product pages wonderfully fast.

Then someone changes the price of a product from $20 to $25. Your database stores the new price, the update succeeds, and a customer still sees $20.

Okay, perhaps that is acceptable while they browse. But now the same customer clicks Buy, and your checkout trusts the cached price too.

Suddenly, the conversation has moved from milliseconds to money, and the little Redis box needs a much better explanation.

I care less about whether an interview answer includes a cache than whether it explains what happens when that cache is wrong. That explanation can be surprisingly concrete, and you do not need to recite every caching strategy to make it useful.

Let’s work through one small shopping example and build an answer that survives a write, an awkward race, and a cache outage. This is an original practice scenario, not a claim about a particular company’s interview.

Start with the promise the customer can actually notice

Before choosing an expiration time, separate browsing from purchasing.

For this example, suppose the product team accepts briefly outdated information on a browsing page, with a clear warning if the final price changes. At checkout, however, the system must validate the applicable price and reserve available stock through the authoritative purchase path.

That is a proposed product contract. Another product might honor a time-limited quote instead, which would require its own quote identity, expiry, and validation rules.

Either way, a cache should implement the promise you chose. It should not accidentally choose the promise for you.

Now name the value you want to cache. A product description, a displayed price, an inventory count, and permission to purchase are different things, even when the UI puts them on the same card.

You might cache the description for longer than the price. You might show approximate availability while validating the actual reservation transactionally. You should not treat a cached inventory count as permission to sell the final item to two customers.

This is also where the cache key deserves a sentence. If a displayed price varies by currency, region, or customer agreement, a key containing only the product ID can return the wrong answer even when it is perfectly fresh.

My scratchpad therefore starts with the cached value, who can share it, how old it may be, and which decisions must use authoritative state. Redis comes after those choices.

Walk through the ordinary path before adding cleverness

Consider a simple cache aside design for public browsing data.

On a read, the application checks the cache. A hit supplies the browsing response. On a miss, the application reads the database and stores a copy with an expiration time.

On an update, the application commits the new value to the database and then invalidates the relevant cache entry. The next cache miss loads the value again.

Microsoft’s cache-aside guidance describes this general pattern and explicitly notes that it does not guarantee consistency between the cache and the data store.

That caveat is the part worth practicing. A sensible-looking sequence is not the same as a correctness guarantee.

Even the order of the write and invalidation matters. If you delete the cache entry before committing the database change, a reader can refill the empty cache from the still-old database value.

Committing first avoids that particular sequence, but there is another one waiting for us.

Let one slow reader interrupt the happy path

Suppose the cache entry is missing and two requests overlap. One request reads the product; the other updates its price.

The reader misses the cache and starts a database read.
That read obtains the old price of $20, but the reader pauses before filling the cache.
The writer commits the new price of $25.
The writer deletes the cache entry and completes its update.
The reader resumes and stores its earlier $20 result in the cache.

We deleted after the write, exactly as planned, and still put the old value back.

Nothing in this example requires a replica to lag. The reader already had an old result in flight. A lagging replica can introduce additional stale reads, but this race exists even when that complication is absent.

An expiration time helps the stale entry disappear eventually. It does not cancel the request that created it. If the old value arrives late and receives a fresh TTL, its age since the underlying update can exceed the TTL you proudly wrote on the diagram.

So avoid promising that a 30-second TTL means every response is at most 30 seconds behind a committed change. That promise needs more assumptions about read freshness, in-flight work, and when the expiration clock starts.

This is the moment where I prefer drawing a timeline to adding another technology logo. Five arrows can reveal more than five minutes of vocabulary.

Choose a repair that matches the promise

For our browsing example, accepting some staleness may be the right decision. Use a suitable expiration policy, make failed invalidations observable, and retry invalidation reliably if the design requires it. Describe the remaining race instead of calling the system strongly consistent.

For checkout, this proposal does something deliberately simpler. It does not let the browsing cache authorize the purchase. The purchase operation validates the applicable price and reserves inventory against authoritative state, with concurrency control that prevents overselling. If that operation cannot safely complete, it should not pretend an old cache value is a successful reservation.

Notice that reading fresh stock and then decrementing it later would still leave a race. The validation and reservation need to participate in the purchase system’s atomic operation or equivalent concurrency protocol.

If the interview requires stronger behavior from cached reads themselves, then the design needs more machinery. Version checks can reject older cache fills, but only when the comparison is atomic and the freshness marker survives the races you are trying to prevent. Deleting a value and losing its version does not magically protect the next fill.

You could also coordinate readers and writers, but now explain lock scope, expiry, failure recovery, and the cost of waiting. Naming a distributed lock is the beginning of that explanation, not the end.

For this scenario, I prefer a clear split between a fast browsing view and an authoritative purchase decision. It solves the stated product problem without claiming that every read in the application has the same requirements.

Work out what happens when the cache disappears

Another tempting answer is that the application will simply fall back to the database.

Let’s put numbers next to that sentence. Suppose the browsing service receives 10,000 reads per second and its cache hit rate is 99%. In this simplified example, about 100 reads per second reach the database.

If every request falls through during a cache outage, the database could receive 10,000 reads per second instead. That is up to 100 times the normal read load, before considering retries or other traffic.

Fallback needs a capacity decision. Bound the number of database requests in flight, set timeouts, and reject or degrade browsing requests when the allowed load is exhausted. If you serve an older copy during a failure, that must fit the browsing contract and requires a copy that remains accessible.

When a popular key expires, coalescing concurrent misses can let requests share a fetch instead of starting identical database work. Be precise about scope, though. Coalescing inside one process still allows one fetch per process, and the waiting requests need limits too.

Spreading expiration times can reduce many different keys expiring together. It does not, by itself, stop a crowd from requesting one missing hot key.

Track hit rate alongside miss latency, database load, invalidation failures, and evidence of stale responses. A high hit rate can look lovely while the cache confidently serves the wrong answer.

Turn the explanation into a test you can actually run

You do not need a large deployment to practice this reasoning. A small test harness with controllable pauses is enough to expose the refill race.

Pause a reader immediately after it obtains the old database result. Run the writer through its commit and invalidation. Release the reader, then inspect what the next request returns.

That gives you a repeatable interleaving, rather than a test that hopes the scheduler produces a bug on the hundredth run.

For the browsing policy, check whether the resulting stale response is permitted and how it eventually recovers. For checkout, submit a purchase after the price change and verify that the cached browsing value does not decide the accepted price or stock reservation.

Then make the cache unavailable and send concurrent requests. Check that database concurrency stays bounded and that rejected or degraded requests follow the behavior you promised.

For your next practice session, choose a read-heavy system from these practice questions and explain just one cached value. Trace its read, its update, and its failure path before expanding the architecture.

I want to be able to point at the diagram and explain who might see an old value, why that is acceptable, and which operation refuses to trust it.

Once those answers are clear, the cache box finally earns its place. Until then, we have made the picture faster without deciding whether the customer can trust the result.

~ Emily

I Can Solve the Question. So Why Do I Freeze on the Follow-Up?

Emily Woods — Tue, 10 Nov 2026 07:08:33 +0000

One familiar problem, three changed requirements, and a practice routine for the moment your memorized answer runs out.

Getting the first solution right can make the next question feel weirdly personal. You were explaining everything so confidently a minute ago, and now someone has changed one requirement and your lovely little hash map suddenly needs a lawyer.

I don’t think the useful response is to panic and add another fifty problems to the queue. Sometimes the missing practice is much smaller. We learned how to reach an answer, but stopped before learning which assumptions were holding it up.

Try this before reading further. You have an array of numbers and need two different positions whose values add up to a target. You know the usual hash-map approach. Now the task changes, and you must count every valid pair of positions instead of returning one pair.

For [1, 1, 3, 3] with a target of 4, is the answer one, two, or four? More importantly, what information does your original solution throw away?

That is the small gap we’re going to practise. No new stack, enormous roadmap, or heroic weekend required.

Your first solution has a contract, even if you never wrote it down

For our starting version, assume an unsorted array, exactly one valid pair, and permission to use extra memory. Return the two indices without reusing an element.

Scan from left to right. Before storing the current value, look for its complement among the values you have already seen. If it is there, you have your pair. With ordinary hash-map assumptions, that takes expected O(n) time and O(n) extra space.

Notice what makes the solution comfortable. You can stop after the first match. One saved index per value is enough. Keeping previous values in memory is allowed.

Those details are the handles a follow-up can pull on. I prefer writing them beside the solution because otherwise the code starts to look more universal than it actually is.

Before changing any code, name what changed, preserve what still works, and find a tiny example that exposes the difference. That gives you something useful to do while your brain catches up.

Count every pair, and the missing information becomes obvious

Back to [1, 1, 3, 3]. Label the positions 0, 1, 2, 3 and the valid pairs are (0,2), (0,3), (1,2) and (1,3). We are counting pairs of positions with the earlier index first, so the answer is four.

If the interviewer means unique pairs of values instead, the answer is one. That clarification belongs before the implementation. You can write perfectly good code for the wrong definition of a pair, which is a very annoying way to spend ten minutes.

For position pairs, a map that remembers only one index for each value has forgotten something important. When the first 3 arrives, it can pair with both earlier 1s.

We still need the complement lookup and the left-to-right scan. What changes is the information in the map. Store a frequency for each previous value, and add the complement’s frequency to the answer.

def count_pairs(nums, target):
    seen = {}
    total = 0
    for value in nums:
        total += seen.get(target - value, 0)
        seen[value] = seen.get(value, 0) + 1
    return total

Look up first, then increment. That order means the map contains only earlier positions, so the current element cannot pair with itself.

After the two 1s, the map holds a frequency of two. Each subsequent 3 contributes two more pairs. For [2, 2, 2] and target 4, the contributions are zero, one and two, giving three pairs rather than nine.

Expected running time remains O(n), with O(u) map space for u distinct values. Returning all the pairs would be a different requirement again. The output itself can contain O(n²) pairs, so counting them and listing them cannot share the same blanket performance promise.

This is why I like practising with tiny inputs. Four numbers revealed the ambiguity, the missing state and the update order. A large random test might give you a red result without explaining any of that.

Sorted input changes the opportunity, not just the example

Reset to finding one pair. This time, the input is already sorted and you are asked to use constant extra space. Suppose [1, 2, 4, 7] has target 6.

Place one pointer at each end. The first sum is eight, which is too large, so move the right pointer left. Now the sum is five, so move the left pointer right. Two plus four gives the target.

The explanation matters more than the pointer vocabulary. If the sum is too small, pairing the current left value with any smaller right value cannot help. Sorted order lets us safely discard that left position. The reverse argument applies when the sum is too large.

We get O(n) time and O(1) auxiliary space because the array is already sorted. If you sort an originally unsorted input yourself, you must account for sorting costs and preserve original indices when the output requires them.

So the useful response to this follow-up is not immediately reaching for a different memorized template. First identify the new guarantee, then explain which search space it lets you eliminate.

A stream changes what you are allowed to forget

Now imagine numbers arriving one at a time, and you need the running count of all pairs seen so far. The frequency-map version still works. Each new value contributes the number of matching earlier values before its own count is added.

But there is a catch worth saying out loud. Streaming does not automatically mean constant memory. With unrestricted values, this map can keep growing as new distinct values arrive.

If the follow-up also limits memory, clarify the value range and whether only a recent window matters. A small bounded range can support a fixed-size frequency array. A last-k-items window needs expiration rules and bookkeeping. Those are changed contracts, not free optimizations for the original all-history problem.

This is a useful place to be calm about uncertainty. You can explain that the current approach remains correct, identify its growing memory cost, and ask which restriction the revised task actually provides.

Give yourself a recovery routine before you need one

When a follow-up feels slippery, take it through four moves. Think of this as a practice scaffold, not a script you have to perform word for word.

Restate the changed requirement. For the counting version, clarify whether different positions count separately. Keep unchanged requirements visible too.
Find the smallest revealing input. Repeated values expose the difference between one saved index and a frequency. Pick an example whose answer you can justify without running code.
Keep the reasoning that survived. Complement lookup still helps. Stopping at the first match no longer does. Change the information you retain before rewriting everything.
Check the revised cost and failure case. Explain time, memory and output size, then test the edge that motivated the change.

In a conversation, those moves can flow naturally. We now need every pair of positions, so duplicate values matter. The complement lookup is still useful, but one index per value loses matches. I’ll store frequencies and check before adding the current value so an element never matches itself.

That explanation gives the interviewer a clear line to follow, even before you finish typing. It also gives you a way back into the problem that does not depend on instantly recognizing its name.

Make your next practice session slightly less comfortable

Spend twenty minutes on a problem you already understand. Familiarity is useful here because it leaves room to practise the change rather than spending the entire session discovering the baseline.

For the first five minutes, solve the original version and write down its input guarantees, required output and memory allowance. During the next five, change exactly one requirement and construct a small example that makes the old answer insufficient.

Use the next seven minutes to adapt the approach, explain what you kept and test the revised behavior. Spend the final three writing one sentence about the assumption you missed. That sentence is more useful than a vague note to revise hashing again.

You can start with this Two Sum practice , then add the counting variation yourself. The linked problem is the baseline; the changed requirements in this essay are our practice extensions.

On the next session, choose a different kind of change. Make the input sorted, restrict memory, or ask for a running result. Don’t pile them together immediately, because then it becomes harder to tell which assumption caused the difficulty.

Judge the session by whether you can explain the change and defend the new solution. Finishing quickly is lovely, but recognizing why your original answer stopped being enough is the skill we came to practise.

I want my practice notes to contain more than solutions I can reproduce when the question behaves itself. I want them to show what I can keep when it changes, what I need to question, and how I can find my footing again.

Before closing your next solved problem, give it one follow up and stay for the slightly uncomfortable part. That is where the next practice session begins.

~ Emily