Google Software Engineer (Mid-Level L4) Interview Preparation Guide 2026

Direct answer
A thorough is_prime(n) test suite needs at least: a negative number, the two special small values 0 and 1 (neither prime nor composite by definition), the only even prime (2), an ordinary odd prime, an ordinary composite, and a large input that exercises the algorithm's actual loop bound rather than a value small enough that a broken implementation would pass by coincidence; each of these targets a distinct, plausible off-by-one or definitional bug in a typical trial-division implementation.

Structured elaboration

• Negative numbers: primality is only defined for positive integers greater than 1; a common bug is a modulo-based check that doesn't special-case negatives and returns a wrong answer instead of False.
• 0 and 1: both are explicitly NOT prime by the mathematical definition (a prime must have exactly two distinct positive divisors), but a naive "no divisors found" loop can accidentally return True for both, because a loop like for i in range(2, n) never executes for n < 2 and falls through to a default True.
• 2: the only even prime; a very common bug is an implementation that starts checking divisibility from 2 and then also SKIPS even numbers in its loop for performance, incorrectly excluding 2 itself before the loop even gets a chance to confirm it.
• A small odd prime and a small composite: baseline correctness on the values the function will overwhelmingly see in normal use.
• A large prime and a large composite with a large prime factor: this is the case that actually tests the algorithm's LOOP BOUND, not just its correctness. A correct trial-division implementation only needs to check divisors up to $\sqrt{n}$, because if $n = a \times b$ with both $a, b > \sqrt{n}$, then $a \times b > n$, a contradiction; testing a large composite whose smallest prime factor is itself large (so the loop must run nearly to $\sqrt{n}$ before finding it) is what actually exercises that bound, whereas a small composite like 9 would pass even with a badly wrong loop bound.

Worked example (executed)

def is_prime(n):
    if n < 2:
        return False
    if n in (2, 3):
        return True
    if n % 2 == 0:
        return False
    i = 3
    while i * i <= n:
        if n % i == 0:
            return False
        i += 2
    return True

Five (plus two extra) pytest tests were written and executed, covering exactly the cases above:

test_negative_number_is_not_prime        is_prime(-7) is False
test_zero_and_one_are_not_prime          is_prime(0) is False, is_prime(1) is False
test_two_is_prime_and_only_even_prime    is_prime(2) is True
test_small_known_primes                  is_prime(3) is True, is_prime(13) is True
test_small_known_composite               is_prime(9) is False, is_prime(100) is False
test_large_prime_performance             is_prime(999983) is True
test_large_composite_with_large_prime_factor   is_prime(999983 * 2) is False

Executed with pytest: 7 passed. The large-input test uses 999983 (a genuine prime, confirmed by the passing assertion) specifically because its smallest divisor other than 1 is itself, so the loop runs all the way to $\sqrt{999983} \approx 1000$ without finding a factor, exercising the loop-bound logic in a way that a small composite like 9 (whose smallest factor 3 is found almost immediately) does not. Per house rule, wall-clock timing was measured out of curiosity during this run but is deliberately NOT reported here, since timing is environment-dependent and unverifiable by a reader re-running the suite; the correctness assertion (is_prime(999983) is True) is what the test actually proves.

Trade-offs and pitfalls
The most common wrong turn is treating "performance considerations" as a wall-clock timing assertion (assert elapsed < 0.01), which is banned as a test design because it is flaky across machines and CI runners; the correct way to test performance-relevant behavior without asserting timing is to test the ALGORITHMIC boundary directly, as the large-prime test does here, by choosing an input specifically engineered to force the loop to its true upper bound rather than exit early. A second pitfall is conflating "large" with "slow": for trial division, a large NUMBER that happens to have a small factor (e.g. 999983 * 2, which is even) is fast to reject, while a large PRIME is the actually expensive case, so test data must be chosen by factorization structure, not just magnitude.

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Direct answer

I say what I did plainly, in public, as soon as I know it: exactly what action I took, why I thought it was safe at the time, and what it caused, rather than waiting for the review to surface it or letting someone else describe my part of it. In the review itself, I show up ready to name my own contribution accurately rather than downplaying it, and afterward I make sure at least one concrete change comes out of it with my name attached to actually driving it, not just discussed and left as an idea.

Structured elaboration

