FAANG-Standard Interview Preparation Guide: Network Engineer, Staff Level

Direct answer

When a stakeholder chooses gut over your recommendation, the first job is to figure out whether that's stubbornness or a legitimate competing priority you haven't accounted for, like protecting a release timeline, and then reframe the case around what they're actually protecting, rather than simply repeating the data louder or overriding the objection because you believe you're right.

Structured elaboration

Step 1: diagnose before you reframe. "Going with my gut" usually means one of two things: they don't trust the data, or they trust it fine but are weighing it against something you haven't priced in, like a release date, a relationship, or a risk you don't see. These require different responses. Reframing only works on the second case; on the first, you need to rebuild trust in the data before framing matters.

Step 2: distinguish reframing from overriding. If the resistance turns out to be a legitimate competing priority, for example a PM protecting a release timeline that a delay would blow up, the senior move is not to win the argument and get your way anyway. It's to treat the timeline as a real constraint to negotiate against, not an objection to defeat. Overriding a reasonable objection with a stronger-sounding data point isn't persuasion, it's just louder; it also tends to win the room and lose the relationship.

Step 3: the reframe, in practice.

1. Listen and validate: ask what's driving the instinct and what they're weighing, specifically. This often surfaces the real constraint (a deadline, a prior bad experience, a political consideration) that the data alone never addressed.
2. Restate the shared goal: get explicit agreement on the metric that actually matters, so the conversation isn't "my data vs. your gut" but "how do we both hit the same target."
3. Present evidence against that shared goal, briefly, including where it's uncertain, not just where it's favorable.
4. If the blocker is a legitimate priority like a release timeline, negotiate against it directly: propose a version of your recommendation that doesn't threaten the thing they're protecting, for example a smaller pilot that fits inside the existing timeline rather than a change that would slip it.
5. Offer a low-risk test with a clear decision gate, so the disagreement gets resolved by a result instead of by who argued better.

Worked example

Situation: a product manager wants to launch a promotional push on gut instinct; the leading indicators (early signals, like click-throughs and signups, that show up well before the final conversion numbers do) suggest low conversion probability, and the recommendation is to wait for more signal.

In the room: instead of restating the data more forcefully, the first move is a clarifying question: "is the concern that the data's wrong, or that waiting costs us the launch window?" The PM's answer reveals it's the second: the campaign is tied to a release date that can't move without a real cost. That reframes the whole conversation, this isn't stubbornness, it's a legitimate competing priority.

The reframe: instead of "wait until we have better signal," the proposal becomes a scoped, two-week pilot that launches inside the existing window on a smaller segment, with clear success criteria, so the PM's timeline is protected and the analyst's concern about weak signal gets tested rather than ignored.

Resolution: the PM agrees to the pilot because it doesn't cost them the thing they were actually protecting. The disagreement gets resolved by what the pilot shows, not by whoever had the stronger-sounding argument in the room.

Trade-offs & pitfalls

• Treating every "gut" objection as stubbornness to be argued down is the most common miscalibration here; a good chunk of the time it's a real constraint you simply hadn't modeled.
• Overriding a stakeholder because your data is defensible can win the individual decision and still damage the relationship, making the next disagreement harder.
• Not every gut call is protecting something legitimate; if the "priority" turns out to be unfounded once probed, the reframe should say so directly rather than inventing a compromise that doesn't need to exist.
• A pilot or compromise that doesn't actually test the disagreement (a token concession) just defers the same argument to a later date.

Direct answer

Strong on-call ownership shows up before an alert ever fires, in deliberate preparation, in a clear way of establishing scope and severity before diving into root cause, in a defined point at which you escalate rather than getting stuck alone, and in a handover specific enough that the next person is not starting from a blank slate.

Structured elaboration

1. Preparing before the shift: review current known issues and any recent changes (a config push, a maintenance window) that could plausibly matter, so you are not learning about an active risk for the first time in the middle of an incident. Confirm every tool and escalation contact you might need actually works before the shift starts, not after a page has already arrived.
2. Triaging and responding to alerts: on any alert, establish scope and severity first, whether this is affecting a small segment or something broad, whether it is degrading or fully down, before diving into root cause, since scope is what actually determines urgency and who else needs to know right away. Apply the runbook for known alert types; for anything unfamiliar, prioritize restoring service, a safe rollback or failover, over fully diagnosing root cause while the clock is running.
3. Escalating: escalate when the issue needs access or authority you do not have, when the runbook's suggested fix does not resolve it within the time it is expected to, or when the blast radius (how far the impact has already spread, one region versus many, one service versus several) is growing faster than you can contain it alone. An escalation includes the concrete state: what is affected, what has already been tried, and what is specifically needed.
4. Handover at the end of the shift: hand off a specific list, not a verbal sense that it was quiet, covering anything still open or being watched closely, anything changed during the shift (a config tweak, a temporary mitigation that still needs a permanent fix), and anything learned that is not yet reflected in the runbook.

