Meta Senior Software Engineer (E5) Interview Preparation Guide

A canary deployment routes a small percentage of traffic to a new version while the rest continues on the known-good version, letting you observe real behavior on a limited, recoverable blast radius before a full rollout.

Using canaries to troubleshoot a suspected regression

Route a small, representative slice of a customer's traffic to the candidate version, monitor a fixed set of signals (error rate, latency, and the specific business metric suspected of regressing) against a control group receiving identical traffic on the old version, and set an automated rollback trigger (a threshold breach sustained for a defined window) rather than relying on someone watching a dashboard continuously. For example, a concrete version of this rule might route 5% of traffic to the candidate, then auto-rollback if its error rate exceeds 2% (versus a steady 0.3% baseline on the control) for any five consecutive minutes.

Extending the canary with automated RCA collection

When a canary does fail its thresholds, automatically collect the artifacts needed for the follow-up investigation right at that moment (logs, traces, a state snapshot) before rolling back, since the failure window may be brief and the evidence otherwise lost once traffic reverts.

A lightweight version for teams without sophisticated infrastructure

The same principle scales down: run smoke tests and a handful of synthetic transactions against the new version first, compare basic latency/error-rate metrics to a recent baseline (even a simple before/after comparison, not a live control group), use a modest percentage/duration rollout with a manual or simple automated rollback rule, and grow the sophistication of the setup over time rather than requiring full canary infrastructure before getting any of the safety benefit.

Trade-offs and pitfalls

A canary's value depends on the canary traffic being representative of the traffic that would actually reveal the regression; a canary sized or targeted (e.g., a single region, a single low-traffic hour) that doesn't include the affected segment can pass cleanly while the regression still exists for everyone else, giving false confidence to proceed with a full rollout.

Direct answer

Pick one story where the task was genuinely vague, you chose a small first deliverable on purpose, and the plan changed because of what you learned. STAR means situation, task, action, result. The story below is an illustrative skeleton; swap in your own facts and numbers.

Structured elaboration: how to choose the first deliverable

I pick the piece that (1) is the smallest thing that is useful end to end, (2) can be tested within about two weeks, (3) uses data or access I already have, (4) carries low risk if wrong, and (5) teaches me the most about the parts I do not yet understand. Everything else gets sequenced after it.

Worked example (STAR)

• Situation: Leadership said, "Use AI to cut our support workload." No spec, no owner, no baseline.
• Task: I owned turning that into a plan within three weeks.
• Action:
  1. Wrote a one-sentence outcome with the sponsor: fewer agent minutes per ticket on routine questions, without a drop in customer satisfaction.
  2. Hand-labelled a random sample of 200 tickets by intent (the reason the customer wrote). 54 of 200 (27%) fell into just three intents with near-scripted answers (password reset, invoice copy, plan change).
  3. Cut the work into pieces: baseline measurement, draft replies for those three intents shown to agents, then a customer-facing chatbot later. Chose draft replies as the first deliverable. Why: 27% of tickets had near-scripted answers, so drafts could be right often; a support agent (a human on the support team, not an AI agent) reviews every draft, so a wrong draft costs little; and the chatbot would have to handle all 200 tickets, including the 73% with no script, while talking to customers directly. Drafts also produce labelled feedback for later steps.
  4. Shipped to four agents in week two.
• What changed: Agents ignored the drafts. The cause was that drafts lacked the customer's account context (plan, last invoice), so agents had to look it up anyway. I added an account lookup to the draft before widening the rollout, and parked the chatbot until acceptance was healthy (we had agreed at least 50% of drafts sent after changing less than about a fifth of the text). I also learned early that the intent categories needed one more split (billing questions with and without a dispute).
• Result: The weekly rate of drafts accepted with little editing, which I had set up before launch, was 22% in week 3 (44 of 200 drafts) and 61% in week 6 (122 of 200) once context was added (illustrative figures; use your own). The sponsor approved a second phase based on that measured number, not on a demo. Be honest about what that number is: acceptance rate is a leading indicator (a proxy that should move before the real outcome), not the outcome the sponsor asked for. Agent minutes per ticket and customer satisfaction were not yet measured, so the second phase was approved on the condition that the first milestone of phase two is that baseline, with a stated bar for the next review. A good result line names the metric, the before and after values, and what decision followed.
• What I would do differently: Measure agent minutes per ticket before building anything, and sit with two agents on day one instead of week two.

