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.

Approach (brief)
Redistribute static routes into OSPF area 0 using a route-map that matches static routes and sets a tag (100). Tagging prevents loops or re-redistribution back into other protocols/iterations and allows policy control. Also set external type (E1 or E2) on the redistribute statement.

Configuration (Cisco IOS)

! create an access-list to match static routes (or use prefix-list)
ip prefix-list STATIC_TO_OSPF seq 5 permit 10.0.0.0/8
! route-map to set tag
route-map RM_STATIC_TO_OSPF permit 10
 match ip address prefix-list STATIC_TO_OSPF
 set tag 100
! redistribute static into OSPF area 0 as type 5 (E2). Use metric-type for E1 if desired.
router ospf 1
 redistribute static subnets metric 20 metric-type 2 route-map RM_STATIC_TO_OSPF
 area 0 stub no-summary   ! only if appropriate for design

Why tagging

• Prevents re-redistribution loops: downstream routers can filter routes with tag 100 so they aren’t re-injected into static or other routing domains.
• Enables selective policy: route-maps or distribute-lists filter based on tag value.

Verification

• Confirm static and OSPF learned routes:
  • show ip route 10.0.0.0
  • show ip route ospf
• See OSPF external LSAs and metric/type:
  • show ip ospf database external
• Verify tags on routes:
  • show ip route 10.0.0.0 detail (shows tag)
  • show ip ospf database external <lsa-id> (LSA may include tag)
• Example to prevent re-redistribution on another router:

route-map BLOCK_REDIST permit 10
 match tag 100
 deny
route-map BLOCK_REDIST permit 20
! apply to redistribute static -> other protocol

Notes / Best practices

• Use prefix-lists over ACLs for route matches.
• Choose metric-type 1 vs 2 based on path selection and consistency.
• Test in maintenance window and monitor with show commands.

Clarify requirements & assumptions

• Two POPs (POP-A, POP-B) carrying an enterprise EVPN/MPLS L3VPN (IRB for routed VNIs or EVPN Type-5/IP Prefix Routes).
• Need control-plane and data-plane redundancy, fast convergence, no loops/blackholes, multi-homing of CE to multiple PEs supported.

High-level design

• Use MP-BGP EVPN between PEs across an IGP/MPLS core. Service routes: Type-2 (MAC/IP), Type-5 (IP-prefix) or IP Prefix NLRI for L3VPN.
• Anycast IRB on PEs in each POP for active-active CE forwarding.
• EVPN Ethernet Segment (ES) + ESI for CE multi-homing; DF election per ES to avoid duplicate forwarding.

PE-PE redundancy

• Deploy at least two active PEs per POP. Anycast gateway: identical IRB IP on both PEs so CE default-gateway is redundant.
• MP-BGP sessions from PEs to other POP PEs (full mesh or route-reflectors). Use BFD on eBGP/IBGP for sub-second detection.
• Data-plane: MPLS LSPs (RSVP-TE or SR-MPLS) with ECMP across PEs for load-sharing.

Inter-POP control-plane synchronization

• Import/export of Route Targets (RTs) per VRF. To limit churn and restrict routes to relevant POPs, use RT-constraints (RT filtering) so only VRF-relevant RTs are propagated to each POP.
• Carry necessary extended communities (ESI, Route-Target, Site-of-Origin) so remote PEs can correctly identify source and avoid re-advertising loops.
• Optionally enable RT-Constraint in BGP to ensure only RT-matching routes are imported by RRs and PEs.

Failure & convergence behavior

• POP failure detection:
  • IGP/BFD detects node or link failures.
  • BGP withdraws NLRI quickly; BFD speeds failover of forwarding.
• Graceful shutdown: when a PE is being taken down, use BGP graceful shutdown + EVPN withdraw of Type-2/Type-5 to avoid transient blackholes.
• On POP-failure, anycast IRB on surviving POP takes over; MPLS labels from failed PE are withdrawn and remote PEs switch to alternate labels/paths via BGP updates. Use pre-convergence FRR (TI-LFA/SR-TE fast-reroute) to minimize data-plane loss.

Preventing loops and blackholes