Worked example

Before the shift starts, the change log shows a routing configuration was pushed the previous evening; that becomes the first thing to check if anything routing-related alerts, rather than starting from zero. Mid-shift, an alert fires for elevated packet loss on one regional link. Triage first: scope is confirmed as one region, not global, and severity is degraded rather than fully down. Given the timing, the prior evening's routing change is the most likely candidate, and it is: reverting that specific change on the affected link resolves the packet loss within the window that change is expected to take effect, without needing to escalate further. If the revert had not resolved it within that window, or if the packet loss had started spreading to additional regions while it was being investigated, that is exactly the trigger to escalate to the network team lead with the specific blast radius and what had already been tried. End-of-shift handover notes the config change that was identified and reverted, flags that the same change still needs a proper root-cause fix before it is ever reapplied rather than being left quietly reverted indefinitely, and confirms no other alerts remain open.

Trade-offs and pitfalls

Skipping the pre-shift review loses the fastest available path to root cause, since recent changes are disproportionately likely culprits when something new breaks. Treating every alert with the same urgency regardless of scope either under-reacts to something that is actively spreading or over-escalates something genuinely minor. And handing over a shift with a vague sense that everything was fine, instead of the specific state, changes, and open items, leaves the next person with far less than they actually need.

Direct answer

When a meeting spirals into people repeating themselves louder, the first move isn't to solve the disagreement, it's to interrupt the pattern: name what's happening out loud, and swap open-ended debate for a short, structured process that separates facts from opinions. That alone usually resets the room enough to get back to a decision.

Structured elaboration

• Interrupt and name it. "We're going in circles, let's reset for a minute" is a deliberate, calm pattern-break, not an apology for stopping people.
• Restate the actual goal. Remind the room what decision you're there to make, since heated debates drift from making a decision to relitigating opinions.
• Structure the next few minutes. Short, timeboxed turns, and a "parking lot" for points that matter but aren't decision-relevant right now.
• Separate decision from design. Agree on the narrow decision needed today, and explicitly defer the bigger architectural or process debate to its own session.
• Close with owners and a written follow-up, so the room doesn't need to re-litigate whether an agreement even happened.

Worked example

In a deployment review, two engineers were arguing over whether to roll back a risky release, talking over each other and re-arguing the same points past the meeting's scheduled time. I paused the discussion, said we were stuck in a loop, and restated the actual question: roll back, or mitigate with a smaller change, and what evidence would tell us which. I set a short structure: one person at a time for two minutes, facts (error rate, affected traffic) captured on a shared screen, opinions parked for later. Someone pulled the live error dashboards while I tracked action items. We landed on a temporary mitigation, routing a slice of traffic away from the new version, rather than a full rollback, with the bigger architecture question deferred to a dedicated design conversation the following week. I wrote up the decision and mitigation steps right after so there was no ambiguity about who owned what.

Trade-offs and pitfalls

Interrupting too early can shut down a disagreement that still had useful signal in it, so it's a judgment call, not a reflex the moment voices rise. If you do this often to the same people, it can start to feel like being silenced rather than facilitated, so pair it with genuinely giving the parked issues a real forum later, not letting the parking lot become where ideas go to die. And a smooth-sounding meeting is not the same as a resolved disagreement: the follow-up (a postmortem, a retro, a 1:1) is where the real repair happens, not the room where you kept things calm.

Direct answer

HSRP (Hot Standby Router Protocol) lets two routers share one virtual gateway address, 10.50.0.1, with one router Active (forwarding) and one Standby (ready to take over). To make Router1 preferred and to make it reclaim the role after it recovers, give it a higher priority than Router2 and enable preempt on it. On failure, Router2 goes Standby to Active; on recovery, Router1 goes through Init, Listen and Speak and then takes Active back (with the 60 second preempt delay configured below it normally waits as Standby first), and Router2 returns to Standby.