• Responding publicly: the incident channel gets a plain statement of what I did and why it's relevant to the current impact, as soon as I realize my action is connected, not after the review connects the dots for me. Waiting to be found out, even innocently because I was still investigating, reads very differently from surfacing it myself.
• Responding within the team: separately from the public incident channel, I talk directly with whoever is most affected or whoever needs to trust my judgment going forward, since a channel message doesn't replace an actual conversation about what happened and what I'm doing about it.
• Participating in the review: my job in the review is to give an accurate account of my own part, including the reasoning that seemed sound at the time, not a version softened to look more defensible in hindsight. A review only surfaces the real cause if the person closest to the mistake is precise about what actually happened, not vague about it.
• Driving concrete changes: the review producing a list of good ideas is not the same as those ideas happening. I pick the change most directly tied to my own mistake and personally drive it to completion, or, if it requires someone else, follow up until it's actually done, rather than treating the review meeting itself as the deliverable.

Worked example

I pushed a change that removed what looked like an unused feature flag (a runtime toggle for turning a code path on or off without a new deploy), based on a search that showed no active references to it in the current codebase. What I missed was that a separate scheduled job, not visible in the code search I'd run, still read that flag's value at runtime, and removing it caused that job to silently fall back to a default behavior that corrupted a batch of downstream records over several hours before anyone noticed.

As soon as I connected the corrupted records back to my change, I posted in the incident channel immediately: what I removed, why I believed it was safe, my search method and what it missed, and what I now suspected it had caused, rather than waiting for someone else's investigation to land on my commit. I also messaged the team that owned the scheduled job directly, since they were the ones who'd have to trust my future changes near their systems, and walked them through it before the formal review even happened.

In the review, I gave the exact account: I described precisely how I searched for references and why that method had a blind spot for scheduled jobs configured outside the main codebase, rather than a vaguer "should have checked more carefully." That precision is what let the group see the actual gap: our standard reference-search convention had never covered configuration-driven job definitions. I volunteered to own the concrete fix, updating the team's reference-search tooling so it also indexes job configuration files, not just application code, and I didn't consider it done when the review ended. I built it over the following days and validated it against three known cases where the old search would have missed a live reference, including the one that had just bitten me, confirming the new tooling actually caught what the old one hadn't.

Trade-offs and pitfalls

The easy version of this story stops at "I told people what happened," which is necessary but not sufficient; a candidate who only apologizes without precision about the actual gap in their reasoning or process gives the team nothing to fix. The harder, senior-discriminating part is being specific enough about your own blind spot that it becomes something structural to close, and then following through personally rather than letting "someone should fix the tooling" become an unowned action item that fades once the review meeting ends.

Direct answer

Break the estimate into three buckets, compute, storage, and network egress, state a small number of explicit assumptions for each (traffic shape, cache hit ratio, unit prices), and multiply through. For this workload, 1,000,000 requests/day and 10 TB of outbound data/month, the arithmetic below lands around 1,246 dollars/month using illustrative unit rates, with network egress the dominant line item. The one sanity check worth doing at the end is dividing total outbound data by total requests: it implies each request carries roughly 333 KB on average, which is large for a "simple web app" and should prompt asking whether the two given numbers actually describe the same traffic.

Structured elaboration

Why three buckets, always kept separate
Compute, storage, and network egress scale with different things (request rate, data volume at rest, data volume transferred), so lumping them together hides which one actually drives the bill. For a workload described mainly by a request count and an outbound-data figure, network egress is very often the surprise line item, since it scales with bytes moved, not with request count.

