Mid-Level Network Engineer Interview Preparation Guide - FAANG Standards

Direct answer

Track a small mix of signals across a few categories: ownership and scope, what decisions and outcomes you're trusted with now versus a few months ago, skill evidence, things you can now do that you couldn't before, and external signal, feedback you actively solicit rather than wait for, reviewed on a set cadence so busyness doesn't get mistaken for progress.

Structured elaboration

Ownership and scope signal. Periodically write down, in a sentence or two, what you're currently trusted to decide or own without checking in first, and compare it to the same note from a few months earlier. If it reads the same, that's useful information regardless of how busy you've been.

Skill evidence signal. Keep a short, honest log of specific instances where you did something you genuinely couldn't have done a few months prior, a list of capability demonstrated, not a list of tasks completed.

External signal, actively solicited. The input side of tracking is asking for feedback on a regular cadence rather than waiting for a formal review to surface it. Pick one or two people whose judgment you trust, a manager, a peer, a cross-functional partner, ask a specific rather than generic question, do it on a set interval so the answers accumulate into a trend, and use that same conversation to show your manager concrete evidence of the movement you've tracked, not just to ask how you're doing.

Keep yourself honest. At each check, ask whether the evidence you've gathered would convince someone who doesn't already like you, not just whether you feel you've been busy. Busyness isn't itself a metric, the ownership, skill, and feedback signals above are proxies for actual movement.

Worked example

"Every few months I set aside a short amount of time to update three things: a one-line note on what I currently own without checking in, a short log entry on anything I did recently that I genuinely couldn't have done before, and a specific question I asked one trusted colleague or my manager about what was still holding me back. One quarter my log of things I did looked long and I felt productive, but my ownership note hadn't changed at all from the previous check, and when I asked my manager the specific question, the answer named a gap I hadn't noticed because I'd been focused on volume rather than scope. That mismatch, feeling busy while the ownership and feedback signals were flat, was the useful signal, and it redirected my effort the following quarter toward the specific gap rather than more of the same work."

Trade-offs & pitfalls

• Treating task completion as the metric rewards busyness and tells you nothing about whether your scope or trust is actually growing.
• Waiting for a formal review cycle to get feedback means the signal arrives too infrequently and too late to redirect effort.
• Asking for feedback with a generic question, how am I doing, tends to produce generic, unhelpful answers. A specific question produces something you can act on.
• Tracking too many metrics becomes its own busywork. A small, consistent set reviewed honestly beats an elaborate dashboard reviewed rarely.

Direct answer

iperf (or iperf3) measures achievable throughput between a client and a server you control at both ends, which lets you localize a bottleneck by systematically varying WHERE the test runs from and to, rather than relying only on passive observation of real application traffic.

Structured elaboration

1. Basic client/server test plan: run iperf3 -s on one end and iperf3 -c <server> on the other; comparing the achieved throughput against the theoretical capacity of the link (its advertised bandwidth) tells you whether you're anywhere near expected performance at all.
2. Isolating client-side versus server-side versus path bottlenecks: run the test between the two original endpoints first, then run it again with the SERVER role temporarily moved closer to (or onto) an intermediate point in the path, and again with the CLIENT role moved; if throughput improves dramatically when either endpoint is swapped for a point further along the path, the segment you just removed from the test is where the bottleneck lives.
3. TCP versus UDP test plans: a TCP test reflects real achievable throughput INCLUDING the effects of congestion control and any loss on the path (loss causes TCP to back off, so a lossy path shows up as reduced TCP throughput even if raw bandwidth is fine); a UDP test (iperf3 -u) sends at a specified rate REGARDLESS of loss, and directly reports the actual loss percentage and jitter, which isolates raw path loss/jitter from TCP's own congestion-driven throughput reduction.
4. Single-direction versus bidirectional tests: run the test in each direction separately (-R reverses the direction in iperf3) since asymmetric paths or asymmetric last-mile connections (common in many access networks) can show very different throughput in each direction; a bidirectional test (--bidir) additionally reveals whether simultaneous traffic in both directions interferes with either direction's throughput, relevant for links that aren't cleanly full-duplex in practice.
5. Interpreting key results: retransmits reported by a TCP test indicate loss occurred somewhere on the path during the test; jitter (reported by UDP tests) indicates variability in inter-packet arrival timing, relevant for real-time traffic; achievable bandwidth well below the link's rated capacity, combined with retransmits, points at loss-driven congestion-control throttling rather than a pure bandwidth ceiling.

Worked example

