FAANG-Standard Network Engineer Interview Preparation Guide (Entry Level)

Direct answer

Each network needs at least 150 usable hosts, and a subnet with h host bits has 2^h - 2 usable addresses (the network address and the broadcast address are not assignable to hosts). A /25 (h = 7) gives only 126, which is too few, so the minimum is a /24 (h = 8, 254 usable). Twelve /24s need 12 x 256 = 3,072 addresses, and the /20 has 4,096, so they fit with a /22 (1,024 addresses) left over: 172.16.12.0/22.

Allocation algorithm

1. Find the smallest prefix that meets the requirement: smallest h with 2^h - 2 >= 150, so h = 8 and the prefix length is 32 - 8 = /24.
2. Check capacity: the /20 holds 2^(24-20) = 16 subnets of /24, and 12 are needed.
3. Allocate in ascending address order from the start of the block. Because every subnet is the same size, each one starts exactly where the previous one ended: a /24 is 256 addresses, so the third octet simply goes up by 1 (172.16.0.0, 172.16.1.0, 172.16.2.0, and so on). Every start address is therefore a multiple of 256, which is what a /24 boundary requires, so nothing is misaligned. (With mixed sizes you would sort largest first so each block stays aligned.)
4. Summarise what is left: the remaining four /24s, 172.16.12.0 to 172.16.15.255, collapse into the single block 172.16.12.0/22.

The 12 subnets

Mask for every row: 255.255.255.0 (/24).

Spare: 172.16.12.0/22 (172.16.12.0 to 172.16.15.255), room for four more /24 networks, or any mix of smaller blocks.

Checking the arithmetic

A short Python check regenerates the table from the rule, so no row depends on hand arithmetic:

import ipaddress
block = ipaddress.ip_network("172.16.0.0/20")
bits = 2
while 2**bits - 2 < 150:
    bits += 1
subs = list(block.subnets(new_prefix=32 - bits))
for i, n in enumerate(subs[:12], 1):
    h = list(n.hosts())
    print(i, n, n.broadcast_address, h[0], h[-1])
print(list(ipaddress.summarize_address_range(subs[12].network_address, block.broadcast_address)))

Line by line: the while loop starts with 2 host bits and adds one until 2^bits - 2 reaches at least 150, which stops at 8. block.subnets(new_prefix=32 - bits) cuts the /20 into every /24 inside it, in address order (16 of them). The for loop prints the first 12; n.hosts() lists the usable addresses, so its first and last entries are the host range, and n.broadcast_address is the broadcast. The final line takes the range from the start of the thirteenth /24 to the end of the /20 and summarize_address_range returns the fewest prefixes that cover exactly that range. It prints [IPv4Network('172.16.12.0/22')], and the 12 rows match the table.

Trade-offs

• Waste is inherent, not a mistake. A 150-host requirement sits between /25 (126) and /24 (254). Each network leaves 254 - 150 = 104 usable addresses idle, 12 x 104 = 1,248 in total. That is the cost of the binary block sizes; no uniform prefix does better, and splitting a 150-host network across two /25s means two subnets (two gateways, two broadcast domains), which is worse operationally than the idle addresses.
• The idle addresses are the growth headroom. A network can grow from 150 to 254 hosts (about 69% more, (254 - 150) / 150) with no renumbering. Reserve the gateway and any redundancy-protocol addresses from that headroom (for example .1 gateway, .2 and .3 router interfaces) and it is still large.
• Keep the leftover block contiguous. Allocating from the bottom keeps 172.16.12.0/22 as one summarisable block; scattering the 12 subnets would fragment it.
• If "at least 150" later becomes 300, a network needs a /23 (510 usable), and a /23 must start on an even third octet (172.16.12.0/23 qualifies; 172.16.5.0/23 does not). Allocating adjacent /24s only helps if the pair is aligned, so decide before handing out the first block whether any network might double.

Direct answer

I give a bounded number fast rather than staying quiet while I chase precision I don't have time for: I state the number, the method behind it, and what I'm assuming, all in the same breath, and I commit openly to a tighter follow-up once there's more time. Silence until it's perfect helps nobody if the stakeholder has to decide by Friday either way.

Structured elaboration

• Find the fastest defensible path, not the most rigorous one. Given a week in an area I don't know well, I look first for existing data or dashboards that are already adjacent to the question, then a short conversation with whoever actually owns that part of the business to get the two or three facts that matter most, before I'd ever try to build something from scratch.
• Make a conservative first cut. Wherever I'm genuinely unsure, I lean toward the more cautious assumption, so if the number is wrong, it's wrong in the direction that's less likely to mislead the decision being made with it.
• Say explicitly what's left out. I tell the stakeholder plainly what the number does and doesn't cover, so they know its boundaries instead of assuming it accounts for everything.
• Put the assumptions right next to the number. Not buried in an appendix nobody reads: if the number depends on three specific assumptions, I say so in the same message the number appears in.
• Give a range, not false precision. A rounded range like "roughly 800 to 1,200" is more honest than a specific-looking figure like "947," because the second implies a level of rigor I don't actually have.
• Commit to and schedule the tightening pass. I say what additional data or time would sharpen the number, and when I'll have it, so the first answer is understood as a starting point rather than the final word.

Worked example