• Split-horizon semantics in EVPN: do not re-advertise routes back to origin based on ES and Site-of-Origin.
• Site-of-Origin and Route-Target tagging prevent same-route re-import into original POP.
• Use ESI+DF election for multi-homing to prevent duplicate forwarding loops at L2 edge.
• Ensure consistent next-hop behavior: preserve next-hop attribute and use next-hop-self at edges only when appropriate; use next-hop tracking and withdraws for dead next-hops.
• Control-plane filters: RT-constraint + prefix-lists to avoid accidental import of remote site routes back into same POP.
• Verify data-plane with MPLS label consistency and use traceroute/mpls stack inspection and monitoring alerts.

Operational notes & metrics

• SLOs: failover < 100 ms for L2 adjacencies (BFD/LFA) and < 1s for control convergence.
• Monitor BGP flaps, ESI/DF state, label distribution, and use automated playbooks for graceful shutdown.
• Test partial failure scenarios (single PE down, full POP down, inter-POP link partition) in lab before production.

Short answer / approach
Isolate noisy neighbors by reducing software bottlenecks, giving predictable hardware resources, and applying per-tenant shaping. Combine host/hypervisor tuning, NIC features, kernel-bypass where appropriate, and measurement to validate.

Concrete mitigations

• SR-IOV / ENA: assign virtual functions (VF) directly to VMs/containers to bypass vSwitching and hypervisor scheduling. Reduces latency/jitter. Trade-off: reduced live-migration, security surface, and orchestration complexity.
• DPDK / kernel-bypass: use user-space dataplane for latency-sensitive tenants (e.g., VNFs). Big gains in throughput and deterministic latency; costs CPU cores and complicates integration with standard stack.
• CPU pinning & NUMA alignment: pin vCPU to dedicated physical cores and place NIC interrupts and memory on same NUMA node. Prevents cross-node memory access and interrupt migration — reduces jitter. Trade-off: lower consolidation efficiency.
• NIC queue tuning: increase number of RX/TX queues, map queues to dedicated CPU cores, tune ring sizes and interrupt coalescing. Improves parallelism and reduces head-of-line jitter; requires careful CPU affinity.
• eBPF-based shaping: attach per-socket or per-tenant qdiscs or BPF classifiers to enforce low-latency priorities, fair-queueing, or dynamic limits. Flexible, low-overhead, live-editable. Trade-off: complexity in policy and CPU overhead for heavy filtering.
• Bandwidth reservations (rate limiting/guarantees): implement per-tenant policers and hierarchical qdiscs (HTB, MQPRIO) on host and upstream switches. Provides isolation but can underutilize capacity if over-reserved.

Measurement & validation

• Baseline metrics: p50/p95/p99 latency, jitter (stddev), throughput, packet loss, CPU utilization, IRQ distribution.
• Tools: perf/top, sar, irqbalance logs; tc -s qdisc; iperf3/netperf; pktgen; pscheduler; eBPF tracing (bcc/tracee) to count packet drops and latencies. Use capture (tcpdump) and histogram exports to Prometheus.
• Validation methodology: A/B tests with controlled noisy-neighbor traffic (generate cross-tenant traffic), measure before/after for multiple percentiles and under load, and run long-duration tests to catch bursts.

Trade-offs summary

• Hardware passthrough (SR-IOV) and DPDK give best isolation but reduce orchestration flexibility and increase CPU cost.
• CPU pinning/NUMA and NIC queue tuning are low-risk but reduce consolidation density.
• eBPF and qdiscs offer flexible, software-level isolation with modest overhead; need careful policy and monitoring.

Immediate (minutes–hours) — stabilize traffic

• Isolate and stop flapping source: identify peer(s) via BGP logs, route-refresh timestamps, and MRT dumps.
• Temporarily damp unstable prefixes with conservative BGP route-flap-damping (low penalty / short half-life) or apply max-prefix/peer prefix-limits to noisy peers.
• Preferentially pin critical prefixes: add static/aggregate routes or local RIB/operation policy to prefer stable next-hops (longer local-preference) so traffic avoids flapping paths.
• Contact upstream/peer NOC(s); coordinate graceful shutdown of problematic session if needed.

Mid-term (days–weeks) — policy & operational changes