Configuration

Router1 (preferred):

interface GigabitEthernet0/0/0
 ip address 10.50.0.2 255.255.255.0
 standby 1 ip 10.50.0.1
 standby 1 priority 110
 standby 1 preempt delay minimum 60

Router2 (default priority):

interface GigabitEthernet0/0/0
 ip address 10.50.0.3 255.255.255.0
 standby 1 ip 10.50.0.1
 standby 1 preempt

• Priority range is 1 to 255 and the default is 100, so 110 beats Router2's 100.
• preempt makes a router with a higher priority than the current Active take over. Preempt is not implied by a higher priority alone: it has to be configured.
• delay minimum 60 makes Router1 wait 60 seconds before taking over the Active role, so routing and switching have time to settle after a reboot. The delay range is 0 to 3600 seconds and the default is 0.
• Hosts use 10.50.0.1 as default gateway. With HSRP version 1, group 1 uses virtual MAC 0000.0C07.AC01 (the Layer 2 address that goes with the virtual IP), and the new Active router takes over that same MAC, so the ARP entry hosts cache (their IP-to-MAC mapping) stays valid through a failover.
• Router2 also gets preempt so the pair behaves symmetrically: if Router1 is Active but its priority later falls below 100 (for example through tracking, covered in the pitfalls), Router2 can only take the role from it if Router2 has preempt configured.
• Defaults: hello 3 seconds, hold time 10 seconds.

Role transitions

HSRP states are Init, Learn, Listen, Speak, Standby and Active.

What the messages mean (RFC 2281): a Hello says the router is running and can become Active or Standby, a Coup says it wants to become Active, and a Resign says it no longer wants to be Active. Speak is the state where a router sends hellos and takes part in electing Active and Standby. A router that has not yet learned the virtual IP waits in Learn; here the address is configured, so Router1 goes straight from Init to Listen.