A TCP test between two data centers achieves only 200 Mbps on a link rated for 1 Gbps, with a nontrivial retransmit count reported. A UDP test at a controlled rate of 900 Mbps between the same two points shows 3% loss. This combination (TCP well under capacity, with retransmits, and UDP confirming real loss at a rate close to the link's capacity) points at actual packet loss on the path being the bottleneck, not a TCP window-tuning or latency issue; the TCP result alone couldn't distinguish "genuinely lossy path" from "TCP just needs window tuning for this RTT," but the UDP test's direct loss measurement resolves that ambiguity.

Trade-offs & pitfalls

A TCP-only test conflates two different possible causes of low throughput (real path loss versus TCP settings simply not being tuned for the path's bandwidth-delay product); running both TCP and UDP tests, and comparing, is what actually separates them. Also remember iperf tests generate real synthetic load; running a large-bandwidth test on a production path during business hours can itself cause the very congestion you're trying to diagnose, so schedule tests thoughtfully or use rate-limited tests when testing shared infrastructure.

Direct answer

QoS (quality of service) on a WAN only works where you own the queue. So the design has three layers: classify and mark once, at a trust boundary you control; shape each WAN link at the branch to just under its real rate and run a priority-plus-bandwidth-share policy inside the shaper, which is where congestion is managed (shaping means holding packets in a queue so they leave at a chosen rate; the policy then gives voice a queue that is always served first and every other class a guaranteed percentage of that rate); and agree a small class menu with each carrier, because marks mean nothing across a network that does not honor them. The MPLS (Multiprotocol Label Switching, a carrier-run private WAN) path can honor marks if the carrier is contracted to; the public internet path will not, so there the design relies on your own egress queue plus measurement-driven path selection.

Classes and marks

DSCP (Differentiated Services Code Point) is the 6-bit field in the IP header that carries the mark. Values below follow RFC 4594. Where the numbers come from: the 6 bits are read as a decimal number. EF (Expedited Forwarding) is 101110 = 46 (RFC 3246). AF names are AFxy, where x is the class (1 to 4) and y the drop precedence (1 to 3, a higher y is dropped first), and the value is 8x + 2y (RFC 2597): AF41 = 100010 = 34, AF21 = 010010 = 18, AF31 = 26. CS (class selector) values are n x 8: CS1 = 8, CS5 = 40, CS6 = 48.

That is six classes; 10 + 20 + 3 + 25 + 5 = 63% reserved. That leaves 37% unreserved for class-default and unclassified traffic. Platforms cap how much of a link can be reserved, so check the cap for your platform and software release; 63% is a modest reservation.

Trust boundaries and re-marking policy

• Trust (the trust boundary is the point where you decide whether to believe arriving marks): desk phones and conference systems (known devices) keep their marks; PCs, servers and guest traffic are re-marked by address and port at the first switch or at the router, because an application can mark itself EF to jump the queue.
• Re-mark on the way out to the carrier's menu, and re-classify on the way in: never trust the DSCP of a packet arriving from a WAN, since the carrier may have bleached it (reset it to 0) or changed it.
• The bulk-analytics versus critical-service case: classify by source and destination subnets at the data center and branch edge, not by what the application sets. The critical service goes to CRITICAL, bulk analytics to SCAVENGER, so a large analytics job cannot take the critical service's share.

Agreeing a minimal menu with the carrier

The branch policy shown further down is what you configure on your own router; this part and the carrier-core part cover how the carrier network handles the result.

RFC 8100 describes four interconnection classes: Telephony (EF), Bulk Real-Time (AF41), Assured Elastic (AF31, AF32) and Default. It also notes that many networks re-mark unrecognised DSCPs to zero. So the carrier menu is four classes and the branch maps into it:

The CS5 re-mark matters on MPLS: the 3-bit MPLS Traffic Class (the old EXP field) is by default copied from the top 3 bits of the DSCP, and EF (101110) and CS5 (101000) both give 5. Without the re-mark, signalling would share voice's class in the carrier core. RFC 8100 suggests carrying signalling as AF31 with the Assured Elastic class; this design instead maps CS5 to AF41 so signalling keeps the video class's treatment, and AF31 is the alternative to agree with the carrier. Ask the carrier for the per-class bandwidth committed, per-class loss and delay targets, and per-class counters you can see.

The carrier core under congestion

Inside the carrier network each class maps to a queue: the EF class is served from a priority queue, AF41 and AF31 get committed shares, and class 0 is dropped first when a link fills. That is the behavior to put in the contract and then verify rather than assume: run the same EF, AF31 and class-0 test streams through the carrier during a busy period and compare loss and jitter per class. If the carrier cannot show per-class counters or will not commit to loss and delay per class, the marks are decoration on that path and the design treats it like the internet path.

Branch policy under congestion (Cisco IOS XE syntax)

Shape the WAN egress below the circuit rate so the queue forms on your router, then run the class policy inside the shaper. For a 50 Mbps MPLS circuit: 0.95 x 50 = 47.5 Mbps.

class-map match-any VOICE
 match dscp ef
class-map match-any INTERACTIVE
 match dscp af41 cs5
class-map match-any NET-CTRL
 match dscp cs6
class-map match-any CRITICAL
 match dscp af21
class-map match-any SCAVENGER
 match dscp cs1
policy-map WAN-CHILD
 class VOICE
  priority percent 10
 class INTERACTIVE
  bandwidth percent 20
  set dscp af41
 class NET-CTRL
  bandwidth percent 3
  set dscp af31
 class CRITICAL
  bandwidth percent 25
  set dscp af31
 class SCAVENGER
  bandwidth percent 5
  set dscp 0
 class class-default
  set dscp 0
policy-map WAN-PARENT
 class class-default
  shape average 47500000
  service-policy WAN-CHILD
interface GigabitEthernet0/0/0
 service-policy output WAN-PARENT

Reading the config line by line:

• class-map match-any VOICE defines a class; a packet joins it if it matches any listed condition, and match dscp ef tests the DSCP mark. Each class-map above does the same for one traffic type.
• policy-map WAN-CHILD is the child policy: what each class gets when the link is full.
• priority percent 10 puts voice in a strict-priority queue, always served first, held to 10% of the rate during congestion so it cannot starve the others.
• bandwidth percent 20 guarantees that class at least 20% of the rate when the link is full; capacity a class is not using goes back to the others.
• set dscp af41 rewrites the mark on the way out, which is the re-mark to the carrier menu in the table above (CS6 and AF21 both become AF31, CS1 becomes 0).
• class class-default in the child matches everything not matched above, and set dscp 0 zeroes its mark, so unclassified traffic reaches the carrier as 0 as the menu table says; without it an unlisted mark such as AF11 would pass to the carrier unchanged.
• policy-map WAN-PARENT has only class class-default (everything), where shape average 47500000 sends at most 47,500,000 bits per second and queues the excess, and service-policy WAN-CHILD nests the child inside the shaper, so the class rules apply to the shaped 47.5 Mbps.
• service-policy output WAN-PARENT attaches the whole policy to the interface in the outbound direction, where you own the queue.

What happens when the shaped 47.5 Mbps fills:

• Voice goes first from the priority queue, but is policed (traffic above the cap is dropped, not queued) to 10% (4.75 Mbps) only during congestion; excess voice is dropped rather than allowed to starve the rest. One G.711 (uncompressed voice codec) call at 20 ms is a 200-byte IP packet, 50 times a second: 80 kbps, or 87.2 kbps with an 18-byte Ethernet header. 4.75 Mbps holds 54 calls (4,750 / 87.2 = 54.5). Set call admission control (refusing new calls once the voice allowance is full) to 54 or fewer, because the 55th call degrades every call. A branch with 40 calls uses 3.49 Mbps, 7.3% of the shaped rate.
• Interactive video gets at least 9.5 Mbps (20%), which carries six 1.5 Mbps streams (an assumed codec setting) with 0.5 Mbps to spare.
• Scavenger gets a floor of 2.375 Mbps (5%) but takes everything idle. A 100 GB branch backup (8 x 10^11 bits) takes 4.7 hours on an idle link and 93.6 hours at the floor, so schedule backups outside business hours or raise the floor.

Inbound traffic, and the internet path

The branch cannot queue what the carrier has already sent it; the congestion point is in the carrier network. Put a per-branch shaper and the same child policy on the hub's WAN egress toward each branch.

For the internet path, DSCP will often be bleached and nothing is guaranteed, so: apply the same shaper and class policy at the egress (that part you own), and add an overlay (a virtual network built across the physical paths) with path monitoring (SD-WAN, software-defined WAN) that measures loss, delay and jitter (variation in packet delay) per path and moves voice to the path that meets thresholds your team sets from the voice platform's documented limits. For a multi-tenant provider, give each customer a parent shaper with the same child policy: only the parent rate varies, so profiles stay supportable. Every custom class layout per customer is another policy to test, document, monitor and audit, and the cost grows with the number of customers, which is why the internal class set is fixed at six classes (mapped onto the carrier's four) and only the parent rate varies.

Cloud paths

Beyond your own routers, public cloud connections behave differently, and QoS across the cloud edge is limited. Azure ExpressRoute honors DSCP only on Microsoft peering for the listed Teams and Skype marks (EF, AF41, AF21, AF11, CS0); on private peering the DSCP is kept but not used to prioritise traffic, and unlisted marks must be rewritten to 0 before sending. AWS documents bandwidth allowances (for example, single-flow traffic is limited to 5 Gbps when instances are not in the same cluster placement group), and this design does not rely on any AWS DSCP queuing behavior; check current documentation before assuming marks are honored. So treat cloud as best effort: shape at your own egress and size capacity rather than rely on marks.

Validate end to end and monitor

1. Marking survives: send a test stream with iperf3 -c <host> -u -b 1M --dscp EF and capture with tcpdump -n -v; a packet marked EF shows tos 0xb8 (the 6-bit mark sits in the top six bits of the 8-bit type-of-service byte, so 46 x 4 = 184 = 0xb8). I ran this on a loopback in a Linux container and saw tos 0xb8 on the stream: it proves the tool marks, and the real test repeats the capture at the branch LAN port and the far end of each path.
2. Behaviour under load: send CS1 bulk at 120% of the shaped rate for several minutes while a voice-sized EF stream at 3.5 Mbps runs; iperf3 reports loss and jitter for the EF stream, which should show none, while the bulk stream shows loss.
3. Repeat per path, because MPLS and internet differ.
4. Enforcement in production: show policy-map interface shows per-class statistics, so alert on any VOICE drops, on CRITICAL drops, and on SCAVENGER drops that stay high all day (backup never finishing).

Direct answer

Virtual Private Cloud (VPC) endpoints and a NAT (Network Address Translation) gateway solve the same surface-level problem, giving a private subnet a way to reach something outside it, but they solve it in structurally different ways: a VPC endpoint gives a private, service-specific path directly to one named destination, while a NAT gateway gives general-purpose outbound internet access to anywhere. For a data-exfiltration-prevention posture specifically, that difference is the entire point: a NAT gateway cannot distinguish "the application calling its expected external API" from "the application calling an attacker-controlled destination," while a VPC endpoint structurally cannot reach anywhere except the one service it was created for.

Structured elaboration

What each actually is. A NAT gateway translates a private subnet's outbound traffic to a public IP and routes it through an internet gateway to any destination on the internet the traffic is addressed to; it is a general-purpose front door out. A VPC endpoint comes in two forms: a Gateway endpoint (currently available for object storage and a managed NoSQL database service on AWS) which adds a specific route-table entry for that one service's traffic, no internet exposure at all; and an Interface endpoint (AWS PrivateLink) which provisions an elastic network interface with a private IP address inside your subnet for a specific supported service or a partner/private service, again with no path to the general internet.

Security benefits. A NAT gateway secures the inbound direction (nothing can initiate a connection into the private subnet through it) but does nothing to restrict the outbound direction beyond what a security group or a separate egress-filtering device enforces; without additional controls, any process in the private subnet can reach any destination on the internet through it. A VPC endpoint's security benefit is structural rather than policy-based: the traffic simply has no path to reach anywhere except the one named service, which means even a fully compromised workload with unrestricted outbound "permission" at the security-group layer still cannot exfiltrate data to an arbitrary external destination through this specific path, because the path does not exist for anywhere else.

Monitoring. NAT gateway traffic can be monitored through VPC flow logs, which show connection metadata (source, destination IP, port, bytes transferred) but, since NAT gateway traffic is addressed to arbitrary internet destinations, distinguishing legitimate traffic from exfiltration in that log stream requires building and maintaining a destination allow-list or a behavioral baseline yourself. VPC endpoint traffic is inherently narrower to monitor, since by construction every request through a given endpoint is going to exactly one service, meaning an interface endpoint's own access logs (where the underlying service supports them) are already scoped to a single, known-legitimate destination type.

Pricing. Gateway endpoints are free (no hourly or data-processing charge). Interface endpoints carry an hourly per-AZ charge plus a per-gigabyte data-processing charge, similar in scale to (though generally somewhat cheaper than) NAT gateway's own hourly and per-gigabyte charges; the practical financial trade-off usually favors NAT gateway for many different remote destinations, and interface endpoints for a small number of specific, frequently-used AWS or partner services, where the security benefit outweighs the marginal cost difference.

Scalability. Both scale automatically to handle throughput within the same subnet without capacity planning on the customer's part; the practical scalability difference is architectural rather than throughput-based: a NAT gateway supports every destination through one construct, while VPC endpoints require creating and managing a separate endpoint per service the application needs to reach, which is more operational overhead as the number of distinct external dependencies grows.

Worked example

An application in a private subnet needs to reach three destinations: an object storage bucket, a Secrets Manager instance, and a third-party payment API not available as a VPC endpoint. The design uses a Gateway endpoint for object storage (free, and removes that traffic from any exfiltration-risk internet path entirely), an Interface endpoint for Secrets Manager (a small, fixed hourly cost, and the same structural exfiltration-prevention benefit), and routes only the third-party payment API traffic through the NAT gateway, since no private-endpoint option exists for it. Because only one of the three destinations uses the NAT gateway path, the egress-monitoring and destination-allow-listing effort needed to detect anomalous exfiltration through that path is now scoped to verifying traffic only goes to the one expected payment-API domain, a far narrower and more tractable monitoring problem than if all three destinations shared the same general-purpose NAT path.

Trade-offs and pitfalls

• A design that routes everything through a NAT gateway "because it is simpler" trades away the strongest, most structural exfiltration-prevention property VPC endpoints offer, for the sake of avoiding a small amount of per-service endpoint configuration. The worked example's narrowed NAT-path exposure (one known destination instead of three) is the direct, measurable benefit of doing the slightly more work up front.
• VPC endpoints only cover services that support them; a design cannot assume every external dependency can be moved off the NAT gateway path, and a dependency audit is needed to know which ones genuinely can be. Treating "we use VPC endpoints" as a blanket exfiltration-prevention claim, without verifying which specific destinations still route through NAT, overstates the actual posture.
• Interface endpoints' hourly-plus-per-AZ charge accumulates faster than teams expect when adopted broadly across many services and many AZs, and a team optimizing purely for the security benefit without tracking this cost can face an unexpectedly large bill; Gateway endpoints, where available (object storage, the managed NoSQL service), should always be preferred over Interface endpoints for the same service, since they are both cheaper and structurally identical in security benefit.
• A cross-account private-endpoint scenario adds a real distinction worth naming: an Interface endpoint can be shared across accounts within an organization (via AWS Resource Access Manager or by exposing it as a PrivateLink-powered service), while a Gateway endpoint's route-table-based mechanism is scoped to the VPC it is created in and does not share the same cross-account model. A multi-account design that needs a shared, centralized private path to an internal service should use an Interface endpoint (or a PrivateLink-based custom service) specifically because of this sharing capability, not a Gateway endpoint, even where both would otherwise seem to fit the same use case.

RTO (Recovery Time Objective) is how long you're allowed to be down: the maximum acceptable gap between an outage starting and service being restored. RPO (Recovery Point Objective) is how much data you're allowed to lose: the maximum acceptable gap, measured in time, between the last durably captured write and the moment of failure. The requirement "payments must be restored within 30 minutes with no more than 5 minutes of data loss" is literally RTO = 30 min and RPO = 5 min stated in plain language, and each number drives a different part of the design.

What each number drives

RPO = 5 minutes drives replication and backup frequency. A nightly or even hourly backup can't meet this: if the outage happens 4 hours after the last backup, you'd lose 4 hours of transactions, not 5 minutes. A 5-minute RPO effectively requires continuous replication (near-synchronous in-region, or streaming WAL (write-ahead log: a durable, ordered record of every change, written before it's considered applied) or CDC (change-data-capture: a stream of those same row-level changes read off that log) shipping to the DR site) with replication lag actively monitored and alarmed well below the 5-minute budget, plus point-in-time recovery for protection against logical corruption that replication alone would just copy.

RTO = 30 minutes drives standby readiness and failover automation. A cold-standby DR site that has to be provisioned from scratch after the fact will blow past 30 minutes just on infrastructure boot time. A 30-minute RTO points toward a warm standby (already running, sized down, kept current via the same replication that satisfies the RPO) with an automated failover runbook: health-check detection, automated promotion, and DNS/routing cutover, because a manual, human-paged process realistically eats 10-15 minutes just in detection and decision-making before any recovery action starts.

Worked example: what these numbers cost against an annual SLA

A useful way to make the 30-minute number concrete is to check it against annual downtime budgets at standard availability tiers, using $525{,}600$ minutes per year (365 $\times$ 24 $\times$ 60):

A single incident with a 30-minute RTO, if the service is held to a 99.99% SLA, consumes:

of the entire year's downtime budget in one event. That reframes "30 minutes sounds generous" into "this design can absorb roughly one such incident a year and still hit four nines," which is exactly the kind of number that should drive whether the DR design gets warm-standby automation now or gets revisited after the first real incident eats most of the annual budget.

Trade-offs and pitfalls

The most common mix-up is treating RTO and RPO as interchangeable "how bad was it" numbers instead of two independent design constraints: a system can have a great RTO (back up in 2 minutes) and a terrible RPO (lost the last hour of writes) if it fails over to a backup instead of a live replica, or the reverse (RPO≈0 via synchronous replication, but a slow, manual promotion process blows the RTO). Both have to be solved, and usually by different mechanisms: RPO is a replication/backup-cadence problem, RTO is an automation/standby-readiness problem. A second pitfall specific to payments: RPO=0 sounds like the obviously "safer" number to chase, but strict synchronous replication that blocks writes during a replica outage can turn a replication hiccup into an availability incident, trading a data-loss risk you might never hit for a downtime risk you're now taking on every day.

Direct answer
Two well-chosen SMART goals for a mentee should target different dimensions, not two flavors of the same gap, typically one concrete skill or output gap and one behavioral or collaboration gap, each tied to real upcoming work (not an abstract exercise) with a defined timeframe and a way to verify progress that isn't just your own impression.

Structured elaboration

Picking the goals

• Start from an actual observed gap, not a generic template. Watch the person's real work for a pattern (recurring rework in reviews, difficulty scoping ambiguous tasks, avoiding certain kinds of conversations) rather than picking goals off a checklist.
• Pick goals from different dimensions on purpose. Two goals that are both "write better code" don't cover as much ground as one technical goal and one collaboration or communication goal; below-the-bar performance and stalled growth are rarely single-dimensional.
• Anchor each goal to real, upcoming work rather than an artificial exercise, so achieving it has actual value beyond the goal itself.

Making them SMART without making them hollow

• Specific: named against a real, current gap, not a generic aspiration ("get better at code review" is weak; "flag the two or three highest-risk issues in a review instead of commenting on every minor style choice" is usable).
• Measurable: defined by evidence you can point to later, not a feeling. This doesn't require an invented precision metric; "the last three reviews they gave focused on real risk rather than style nits" is legitimate evidence.
• Achievable: a real stretch, not guaranteed, but genuinely possible in the timeframe given their current level.
• Relevant: tied to what actually matters for their next step, not an arbitrary skill.
• Time-bound: a defined window, short enough to check in on meaningfully, long enough for real practice to happen.

Verifying they were met

Verification should come from something observable in the work itself, ideally corroborated by someone other than just you (a peer's comment, a second reviewer's read), not solely your own subjective sense that things feel better.

Worked example

Situation

A mentee was technically solid but had two recurring gaps: their code reviews tended to focus on minor style points while missing the real risk in a change, and they rarely spoke up in group design discussions even when they clearly had a relevant opinion afterward.

The two goals

1. Review focus: over the next 6 weeks, shift their code review comments toward flagging genuine risk (correctness, edge cases, design concerns) rather than style, verified by a second reviewer independently agreeing their flagged issues were the real risk areas in at least the majority of reviews they gave in that window.
2. Speaking up in design discussions: over the next 8 weeks, raise at least one substantive point live in a design discussion, rather than only afterward privately, verified simply by whether it happened and by a peer noticing the shift unprompted.

Why these two, not two code-quality goals

Picking a technical goal and a behavioral goal together addressed two independent gaps at once, rather than doubling down on the dimension that was already their relative strength.

Result

Both goals gave something concrete to check in on during regular 1:1s, and both had a verification method that didn't rely purely on my own impression, which mattered for making the conversation feel objective rather than a subjective judgment.

Trade-offs & pitfalls

• Goals that sound measurable but aren't actually verifiable. "Be more proactive" dressed up with a number attached is still not a real SMART goal if there's no real way to check it.
• Two goals in the same dimension. Picking two technical goals, or two soft-skill goals, leaves a real gap uncovered and wastes the opportunity a second goal represents.
• Goals set without the mentee's buy-in. A goal the mentee didn't help shape, or doesn't actually agree reflects a real gap, is much less likely to stick, even if it's technically well-formed.
• No connection to real work. An artificial exercise goal ("complete this course") is weaker evidence of growth than a goal embedded in work they were doing anyway.

Contain fast without destroying evidence: isolate the host at the segmentation layer, not by powering it off, tighten its reachability to nothing except a monitored forensics path, and verify containment by confirming, from telemetry outside the host itself, that the beaconing traffic has actually stopped and the host can no longer reach anything it previously could.

Step 1: isolate without destroying evidence

Rather than shutting the host down, which can lose volatile evidence such as in-memory malware artifacts, or manually killing the suspicious process, which can tip off active command-and-control (some malware has dead-man-switch behavior), move the host into a quarantine segment or apply a host-based firewall policy that denies essentially all outbound and inbound traffic except a narrow, monitored path to incident-response tooling.

Step 2: contain with layered segmentation controls

Combine several levers rather than relying on one: revoke or change the host's existing access-rule membership (an access-rule change removing it from whatever security group previously granted it broad reach); apply microsegmentation-style explicit deny rules for the specific suspicious internal address and any other destinations flagged during triage; add a host-based firewall policy on the host itself as a second, independent layer; and, if the host holds a workload identity or certificate, revoke it so even a valid-looking authenticated request from it is rejected by other services' policy.

Step 3: narrow the blast radius further

Rotate any credentials or secrets the host had access to, on the assumption that isolation stops FUTURE misuse but doesn't undo anything already taken.

Step 4: verify containment actually held

Don't rely on "I applied the rule" as proof. Confirm from independent telemetry, network flow logs, the destination's own connection logs, or the segmentation control plane's enforcement confirmation, that the specific beaconing pattern has stopped appearing after the change, that the host can't reach any segment or service it could reach before, and that no OTHER host has started showing a similar beaconing pattern, which would indicate the compromise had already spread before containment.

Worked example

A host is observed beaconing every few minutes to a suspicious internal address in the payments segment. Containment: move the host's security-group membership from its normal tier to a quarantine group that denies all except a forensics jump host; add an explicit deny rule for the specific destination address at the payments segment boundary as a second layer, in case the quarantine change is delayed or incomplete; and revoke the host's workload certificate so any request it still manages to send is rejected by identity-aware policy on the receiving end, not just blocked at the network. Verification, roughly fifteen minutes later: flow logs show zero connections from the host to the previously targeted address, and payments-segment access logs show zero requests bearing the host's now-revoked identity, confirming both the network path and the identity path are closed, not just one of the two.

Trade-offs and pitfalls

Isolating too aggressively, killing the process or shutting the host down, can destroy forensic value and, in some cases, trigger a scripted destructive response from the malware faster than a quiet network-level isolation would; isolating too slowly to preserve evidence risks continued lateral movement while you wait. Most incident-response playbooks resolve this by favoring immediate network-level containment, fast and low-risk of tipping off the attacker, while deferring host-level forensic actions like memory capture or a process kill to a separate, deliberate step once network isolation is confirmed.

Direct answer
IPv6 removed the ability for ROUTERS along the path to fragment a packet; only the ORIGINATING host may fragment an IPv6 packet, using a dedicated fragmentation extension header, which pushes the entire responsibility for correctly sizing packets (and reacting to Path MTU, Maximum Transmission Unit, Discovery feedback) onto the sender rather than sharing it with the network.

Structured elaboration
In IPv4, any router along the path could fragment a packet too large for its outgoing link (unless the Don't Fragment bit was set), a convenience that came at real cost: routers doing fragmentation work on the fly, and receivers having to reassemble fragments that could have been created by ANY device along the path, not just the sender. IPv6's designers removed this entirely: routers now MUST drop an IPv6 packet that's too large for the next link and send back an ICMPv6 "Packet Too Big" message reporting the link's MTU, rather than fragmenting it themselves. If the ORIGINATING host still needs to send data larger than the smallest MTU along the path, it must fragment the packet itself, before sending, using the IPv6 Fragment extension header (which carries the same conceptual information as IPv4's Identification/Flags/Offset fields, just in a dedicated extension header rather than baked into the main IP header).

Worked example
This design change makes Path MTU Discovery load-bearing in IPv6 in a way it wasn't strictly required to be in IPv4: since no device in the middle of the path can rescue an oversized packet by fragmenting it, a sender that doesn't properly discover and respect the path's minimum MTU will simply have its packets dropped along the way (with an ICMPv6 message reporting why, PROVIDED that message isn't itself being filtered somewhere, the classic PMTUD-blackhole failure mode). This is also why a middlebox in the middle of an IPv6 path is a materially different kind of obstacle than in IPv4: it cannot silently paper over an oversized-packet problem by fragmenting on the sender's behalf; it can only drop and (hopefully) report back.

Trade-offs & pitfalls
The IPv6 design trades away routers' ability to "fix" an oversized packet on the fly in exchange for a simpler, more predictable job for routers (never having to fragment) and a stronger incentive for senders to get Path MTU Discovery right in the first place, rather than relying on the network to quietly compensate for an oversized packet. The practical implication: if ICMPv6 "Packet Too Big" messages are filtered anywhere along an IPv6 path (the same class of misconfiguration that breaks IPv4 PMTUD), there is NO fallback fragmentation happening in the middle of the path to mask the problem, the failure is more absolute than the equivalent IPv4 case.

Direct answer

Split-horizon DNS (also called split-brain or split-view DNS) means the same domain name answers differently depending on who asks: internal clients get internal addresses and internal-only names, outside clients get only the public view. Organisations run it so internal users reach a service by its private address, and so that internal-only hosts such as a database name never appear in public DNS. A conditional forwarder is a rule on a resolver: "for queries inside zone X, send them to these servers instead of walking from the root". It is how the internal resolver reaches a partner's private zone, or sends public names to the right place.

My recommendation for one shared domain: keep internal-only services under their own subdomain (for example int.example.test) that is served only by internal servers, so the public servers never hold those names at all, and use split horizon only for names that must resolve differently from inside, such as www. Where an internal-only name has to live in the shared zone itself, views are the tool, and the design below handles that case. A view is a software boundary on one server; separate servers are a network boundary, and I prefer the network boundary when the estate can afford it.

The design

Rules that make it secure:

1. Recursion only for internal clients. The public side answers authoritatively (from zone data it owns) and refuses recursion (going off to look up other names for the asker); otherwise it becomes an open resolver that outsiders can abuse for amplification, meaning they send small queries with a forged source address and your server sends large answers at the victim.
2. The internal view is a superset. Every public name internal users need must also exist in the internal view; if the internal view serves example.test it is authoritative for the whole zone (it answers from its own copy and never asks anyone else about names in that zone), and a missing public record gives internal clients NXDOMAIN ("no such name") for it.
3. No transfers to strangers. allow-transfer { none; } unless a named secondary needs a copy. A zone transfer hands another server a full copy of the zone, so an open transfer lets anyone download every name in it.
4. Do not treat DNS views as access control. A name that is hidden is not a name that is protected; the database still needs authentication and network controls.
5. DNSSEC and views (applies only if the public zone is signed). DNSSEC adds cryptographic signatures to DNS data. A signed zone's parent publishes a DS record (delegation signer), a fingerprint of the zone's signing key, which tells every validating resolver "this zone is signed, so insist on valid signatures". An internal validating resolver that gets unsigned internal answers for the same name therefore cannot verify them, marks them bogus and returns SERVFAIL (the generic "server failure" error) instead of the data. Sign the internal view with the same keys, or tell the internal validators to treat the zone as insecure (Unbound's domain-insecure, an option that skips validation for the named zone and passes unbound-checkconf).

BIND views, executed in a lab

This configuration passes named-checkconf and was run on BIND 9.20. The client address 127.0.0.2 stands in for a corporate client; 127.0.0.1 stands in for an outsider:

acl corp { 127.0.0.2; 10.0.0.0/8; };

options {
    directory "/etc/bind";
    listen-on { 127.0.0.12; };
    listen-on-v6 { none; };
    pid-file "/run/named/named.pid";
    dnssec-validation no;
    allow-transfer { none; };
};

view "internal" {
    match-clients { corp; };
    recursion yes;
    allow-recursion { corp; };
    zone "example.test" { type primary; file "/etc/bind/internal.example.test.zone"; };
    zone "partner.test" { type forward; forward only; forwarders { 198.51.100.53; }; };
};

view "external" {
    match-clients { any; };
    recursion no;
    zone "example.test" { type primary; file "/etc/bind/external.example.test.zone"; };
};

The external zone file has www A 192.0.2.20 and mail A 192.0.2.30 (plus ns1 and the SOA/NS); the internal one has www A 10.0.5.20, mail A 192.0.2.30 and db A 10.0.9.5. Reading the configuration line by line:

• acl corp { ... }; names a list of addresses (an access control list, ACL) that other lines can refer to as corp.
• listen-on { 127.0.0.12; }; makes the server answer only on that address; listen-on-v6 { none; } turns off IPv6 listening; pid-file is where the process records its ID.
• dnssec-validation no; switches signature checking off, a simplification for the lab.
• allow-transfer { none; }; refuses zone transfers to everyone.
• view "internal" { ... }; opens a view: a named set of zones and settings that only some clients see.
• match-clients { corp; }; selects which clients get this view; recursion yes; with allow-recursion { corp; }; lets exactly those clients have the server look up other names for them.
• zone "example.test" { type primary; file "..."; }; makes this server the primary (owner of the master copy) for the zone, read from that file. The two views use two different files for the same zone name, which is the split.
• zone "partner.test" { type forward; forward only; forwarders { ... }; }; is the conditional forwarder, explained below.
• view "external" with match-clients { any; }; is the catch-all for everyone else, with recursion no;.

Views are evaluated in order and the first match-clients that matches wins, so the narrow internal view must come first. (In the executed lab the partner.test forwarder pointed at the server itself on a spare port; the documentation-range address above is the production shape and passed named-checkconf.)

$ dig -b 127.0.0.2 +short @127.0.0.12 www.example.test A   # status: NOERROR
10.0.5.20
$ dig -b 127.0.0.2 +short @127.0.0.12 db.example.test A   # status: NOERROR
10.0.9.5
$ dig -b 127.0.0.1 +short @127.0.0.12 www.example.test A   # status: NOERROR
192.0.2.20
$ dig -b 127.0.0.1 +short @127.0.0.12 db.example.test A   # status: NXDOMAIN

The outsider gets the public address for www and NXDOMAIN for db; the internal client gets both internal answers.

The conditional forwarder

The zone "partner.test" { type forward; forward only; ... } statement in the internal view is the BIND form: queries for partner.test go to the partner's resolver and nowhere else. forward only means no fallback to iterating from the root, so a dead forwarder produces SERVFAIL for that zone only. A lab run shows the difference with a zone-level forward to a dead address (198.51.100.53) and the answer held by a lab root server in the hints file: forward only returned status: SERVFAIL after Query time: 10001 msec, while forward first returned status: NOERROR, www.partner.test. 300 IN A 198.51.100.77, after Query time: 1204 msec, because it fell back to iterating. The Unbound form of the same rule, which passes unbound-checkconf:

forward-zone:
  name: "partner.test."
  forward-addr: 198.51.100.53

Trade-offs and pitfalls

• Views vs separate servers. Views are cheapest and fine for a small estate; they put internal data on a server that also answers the internet, so one mistake in an access control list (ACL) leaks the internal zone. Separate servers (a managed provider for the public zone, internal servers inside the network) remove that failure mode at the cost of keeping two zones in step.
• Drift. The same name in two zones means two places to edit. Generate both from one source and review diffs; a public record added to only the public file is missing for internal users.
• Forwarder dependencies. Each conditional forwarder is a dependency on someone else's resolver and the VPN to reach it. Monitor it, and restrict it to the specific zones needed.
• What would change the choice: if no name needs to differ between inside and outside, drop split horizon entirely and delegate an internal subdomain to internal servers; it is simpler and the public servers cannot leak what they never held.

Direct answer

Set the decision at the right altitude before setting the decision itself: agree in advance on what counts as reversible-and-cheap versus irreversible-or-expensive, let anyone decide locally within a pre-agreed threshold for the first kind, require explicit escalation for the second, and write down every non-trivial call so it can be revisited once real outcome data exists. That same underlying pattern holds whether the tension is shipping speed against general quality controls, or, on a machine-learning team, shipping velocity against model safety and accuracy checks.

Structured elaboration

• Decision criteria: for any trade-off, ask how reversible it is (can it be rolled back quickly if wrong), what its blast radius is (one customer or all of them), and whether a hard external commitment, a compliance deadline or a contractual date, is forcing the timeline.
• Risk thresholds: define numeric or categorical thresholds in advance, before anyone is negotiating under pressure mid-incident, for example, "a change affecting under 5% of traffic that's reversible within an hour can ship without extra sign-off," or, for a model team, "a model change with an accuracy drop under 1 percentage point on the offline evaluation set ships with standard review, anything larger requires a dedicated safety review." Those figures are a team's own chosen starting values, not a benchmark to copy from somewhere else, and that is the point: a written number can be argued with and revised, where a phrase like "a small change" cannot. Expect an interviewer to ask where your number came from, and the honest answer is usually "we picked a starting point we could defend and agreed what evidence would move it," not "this is the industry figure."
• Pick the metric before you pick the number: a threshold is only as good as the quantity it is written on. On a fraud model, writing the gate on overall accuracy is close to useless, because fraud is rare enough that a model can lose most of its useful behaviour while overall accuracy barely moves, which is why the fraud example below writes its threshold on false-positive rate instead.
• Escalate versus decide locally: escalate when a threshold is exceeded, when a decision sets precedent beyond the one case in front of you, or when the people closest to the decision disagree with each other. Decide locally when it's within threshold and there's local agreement.
• Documenting and revisiting: write a short record of what was decided, what alternative was rejected and why, and what threshold or assumption it relied on, then set a specific trigger, for example "revisit after the next two incidents," to check whether the threshold was actually set correctly rather than leaving it to be re-litigated from scratch every time.

Worked example

Two versions of the same framework. General engineering: a team keeps clashing over shipping a feature via a small partial rollout versus running a longer manual QA pass first. They agree that rollouts to 5% or fewer of users, reversible with a feature flag within minutes, ship on the engineer's own judgment, while anything wider, or anything touching payments, needs QA sign-off first. They also agree up front what would justify widening the cap, because "it's been fine so far" is not a number: twenty consecutive rollouts inside the cap with zero rollbacks. Even that is weaker evidence than it feels. Zero failures in twenty tries still leaves room for a true rollback rate around 15% (the rule of three: with no failures in n tries, the rate could still be roughly 3 divided by n, so 3/20). That's precisely why they widen the cap from 5% to 10% rather than removing it, and set the same evidence bar again at the new level. Machine-learning variant: a fraud-model team keeps clashing over releasing model updates quickly versus running a full safety review every time. They agree that an update with a false-positive-rate change under 0.5 percentage points versus last month's data ships with standard review, while anything larger, or any change to a customer-facing risk threshold, requires a safety review with a second reviewer. After a quarter, they compare every release's actual measured drift against that threshold and adjust it based on how often it was close to being wrong.

Trade-offs and pitfalls

The biggest failure is setting a threshold once and never revisiting it, a threshold calibrated for a smaller, lower-stakes system becomes dangerously loose as the system scales, or unnecessarily strict once a team has demonstrated it can be trusted at a lower tier. That gap between a real framework and a one-time compromise is exactly what the revisit step protects against. The mirror-image failure is revisiting on the wrong evidence, loosening a safety gate after a short clean run, since a run of zero failures is compatible with a failure rate high enough to hurt you and feels far more reassuring than it should. The other failure is treating every disagreement as needing escalation, which quietly kills the local decision-making the framework was meant to protect, and teams that over-escalate end up right back at "everything goes through a committee," the speed problem the framework was supposed to solve in the first place.