• Tighten import/export filters: strict prefix-lists, ROA/RPKI validation, AS-PATH filtering to reject accidental announcements.
• Implement BGP PIC/fast-reroute and tuned timers (keepalive/hold) per peer class; avoid overly aggressive timers for stability-sensitive peers.
• Deploy BGP communities to control propagation and passive suppression of re-advertisements for unstable prefixes.
• Improve monitoring/alerting: MRT collection, BGPstream, prefix-origin change alerts, and automated correlation to detect flapping before impact.

Long-term (weeks–months) — architecture & resilience

• Multi-homing diversity: add geographically and topologically diverse peers and IXPs to reduce single-peer sensitivity.
• Route reflectors + Anycast for critical services to absorb churn; employ ECMP and traffic engineering (SR/MPLS) to spread load.
• Automated policy verification (config linter) and pre-deploy simulation of route changes.
• Invest in RPKI full-validation and origin enforcement across edge.

Trade-offs

• Faster convergence (aggressive timers, withdraws) can cause transient blackholes if peers oscillate; conservative timers improve reachability but increase failover time.
• Flap damping reduces control-plane churn but can blackhole legitimate prefixes if penalties are too strict.
• Anycast and ECMP improve reachability but add complexity in stateful services and debugging.

I would start with containment (pin critical prefixes), communicate with peers, then harden policies and expand topology diversity to reduce future sensitivity.

How STP elects the Root Bridge

• STP elects the root bridge by comparing Bridge IDs (BIDs) carried in BPDUs. The lowest BID wins.
• Bridge ID = Bridge Priority (16-bit) + System ID Extension (VLAN ID) + MAC address. Effectively compared as: lowest priority → lowest MAC as tiebreaker.
• BPDUs propagate from the current root; switches select paths based on cumulative path cost to that root.

Port role determination

• Root Port (RP)
  • On each non-root switch, the port with the lowest cumulative path cost to the root becomes the Root Port.
  • Tie-breakers: lower received root path cost, then lower sending bridge ID, then lower sending port ID.
• Designated Port (DP)
  • For each network segment, the port on the switch that offers the lowest path cost to the root becomes the Designated Port and forwards traffic for that segment.
  • If equal cost, the switch with lower BID wins; if still tied, lower port ID wins.
• Blocked Port
  • Any port that is neither RP nor DP is put into Blocking to prevent loops; it still listens for BPDUs.

Path cost influence

• Path cost is cumulative: each link contributes a cost value based on link speed. STP selects ports based on the lowest total cost to the root.
• You can influence selection by changing either:
  • Interface cost (per-port): e.g., lower the cost on desired links so they become preferred.
  • Bridge priority (global per VLAN): lower priority makes the switch more likely to be root.

Commands / Example to force a switch to be root (Cisco IOS examples)

• Make this switch the primary root for VLAN 10:

configure terminal
spanning-tree vlan 10 root primary
end

• Or set priority explicitly (lower is better; default 32768; valid increments of 4096):

configure terminal
spanning-tree vlan 10 priority 4096
end

• Set an interface path cost to prefer a link:

configure terminal
interface GigabitEthernet1/0/1
spanning-tree cost 2000
end

Practical notes

• Use “root primary/secondary” helpers on Cisco to automate safe priority values.
• When planning changes, account for VLAN-specific BIDs (system ID) and avoid abrupt topology changes during production hours.

Goal & assumptions
Segregate prod/non-prod while minimizing downtime. Assumes same Kubernetes distribution (EKS/GKE/AKS), RBAC in place, CI/CD pipelines, and observability.

Phased migration plan

1. Discovery & design (week 0–1)

• Inventory namespaces, services, ingress, network flows (netflow, kube-bench, kube-state-metrics).
• Design segmentation: separate namespaces + NetworkPolicies + dedicated node pools or clusters for prod/non-prod as risk budget allows.
• Risks: incomplete inventory → missed dependencies. Mitigation: passive traffic capture + tagging; rollback: freeze changes, continue discovery.

2. Implement baseline NetworkPolicies (week 1–3)

• Start with default-deny egress/ingress per namespace; progressively add allow rules using label-based selectors.
• Use policy engine (Calico) for advanced selectors and global policies for infra.
• Test with canaries in non-prod; staged rollout to prod.
• Risks: broken service communication. Mitigation: policy staging, automated policy simulator (calicoctl check), CI tests. Rollback: revert to permissive policy (apply known-good ClusterNetworkPolicy).