Timing of the failure case: Router2 declares Router1 dead 10 seconds after the last hello it received. Hellos arrive every 3 seconds, and Router1 can fail anywhere in that interval, so takeover happens between 7 and 10 seconds after the failure. If you need faster takeover, shorten hello and hold times (Cisco's command reference allows millisecond hello timers from 15 to 999 ms and recommends hold times under 250 ms only on Cisco 7200-class or better platforms and on Fast Ethernet or faster interfaces).

Verification

show standby brief on both routers. Expected stable output on Router1: group 1, priority 110, state Active, virtual IP 10.50.0.1. show standby gives the long form, including Preemption enabled and the Active virtual MAC address. After failing Router1, Router2's state should read Active. Test by pinging 10.50.0.1 from a host during the event.

Pitfalls

• Forgetting preempt on Router1: when it returns it stays Standby and Router2 keeps the Active role indefinitely, which is the opposite of what was asked.
• Preempt with no delay: Router1 can become Active before its uplink routing is ready, black-holing traffic (accepting packets it cannot forward, so they vanish). Tracking an object that follows the uplink (standby 1 track <object> decrement 20, which lowers the priority by 20 while the tracked object is down, taking 110 to 90, below Router2's 100) makes it give up Active when its uplink fails.
• HSRP watches the interface it runs on, not the path beyond it; without tracking, hosts keep sending to an Active router that has lost its uplink.

Direct answer
Culture fit asks whether you already share a team's existing norms and behaviors; culture add asks what you would bring that the team does not already have. I would describe myself mostly as a culture add: I share the fundamentals a team needs to trust me (reliability, candor, respect for other people's time), but the useful thing I offer beyond that is a genuinely different working background rather than a mirror of the team that is already there.

Structured elaboration

1. Define both terms precisely before answering for yourself. Culture fit is about alignment on shared behaviors and values: does this person operate the way we already operate. Culture add is about complementary difference: does this person's background, working style, or perspective fill a gap the team doesn't currently have.
2. Explain why the distinction matters, not just define it. A team optimized purely for fit tends toward groupthink: everyone reasons the same way, so blind spots go unchallenged and the same kinds of mistakes recur. A team that only adds without any shared fit becomes uncoordinated: people can't predict each other's reasoning enough to move fast together. The healthy target is fit on a small number of load-bearing behaviors (honesty, follow-through, respect) plus deliberate add on everything else.
3. Give a genuine, specific example of your own add, not a generic trait. Vague claims ("I bring diverse perspectives") are the single most common failure mode here; a strong answer names the concrete gap and the concrete evidence.
4. Anticipate the natural follow-up: how do you know your difference is actually useful, versus just different for its own sake. The answer is to point at a specific decision, disagreement, or piece of feedback that changed because of the difference you brought, not just a credential or background fact.

Worked example
Suppose your last two teams were both product engineering teams building consumer-facing features, and the team you're interviewing for is mostly staffed by engineers with that same background. Your own prior role was on a data-platform team, closer to the systems that feed those consumer features than to the features themselves. A concrete add-story: in a past project, a product team wanted to ship a new recommendation feature quickly; because of your platform background, you asked a question the rest of the team hadn't raised (whether the upstream data pipeline's freshness guarantees actually matched what the feature's UI implied to users), which surfaced a real gap between a 24-hour batch refresh and a UI copy that said "updated just for you." The team fixed the copy and adjusted the refresh cadence before launch rather than after a user complaint. That is a genuine add: a different background produced a question the existing team composition was less likely to ask on its own, and it changed a real outcome.

Trade-offs & pitfalls
The common failure is answering only the definitional half (correctly explaining fit versus add) and then, when asked for a personal example, retreating to generic self-description ("I'm a good communicator", "I care about quality") that any candidate could say and that does not actually demonstrate difference. A second pitfall is overcorrecting into implying you don't fit at all; the strongest answers are explicit that you also share the small set of behaviors every functioning team needs, and that add is about everything on top of that baseline, not a replacement for it.

Direct answer

Work from the physical layer up, and compare both ends at each step: link state and speed, then the negotiation mode and protocol (LACP or PAgP), then member-port consistency (speed, duplex, access VLAN or trunk settings, native VLAN, allowed VLANs), then the port-channel interface itself. Members get suspended when the switch detects a mismatch, so the first command on both sides is show etherchannel summary. When members sit on different physical switches, ordinary EtherChannel (Cisco's name for bundling several physical Ethernet links into one logical link, which Cisco describes as fault-tolerant and high-speed) does not work unless those switches act as one logical device (a switch stack, or a multichassis feature such as vPC on Nexus).

LACP (Link Aggregation Control Protocol, labelled IEEE 802.3ad in Cisco's guide; link aggregation is now specified in IEEE 802.1AX) is the standard negotiation; PAgP (Port Aggregation Protocol) is Cisco's proprietary one.

Ordered checks (do each on both switches)

1. State and flags. show etherchannel summary. The letters that matter first are P (healthy, bundled), s (suspended, a configuration mismatch) and D (down); the rest are secondary. Illustrative output in Cisco's format, with one member suspended:

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         LACP      Gi1/0/47(P)  Gi1/0/48(s)

Read it left to right: group 1 is Po1, flags S and U mean a Layer 2 channel that is in use, the protocol is LACP, and member Gi1/0/47 is bundled (P) while Gi1/0/48 is suspended (s), so compare Gi1/0/48's configuration against Gi1/0/47's. Cisco's full flag legend: P is bundled in the port-channel, s is suspended, I is stand-alone (the port is not in any bundle), D is down, H is hot-standby (LACP only), w is waiting to be aggregated, M means not in use because minimum links are not met, u is unsuitable for bundling, d is the default port, f is failed to allocate aggregator, A is formed by Auto-LAG. U on the port-channel means in use, S means Layer 2, R means Layer 3. An (SD) port-channel is a Layer 2 channel that is down; (SU) is up.
2. Physical. show interfaces status: are all members connected and the same speed and duplex? One member at a different speed will not bundle with the others.
3. Negotiation modes. In LACP, active talks first and passive only answers: active-active and active-passive form a channel, passive-passive never does. In PAgP, desirable and auto follow the same pattern. Mode on forms a channel only against another on, with no negotiation. LACP and PAgP cannot interoperate, so one side set to PAgP (desirable or auto) and the other to LACP stays down. Check channel-group <n> mode ... in the config on both sides, and channel-protocol if used.
4. Member consistency. The ports must share the same speed and duplex, the same access VLAN or the same trunk configuration, the same native VLAN, and the same allowed VLAN list. Cisco states that when misconfigurations are detected in a port mode or VLAN mask, the ports are suspended. In the same-trunk-settings line, native VLAN means the VLAN whose frames cross the trunk untagged, and the allowed VLAN list is the set of VLANs the trunk may carry. Compare show running-config interface for each member against the others and against the far end.
5. LACP view. show lacp neighbor (does the partner answer, with which system) and show lacp internal (local state of each member), and show etherchannel <n> detail for per-port detail.
6. Port-channel interface. Configuration on the port-channel interface applies to all members, while changes on one physical port apply to that port only, so put the trunk and VLAN settings on the port-channel and keep members identical. Check the port-channel's trunk allowed list against the far end's.
7. Limits. An LACP bundle can have up to 16 member ports, of which at most eight are active and up to eight are hot-standby (flag H). A ninth link that sits in standby is by design, not a fault. Hot-standby means ready to join the bundle if an active member fails. A separate minimum-links setting can require a minimum number of healthy members before the channel is used; below it the flag is M.

Typical fixes

interface GigabitEthernet1/0/47
 switchport mode trunk
 channel-group 1 mode active
interface GigabitEthernet1/0/48
 switchport mode trunk
 channel-group 1 mode active
interface Port-channel1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,40

The same channel-group 1 mode active (or passive on one side) on the far switch, with the same trunk settings, makes show etherchannel summary show the members with flag P.

Members on different physical switches

Plain EtherChannel assumes every member goes to the same partner device, so two separate switches look like two different partners and the bundle cannot form across them. There are two working designs:

• A switch stack, where several physical switches are managed as one. Cisco documents that EtherChannels can span members of one stack, so one port on each stack member can be in the same channel.
• vPC (virtual port channel) on Cisco Nexus, a Nexus-specific and more advanced option in which links to two Nexus switches appear as one port channel to the third device. The checks above remain the core for any bundle. Failure modes: a Type 1 configuration mismatch between the two peers can stop the vPC or its member ports from coming up (check show vpc, show vpc brief and show vpc consistency-parameters), the peer link carries synchronisation and the peer-keepalive link detects a dead peer. LACP in active mode is the usual choice on the vPC member interfaces.

On two ordinary independent switches, use separate links with spanning tree or routed uplinks instead, and do not try to bundle.

Pitfalls

• Changing one member's trunk settings after the bundle is up can leave that member suspended while the others stay bundled, so the summary shows both P and s.
• Leaving on on one side while the other side runs LACP is a common reason a bundle stays down, because on only forms a channel against another on.
• A bundle with fewer healthy members than minimum links is flagged M, not P.

Direct answer

For a new production fabric, recommend the proven BGP-signalled approach: BGP-based services (EVPN, the Ethernet VPN control plane carried in BGP, or L3VPN, the BGP/MPLS IP VPN of RFC 4364 that keeps each customer's routes in a separate table) over an MPLS data plane, with SR-MPLS (segment routing with MPLS labels) if you need path control. Run SRv6 (segment routing over IPv6, where each segment is a 128-bit IPv6 address) in one pilot pod with written exit criteria. The deciding facts are not the elegance of SRv6 but whether the leaf and spine switch chips (ASICs) you will actually buy forward it at line rate (full port speed, no slowdown) with the segment depth you need, how much header it adds, and whether your team can operate and debug it at 3 a.m. A Clos fabric (leaf and spine tiers where every leaf connects to every spine) already gets path diversity from ECMP (equal-cost multipath: a switch spreads flows across all of its equally good next hops), so it rarely needs traffic engineering (TE, steering traffic along a chosen path instead of the shortest one), and that removes SRv6's biggest selling point from the underlay.

What to weigh

Header overhead, computed

What the packet looks like for a three-segment path (the number of bytes each piece adds in front of the payload):

• SR-MPLS: three transport labels plus one service label, 4 bytes each = 16 bytes.
• SRv6 full encapsulation: outer IPv6 header (40) + SRH fixed part (8) + three SIDs (3 x 16 = 48) = 96 bytes. The destination address holds the active SID and the SRH repeats the whole list.
• SRv6 reduced encapsulation: the first SID lives only in the destination address, so the SRH carries two: 40 + 8 + 32 = 80 bytes.
• SRv6 with one compressed container: no SRH at all, 40 bytes.

An SRv6 segment list can be compressed. RFC 9800 defines compressed SIDs (C-SIDs) in two flavours, NEXT-CSID and REPLACE-CSID. The idea: every SID in the fabric starts with the same leading bits, the locator block (the shared prefix the operator carves out for SIDs), so repeating it in each 128-bit SID wastes space. A compressed segment list writes the block once and then packs short node identifiers behind it. With a 32-bit locator block and 16-bit micro-SIDs, six fit in the remaining 96 bits of one 128-bit container (32 + 6 x 16 = 128; arithmetic from those two assumed lengths, so confirm against the RFC and your vendor for your chosen block size).

A traced three-segment example with NEXT-CSID (illustrative values from the 2001:db8::/32 documentation range): block 2001:db8::/32, and micro-SIDs 1 for leaf-1, 7 for spine-3 and 9 for leaf-9. The container is 2001:db8:1:7:9:: and the packet's destination address starts as exactly that. The network routes it to leaf-1, the owner of micro-SID 1. leaf-1 drops its own slot and shifts the rest left, so the destination becomes 2001:db8:7:9:: and the packet goes to spine-3. spine-3 shifts again to 2001:db8:9::, which leads to leaf-9. Three segments, one 128-bit address, no SRH: 40 bytes. REPLACE-CSID reaches the same goal differently: several C-SIDs are packed into containers carried in the SRH, and each node overwrites its slot in the destination address from that list (selected by an index kept in the address), so it needs the SRH. The two flavours are not interchangeable on the wire, so the question for a vendor is which one the chip supports.

def mpls(labels): return 4 * labels
def srv6_full(n): return 40 + 8 + 16 * n          # outer IPv6 + SRH + n SIDs
def srv6_reduced(n): return 40 + 8 + 16 * (n - 1) # first SID rides in the destination address
usid = (128 - 32) // 16                           # 16-bit uSIDs after a 32-bit block
def usid_bytes(n):                                # extra containers ride in an SRH, first one in the destination address
    containers = -(-n // usid)
    return 40 if containers == 1 else 40 + 8 + 16 * (containers - 1)
print("uSIDs per 128-bit container:", usid)
for n in (3, 6):
    print(f"{n} segments: SR-MPLS {mpls(n + 1)} B (incl. 1 service label) | SRv6 full {srv6_full(n)} B | "
          f"reduced {srv6_reduced(n)} B | uSID {usid_bytes(n)} B")
for payload in (1500, 9000):
    print(f"host MTU {payload}: fabric MTU needed with 3 segments: "
          f"SR-MPLS {payload + mpls(4)} | SRv6 full {payload + srv6_full(3)} | uSID {payload + 40}")

uSIDs per 128-bit container: 6
3 segments: SR-MPLS 16 B (incl. 1 service label) | SRv6 full 96 B | reduced 80 B | uSID 40 B
6 segments: SR-MPLS 28 B (incl. 1 service label) | SRv6 full 144 B | reduced 128 B | uSID 40 B
host MTU 1500: fabric MTU needed with 3 segments: SR-MPLS 1516 | SRv6 full 1596 | uSID 1540
host MTU 9000: fabric MTU needed with 3 segments: SR-MPLS 9016 | SRv6 full 9096 | uSID 9040

In the output, "full" means the SRH repeats every SID and "reduced" means the first SID is left out of the SRH because the destination address already holds it. With three segments, SR-MPLS adds 16 bytes (three transport labels plus one service label), an uncompressed SRv6 SRH path adds 96 (80 with the reduced encapsulation, RFC 8986, which leaves the first segment in the IPv6 destination address), and a single compressed container adds 40. If hosts send 9000-byte payloads the fabric MTU must be at least 9016, 9096 or 9040 bytes respectively, so MTU planning is part of the choice.

Recommendation, conditions and rollout

Choose BGP/MPLS now. Move to SRv6 for the production underlay only when all of these hold: the shortlisted leaf and spine models document line-rate compressed-SID forwarding at the depth you need; there is a concrete requirement for per-flow steering or service chaining across DC and WAN that ECMP cannot meet; the underlay is already IPv6; and the team has operated segment routing before.

Pilot design: one pod, failure injection on links and nodes, measurement of convergence by test traffic rather than by vendor claims, an MTU audit, a check that your packet capture and traceroute tools show the segment list, and a go or no-go review at the end of a fixed soak period. Roll back by keeping the pod's services dual-advertised (the same service routes announced over both the SRv6 and the MPLS paths) so traffic can return to the MPLS path.

Pitfalls

Treating "future-proof" as a requirement, forgetting that SIDs must never be reachable from outside the SR domain, and sizing MTU for the compressed case while running the uncompressed one.

Evaluate vendor relationship — approach

• Review contact points, escalation path, recent performance reports, ticketing transparency, and change-management communications.
• Check whether the provider assigns a technical account manager and conducts regular business reviews (QBRs).
• Interview stakeholders (NOC, security, app owners) to capture pain points and ticket backlog patterns.

Review SLAs and contract constraints

• Verify SLA metrics: availability (%), latency, jitter, packet loss, mean time to repair (MTTR), and SLAs per path (active/backup).
• Confirm measurement methodology (who measures, probes vs. CPE telemetry), reporting cadence, and credits calculation.
• Look for restrictive clauses: long notice periods, single-vendor lock-in, liability caps, data-handling/privacy terms, and change control fees.

Proposed improvements

1. Operational: Implement monthly joint QBRs with shared dashboards (NetFlow/synthetic tests) and a runbook for tiered escalations; add automated telemetry ingestion into our monitoring (Prometheus/Grafana) for independent verification.
2. Contractual: Add measurable KPIs for latency/jitter for critical sites, tighten MTTR commitments for high-priority paths, and convert vague SLA credits into service restoration and performance-based penalties plus an exit flexibility clause after repeated SLA breaches.

Why this helps

• Increases visibility, shortens incident resolution, aligns incentives, and reduces business risk from prolonged outages.

First pin down what the 3-year requirement actually names. Compliance rules usually name audit evidence (who changed a device configuration, authentication logs, firewall deny logs, flow records for regulated segments) and rarely demand 30-second interface counters for three years. I would ask for the written control text (the exact wording of the compliance requirement) and design tiers around it; counters kept for capacity planning are a separate decision.

Sizing assumptions (stated so the numbers can be checked): 1,000 devices, 48 interfaces each, 8 metric series per interface = 384,000 series. A series is one metric on one interface over time (for example bytes out on port 12 of router A); a scrape is one collection of a device's current values by the monitoring server, here every 30 seconds, and one reading of one series is a sample. That is 12,800 samples per second. Prometheus documentation puts storage at roughly 1 to 2 bytes per sample, so I use 2 bytes as the upper end (ESTIMATE, not measured on this fleet).

Tier 1, hot (30 days): raw 30-second metrics, 7 days of raw flow records, full-text indexed logs. Metrics: 384,000 x 2,880 samples per day x 30 days x 2 bytes = about 66 GB. Prometheus local storage is not clustered or replicated, so send a copy with remote write (a Prometheus feature that forwards every sample to another store as it arrives) to a long-term store.

• Lost vs a longer raw window: nothing yet. This is the incident-response tier.

Tier 2, warm (13 months): 5-minute rollups of average and maximum. About 175 GB (384,000 x 2 aggregates x 288 per day x 395 days x 2 bytes). Flow data becomes hourly aggregates keyed by source prefix, destination prefix, protocol and destination port class.

• Lost: bursts shorter than 5 minutes between the maximum and the average, individual flows, exact 5-tuples (source IP, destination IP, ports, protocol), and anything below the flow sampling rate.

Tier 3, cold (3 years): 1-hour rollups of average, minimum and maximum. About 60 GB (384,000 x 3 x 24 x 1,095 x 2 bytes). Total of the three tiers is about 302 GB against about 2.4 TB if raw 30-second data were kept three years, roughly 12.5%. These sizes count only the two or three aggregates named per tier. Thanos downsampled blocks store more per point (its compactor documentation lists min, max, sum and count aggregates, plus one for counters) and the same documentation says downsampling does not reduce storage, so if Thanos is the store, treat 302 GB as the lower bound of this arithmetic (ESTIMATE) and size the real tiers from a measured block.

• Lost: anything shorter than an hour, so you can answer "was this link saturated in March two years ago" but not "was there a 90-second burst".

As one implementation of the long-term store, Thanos (an open-source system that keeps Prometheus data in object storage) has a compactor, a background job that merges stored blocks of data and builds downsampled copies. Downsampled blocks keep one summary point per 5 minutes or per hour instead of one per scrape. The compactor creates 5-minute downsampled blocks for data older than 40 hours and 1-hour blocks for data older than 10 days. Downsampling alone saves no space (it adds blocks); space is saved by per-resolution retention, for example --retention.resolution-raw=30d --retention.resolution-5m=400d --retention.resolution-1h=1100d: keep full-resolution samples 30 days, the 5-minute points 400 days and the 1-hour points 1,100 days. Retention for each resolution must exceed the age at which the next downsampling pass runs, or data is deleted before it can be downsampled; the values above satisfy that. The 1100 days is 3 years with margin for the leap day.

Device logs. Split by purpose. Security-relevant logs (authentication, configuration change, ACL deny) go to write-once object storage (storage that refuses edits and deletes until the retention period ends) for 3 years, compressed. As an illustration, 1,000 devices each sending 5 such lines a minute at 200 bytes is 1.44 GB a day raw, and about 158 GB over 1,095 days if compression is 10x (ESTIMATE). Keep only 30 days in the searchable index; older logs are retrieved from the archive on request. Debug and informational noise is deleted at 30 days if the control text does not name it.

• Lost: instant search past 30 days (a rehydration job, which restores archived logs into the searchable index, takes minutes to hours) and the noise tier entirely.

High cardinality. Cardinality is the number of distinct series. It explodes when a label has many possible values: adding a client-IP label to one metric on 48,000 interfaces, with 500 distinct clients seen on each, would create 48,000 x 500 = 24,000,000 series, 62.5 times the entire 384,000-series fleet, so labels like IP addresses or flow identifiers do not belong on metrics. Per-interface series are the largest legitimate set, so roll them up first; flow summaries and logs are bounded by the aggregation keys and severity filters you choose, not by device count. For illustration, if hourly flow summaries hold 50,000 rows of 50 bytes, that is 60 MB a day and about 66 GB over 1,095 days (ESTIMATE), so the flow tier mostly costs you detail (individual flows) rather than bytes.

Cold-tier trap. Rolled-up counters must be stored as rates or as average/min/max, never as raw counter values, or a counter reset (device reload) looks like negative traffic in the rollup.

Finally, test restores: pick a date in tier 3, rebuild a monthly utilisation graph, and confirm the result with the compliance owner before the first audit asks for it.

Direct answer

Sponsorship means spending your own credibility to open a door someone couldn't open for themselves, which is different from mentoring, which is advice given directly to the person. The core act is advocating for them by name in a room they aren't in, backed by specific, evidence-based reasons they deserve the opportunity.

What sponsorship requires

Political capital and timing, not just advice. Mentoring can happen anywhere, anytime, one on one. Sponsorship requires actually being present, or having enough standing, in the room where a real decision gets made: a promotion committee, a staffing decision, an assignment to a high-visibility project.

An evidence-backed case, not a vague endorsement. "They're great" doesn't move a room. Specific, concrete contributions you can vouch for personally do. Building this case ahead of time, before the opportunity comes up, is part of the work.

Deciding when it's warranted. The right moment is when someone is already delivering at the target level but lacks the visibility or exposure to be considered for it, there's a real decision window open, and you have enough credibility in that specific room for your advocacy to actually carry weight.

Making the specific ask. Vouching in general terms is weaker than naming the specific opportunity and asking for the specific outcome: this person, for this role, on this team, now.

Aftercare. Sponsorship only compounds if the person knows it happened. Telling them what you did lets them lean into the opportunity and know someone is actively in their corner, not just quietly hoping things work out. Following up on the outcome, win or not, matters too.

Worked example

Someone you work closely with does excellent work but has almost no visibility outside their immediate team. A high-visibility opportunity, or a promotion cycle, comes up in a room they aren't part of. You go in with specific, concrete contributions you can personally back, not general praise, and explicitly vouch for their readiness for that specific opportunity. Afterward, they're included in the opportunity or the promotion conversation, and you tell them directly what you did and why, rather than letting them find out secondhand or not at all.

Trade-offs and pitfalls

Sponsoring someone whose work you can't concretely back with specifics spends your credibility on hope rather than evidence, and if it doesn't pan out, it costs you standing in that room for the next person you'd want to sponsor.

Sponsoring quietly and never telling the person defeats much of the point. They don't know to lean into the opportunity, and they don't know someone is actively advocating for them, which is often as valuable as the opportunity itself.

Sponsorship is finite. You have a limited amount of credibility to spend across your whole network, which means you genuinely cannot sponsor everyone equally, and who you choose to spend it on is a real, sometimes uncomfortable decision worth being honest with yourself about.

A common confusion is treating a glowing performance review comment as sponsorship. Real sponsorship requires actually being in the room, advocating for a specific decision, not just praising someone in the abstract where it doesn't reach the decision-maker.