The same shape in other settings

• Ambiguous security task, little documentation: first deliverable was an inventory of services holding customer data (a usable v1 in days), which then told us where to look deeper.
• Cross-team operational problem: first deliverable was a shared timeline of handoffs between teams, since nobody owned the whole picture, followed by one agreed fix per handoff.

Pitfalls

• Starting with the most interesting piece, not the most informative.
• A story with no plan change. Interviewers are probing whether you adapt.
• Inventing precise results. If you lack a number, say what you measured and how it moved.

Direct answer

Pick a project that genuinely needed more than one function, and be specific about two things: what YOU owned (not what 'the team' did), and the one concrete mechanism that determined whether the collaboration worked, such as a shared definition of done, a clear handoff point, or clarity on who decided what when opinions differed. Vague answers ('we communicated well') sound rehearsed; specific answers sound lived-in.

What the story needs to show

Your specific contribution. Interviewers are listening for what you personally decided or built, distinct from what your collaborators did. If every sentence is 'we', the interviewer cannot tell what you'd do differently on the next team.

A mechanism-level explanation. Organize the story around one of three lenses:

• Shared goal: did every function agree on what 'done' looked like and how success would be measured, or was each function quietly optimizing for its own definition?
• Interface or handoff: was there a clear point where work crossed from one function to another, and was that point actually defined, or did people guess?
• Decision rights: when functions disagreed, was it clear whose call it was, or did disagreement just stall until someone got tired of arguing?

Honesty if it's a struggle story. The question explicitly allows 'succeed or struggle'. A good struggle story ends on what you changed about the collaboration, not on who was at fault.

Worked example

Situation: [your team] needed to deliver [a feature or initiative] that required real work from [Team A, for example a design or research function] and [Team B, for example a data or infra function], against a fixed external date.
Task: your role was the one connecting the three groups, for example owning the shape of the interface between design and engineering, or owning how data requirements got translated into a schema.
Action: early on, each function had a different idea of what 'done' meant for their piece, which caused rework when the pieces met. You wrote a short one-page agreement naming the shared definition of done and who would sign off on each handoff, and used it to resolve the next two disagreements without a meeting.
Result: the project shipped on the revised date, and the agreement itself became something the group reused on the next cross-functional piece of work, which is the real marker of a story about redesigning the collaboration rather than just pushing through it.

To make that skeleton concrete rather than a fill-in-the-blank: picture a checkout redesign that needed real work from the design function and the payments engineering function, against a fixed external date tied to a promotional campaign launch. The specific disagreement was about what 'done' meant for the new payment-method selector: design considered the screen done once every state (loading, error, empty) matched the approved mockups pixel-for-pixel, while payments engineering considered it done once the integration correctly handled every payment-provider response code, even ones with no mockup drawn yet. That mismatch caused two rounds of rework when a payment-provider error state shipped without a design pass. The one-page agreement that resolved it included this line: 'A screen is done when it matches an approved mockup for every state the payments API can return, and any new state discovered after mockups are drawn triggers a joint 15-minute review before either side builds it.' That single sentence is what let the two functions stop re-litigating 'done' every time a new edge case appeared, and both sides signed off on it before the next round of work began.

Trade-offs and pitfalls

• A generic 'we all communicated well' answer with no mechanism is the single most common weak version of this story, avoid it.
• Over-crediting the team at the expense of your own specific contribution leaves the interviewer unable to evaluate you.
• If you pick a struggle story, resist framing it as the other function's fault. The senior version of this answer explains what you changed about how the groups worked together, not who dropped the ball.
• The strongest answers show you redesigning a structure (a handoff, a shared definition, a decision rule), not just working harder inside a broken one.