3. Deploy service mesh (week 3–6)

• Install mesh in non-prod (Istio/linkerd) with sidecar injection for canaries; enable mTLS, traffic shifting.
• Use mesh policies to enforce inter-service auth and observability.
• Risks: latency/CPU on sidecars. Mitigation: resource limits, gradual percentage rollout, perf testing. Rollback: disable sidecar injection or scale mesh control plane down and revert traffic routing.

4. Web Application Firewall & ingress hardening (week 5–8)

• Place WAF (ModSecurity/Cloud WAF) in front of ingress; enforce OWASP rules, rate limits, IP allowlists for prod.
• Test in detection mode then enforcement in staging.
• Risks: false positives blocking users. Mitigation: run in monitor mode, whitelist known clients, staged enforcement. Rollback: switch WAF to monitor or bypass for specific paths.

5. Continuous compliance & verification (ongoing)

• Integrate policy-as-code: OPA/Gatekeeper for admission, CIS/Kubernetes benchmarks via periodic scans, runtime policy checks (Falco).
• CI gates: reject manifests violating NetworkPolicy/ingress/WAF rules.
• Risks: developer friction. Mitigation: clear docs, pre-commit checks, staged enforcement windows. Rollback: relax admission policies temporarily.

Rollback & runbook

• Maintain versioned manifests and a playbook: step identifier, kubectl/apply rollback manifest, rollback window, stakeholders, monitoring checklist.
• Use feature flags for traffic, and circuit breakers in mesh to redirect to stable deployments.

Monitoring & verification

• KPIs: pod-to-pod latency, policy deny rate, 4xx/5xx spikes, deployment failure rate.
• Post-mortem and incremental hardening.

This plan minimizes blast radius by progressive enforcement, testing in non-prod, and provides clear rollback actions for each phase.

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.

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.

Overview / goals
Designing HA for stateful firewalls means preserving connection state (sessions, NAT mappings) across failover so active flows continue with minimal disruption while maintaining security correctness.

Key considerations

• What to sync: per-conn state (5-tuple, TCP seq/ACK windows, timers), NAT translations, ALG/stateful protocol helpers, security policy counters.
• Sync latency & frequency: lower latency reduces lost packets but increases bandwidth and CPU.
• Failure detection: fast heartbeats (VRRP/HSRP for VIP; vendor heartbeats for state) vs false positives.

State/NAT sync methods & examples

• OS/protocol-based: pfsync (OpenBSD/FreeBSD), conntrackd with nf_conntrack (Linux) — transports delta/complete state over a secure channel.
• Vendor solutions: Cisco ASA SSO/NSR, Palo Alto HA session sync, Fortinet FGCP — proprietary, optimized for TCP window/sequence sync.
• Mechanisms: full state replication, incremental deltas, checkpointing, on-demand pull.

Active/passive vs active/active

• Active/passive: simpler, deterministic single-writer state; easier to guarantee consistency; briefly higher failover time but simpler conflict-free state.
• Active/active: better utilization and capacity; requires distributed state synchronization or session affinity; higher complexity (conflict resolution, split-brain concerns), potential for asymmetric routing and policy divergence.

Sticky sessions & load balancing

• Use client-source affinity at load balancer or firewall cluster to keep flows on the same node when active/active.
• Combine with flow hashing and health checks; avoid relying solely on IP NAT translation if client IPs change.

Minimizing session loss

• Use synchronous or low-latency incremental state sync; enable session checkpointing.
• Implement graceful shutdown/connection draining and TCP connection mirroring if available.
• Increase TCP keepalive/timeouts briefly during failover; use ARP/VRRP gratuitous announcements to speed re-route.
• Test failover under load; tune heartbeat and hold-down timers to balance speed vs stability.

Practical recipe

• For Linux-based boxes: nf_conntrack + conntrackd with high-frequency, encrypted sync channel; use VRRP for VIP.
• For enterprise: use vendor HA (ASA SSO, Palo Alto HA) in active/passive for simplest correctness; consider active/active only with proven session-distribution and stickiness.
• Monitor sync health, bandwidth, and session loss metrics; automate failback and post-failover reconciliation.

This approach balances reliability, performance, and operational complexity for network-grade stateful firewall HA.