A stakeholder once needed an estimate of how much additional support-ticket volume a new customer segment would generate, before we finalized staffing for the following quarter, and I'd never analyzed that segment before. Rather than going quiet for a week to build a proper model, I spent half a day finding the closest available proxy: an existing segment with roughly similar product usage patterns, and its historical ticket rate per active user. I applied that rate to our projected user count for the new segment, deliberately rounding up the assumption about how "similar" the segments really were, since I wasn't confident and wanted the estimate to err toward not under-staffing. I sent the number as a range, with the two assumptions stated directly underneath it (the proxy segment's comparability, and the projected user count itself), and said I'd have a tighter number within two weeks once we had a few actual weeks of the new segment's real data. That let them staff conservatively now, and the follow-up estimate two weeks later came in close to the original range.

Trade-offs and pitfalls

The clearest pitfall is going quiet while trying to build something more rigorous than the deadline allows, since the stakeholder ends up deciding without you anyway, just with worse information. The opposite pitfall is handing over a specific-looking number without caveats, which invites the stakeholder to trust it further than it deserves and use it in ways it was never meant to support. The middle path, a clearly-labeled range with visible assumptions and a committed follow-up, is what actually respects both the deadline and the limits of what you know.

Direct answer

A steady 5-minute period means something is driven by a timer or a repeating state machine, not by random failures. I would first prove what is oscillating (reachability, best-path choice, or only attributes), group the affected prefixes by what they share (next hop, neighbor AS, origin AS, community), and then match the period against each candidate timer. The five candidates leave different fingerprints, so a few targeted observations separate them before I change anything.

Vocabulary used below. A route reflector (RR) is an iBGP router (BGP between routers of one autonomous system) that re-advertises routes it learned from its clients, so those clients need not peer with every router; an RR and its clients form a cluster. Two attributes stop reflection loops: ORIGINATOR_ID (the router ID of the router that first injected the route into the AS) and CLUSTER_LIST (the CLUSTER_IDs of the clusters the route has been reflected through, newest first); the CLUSTER_ID is the cluster's name, shared by its redundant RRs. A confederation splits one AS into member ASes with the same effect of avoiding a full mesh. MED (Multi-Exit Discriminator) is a number a neighboring AS attaches to say which of its links it prefers you use, lower wins, and it is only comparable between paths from the same neighbor AS (RFC 4271 section 9.1.2.2). MRAI (MinRouteAdvertisementInterval) is the minimum time a router must leave between two UPDATEs about the same prefix to one peer (RFC 4271 section 9.2.1.1). BMP (BGP Monitoring Protocol, RFC 7854) lets a router stream a copy of the routes and updates it receives to a collector.

Step 1: Pin down the pattern (10 minutes of data)

1. Pick two or three affected prefixes. Capture every UPDATE and WITHDRAW for them from a passive source: a BMP feed or a route collector if you have one, otherwise a debug of BGP updates filtered to those prefixes on one router, plus syslog timestamps. Record, per event: time, peer, whether it was a withdrawal or an announcement, and the attributes (AS path, next hop, MED, local preference, communities, ORIGINATOR_ID, CLUSTER_LIST).
2. Run a packet capture on one affected session so the capture agrees with the router's own view: tcpdump -nn -ttt -w bgp.pcap 'tcp port 179 and host 192.0.2.1' (the filter compiles as written; replace the address with the peer). Decode the UPDATEs offline.
3. Classify each event:
   • Withdrawal then re-announcement: the prefix really becomes unreachable (next hop loss, upstream withdrawal, session event).
   • Announcement only, attributes changed: the new UPDATE silently replaces the old path (an implicit withdrawal, no WITHDRAW message is sent). This is best-path churn. MED, route reflection and policy cause it.
4. Group the prefixes. If they all share one next hop, suspect next-hop reachability. If they all come from two neighbor ASes, suspect MED. If they share an origin AS or a community, suspect upstream policy.
5. Write down the period precisely (for example 300 s plus or minus 1 s) and the phase relative to other events (the IGP (interior gateway protocol) log, interface errors, scheduled jobs).
6. Review configuration changes: diff the running configuration against the last known-good version and read the change log for the onset time of the first oscillation. Look for new or edited route-maps, MED or local-preference settings, damping, route-reflector cluster IDs, next-hop-self, timers, and IGP metric changes. A flap that began right after a policy change is the cheapest hypothesis to test.

Reading the router side: on a reflected path show ip bgp <prefix> prints a line such as Originator: 192.0.2.1, Cluster list: 2.2.2.2 (illustrative addresses). The Originator is the router that first learned the route inside the AS, and the Cluster list shows which clusters reflected it. If the Originator or Cluster list changes between consecutive updates for the same prefix, the route is arriving through different reflection paths each time, which is the reflection signature.

Step 2: Match the period to a timer

RFC 4271 section 10 suggests these defaults, which are the timers worth comparing against 300 seconds: the hold time 90 seconds with keepalive at one third of it, MinRouteAdvertisementInterval 30 seconds on eBGP and 5 seconds on iBGP, and the connect retry timer 120 seconds. Also compare against the IGP SPF (shortest path first) throttle (the delay a link-state IGP waits before re-running its path calculation after a change), the BGP next-hop tracking delay (BGP's watch on the IGP route to each next hop, so it reacts within seconds when one disappears; Cisco default 5 seconds), route flap damping half-life (default 15 minutes), and anything scheduled on the box (IP SLA, tracked objects, cron-style automation). None of the protocol defaults equals 300 seconds. A whole-session reset resets every prefix from that peer, so a flap limited to "a set of prefixes" points away from keepalive and hold-timer expiry and toward attribute or next-hop causes.

As a first suspicion, not proof: MED oscillation has no clock of its own, its rhythm comes from how quickly updates propagate, so a period that stays at exactly 300 s is more likely a configured timer, a scheduled job or an upstream's own policy. Rule those in or out with the capture first, then move to the route-reflection causes.

Step 3: Test each cause, in this order

How a route reflector plus MED makes the best path rotate

MED is only compared between paths learned from the same neighbor AS, and a route reflector chooses from only the paths it has been sent. Together these let two RRs knock each other's preferred path out in turn. The numbers below are the textbook case from RFC 3345 (Figure 1). Cluster 1 has RR Ra with clients Rb and Rc; cluster 2 has RR Rd with client Re. All three clients learn the same prefix from outside: Rb from AS10 with MED 10, Rc from AS6 with MED 1, Re from AS6 with MED 0. Ra's IGP costs are 5 to Rb, 4 to Rc and 13 to Re; Rd's are 12 to Re, 5 to Rc and 6 to Rb.

1. Ra holds the AS6 path via Rc (MED 1, cost 4) and the AS10 path via Rb (cost 5). They come from different neighbor ASes, so MED is not compared and the lower IGP cost wins: Ra picks the AS6 path and advertises it to Rd.
2. Rd now holds Re's AS6 path (MED 0, cost 12) and Ra's AS6 path (MED 1, cost 5). Same neighbor AS, so MED decides: MED 0 beats MED 1. Rd picks Re's path and advertises it to Ra.
3. Ra now sees an AS6 path with MED 0 (via Rd, cost 13). That path eliminates the MED 1 path from Rc, leaving the AS6 MED 0 path (cost 13) against the AS10 path (cost 5). IGP cost now picks AS10, so Ra advertises the AS10 path and withdraws what it sent about AS6.
4. Rd now holds Re's AS6 path (cost 12) and Ra's AS10 path (cost 6). IGP cost picks AS10 and Rd withdraws its AS6 advertisement.
5. Ra no longer hears the MED 0 path, so the MED 1 path via Rc is back in play and beats AS10 on IGP cost (4 against 5). That is step 1 again, and the cycle repeats with no external change.

RFC 3345 states the conditions: a single-level reflection or confederation design, and MEDs from two or more neighbor ASes that are unique. Its preferred mitigation is the one in the table: had the inter-cluster IGP metrics been much larger than the intra-cluster ones, step 3 would not occur, because Ra would always prefer exits inside its own cluster.

Worked example: how damping would behave on a 5-minute flap cycle

Route flap damping gives each prefix a penalty score. Every flap adds points, the score decays over time and halves every half-life, and once it passes the suppress threshold the router stops using the route; it uses the route again when the score decays below the reuse threshold. Take the default Cisco damping parameters listed in RFC 7196 Table 1: a withdrawal adds 1000, an attribute change adds 500, suppress threshold 2000, reuse threshold 750, half-life 15 minutes, maximum suppress time 60 minutes. The ceiling is therefore 750 x 2^(60/15) = 12000. With one withdrawal every 5 minutes, the penalty just after each event is 1000, 1794, 2424, 2924, 3321, 3635, 3885, 4084 (computed, each step decays the previous value by 0.5^(5/15) and adds 1000). It crosses 2000 at the third flap (minute 10) and the route is suppressed from then on. The steady-state value approaches 1000 / (1 - 0.5^(5/15)) = about 4847, so once the upstream stops flapping the route stays suppressed for 15 x log2(4847/750) = about 40 minutes before reuse. That is the operational lesson: damping converts a 5-minute flap into a 40-plus-minute outage, so if the symptom stays a clean 5-minute cycle, damping is not suppressing it, and if reachability becomes much worse after the first 10 minutes, damping is amplifying it.

Step 4: Mitigate and prove it

Apply the one fix that matches the fingerprint, then verify for at least two full periods plus margin (a 12-minute window shows two cycles): zero UPDATEs for the affected prefixes on the capture, a stable best path in show ip bgp <prefix>, and no growth in flap statistics. If you cannot prove which cause it is, a safe interim step is to stop the loop from propagating (a stable static or aggregate at the edge), not to widen timers across the whole network.

Pitfalls

• Changing MRAI or damping first can hide the symptom while the root cause remains.
• MED is compared only between routes learned from the same neighboring AS (RFC 4271 section 9.1.2.2), so "always compare" settings change the whole decision process and need a network-wide change window.
• Treating route reflection and MED as two unrelated suspects: RFC 3345 shows the oscillation needs both (a route-reflection or confederation design plus unique MEDs from two or more ASes).

Direct answer

A rollback changes the authoritative data, but nothing tells the thousands of resolver caches that already hold the bad answer. Each cache keeps it until its own timer runs out, and the timer is the TTL (time-to-live) that was published with the bad record, counted from when that particular cache fetched it, not from when you rolled back. In times: if the bad record carried a TTL of four hours and the last moment anyone could fetch it was the 09:40 rollback, a cache that fetched it at 09:40 keeps it until 13:40. That is why the damage after a rollback lasts up to one full TTL beyond the last moment anyone could still fetch the bad data. To shorten it, make the bad answer harmless (keep the old target serving traffic), flush the caches you or others can flush, and communicate; to prevent a repeat, lower TTLs ahead of risky changes, roll out to a small share first, and watch resolution from outside before and after.

Why stale answers survive a rollback (executed demonstration)

Setup in a Debian container: BIND is the authoritative server for example.lab with a record TTL of 600 s; Unbound is a caching resolver in front of it.

=== step 1: publish app A 192.0.2.10 with TTL 600; resolver asks and caches
app.example.lab.	600	IN	A	192.0.2.10
=== step 2: bad change: app moved to 192.0.2.99 (authoritative now serves it)
authoritative says:
app.example.lab.	600	IN	A	192.0.2.99
=== step 3: a few seconds later the resolver still answers from its cache, TTL counting down
app.example.lab.	596	IN	A	192.0.2.10
=== step 4: the resolver operator flushes the name
ok
app.example.lab.	600	IN	A	192.0.2.99

Step 3 is the whole story: the authoritative answer changed, the resolver kept serving its copy with a counting-down TTL, and only an explicit flush (unbound-control flush app.example.lab) removed it. Read the lines this way: the number after the name is the remaining TTL in seconds (600 when fresh, 596 a few seconds later because the resolver's copy is already four seconds old), and the last field is the address, which is still the old 192.0.2.10 while the authoritative server says 192.0.2.99.

For BIND the equivalent is rndc flushname app.example.lab. What success looks like differs between the two tools. unbound-control flush prints ok and exits 0. rndc flushname prints nothing and exits 0 (checked with echo $?). In a test with a forwarding BIND resolver, dig @resolver app.example.lab A returned the stale 192.0.2.10 with a TTL of 595 before the flush and 192.0.2.99 with TTL 600 after it. A flush clears that one name from that one resolver only, so the check that it worked is a fresh dig against the resolver, comparing the address and TTL with what the authoritative server returns.

The arithmetic of "hours"

Say the bad record had TTL 14400 (four hours), was published at 09:00, and rolled back at 09:40. A resolver that fetched it at 09:39 holds it until 13:39; the worst case, a fetch at 09:40, holds it until 13:40. With a TTL of 300 the same mistake would have been gone from every compliant cache by 09:45. (Computed with Python datetime: 09:40 plus 14400 s is 13:40; plus 300 s is 09:45.)

What stretches the tail beyond the TTL

• Resolvers that clamp TTLs. To clamp is to force a value into a limit: some resolvers enforce a minimum TTL and treat anything shorter as that minimum. A second Unbound instance with cache-min-ttl: 300 answered short.example.lab with TTL 300 while the authoritative server published 30. A published TTL of 60 behind a resolver with a 3600 s floor lasts until 10:40 in the example above.
• Negative caching. If the bad change deleted a record, resolvers cache the NXDOMAIN (name does not exist) answer. RFC 2308 sets its lifetime to the smaller of the SOA record's own TTL and its MINIMUM field, and recommends keeping it to one to three hours, noting that more than a day is problematic. Unbound's default ceiling for negative answers is 3600 s.
• Other layers with their own timers: CNAME targets, NS (delegation) records, and caches in the operating system, browser and application runtime, plus connection pools (sets of already-open connections that an application reuses) that keep using an address they already hold.
• Serve-stale. Resolvers that implement RFC 8767 (serve-stale means answering from a record whose TTL has already run out) may answer from expired data, with a recommended TTL of 30 seconds on such answers, when the authoritative servers are unreachable. That prolongs outages, not bad answers from reachable servers.

How to shorten the damage

1. Make the bad answer work. The fastest cure is to keep serving real traffic at the address the cached answer points to: proxy or redirect it to the good stack. This ends user impact without waiting for any cache.
2. Flush what can be flushed: your own resolvers (commands above) and the large public ones. Google Public DNS provides a Flush Cache tool, and Cloudflare's 1.1.1.1 has a Cache Purge tool taking a domain name and record type. Confirm with dig SOA against the resolver and an authoritative server that they agree.
3. Do not change the record again to "fix" the fix: each change creates a new cohort of caches (a group of caches that fetched the record in the same window, so they expire together) with different expiry times and makes the picture harder to read. Worked example with a TTL of 3600 s: the bad record goes live at 09:00, you roll back at 09:30, and then change it a third time at 09:50. Caches that fetched the bad record between 09:00 and 09:30 hold it until 10:00 to 10:30. Caches that fetched the rollback value between 09:30 and 09:50 hold it until 10:30 to 10:50. Caches that fetch after 09:50 hold the third value. So up to three different answers are live from 09:50 to 10:30, and the last cache with a stale value lets go at 10:50. Had you left the rollback alone, the last bad entry would have expired at 10:30 (computed in Python: 09:30 plus 3600 s is 10:30, 09:50 plus 3600 s is 10:50).
4. Communicate the expected end time from the arithmetic above (last bad answer plus TTL), not a guess.

A change process that prevents the repeat

• Lower the TTL first for records you are about to change, and wait out the old TTL (the cutover method in a planned migration).
• Stage it: weighted or percentage-based DNS routing (the DNS service hands out the new address for only a set share of queries and the old one for the rest) for 1 to 5 percent of traffic first, so a bad answer reaches a small fraction and rolling back has a small tail.
• Lint and diff before publishing: zone-file checks (named-checkzone) and a reviewed diff of what will change; treat warnings as failures where they matter.
• Verify from outside: automated probes that query the authoritative servers and a few public resolvers right after publish and compare to expectations, with an automatic revert decision.
• Make rollback a first-class step: the previous record set is stored, the rollback is rehearsed, and the old target stays up for at least one old TTL after any change.

Pitfalls

• "We rolled back" is not the same as "users are fixed". The metric to watch is the share of successful resolutions seen from outside, over time.
• Resolver TTL clamps and application caches make an exact end time unknowable, so say "by about" and keep measuring.

Direct answer
Building reliability on top of UDP means implementing, by hand, the exact machinery TCP gives you for free: a sequence number to detect duplicates, explicit acknowledgments, and a retransmission timer. A single-bit (0/1) sequence number is enough for stop-and-wait specifically, because only one message is ever in flight at a time.

Structured elaboration (approach)
send_reliable sends the payload tagged with the current sequence bit, then blocks (with a timeout) waiting for a matching ACK; on a timeout it just resends the same packet, and on receiving an ACK for the WRONG sequence number (a stale ACK from a previous round) it keeps waiting rather than treating that as success. receive_reliable accepts a packet, immediately ACKs it (even if it's a duplicate, in case its own previous ACK was lost), and only hands NEW data (matching the expected next sequence bit) up to the caller, silently absorbing duplicates.

Worked example (code)

import socket, struct

HEADER = struct.Struct("!BB")  # (sequence bit, type: 0=DATA, 1=ACK)

def send_reliable(sock, dest, payload, timeout, max_retries=5, state={"seq": 0}):
    seq = state["seq"]
    packet = HEADER.pack(seq, 0) + payload
    sock.settimeout(timeout)
    for _ in range(max_retries):
        sock.sendto(packet, dest)
        try:
            data, addr = sock.recvfrom(4096)
        except socket.timeout:
            continue  # retransmit on timeout
        if len(data) < HEADER.size:
            continue
        ack_seq, ack_type = HEADER.unpack(data[:HEADER.size])
        if ack_type == 1 and ack_seq == seq:
            state["seq"] = 1 - seq
            return True
    return False

def receive_reliable(sock, state={"expected_seq": 0}):
    while True:
        data, addr = sock.recvfrom(4096)
        if len(data) < HEADER.size:
            continue
        seq, pkt_type = HEADER.unpack(data[:HEADER.size])
        if pkt_type != 0:
            continue
        payload = data[HEADER.size:]
        sock.sendto(HEADER.pack(seq, 1), addr)  # always ACK, even duplicates
        if seq == state["expected_seq"]:
            state["expected_seq"] = 1 - seq
            return payload, addr
        # else: duplicate, already ACKed above, loop for the real next message

This was executed against a deterministic loss-simulating wrapper (a UDP socket wrapper that drops a configurable fraction of outgoing packets using a seeded random generator, so the test is reproducible) sending 4 messages at loss rates of 0%, 30%, and 60%. At every loss rate tested, all 4 messages were delivered exactly once, in the original order, confirming both the retransmit-on-timeout path and the duplicate-suppression path work correctly under real, repeated loss.

Trade-offs & pitfalls (edge cases and complexity)
Complexity: with a single sequence bit and no pipelining, stop-and-wait can send only ONE unacknowledged message at a time, so throughput is bounded by one round trip per message (a real reliability layer would need a sliding window of sequence numbers, not just one bit, to use a high-bandwidth-delay-product link efficiently, exactly the same motivation as TCP's own window). Edge cases handled: a lost DATA packet (sender times out, retransmits), a lost ACK (receiver gets a duplicate DATA packet, re-ACKs it without re-delivering the payload to the application), and a delayed ACK arriving after the sender has already given up and retransmitted (the sender must ignore an ACK for the WRONG sequence number rather than treating it as confirmation, otherwise a stale ACK could be mistaken for acknowledging the NEXT message). What this exercise demonstrates: TCP is doing exactly this kind of bookkeeping (and much more, for a full sliding window, congestion control, and out-of-order buffering) on every connection, for free.

Direct answer

The core move in an incident explanation to a non-technical audience is separating three layers up front: what happened (in plain terms, no root-cause mechanism), what it meant for them (impact, in terms they already track), and what's being done about it, then deliberately leaving out anything that doesn't serve one of those three. Below is an incident where I did that under time pressure, including delivering it live to a mixed engineering-and-business audience.

What to include, what to leave out, and how to decide

• Lead with impact, not sequence. Legal, sales, and executives care about what happened TO THEM first, which customers, how long, what's the exposure, the technical timeline is useful evidence, not the headline.
• Deliberately exclude logs, stack traces, and internal service names; they add authority for an engineering audience and add nothing but confusion for this one. A useful test: if a detail doesn't change what the listener should do next, leave it out.
• Give the cause in one plain sentence with no jargon, something like "a recent configuration change made one of our systems too slow to respond to a partner service in time," rather than either omitting cause entirely (which reads as evasive) or over-explaining the mechanism.
• When delivering this live rather than in a written report, whether it's a hallway update or presenting a postmortem verbally to a room that mixes engineers and business stakeholders, pause after the impact statement for questions before moving to cause. People worried about impact can't absorb a root-cause explanation until that worry is addressed first.

Worked example

Situation: during a high-traffic sales period, our payment service began intermittently failing checkout requests for roughly ninety minutes. Legal, sales leadership, and the executive team needed an explanation quickly.

Task: explain what happened clearly enough for them to act, communicate with affected customers, assess any obligations, decide on immediate next steps, without either alarming them with irrelevant detail or minimizing the impact.

Action: I opened with impact, in the terms they track: which customers were affected, for roughly how long, and that the issue was fully resolved and being watched closely. I gave the cause in one sentence: a recent configuration change made our payment service too slow to respond to our external payment gateway in time, causing some checkout attempts to fail. I described what we did in plain terms (reverted the change, increased how long we wait before giving up on a slow response, added an automatic circuit breaker so a slow dependency can't cascade into a wider outage) and what we were doing next (a deeper review, with a fuller technical writeup available to anyone who wanted it). I left out the specific error codes, service names, and configuration parameter, none of which changed what legal, sales, or the executives needed to do next. I paused for questions right after the impact statement, before moving on, and answered a legal question about customer notification obligations directly instead of routing it back to engineering jargon.

Result: legal and sales left with a clear, accurate picture of exposure and could communicate confidently with affected customers; the executive team approved the follow-up work (the circuit breaker and review) without needing to dig into implementation detail themselves, and a fuller technical postmortem was made available separately for the engineering team that wanted the mechanism-level explanation. I learned that pausing for questions right after the impact statement, before cause, kept people from tuning out a cause explanation they weren't ready to hear yet.

Trade-offs and pitfalls

Leaving out technical detail can read as evasive if you do it silently; I said "I'm not going to walk through the technical internals here, I'm glad to share those separately" so the omission was visible on purpose rather than hidden. The other pitfall is understating severity to keep the room calm, that erodes trust the moment the real scope becomes clear later. State the honest impact even when it's uncomfortable, and let the "what we're doing about it" section carry the reassurance instead of the impact statement itself.

Direct answer

Spanning tree is the protocol that stops loops in a switched network by electing one switch as the root bridge (the reference point, the one with the lowest bridge ID: the priority number first, with the MAC address as the tie-break) and blocking every redundant port so each switch keeps a single forwarding path toward the root. A pod is a group of racks built and managed as one unit, and a ToR (top-of-rack) switch is the switch at the top of each rack that the servers plug into. Spanning tree hurts at pod scale because it makes redundancy cost bandwidth: it blocks every redundant link so each switch has one forwarding path to the root bridge, which means half of dual-homed uplink capacity sits idle, and a topology change can disturb forwarding while it reconverges. For the access layer I would put a multi-chassis link aggregation (MLAG, called vPC, virtual PortChannel, on Cisco Nexus) pair at the top of each rack, with servers dual-homed using LACP (Link Aggregation Control Protocol, which bundles several cables into one logical link) and ToR uplinks routed (each uplink is a layer 3 point-to-point link with its own IP address, and the routing protocol spreads traffic over all equal-cost uplinks, so there is no layer 2 loop to block) or aggregated into a port-channel, so every link forwards and failure is handled by link aggregation, not by a spanning-tree recalculation. I would still keep spanning tree running as a safety net on edge ports to stop a mistaken cable from causing a loop, and keep it as the main mechanism where a legacy switch or a device without LACP support must attach with redundant links.

Where spanning tree hurts (computed example)

Spanning tree (Cisco defaults to Rapid PVST+ on Catalyst 9000, with bridge priority 32768 and port priority 128) forces redundant paths into a blocked state. Example: a pod where each of 20 access switches has two 40G uplinks to two aggregation switches. Under a single spanning tree shared by all VLANs (or per-VLAN trees that all have the same root), one uplink per switch forwards: usable = 20 x 40G = 800G of 1,600G installed, 50%. Per-VLAN trees (PVST+, one tree per VLAN) or multiple spanning tree (MST, one tree per group of VLANs) can alternate the blocked link per VLAN. Concretely, with 20 VLANs, make aggregation switch 1 the root for VLANs 1 to 10 and aggregation switch 2 the root for VLANs 11 to 20: on each access switch the uplink to switch 1 forwards VLANs 1 to 10 and blocks 11 to 20, and the uplink to switch 2 does the opposite. Each 40G uplink carries 10 VLANs, so both are used and, if the VLANs carry equal load, the pod uses its full 1,600G on average. It recovers capacity on average, but any one VLAN (and so any single large flow in it) still has only one 40G path, and the load balance is a manual VLAN-to-root assignment that drifts as workloads move.
Other costs at scale:

• Blocked links are not tested by traffic until failure, so a bad standby link surfaces during an outage.
• Root election is fragile: a switch added with a lower bridge priority value than the intended root wins the election and reshapes the whole tree.
• Large single broadcast domains and many VLANs on shared trees amplify any mistake into a pod-wide event.

What to use instead, at layer 2

When I would still keep spanning tree

1. Always on edge ports as a protection: PortFast (moves the port straight to forwarding) plus BPDU guard (error-disables the port if it receives spanning-tree messages), configured with spanning-tree portfast and spanning-tree bpduguard enable on Cisco, or globally with spanning-tree portfast default (PortFast on all non-trunking access ports) plus spanning-tree portfast bpduguard default (BPDU guard on PortFast ports; the second command alone does not turn PortFast on). A server NIC bridge or a stray switch then cannot create a loop.
2. As the main protocol where it is the only safe option: attaching a legacy switch with redundant links to the pod, a small branch or lab pod where two cables are the entire redundancy need, or a device that cannot run LACP.
3. Root guard (spanning-tree guard root) and a deliberately set root where access switches connect to a shared layer.

Pitfalls

• Disabling spanning tree entirely "because MLAG is loop-free": a miscabled port-channel or a bridged server then floods the pod.
• Treating MLAG as free: it couples two switches' software versions and makes the peer link critical.
• Mixing MST and PVST+ domains without checking the root placement.
• Believing the hashing balances evenly: the hash (a fixed recipe that turns address bits into a link number) sends every frame of one flow down the same link so frames stay in order, which is why a few large flows can still fill one member link.

Direct answer

Front the design with load balancers spread across two availability zones (AZs) for both scale and failover, put the web and application tier in a subnet per AZ reachable only through the load balancer, keep the database tier in a private subnet per AZ reachable only from the application tier, and size each tier so that losing one entire AZ still leaves enough capacity in the surviving AZ to serve the 10,000-requests-per-second (RPS) target.

Structured elaboration

Tiers and subnets, duplicated per AZ.

• Public subnet: load balancers only, terminating HTTPS/TLS (Transport Layer Security), health-checking the tier behind them.
• Demilitarized zone (DMZ) subnet: web and application servers, reachable from the load balancer on the application port only, never directly reachable from the internet.
• Private subnet: database tier, reachable only from the DMZ subnet's application servers on the database's own port.

flowchart TB
    subgraph AZ1[Availability Zone 1]
        LB1[Load balancer] --> WEB1[Web app tier]
        WEB1 --> DB1[Database tier]
    end
    subgraph AZ2[Availability Zone 2]
        LB2[Load balancer] --> WEB2[Web app tier]
        WEB2 --> DB2[Database tier]
    end
    INET[Internet] --> LB1
    INET --> LB2

Firewall rules between tiers. Load balancer to web/application tier: allow only the application's listening port. Web/application tier to database tier: allow only the database's own port. An explicit deny applies to everything else at each boundary, identically in both AZs, so failover into the surviving AZ does not quietly relax the security posture there.

NAT/load-balancer placement. The load balancer is the only internet-facing component; application servers have no public address at all and are reachable only through the load balancer's private-subnet path. Outbound internet access the application or database tiers might still need, for patching or package repositories, goes through a NAT gateway per AZ rather than a public address on those tiers directly, keeping inbound exposure (nothing but the load balancer) and outbound exposure (routed and still filterable) deliberately asymmetric.

Health checks. The load balancer's health check should exercise a real application endpoint, not just confirm the port is open, and health checks should run per AZ so the load balancer can route traffic away from an unhealthy AZ's instances without waiting for an explicit failover event.

Minimizing attack surface while meeting the scale target. Transport Layer Security terminates at the load balancer, optionally re-encrypting to the backend for defense in depth, so the DMZ subnet and the internet only ever exchange encrypted traffic and certificate management lives in one place rather than scattered across every instance. Only the load balancer ever has a public listener; the web/application and database tiers have zero public addresses; and administrative access to any tier goes through a separate bastion path, not through the same subnets serving customer traffic.

Worked example

Illustrative capacity math, explicitly an assumed input rather than a measured benchmark: suppose each web/application instance can sustain roughly 500 requests per second before its own response-time service-level objective (SLO) degrades. Serving 10,000 RPS from a single AZ then needs about 10,000 divided by 500, which is 20 instances. For the design to survive losing one AZ entirely and still serve the full 10,000 RPS from the surviving AZ alone, that AZ's own capacity needs to already be sized (or able to scale quickly) to roughly 20 instances on its own, meaning close to 40 instances total across both AZs if the organization wants that headroom running in steady state rather than scaling reactively during the failure. That capacity-versus-cost decision has to be made explicit rather than assumed away by simply saying "two AZs."

Trade-offs and pitfalls

Sizing each AZ for only half of the 10,000 RPS target, with no failover headroom, means an AZ failure causes a real capacity shortfall exactly when it can least be afforded, so having two AZs alone does not guarantee availability unless capacity is planned for the failure case specifically. Giving application servers public addresses "just for easier administrative access" defeats the entire point of the DMZ design and is a common shortcut under deadline pressure. Forgetting that the load balancer itself needs to be deployed redundantly across both AZs leaves a single point of failure even when everything behind it is properly duplicated. A health check that only confirms a port is open, rather than real application health, will happily keep routing traffic to a broken instance.

Direct answer

For a concrete question like "which flows are retransmitting the most" or "what's the per-flow handshake latency," script it with a pcap-parsing library (Python's scapy, or shelling out to tshark's field-extraction mode) rather than opening captures by hand; the key engineering concerns are correctness (handling out-of-order and duplicate packets) and scale (not loading an entire large capture into memory at once).

Structured elaboration

1. Choose the extraction path: tshark -r file.pcap -T fields -e ip.src -e ip.dst -e frame.len streams field values without building Python objects for every packet, and scales best for very large captures; scapy's PcapReader (as opposed to rdpcap) reads packets one at a time, which is the right choice when you need custom logic per packet in Python.
2. Aggregate incrementally: keep running totals in a dictionary keyed by the flow tuple (source IP, destination IP, and for TCP also ports), rather than storing every packet, so memory use stays flat regardless of capture size.
3. Handle multiple capture points and out-of-order packets explicitly: if flows are captured at more than one point in the path, do not assume packet order in the file matches wall-clock order; sort by timestamp within each flow before computing anything that depends on ordering (like handshake latency, which needs to match a SYN to its SYN-ACK, not just the Nth and N+1th packet).
4. Validate against a known-answer capture before trusting the script's output on real production data.

Worked example

Here is a minimal top-talkers-by-bytes script, executed against a synthetic 60-packet capture (3 flows) built with scapy for this validation:

from collections import defaultdict
from scapy.all import PcapReader, IP

def top_talkers(path, n=10):
    counts = defaultdict(int)
    byte_totals = defaultdict(int)
    with PcapReader(path) as reader:
        for pkt in reader:
            if IP in pkt:
                key = (pkt[IP].src, pkt[IP].dst)
                counts[key] += 1
                byte_totals[key] += len(pkt)
    return sorted(byte_totals.items(), key=lambda kv: kv[1], reverse=True)[:n]

Run against the test capture, this correctly reported two flows: 10.1.1.10 -> 10.2.2.20 with 40 packets totaling 28,700 bytes, and 10.1.1.11 -> 10.2.2.21 with 20 packets totaling 11,700 bytes, matching the known composition of the synthetic file exactly. For handshake-latency specifically, the same pattern applies but keyed by the full 4-tuple, matching each SYN to the SYN-ACK sharing its source/destination ports and computing the timestamp delta.

Trade-offs & pitfalls

Loading an entire multi-gigabyte capture with rdpcap (which reads the whole file into memory as a list) is a common and expensive mistake; use a streaming reader instead. When captures come from multiple points, do not assume a packet appearing in one capture but not another means it was dropped; capture loss at the tap/collection point itself is a real, separate failure mode from network packet loss, and conflating the two produces wrong conclusions.

Direct answer

A strong pre-interview research plan works from the most authoritative sources outward: company-controlled material first (site, blog, filings), then people-and-code sources (LinkedIn, GitHub), then outside voices (news, reviews), synthesized into a short brief with the one or two findings that would most change your approach flagged as open questions to raise or confirm.

Structured elaboration

What to pull from each source:

• Engineering or product blog: what they're building and what they've recently launched or pivoted away from. Tells you current priorities, not just stated ones.
• LinkedIn: team size and growth trend, who the hiring manager's other reports are, recent hires or departures (a churn signal), and the seniority mix of recent hires.
• GitHub (if they have public repos): commit cadence, open-issue volume and age, contributor count. This is a proxy for engineering health and how much attention a given system gets.
• Public filings (a 10-K or 10-Q, the annual and quarterly financial reports public companies must file with regulators) or funding announcements for a startup: which business segment is growing, headcount trends, and risks the company names about itself.
• Recent news: layoffs, funding rounds, leadership changes, or product launches, which tell you whether the team is likely riding a tailwind or working through a headwind.

Most of what you find is context. Two findings are worth naming explicitly as the ones that would change how you approach the role, because they change what you do, not just what you know:

• The red flag that matters most: departures concentrated in the team you'd join. Not company-wide churn, which usually reflects the market, but several people at your level leaving that one team within a couple of quarters, especially alongside a posting that has been re-listed. That pattern points at the team rather than the industry. It changes your approach from selling yourself to diligence: you'd want the hiring manager's own account of what changed and who left, and you'd weight what individual engineers say about it far above what the recruiter does.
• The positive signal that matters most: recent, specific, public evidence the team ships. A dated engineering post describing a system they actually built and what went wrong, a changelog with real entries rather than "bug fixes," a conference talk by someone still there. Claiming a culture of ownership is free; a public record of shipping is expensive to fake. This one raises how much scope you'd be willing to take on at the stated level, rather than negotiating for a safer, narrower remit.

Two things also matter more than any single source:

1. When sources conflict, don't average them. If LinkedIn shows fast headcount growth but reviews mention understaffing complaints, hold both as live hypotheses and pick the one interview question that would resolve the conflict, rather than quietly picking whichever story you like better.
2. Synthesize into something short you'd actually use. A one-page brief (mission in one line, likely challenges ranked, two or three open questions) beats a folder of tabs you never revisit.

Worked example

Say you're interviewing for a Backend Developer role at a mid-size fintech company. The blog's last three posts are about migrating a monolith to services. LinkedIn shows engineering headcount growing noticeably over the past year, and most recent hires are titled "Senior," none "Staff." Their one public GitHub repo, a customer-facing SDK (software development kit, a packaged set of tools other companies use to integrate with a product), has a large number of open issues, the oldest well over a year old. News shows a funding round closed several months ago.

Reading this together: the funding round is the likely reason the headcount line moved, which makes this growth a funded plan rather than a churn backfill, and senior-heavy hiring during a service migration suggests they need people who can operate with less hand-holding. Those two together are the positive signal, and they're worth saying out loud because they tell you the role is probably real scope rather than a replacement seat. The stale open-source issues on a customer-facing SDK is the actual red flag worth raising, not as a criticism, but as a genuine question: is that repo neglected, or intentionally deprioritized while the team focuses elsewhere? Note it isn't a strong enough flag to change whether you'd take the role, only what you'd ask.

Trade-offs and pitfalls

The most common mistake is treating any single source as ground truth, LinkedIn headcount counts are noisy (they include inactive profiles and contractors), so weight repeated, specific signals over one-off numbers. It also helps to say your assumptions out loud early in the process, whether to the recruiter or the hiring manager, rather than presenting inference as settled fact, since that's what catches a wrong read before it steers your whole set of questions in the wrong direction. A related failure is collecting a fact and then never using it, if the funding round or the layoff never shows up in your reading of the team, it wasn't research, it was browsing. Finally, don't let the research become the performance itself, its job is to sharpen two or three real questions, not to be recited back verbatim.