Direct answer. Offset pagination (?page=3&page_size=20) is the simplest to implement and the worst under change: it skips or repeats rows when data is inserted or deleted between page requests, and gets slower the deeper you page because the database still has to count past all the skipped rows. Cursor (keyset) pagination anchors each page on the last row you actually saw, so it stays correct under churn and stays fast at any depth, at the cost of losing the ability to jump straight to page 40.

Why offset breaks under churn. If a new row is inserted at the front of the sorted list while a client is between page 1 and page 2, everything shifts by one position: the client's page 2 request (offset=20) now returns a row it already saw on page 1, and misses the row that got pushed off the end. Nothing is wrong with the server, the math of "skip N rows" simply assumes the set of rows is frozen, which it never is in a live system.

Why cursor pagination does not have this problem. Instead of saying "skip 20 rows", a cursor request says "give me rows that sort after THIS specific row I already saw" (typically encoded as the last row's sort key plus its id, to break ties). New rows inserted anywhere other than exactly at that boundary do not shift anyone's position relative to a cursor they already hold, because the cursor is anchored to real data, not a row count.

Performance at depth. Offset pagination on page 10,000 still has to have the database walk past (or index-skip) the first 200,000 rows before it can return row 200,001; that cost grows with the offset. A cursor query uses an index seek directly to the anchor position and returns the next page from there, so page 10,000 costs roughly the same as page 1.

When offset is still the right choice anyway. An admin UI where someone genuinely wants to jump to "page 40" by number, or a small, rarely-changing dataset where churn is not a real concern, is a legitimate reason to keep offset pagination: cursor pagination cannot support random access to an arbitrary page number, only "next" and "previous" relative to where you are.

Direct answer

A sorting algorithm is stable if it preserves the relative order of elements
that compare equal on the sort key. If two records tie on the key you sorted
by, a stable algorithm guarantees the one that came first in the input still
comes first in the output. This matters for multi-key sorts: if you sort by a
secondary key after already sorting by a primary one, stability is what lets
the primary ordering survive as a tiebreaker inside each secondary-key group.
Merge sort and Python's Timsort (the algorithm behind sorted() and list.sort())
are stable; classic in-place selection sort and a typical quicksort are not.

Structured elaboration

Why stability matters for multi-key sorts. The standard trick for sorting
by (primary key, secondary key) without writing a composite comparator is:
sort once by the primary key, then sort the result by the secondary key. This
only produces the correct combined order if the second sort is stable: a
stable sort only reorders elements that actually differ on the secondary key,
so within any group of equal secondary-key values, the primary-key order from
step one is left untouched. An unstable sort makes no such promise: it may
reorder equal-secondary-key elements arbitrarily while grouping them, silently
destroying the primary ordering you already paid to establish.

A stable sort: merge sort, and Timsort (the hybrid merge/insertion sort
used by Python and Java's Collections.sort for objects). Both work by
merging or shifting elements without ever swapping two elements past an equal
one, so ties keep their input order.

An unstable sort: classic in-place selection sort (repeatedly swap the
current position with the position of the next-smallest remaining element).
The swap step moves elements across long distances in the array, including
past other elements with the same key, which is exactly what breaks ties.
Typical in-place quicksort implementations are unstable for the same reason
(the partition step swaps non-adjacent elements).

If you only have an unstable sort available, you can force stability by
attaching the original index to each record and sorting by (key, original_index)
instead of key alone. Ties on key are then broken by index, which exactly
reproduces stable behavior, at the cost of allocating one extra field per record.

Worked example

Take four employee records, already sorted by name (the primary key):

Now sort by department (the secondary key). A stable sort must produce:

Eng: Chen, Ito       (name order preserved)
Sales: Alvarez, Diallo  (name order preserved)

Running this in Python, where sorted() is stable, versus a hand-rolled
unstable selection sort, on the exact same input:

records = [
    {"name": "Alvarez", "dept": "Sales"},
    {"name": "Chen", "dept": "Eng"},
    {"name": "Diallo", "dept": "Sales"},
    {"name": "Ito", "dept": "Eng"},
]

stable_result = sorted(records, key=lambda r: r["dept"])

def unstable_selection_sort_by_dept(items):
    items = list(items)
    n = len(items)
    for i in range(n):
        min_idx = i
        for j in range(i + 1, n):
            if items[j]["dept"] < items[min_idx]["dept"]:
                min_idx = j
        items[i], items[min_idx] = items[min_idx], items[i]
    return items

unstable_result = unstable_selection_sort_by_dept(records)

print([(r["dept"], r["name"]) for r in stable_result])
print([(r["dept"], r["name"]) for r in unstable_result])

Output (verified by running this exact code):

[('Eng', 'Chen'), ('Eng', 'Ito'), ('Sales', 'Alvarez'), ('Sales', 'Diallo')]
[('Eng', 'Chen'), ('Eng', 'Ito'), ('Sales', 'Diallo'), ('Sales', 'Alvarez')]

The Eng group comes out identical either way, but the Sales group is
reversed under the unstable sort: Diallo now precedes Alvarez, even though
Alvarez came first alphabetically. That reversal is the bug: any downstream
code relying on "same department, alphabetical order" is now silently wrong,
and the failure is data-dependent, so it will not show up on every input.

Trade-offs & pitfalls

• Stability is a property of the algorithm's specification, not just a given
  implementation detail: "quicksort" is not stable by definition, but a
  particular library's sort might document stability as a guarantee (check
  the docs rather than assuming from the algorithm's name).
• The index-as-tiebreaker trick works with any comparison sort, stable or not,
  but costs O(n) extra memory for the index field and slightly more comparison
  overhead per element; it is the right choice when the language's built-in
  sort is unstable by contract (e.g. a raw quicksort library call) and you
  cannot swap in a stable one.
• A common wrong turn is assuming "the final order looks right on my test
  data" is proof of stability; instability is a tie-breaking behavior that
  only shows up when there are actual ties, so it hides in datasets with few
  duplicate keys and surfaces later at a different data distribution.
• Do not confuse stability with sort correctness on the primary sort key
  itself: an unstable sort still produces a fully correct order on the key it
  was told to sort by, it only fails to preserve unrelated prior ordering
  among equal elements.

Direct answer
Single-element arrays and duplicate-heavy arrays are frequent edge cases because array algorithms are usually written and mentally verified against the "typical" case of several distinct elements, and that typical case silently hides two classes of off-by-one and comparison assumptions: code that assumes there are at least two elements to compare (loops that start iterating from index 1 and compare against index 0), and code whose correctness depends on values being distinct (deduplication logic, "find the unique X" logic, or median/middle-element logic that assumes a clean ordering).

Structured elaboration

• find_min: a loop that initializes the running minimum from arr[0] and then compares against arr[1:] is correct on a single-element array only if the loop body correctly does nothing when the remainder slice is empty; a common bug is initializing the minimum to a sentinel like 0 or the first two elements' comparison, which breaks on a single-element input. An empty array is a separate, harder edge case: there is no valid minimum, so the function must raise rather than return a sentinel that looks like real data.
• remove_duplicates: an array with many duplicates is the case that most directly exercises the function's core logic (as opposed to its scaffolding), so it is the highest-value case to test explicitly; a common bug is using a data structure that doesn't preserve insertion order (an unordered set converted straight back to a list) when the contract implicitly requires the first occurrence of each value to be kept in its original relative position.
• get_middle_element: for even-length arrays there are two "middle" elements, so a duplicate-heavy or single-element input directly probes whether the function's parity handling is correct; a single-element array is the smallest input where "the middle" is unambiguous (index 0), which makes it a cheap and high-signal edge case to assert first before testing the even/odd split logic.

Worked example (executed)

def find_min(arr):
    if not arr:
        raise ValueError("find_min() called on empty array")
    m = arr[0]
    for x in arr[1:]:
        if x < m:
            m = x
    return m

def remove_duplicates(arr):
    seen = set()
    out = []
    for x in arr:
        if x not in seen:
            seen.add(x)
            out.append(x)
    return out

def get_middle_element(arr):
    if not arr:
        raise ValueError("get_middle_element() called on empty array")
    n = len(arr)
    return arr[n // 2] if n % 2 == 1 else (arr[n // 2 - 1], arr[n // 2])

Two concrete unit tests per function (input -> expected), executed with pytest and confirmed passing (7/7):

Pytest output (executed): 7 passed in 0.01s, comprising the 6 cases shown in the table above plus one additional find_min([]) test asserting a ValueError is raised, which also passed.

Trade-offs and pitfalls
The common wrong turn is treating "single-element" and "duplicate-heavy" as one generic "small input" test category and writing only one combined case; they exercise different failure modes (loop-bound assumptions versus distinctness assumptions) and a suite with only one blended case can pass while either underlying bug is still present. The other pitfall is under-specifying the contract before writing the tests: get_middle_element on an even-length array could reasonably return the lower element, the upper element, or a pair, and find_min/get_middle_element on an empty array could reasonably return None, raise, or be defined as undefined behavior; a senior engineer nails down and documents that contract decision first, then writes tests that lock it in, rather than writing tests that happen to match whatever the first implementation did.

Direct answer

Lead with the baseline metric, the specific change you made, the resulting metric with enough of the underlying numbers shown that the improvement is checkable, and the trade-off you knowingly accepted, in that order. The trade-off is not optional detail: naming it, and what you did to monitor it, is what separates a senior answer from a number without context.

Structured elaboration

The four-part shape:

1. Baseline: what was the metric before, and how was it measured?
2. Change: the specific decision, not a list of everything you tried.
3. Result: the new metric, with enough of the underlying numbers shown that the improvement is checkable, not just asserted.
4. Trade-off and monitoring: what got worse or riskier as a direct consequence, and what you put in place to catch it if it went too far.

Common metric families by domain (pick the one that matches your role; the story shape is identical):

Worked example

"A service's average response time was too high under peak load. Baseline: 40% of requests hit a warm cache (5ms), the other 60% missed and hit the database (200ms). Baseline average latency: (40% × 5ms) + (60% × 200ms) = 2ms + 120ms = 122ms. The change: I raised the cache TTL from 30 seconds to 10 minutes, which pushed the effective hit rate to 85%, at the cost of serving data up to 10 minutes stale instead of 30 seconds stale. New average latency: (85% × 5ms) + (15% × 200ms) = 4.25ms + 30ms = 34.25ms. That's a drop from 122ms to 34.25ms, a (122 minus 34.25) divided by 122, roughly 72% reduction. The trade-off: any field that changed within that 10 minute window could be served stale. I mitigated it by adding explicit cache invalidation on writes for the two fields that actually mattered for correctness, account balance and permission level, and left everything else on the longer TTL, plus a staleness alert if invalidation events started failing silently."

Trade-offs and pitfalls

• Never present the "after" number without the baseline; an improvement with no starting point is unfalsifiable and interviewers know it.
• Don't hide the trade-off; claiming a change had zero downside reads as either dishonest or shallow. Every real optimization costs something.
• Match your monitoring to the specific failure mode you introduced; generic "we added logging" is weaker than "we alerted specifically on the thing that could go wrong because of this change."
• Round, checkable numbers you can defend beat impressively precise ones you can't reconstruct if asked.

Direct answer

Anti-entropy is the background process that repairs replicas which have drifted apart by comparing what each replica actually holds and shipping only the differences. Full Merkle trees, range-based comparison, and delta-based synchronization all solve this, but they trade CPU and memory (building or maintaining a comparison structure) against network bytes (what actually gets transferred) in different proportions, and at terabyte scale that trade-off is what decides which one wins.

Full Merkle trees

A Merkle tree is a hash tree: each leaf is the hash of a key-range's contents (or a single key's version), and each internal node is the hash of its children. Two replicas compare root hashes first; if they match, the whole subtree underneath is known to agree and no further comparison is needed; if they differ, both sides recurse into whichever child subtrees disagree, pruning everything else. This localizes a small number of actually-differing keys very cheaply in network terms, but building the tree from scratch means hashing the entire dataset, which for a terabyte-scale store is a full scan whose CPU and I/O cost is proportional to the dataset size, not to how much has actually drifted.

Range-based comparison

Instead of a tree, the keyspace is partitioned into fixed or size-based ranges up front, and each replica computes one summary per range (a checksum, a record count, a max version) and exchanges those directly. A mismatched range is either subdivided further or transferred whole. This skips the recursive tree bookkeeping, at the cost of coarser precision: if a single key differs inside a large range, the whole range still has to move (or be subdivided) rather than just that one key.

Delta-based synchronization

Each write is stamped with a monotonically increasing per-replica version number, and instead of building any hash structure at all, one replica asks the other for everything with a version greater than its own last-synced position (tailing an operation log). This is by far the cheapest in both CPU and network when it applies, because it transfers exactly the changed records and nothing else, but its correctness depends entirely on both sides retaining a comparable version log; if the divergence is older than the retained log window, delta sync cannot answer the request and the system must fall back to a full Merkle or range comparison instead.

Comparison at terabyte scale

Building a full Merkle tree over a terabyte dataset from scratch on every anti-entropy pass is prohibitively expensive; production systems maintain it incrementally as writes happen rather than rebuilding it each run. Range-based comparison avoids that recursive bookkeeping at the cost of transferring more bytes per mismatch, which can be mitigated with adaptive range sizing (smaller ranges where churn is high, larger ranges where data is cold). Delta-based sync is cheapest whenever the version log covers the actual gap, but has an unbounded-retention cost if you want it to always apply.

Recommendation for a large, skewed keyspace: use adaptive, size- or churn-based ranges as the primary mechanism (isolating hot keys into small ranges and cold data into large ones), maintain shallow per-range Merkle hashes to localize differences quickly within a cold range, and prefer delta-based sync wherever the version log still covers the gap, falling back to the range/Merkle comparison only once the log window has been exceeded.

graph TD
    RootA[Root hash A] --> BL[Branch Left]
    RootA --> BR[Branch Right]
    BL --> L1[Leaf: keys 1-1000]
    BL --> L2[Leaf: keys 1001-2000]
    BR --> L3[Leaf: keys 2001-3000]
    BR --> L4[Leaf: keys 3001-4000]

Read repair: fixing staleness at read time

Anti-entropy runs in the background regardless of what's being read right now; read repair instead fixes staleness the moment a client happens to read a key, without adding latency to that client's own request. When a quorum read is served from multiple replicas, the coordinator compares the versions it gets back: suppose replica R1 returns (value=v2, version=7), R2 returns (value=v1, version=5), and R3 returns (value=v2, version=7). The coordinator returns v2 (the version two of three replicas agree on) to the client immediately, and separately, off the client's response path, pushes a repair write of (K, v2, version=7) to R2 in the background. Because this only happens for keys someone actually reads, read repair does nothing for cold keys nobody queries, so background anti-entropy is still needed as the backstop for data that is never read.

Hinted handoff: staying writable through a node outage

When a target replica for a key is unreachable at write time, for example replica R2 is down, a Dynamo-style store stays always-writable by handing that write to a different, healthy node (a hint holder, say R4) along with a hint recording who the write actually belongs to. R4 stores the write plus the hint. Concretely: the replica set for key K is {R1, R2, R3}; R2 is down; a write W(K=v3) arrives; the coordinator writes directly to R1 and R3, and since R2 is unreachable, hands the write to R4 with hint={target: R2, key: K, value: v3}. R2 recovers ten minutes later; R4's health check or gossip layer learns R2 is back; R4 forwards W(K=v3) to R2 and deletes its own hint copy. All three original replicas now hold v3.

Trade-offs & pitfalls

Hinted handoff is a latency and availability optimization, not a substitute for anti-entropy: if the hint holder itself crashes before delivering the handoff, that write is only recoverable through whatever the normal replica quorum still retains, so anti-entropy (or read repair) remains the backstop even when hinted handoff is in use. Read repair only heals keys that get read, so a design that relies on it exclusively can leave cold data permanently drifted. Over-aggressive range subdivision in range-based sync adds coordination overhead without meaningfully reducing transferred bytes unless the workload's skew actually justifies the extra ranges.

The idea in plain words

The height of a tree is the length of the longest path from the root down to a leaf. Counting here is in edges (the lines between parent and child): an empty tree has height -1, a single node has height 0, and in general height(node) = 1 + max(height(left), height(right)). Recursion follows that formula directly. The iterative version walks the tree level by level with a queue (breadth-first search, BFS) and counts how many levels it passed through.

Approach

Recursive. The height of a node is one more than the taller of its two subtrees. The empty tree is the base case and returns -1, which makes a leaf come out as 1 + max(-1, -1) = 0.

Iterative with BFS. Keep a queue of the current level. Each pass removes all nodes of that level and adds all of their children, which is the next level. Count the passes; the height is the pass count minus one (edges, not levels), which the code does by starting the counter at -1.

Code

from collections import deque


class TreeNode:
    def __init__(self, val, left=None, right=None):
        self.val = val
        self.left = left
        self.right = right


def height_recursive(node):
    if node is None:
        return -1                      # empty tree
    return 1 + max(height_recursive(node.left), height_recursive(node.right))


def height_bfs(root):
    if root is None:
        return -1
    height = -1
    queue = deque([root])
    while queue:
        height += 1                    # one more level has been reached
        for _ in range(len(queue)):
            node = queue.popleft()
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
    return height


def depth_of(root, target):
    """Edges from the root to the first node holding target, or -1 if absent."""
    queue = deque([(root, 0)] if root else [])
    while queue:
        node, depth = queue.popleft()
        if node.val == target:
            return depth
        for child in (node.left, node.right):
            if child:
                queue.append((child, depth + 1))
    return -1


#      7
#     / \
#    3   9
#     \   \
#      5   12
#         /
#        11
tree = TreeNode(7, TreeNode(3, None, TreeNode(5)), TreeNode(9, None, TreeNode(12, TreeNode(11))))
leaf = TreeNode(1)
print("recursive:", height_recursive(tree), height_recursive(leaf), height_recursive(None))
print("bfs      :", height_bfs(tree), height_bfs(leaf), height_bfs(None))
print("depth of 11:", depth_of(tree, 11), "| depth of 7:", depth_of(tree, 7), "| depth of 99:", depth_of(tree, 99))

for n in (900, 5000):
    chain = None
    for i in range(n):
        chain = TreeNode(i, right=chain)
    try:
        print(f"chain of {n}: recursive", height_recursive(chain), "| bfs", height_bfs(chain))
    except RecursionError:
        print(f"chain of {n}: recursive RecursionError | bfs", height_bfs(chain))

Output:

recursive: 3 0 -1
bfs      : 3 0 -1
depth of 11: 3 | depth of 7: 0 | depth of 99: -1
chain of 900: recursive 899 | bfs 899
chain of 5000: recursive RecursionError | bfs 4999

Worked example

      7
     / \
    3   9
     \   \
      5   12
         /
        11

The longest path is 7, 9, 12, 11, which is 3 edges, so the height is 3. Both functions print 3 for this tree, 0 for a single node (leaf), and -1 for the empty tree.

The BFS passes on this tree: [7] (counter goes from -1 to 0), [3, 9] (1), [5, 12] (2), [11] (3). The queue is then empty and the counter holds 3.

Conventions

• Edges versus nodes. Counting nodes on the longest path gives the edge answer plus 1: empty tree 0, single node 1. Problems that ask for "maximum depth" usually mean this node-count version. Say which one you use before you code, and make the base case match.
• Depth of a given node: the number of edges from the root to a node holding a given value. depth_of finds it with BFS, carrying the depth next to each queued node, and returns -1 when the value is absent: it gives 3 for 11, 0 for the root 7, and -1 for 99.
• In C++ the same recursive function returns int, takes TreeNode*, and checks root == nullptr first; the structure is identical.

Stack depth on a skewed tree

A skewed tree is one where every node has a single child, so the tree is a chain. The recursive function has one pending call per node on the path, plus the call on the empty child, so a chain of n nodes uses about n + 1 stack frames at the deepest point: the stack depth equals the height plus a small constant. CPython allows 1000 frames by default. The demo shows the result: a chain of 900 nodes works (height 899) but a chain of 5,000 raises RecursionError, while the BFS version returns 4999 on the same input. In languages such as Java or C++ the limit is the thread's stack size rather than a fixed frame count, and a very deep chain fails there as well.

Complexity

Here n is the number of nodes and h the height. Each node is handled once in both. The two versions trade stack depth against queue width, so BFS is the one to use when the tree might be a deep chain, and the recursive form is fine for balanced trees.

Edge cases and common mistakes

• Empty tree: -1 here. In a node-counting version it is 0. Decide before writing the base case.
• Single node: 0 edges.
• Using list.pop(0) for the queue, which is O(n) per pop; collections.deque.popleft() is O(1).
• Incrementing the counter once per node instead of once per level. With the counter starting at -1 as here, that returns the node count minus 1 (5 for the 6-node example tree instead of 3); starting the counter at 0 would return the node count itself. Either way it is not the height.
• Taking max of the heights but forgetting the 1 +, so every tree reports -1.

Running the code

Save the code block as tree_height.py and run python3 tree_height.py with Python 3.12. Only the standard library is used.

Direct answer
A blameless postmortem is a structured written review of an incident that treats the failure as evidence of a gap in the system rather than as evidence of a person's incompetence. It assumes everyone involved acted reasonably given the information and pressure they had at the time, and it asks 'what about the system made this possible' instead of 'who made this mistake.' A good postmortem document has a small, consistent set of sections: an incident summary and severity, a timestamped timeline, quantified impact, the root cause and any contributing factors, immediate mitigations already taken, and a list of owned, dated action items.

Structured elaboration
Each section earns its place by answering a different question a reader will actually ask:

• Summary and severity. One or two sentences so a reader who will never open the full document still knows what happened and how bad it was.
• Timeline. An objective, timestamped sequence of what happened, detected, and was done. This is the shared factual spine the rest of the document hangs off; without it, discussion drifts into competing memories.
• Impact. Quantified: how many users, how much revenue, how long, which SLOs were breached. Impact is what makes prioritization of the resulting action items defensible later.
• Root cause and contributing factors. The root cause is the condition that, if changed, would have prevented the incident; contributing factors made it more likely or worse but would not alone have caused it. Separating the two stops the document from over-claiming a single tidy cause when the real story is usually several factors lining up.
• Immediate mitigation. What was done to stop the bleeding, kept separate from the long-term fix, since these often have very different owners and timelines.
• Action items with owners and dates. Concrete, individually verifiable, and never phrased as 'be more careful.' A postmortem that ends with vague advice instead of an owned commitment produces no durable change.

The wording throughout matters as much as the structure. 'The on-call engineer missed a step in the runbook' names a person; 'the runbook did not make the required step hard to skip' names a system gap that is actually fixable. This isn't softening the facts, it's redirecting the analysis toward the thing you can change.

Worked example
An API returns errors for 45 minutes after a deploy. A blame-oriented writeup might say: "the engineer pushed a bad config and didn't test it." A blameless version says: "a config change with an invalid timeout value was deployed to production without automated validation or a staged rollout; the on-call engineer restored service in 12 minutes by rolling back. Root cause: the deploy pipeline allows unvalidated config to reach 100% of traffic in one step. Contributing factor: the config schema has no automated check for out-of-range timeout values. Action items: (1) add schema validation to the deploy pipeline, owner platform-team, due in two weeks; (2) require staged rollout for config-only changes above a defined blast-radius threshold, owner SRE lead, due in one month." Same incident, same facts, but the second version is auditable, points at fixable system gaps, and produces action items an unrelated engineer could pick up and execute.

Trade-offs and pitfalls
The most common failure is stopping the investigation at 'human error' as though that were itself the root cause. If a person did something reasonable given what they knew and the system still let it cause an outage, the real root cause is upstream: missing validation, an unclear runbook, a dangerous default. A second common failure is a postmortem so long and hedged nobody reads it. Sections should be short and factual; depth belongs in linked artifacts (logs, dashboards), not in the narrative itself.