Stated assumptions (illustrative unit rates, not any specific vendor's current list price, so the arithmetic below is fully reproducible from these inputs alone):

• 1 TB = 1,000 GB for this estimate (a decimal convention, kept simple and stated once; real billing sometimes uses the binary definition instead).
• A 5x peak-to-average traffic ratio, a common assumption absent a stated diurnal profile.
• Compute: $0.10 per instance-hour; a minimum of 3 instances regardless of load, for basic redundancy and zero-downtime deploys.
• Storage: a flat $20/month (small, since a "simple web app" is not primarily a database- and storage-heavy workload).
• Network: 60% of requests served from a content delivery network (CDN) cache; origin egress (cache misses only) at $0.09/GB; CDN edge egress (all bytes delivered to users) at $0.06/GB.
• Miscellaneous (load balancer, monitoring, DNS): $50/month.

Worked example

Compute.

$\text{avg RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6, \qquad \text{peak RPS} \approx 11.6 \times 5 \approx 58$

Even one modest instance clears 58 req/s comfortably for a typical stateless web app, so the instance count here is driven by redundancy, not raw capacity: 3 instances.

$\text{compute} = 3 \times \$0.10/\text{hr} \times 24 \times 30 = \$216/\text{month}$

Network egress, the dominant cost for this workload. Two separate legs, both real: the cache-miss traffic the CDN pulls from the origin (pricier), and the full volume the CDN delivers to end users regardless of hit or miss (cheaper, volume-discounted).

$\text{miss traffic} = 10{,}000 \text{ GB} \times (1 - 0.6) = 4{,}000 \text{ GB}$

$\text{origin cost} = 4{,}000 \text{ GB} \times \$0.09/\text{GB} = \$360$

$\text{CDN cost (all delivered bytes)} = 10{,}000 \text{ GB} \times \$0.06/\text{GB} = \$600$

Total.

$\text{total} \approx \$216 + \$20 + \$360 + \$600 + \$50 = \$1{,}246/\text{month}$

Sanity check, the part the question explicitly asks for. Cross-check the two given numbers against each other, not just against the chosen unit prices:

$\text{requests/month} = 1{,}000{,}000 \times 30 = 30{,}000{,}000$

$\text{avg payload} = \frac{10{,}000 \text{ GB} \times 1000 \text{ MB/GB}}{30{,}000{,}000} \approx 0.33 \text{ MB} \approx 333 \text{ KB per request}$

A typical JSON API response is a few KB, not a third of a megabyte. A 333 KB average suggests this "simple web app" is actually serving images, downloads, or media, not just API calls, or that the two input numbers don't describe the same traffic, for instance if the 10 TB includes a batch export job outside the 1,000,000 daily request count. That is the real value of this sanity check: it isn't re-verifying the arithmetic, it's confronting whether the two numbers handed to you are internally consistent with the story you were told, before handing a stakeholder a dollar figure built on an unstated contradiction.

Trade-offs & pitfalls

• Pricing only one leg of egress (origin-to-CDN or CDN-to-user) and treating the network line item as done.
• Skipping the sanity check and presenting the total as precise when the underlying assumptions (cache hit ratio, peak ratio) were guesses; state which input the total is most sensitive to.
• Sizing compute purely off average load; for small-to-medium workloads, redundancy and deploy safety often set the compute line, not raw throughput math.
• What separates a senior answer: showing the arithmetic and stating which two given numbers were cross-checked at the end, and why, rather than presenting a total as if it fell out of a spreadsheet with no further scrutiny.

Direct answer
A short executive postmortem summary should fit in roughly 150 to 200 words and cover exactly four things: impact, root cause in one sentence, key corrective actions, and the expected timeline for completing them. Everything else belongs in the linked full postmortem, not the summary.

Structured elaboration
The discipline here is compression without losing the load-bearing facts: an executive reading this in thirty seconds should know what happened, how bad it was, why, and what's being done, without needing to ask a single follow-up question about the basics.

Worked example
"On [date], an autoscaling policy misconfiguration caused the checkout service to under-provision during a traffic spike, resulting in a three-hour partial outage. Approximately 15% of checkout attempts failed or timed out during the peak of the incident, affecting an estimated 40,000 orders; no customer data was exposed. Root cause: a recent change to the autoscaling policy set a maximum instance count too low for current traffic levels, and no alert existed to catch an autoscaling ceiling being reached. Immediate mitigation: on-call manually scaled the service within 12 minutes of detection, and full service was restored within three hours as the traffic spike subsided. Corrective actions: (1) raise the autoscaling ceiling to match current capacity planning, completed same day; (2) add an alert that fires when autoscaling hits its configured ceiling, targeted for completion within one week; (3) add autoscaling ceiling review to the quarterly capacity-planning process, targeted for next quarter. We expect all three actions complete within 30 days and will confirm the new alert has been validated against a synthetic test before considering this closed."

That's roughly 180 words and answers all four required elements without technical jargon an executive would need explained.

Trade-offs and pitfalls
The most common mistake is trying to also explain the full technical mechanism (why the specific autoscaling algorithm behaved this way) inside the short summary, which blows past the word budget and buries the four things that actually matter to this audience. A second is omitting a concrete timeline and just saying 'we are addressing this,' which reads as less credible than named actions with dates, even when the actions themselves are modest.

Direct answer

Python computes MRO (Method Resolution Order), the linear order in which base classes are searched for an attribute or method, using the C3 linearization algorithm. For class A, class B(A), class C(A), class D(B, C), the MRO is [D, B, C, A, object]: D first, then its bases left to right (B before C, matching the declared order in class D(B, C)), with A appearing only once, after both of its subclasses, never before either of them. This matters for super() because super() doesn't mean "my direct parent"; it means "whatever comes next in the MRO," so the MRO is what actually determines which implementation a chain of super() calls reaches at each step.

Structured elaboration

Why not just "depth-first, left to right" (Python 2's old classic-class behavior)? That naive rule would visit D, B, A, C, A, walking through A twice and, worse, visiting it in an order that puts it before C gets a chance to run first. C3 linearization fixes this with three constraints simultaneously:

1. A class always appears before its own base classes (local precedence).
2. The order bases were listed in a class definition is preserved (B before C in D(B, C)).
3. Any given class appears in the final MRO exactly once, at the position where all of the above constraints are still satisfiable (monotonicity).

Applied to the diamond A / B(A) / C(A) / D(B, C): D must come first (constraint 1). B must come before C (constraint 2, from D's base list). A must come after both B and C because it's a base of both, and neither B nor C can be reordered relative to each other or to A without violating a constraint. The unique linearization satisfying all of that is [D, B, C, A, object]. If the constraints were unsatisfiable (a genuinely contradictory base ordering across the hierarchy), Python raises TypeError: Cannot create a consistent method resolution order at class-definition time rather than picking an arbitrary order.

Why this matters for super() specifically: super() inside a method looks up "the next class after the current one in the instance's MRO," not "my declared parent class." In cooperative multiple inheritance (several mixins each calling super().__init__(...) to chain to the next one), the actual chain that executes depends entirely on the concrete class's MRO, which can differ from what any single class in isolation would suggest. This is what makes mixin-based designs (logging mixins, serialization mixins, resource-management mixins) predictable: as long as every class cooperates via super() rather than naming a base class directly, the MRO guarantees each one runs exactly once, in a well-defined order, regardless of how deep or diamond-shaped the hierarchy gets.

Worked example

class A:
    def foo(self):
        return "A"

class B(A):
    def foo(self):
        return "B"

class C(A):
    def foo(self):
        return "C"

class D(B, C):
    pass

print([c.__name__ for c in D.mro()])   # ['D', 'B', 'C', 'A', 'object']
print(D().foo())                       # B

D doesn't define foo itself, so attribute lookup walks the MRO starting right after D: B is the first class in that list that defines foo, so D().foo() returns "B", never reaching C.foo or A.foo at all for this particular call.

Trade-offs & pitfalls

• If B and C both call super().foo() instead of returning directly, the MRO is what makes D().foo() walk through B.foo() -> super().foo() reaching C.foo() next (not A.foo() directly), because C is the next entry after B in D's MRO. This cooperative-chaining behavior is easy to get backwards if you assume super() means "go to my own declared parent," since B's declared parent is A, but B's super() in an instance of D resolves to C.
• Declaration order in the base-class list is a real, load-bearing design decision, not an arbitrary detail: class D(B, C) and class D(C, B) produce different MROs ([D, B, C, A, object] vs. [D, C, B, A, object]) and therefore different behavior for both plain method lookup and super() chains, even though the two class hierarchies "look the same" if you only read class B(A) and class C(A) in isolation.
• A common wrong turn: assuming multiple inheritance always "just works" by mentally picking whichever base's method feels intended, and only inspecting Class.mro() after something behaves unexpectedly. Since MRO is computable and inspectable (D.mro() or D.__mro__) before you ever run the code, checking it up front for any non-trivial mixin hierarchy is cheap and removes the guesswork entirely.
• Not every base-class ordering is linearizable. A contradictory set of base classes (for example, inheriting from two classes that each demand a different relative order for a shared ancestor) causes Python to refuse to create the class at all, raising TypeError rather than silently picking an inconsistent order.

Situation: I needed the Support team to invest time in a new escalation process, but I had no formal authority over them.

Task: My job was to earn their support instead of asking for compliance.

Action: I started by learning what mattered to them. I met with the support manager and a few frontline agents to understand their pain points. The main issue was that they were already overloaded, so any new process had to save time, not add work. I then reframed my initiative in their language. Instead of talking about my project milestones, I showed how the change would reduce repeat tickets and make it easier to resolve customer issues on the first contact. I also offered a small pilot so they could test the idea before committing fully.

Result: Because I tied the request to their goals and reduced the burden, they agreed to participate and became active partners in the rollout.

What I learned is that influence comes from understanding the other function’s priorities, showing respect for their constraints, and making the benefit concrete.

Framing

This is a classic space-versus-time trade-off: precompute-and-cache pays a fixed memory cost to hold results ready, so every read is cheap, while compute-on-demand pays a repeated CPU cost every single time a result is needed but uses no extra memory. Which one is cheaper in dollars depends on how many times a cached value gets reused before it needs recomputing, weighed against cloud pricing for memory (billed per GB, whether or not it is being read right now) against vCPU time (billed roughly per unit of work actually done).

Worked example (one basis: illustrative cloud rates)

Say each ranking feature vector is 1 KB, and there are 10 million items, so the full cached set is about 10 GB. At an illustrative memory-optimized rate of $0.01 per GB-hour, holding that cache resident costs about $0.10/hour, regardless of how many times it gets read.

Computing a feature on demand instead takes, say, 2 milliseconds of CPU time. At an illustrative $0.04 per vCPU-hour, a single computation costs about $0.0000000222 (2ms is 2/3,600,000 of an hour, times $0.04). That looks tiny, but it is paid on every read, while the cache cost is paid once regardless of read volume.

Where the crossover is

Setting the two costs equal and solving for the read rate (queries per second, QPS) where they break even: at this compute cost per item, on-demand computation only matches the flat $0.10/hour cache cost at around 1,250 QPS sustained:

QPS x 3,600 sec/hour x $0.0000000222/computation = $0.10/hour
QPS = $0.10 / (3,600 x $0.0000000222) ~= 1,250
``` Below that read rate, compute-on-demand is cheaper, since you are not paying to hold memory mostly idle. Above it, caching is cheaper, since you are avoiding repeated compute on the same value over and over.

**How I'd measure and decide**

- Measure the real request rate against this feature, and measure the real per-item compute cost by timing the actual feature computation, not an estimate.
- Account for staleness: caching only works if the feature does not need to be freshly recomputed on every read, so factor in how often the underlying data changes and how expensive it is to refresh the cache versus how expensive it is to just always compute fresh.
- Recompute the crossover QPS whenever cloud pricing or the feature's compute cost changes, since both are exactly the two numbers the decision hinges on, and a hard-coded decision quietly goes stale.

Approach: create a debounce that returns a wrapped function and exposes a cancel method. Use a timer for delaying invocation and support immediate (leading) option and proper typing. Cancellation clears pending timer and prevents the scheduled call.

type Fn<T extends any[]> = (...args: T) => void;

function debounce<T extends any[]>(
  fn: Fn<T>,
  wait = 300,
  options: { leading?: boolean } = {}
) {
  let timer: ReturnType<typeof setTimeout> | null = null;
  let lastArgs: T | null = null;
  let calledLeading = false;

  const invoke = () => {
    if (lastArgs) fn(...lastArgs);
    lastArgs = null;
    timer = null;
    calledLeading = false;
  };

  const debounced = (...args: T) => {
    lastArgs = args;

    if (options.leading && !calledLeading) {
      fn(...args);
      calledLeading = true;
      // still start a timer to block trailing immediate repeat
      timer = setTimeout(() => {
        timer = null;
        calledLeading = false;
        lastArgs = null;
      }, wait);
      return;
    }

    if (timer) clearTimeout(timer);
    timer = setTimeout(invoke, wait);
  };

  debounced.cancel = () => {
    if (timer) {
      clearTimeout(timer);
      timer = null;
    }
    lastArgs = null;
    calledLeading = false;
  };

  return debounced as typeof debounced & { cancel: () => void };
}

Usage example (React-style input handler):

const fetchSuggestions = async (q: string) => { /* call API */ };

const debouncedFetch = debounce(([q]: [string]) => fetchSuggestions(q), 250);

function onInputChange(e: React.ChangeEvent<HTMLInputElement>) {
  debouncedFetch(e.target.value);
}

// To cancel (e.g., on unmount)
debouncedFetch.cancel();

Key points:

• Prevents excessive API calls by batching rapid events.
• cancel() avoids stale calls during unmount/navigation.
• Time complexity: O(1) per event; space: O(1).
  Edge cases: ensure cancellation on component unmount, handle leading vs trailing behavior, and pass latest args for trailing invocation.

Schema: events(event_id PK, tenant_id, event_time TIMESTAMP, event_type, payload JSONB, created_ts). Use tenant_id + event_time as primary query axis. Partitioning: multi-level: partition by tenant_id (if tenant count small/medium) or hash by tenant_id + subpartition by RANGE(event_time) monthly. For many tenants, use global time partitions and local tenant indexes. Indexing: clustered index on (tenant_id, event_time DESC) for fast latest-per-tenant; secondary index on (tenant_id, event_time) to support range scans; GIN index on payload if queried. Isolation: enforce tenant_id on every query via row-level-security policies or separate schemas per tenant for strict isolation. Consider separate physical databases for very large tenants. TTL/retention: drop old partitions. Benefits: queries scoped to tenant + time hit single partition and use sorted index for efficient range scans and latest-value retrieval while preserving tenant isolation.