Senior Network Engineer Interview Preparation Guide - Google

Network Engineer

Google

Senior

7 rounds

Updated 6/15/2026

Google's interview process for Senior Network Engineer typically includes an initial recruiter screening, technical phone screens focused on networking fundamentals and troubleshooting, followed by 4-5 onsite rounds covering network architecture design, infrastructure troubleshooting, Google-specific infrastructure knowledge, and behavioral/culture fit assessment. The process emphasizes both deep technical expertise and alignment with Google's values of collaboration, bias to action, and comfort with ambiguity.

Interview Rounds

Recruiter Screening

30 min3 focus topicsculture fit

Technical Phone Screen 1: Networking Fundamentals and Protocol Deep Dive

60 min5 focus topicstechnical

What to Expect

First technical phone interview focused on core networking protocols, OSI model layers, and fundamental networking concepts. The interviewer will ask questions about IPv4/IPv6, routing protocols (BGP, OSPF), switching, VLAN concepts, DNS, TCP/IP behavior, and network troubleshooting methodology. You should be able to explain protocols clearly and discuss trade-offs between different approaches. This round assesses your foundational knowledge and communication ability.

Tips & Advice

Review networking protocols in depth, focusing on BGP (critical for senior roles), OSPF, and EIGRP. Be comfortable explaining packet flow at different layers. Know the differences between connection-oriented and connectionless protocols. Practice explaining why certain protocols are used in specific scenarios. Use a whiteboard or shared screen to diagram network flows. Be prepared for follow-up questions that test your understanding, not just memorization. Explain your troubleshooting approach clearly—many questions will be framed as "what would you check first" scenarios.

Focus Topics

DNS and Name Resolution

DNS query process, recursive vs iterative resolution, DNS record types (A, AAAA, CNAME, MX, TXT, NS), DNS caching behavior, and common DNS troubleshooting scenarios

Practice Interview

Study Questions

Switching, VLANs, and Layer 2

VLAN tagging and trunking, STP/RSTP for loop prevention, MAC learning, spanning tree topology selection, access vs trunk ports, and inter-VLAN routing design

Practice Interview

Study Questions

TCP/IP Protocol Suite

TCP vs UDP behavior, connection establishment, flow control, congestion control, segment sizing, retransmission behavior, and how these affect application performance

Practice Interview

Study Questions

Network Troubleshooting Methodology

Systematic approach to isolating network issues: verifying connectivity at each layer, using tools (ping, traceroute, netstat, ss, tcpdump), distinguishing DNS vs routing vs firewall issues, and identifying the root cause logically

Practice Interview

Study Questions

Routing Protocols and BGP

Deep understanding of Border Gateway Protocol (BGP), interior gateway protocols (OSPF, EIGRP), path selection, convergence behavior, and when to use each protocol in different network designs

Practice Interview

Study Questions

Technical Phone Screen 2: Network Design and Troubleshooting at Scale

60 min5 focus topicssystem design

What to Expect

Second technical phone interview focused on network architecture design, infrastructure troubleshooting at scale, and system-level thinking. You may be given a scenario like designing a network for a distributed data center environment, handling traffic growth, or troubleshooting a complex connectivity issue. The interviewer assesses your ability to think about trade-offs, scalability, redundancy, and security. You should discuss design decisions and explain why you chose specific approaches. This round often includes a semi-open-ended design problem or complex troubleshooting scenario.

Tips & Advice

Practice designing networks end-to-end: start with requirements gathering, discuss constraints (bandwidth, latency, cost, availability), propose architecture with redundancy, consider failure modes, and evaluate trade-offs. For troubleshooting scenarios, explain your diagnostic approach out loud and ask clarifying questions about symptoms. Think about monitoring, observability, and how you'd detect issues. Be ready to explain why you avoided certain technologies or approaches. Discuss capacity planning, growth scenarios, and how your design scales. Mention security considerations and how your design addresses them. Show familiarity with modern approaches like Software-Defined Networking (SDN), automation, and cloud-native networking if relevant to your experience.

Focus Topics

Network Security in Design

Incorporating security into network architecture: DMZs, firewalling, access control lists (ACLs), network segmentation, VPN design, DDoS mitigation, and balancing security with performance

Practice Interview

Study Questions

Network Monitoring and Observability

Designing systems to be observable: flow monitoring, NetFlow/sFlow, SNMP, metrics collection, logging, alerting strategy, and using data to optimize network performance

Practice Interview

Study Questions

Network Architecture Design for Scale

Designing resilient, scalable network topologies supporting distributed systems. Understanding multi-layer architecture, redundancy strategies, load balancing, and handling growth while maintaining performance and reliability

Practice Interview

Study Questions

Complex Troubleshooting Scenarios

Diagnosing multi-layer issues involving routing, firewalls, DNS, and application behavior. Isolating which layer is causing problems, collecting relevant data, and forming hypotheses based on evidence

Practice Interview

Study Questions

High-Availability and Redundancy Design

Designing networks with no single points of failure, failover mechanisms, multi-path routing, redundant hardware, and assessing trade-offs between complexity and availability

Practice Interview

Study Questions

Onsite Round 1: Network Architecture Design Interview

75 min5 focus topicssystem design

What to Expect

In-person or video interview focused on designing a medium-to-large scale network architecture. You'll be given a business scenario (e.g., connecting multiple data centers, supporting a growing user base, or migrating infrastructure) and asked to design a network that meets specified requirements. The interviewer will probe your design decisions, ask about trade-offs, and explore edge cases. You should demonstrate understanding of scalability, redundancy, cost optimization, and security. This round assesses your architectural thinking and communication ability.

Tips & Advice

Start by clarifying requirements and constraints before designing. Ask about scale (number of users/locations), latency requirements, bandwidth needs, availability targets, and budget. Propose a clear architecture with diagrams. Explain component choices and why you selected specific technologies. Walk through traffic flows in normal and failure scenarios. Discuss scalability as traffic grows. Address security, redundancy, and monitoring from the start. Be prepared to modify your design based on feedback. Show that you're thinking about operational aspects: How is this managed? How are updates deployed? What breaks and how do you detect it? Practice designing on a whiteboard or digital drawing tool. Use standard network notation. Ask clarifying questions when scenarios are unclear.

Focus Topics

Firewall and Security Architecture

Designing stateful firewalls, establishing security zones, implementing access policies, understanding DDoS mitigation, and integrating security without excessive latency

Practice Interview

Study Questions

IP Addressing and CIDR Planning

Designing IPv4 and IPv6 addressing schemes that scale, understanding supernetting and aggregation, planning for NAT-less architectures, and managing address space efficiently

Practice Interview

Study Questions

Capacity Planning and Growth Scenarios

Estimating bandwidth requirements, planning for traffic growth, understanding headroom requirements, and designing infrastructure that can scale incrementally

Practice Interview

Study Questions

Data Center Networking and Inter-DC Design

Designing networks connecting multiple data centers, handling traffic between data centers efficiently, understanding latency constraints, and implementing disaster recovery and business continuity

Practice Interview

Study Questions

Network Topology Trade-offs

Understanding mesh vs hierarchical topologies, spine-leaf architecture, and when to use each approach based on requirements, costs, and operational complexity

Practice Interview

Study Questions

Onsite Round 2: Network Operations and Troubleshooting

60 min5 focus topicstechnical

What to Expect

Interview focused on operational excellence and troubleshooting complex network issues. You'll be presented with real-world scenarios (e.g., intermittent packet loss, latency spikes, asymmetric routing) and asked to diagnose root causes. The interviewer assesses your systematic troubleshooting methodology, use of tools, and ability to prioritize when multiple issues could explain observed behavior. This round tests practical expertise and your ability to debug production systems under pressure.

Tips & Advice

For troubleshooting scenarios, establish a clear mental model: gather facts first, form hypotheses, test hypotheses, and iterate. Describe the tools you'd use (tcpdump, netstat/ss, ping, traceroute, BGP route inspection, SNMP, NetFlow, etc.) and what you'd learn from each. Practice describing packet flows through your network topology. Be comfortable with Linux networking tools. When faced with ambiguous symptoms, discuss what additional information would be helpful. Show that you understand the difference between correlation and causation. Discuss how you'd approach this in production (e.g., using non-invasive monitoring before running tests that might impact service). Mention metrics you'd review: latency percentiles, packet loss, jitter, retransmission rates. Be ready to pivot if your initial hypothesis is wrong and choose the next most likely cause logically.

Focus Topics

Performance Analysis and Optimization

Identifying performance bottlenecks, analyzing latency sources (propagation, processing, queuing), understanding bandwidth constraints, and optimizing network configurations for application requirements

Practice Interview

Study Questions

Firewall and NAT Troubleshooting

Diagnosing firewall rule issues, understanding stateful firewall behavior, troubleshooting NAT and port forwarding problems, and interpreting connection tracking information

Practice Interview

Study Questions

Handling Asymmetric Routing and MTU Issues

Understanding and troubleshooting path asymmetry that causes return traffic to take different routes, fragmentation vs MTU path discovery (PMTUD), and implications for TCP performance

Practice Interview

Study Questions

Network Tool Proficiency and Instrumentation

Deep knowledge of Linux networking tools (netstat, ss, ip route, iptables, tcpdump), SNMP monitoring, NetFlow analysis, syslog interpretation, and knowing which tool answers which question

Practice Interview

Study Questions

Advanced Troubleshooting and Root Cause Analysis

Systematic methodology for diagnosing complex multi-layer issues, using network tools effectively (tcpdump, netstat, ss, mtr, ping, traceroute, dig), interpreting packet captures, and distinguishing symptoms from root causes

Practice Interview

Study Questions

Onsite Round 3: Google Infrastructure and Cloud Networking

60 min5 focus topicstechnical

What to Expect

Interview focused on your understanding of modern infrastructure approaches, Google Cloud Platform (GCP) networking services, and how networking evolves in cloud environments. You may be asked about Software-Defined Networking (SDN), network automation, cloud-native networking architectures, and GCP services like Cloud VPN, Cloud Interconnect, Cloud Load Balancer, and VPC networking. The interviewer assesses your awareness of modern approaches and willingness to learn new technologies. This round is particularly important for Google roles since they heavily use cloud infrastructure internally.

Tips & Advice

Research GCP networking services thoroughly: understand Cloud VPC, subnets, firewall rules, Cloud Load Balancer, Cloud CDN, Cloud Interconnect, Cloud VPN, and Shared VPC. Understand the differences between GCP networking and traditional networking. Learn about SDN principles and how they differ from traditional hardware-based switching. Discuss automation: Infrastructure as Code (IaC), configuration management, and how you've used these in previous roles. Talk about containers and Kubernetes networking implications. If you have GCP experience, discuss real projects. If not, discuss how your networking knowledge applies to cloud platforms. Show understanding that cloud networking is more software-driven, more ephemeral, and requires different operational approaches. Discuss observability in cloud environments and differences from traditional network monitoring.

Focus Topics

Container and Kubernetes Networking

Understanding container networking models, overlay networks, Kubernetes networking concepts (Services, Ingress, NetworkPolicy), and how networking works differently in containerized environments

Practice Interview

Study Questions

Observability in Cloud and Modern Infrastructure

Understanding metrics, logs, and traces for cloud infrastructure. Using cloud-native observability platforms, understanding network flow data in cloud contexts, and monitoring microservices architectures

Practice Interview

Study Questions

Network Automation and Infrastructure as Code

Using Terraform, Ansible, or similar tools to define and manage network infrastructure, benefits of IaC (repeatability, version control, auditability), and integrating automation into deployment pipelines

Practice Interview

Study Questions

Software-Defined Networking (SDN) Concepts

Understanding the shift from hardware-based to software-defined networking, control plane vs data plane separation, network virtualization, and implications for network design and operations

Practice Interview

Study Questions

GCP Networking Services and Architecture

Understanding Google Cloud Platform networking fundamentals: VPC design, subnets, firewall rules, Cloud Load Balancer, Cloud CDN, Cloud Interconnect, Cloud VPN, and how networking is abstracted in cloud environments[4]

Practice Interview

Study Questions

Onsite Round 4: Google Behavioral and Culture Fit Interview

45 min6 focus topicsbehavioral

What to Expect

Interview focused on assessing your alignment with Google's culture and values. The interviewer will ask behavioral questions about your past experiences to evaluate: your ability to demonstrate leadership even without formal authority, how you handle ambiguity and complexity, your collaboration skills, your bias toward action, your communication ability, and your growth mindset. Unlike technical interviews, these questions assess soft skills, decision-making under uncertainty, and team dynamics. You should prepare specific examples from your past that illustrate key competencies. This round is critical for senior-level candidates as leadership and influence are core expectations[2].

Tips & Advice

Prepare 5-7 concrete examples from your career that demonstrate different competencies. Use the STAR method (Situation, Task, Action, Result) but focus on your specific contributions and how you influenced outcomes. For senior roles, emphasize: leading without formal authority, influencing team direction, mentoring others, handling ambiguity, making difficult trade-off decisions, and driving results in complex environments. Practice explaining failures and what you learned. Have examples showing collaboration across teams, driving process improvements, and contributing to team culture. Be authentic and specific—avoid generic corporate language. Show genuine enthusiasm for Google's mission and products. Ask thoughtful questions about the team and role. Research Google's leadership principles and weave them into your answers[2]. Discuss how you've operated at a higher level as you progressed in your career.

Focus Topics

Learning, Growth, and Adaptation

Examples of learning new technologies, adapting to changing business needs, seeking feedback, and demonstrating continuous growth throughout your career[2]

Practice Interview

Study Questions

Collaboration and Teamwork

Examples of working effectively with difficult stakeholders, collaborating across functional teams, resolving conflicts, and contributing to team culture[2]

Practice Interview

Study Questions

Technical Decision-Making and Trade-offs

Examples of making architectural or technical decisions that involved trade-offs, explaining your decision-making process, considering multiple perspectives, and defending your choices

Practice Interview

Study Questions

Bias to Action and Execution

Examples of moving quickly to deliver results, taking ownership of problems, driving projects to completion, and balancing speed with quality[2]

Practice Interview

Study Questions

Emergent Leadership and Influence Without Authority

Demonstrating leadership when you don't have formal authority over others. Examples of stepping up to lead technical initiatives, mentoring team members, influencing decisions, and driving change through collaboration and technical credibility[2]

Practice Interview

Study Questions

Managing Ambiguity and Complexity

Examples of making decisions with incomplete information, operating in ambiguous situations, adapting to changing requirements, and helping teams navigate uncertainty[2]

Practice Interview

Study Questions

Frequently Asked Network Engineer Interview Questions

Network Scalability and Growth PlanningHardTechnical

60 practiced

An on-prem backbone is reaching the maximum number of MAC addresses and ACL entries supported by current switch models. Describe how you would evaluate and select replacement equipment, including metrics to compare (TCAM, ASIC throughput, buffer sizes, feature parity), and a migration strategy minimizing risk.

Sample Answer

**Clarify requirements & constraints**- Current and projected MAC/ACL growth over 3–5 years, required port density, uplink speeds, latency SLAs, budgets, and preferred vendors/support models.

**Evaluation criteria (metrics to compare)**- TCAM capacity: number of L2 MAC entries, IPv4/IPv6 routes, ACL (ACE) entries; distribution between exact-match vs ternary.- ASIC throughput and forwarding tables: line-rate Gbps per slot/port; packet-per-second (PPS).- Buffering: per-port static/shared buffers (KB/MB), headroom for microbursts, buffer allocation strategy.- Latency and jitter: hardware latency under load, queueing behaviour.- Feature parity: VLAN, STP, MLAG, EVPN/VXLAN, MAC learning scale, dynamic MAC aging, ACL types (distributed vs centralized), QoS, ECMP, PBR, sFlow/Telemetry, VXLAN-GW, Camel/NSH if needed.- Control-plane: CPU headroom, control-plane policing, BGP/EVPN scale, route refresh times.- High-availability: redundant supervisors, graceful restart, hitless upgrades.- Manageability & observability: telemetry (gNMI/sFlow), CLI/Netconf/REST, automation support.- Power, cooling, physical size, warranty, support SLAs, EOS/EOU timelines, TCO (capex + 5-year opex).

**Testing & validation**- Lab or vendor loaner: realistic MAC churn, ACL stress tests, microburst tests, feature sets (EVPN/VXLAN), failover scenarios.- Test scripts for scale: automated MAC churn, ACL install/remove rate, control-plane convergence.

**Migration strategy (minimize risk)**1. Pilot: pick non-critical POD; install switches in parallel. 2. Staging: pre-load configs, templates, automation playbooks (Ansible), validate TACACS/AAA and management access. 3. Phased cutover: migrate uplinks and leafs in groups during maintenance windows; use MLAG/stacking to peer old and new; dual-homing to avoid single points. 4. Validation: functional tests (MAC learning, ACL enforcement), performance tests (throughput, latency), telemetry dashboards. 5. Rollback plan: preserve old configs, keep old hardware powered and paths intact for quick revert; document rollback steps. 6. Post-migration: monitor for 72 hours with elevated alerting, tune TCAM/aging, and offload large ACLs to firewall where appropriate.

**Trade-offs & recommendation**- Favor higher TCAM with flexible partitioning and larger shared buffers if bursty east-west traffic. Prioritize proven feature parity for EVPN/VXLAN if overlay is used. Balance cost vs longevity (EOS dates) and vendor support.

This approach ensures objective vendor comparison, validated performance, and a low-risk, reversible migration path.

Network Monitoring and ObservabilityHardTechnical

54 practiced

You need to collect per-interface metrics for 200,000 interfaces and keep Prometheus stable and queryable. Propose concrete architecture options (label design, relabeling to reduce cardinality, push/agent-side aggregation, horizontal sharding, remote-write to long-term stores), estimate expected series counts for alternatives, and propose monitoring/alerting for Prometheus resource saturation.

Sample Answer

**Situation & goal**Collect per-interface metrics for 200,000 interfaces while keeping Prometheus stable and queryable. Focus on concrete architectures, series estimates, cardinality-reduction techniques, and monitoring/alerts.

**1) Baseline estimate (naïve)**- Suppose 10 metrics per interface (ifIn, ifOut, errors, speed, status, etc.) => 200,000 * 10 = 2,000,000 active series in the Prometheus head. With typical label cardinality (interface, device, region, ifIndex) you may get high churn and memory blowup.

**2) Label design & relabeling (reduce cardinality)**- Keep only necessary labels: device (host), interface (short id), region. Drop descriptive labels like long names, VLAN or MAC in head.- Use relabel_config to map long interface names to stable short IDs, and to drop static labels at scrape-time.- Example: drop per-user or per-flow labels; move low-cardinality labels to metric name when appropriate.

**3) Agent-side aggregation / push model**- Run lightweight agents (Telegraf / Vector / custom exporter) on collectors to: - Aggregate counters across polling windows (sum/avg) per device. - Emit per-device rollups (device-level totals) to Prometheus, and per-interface deltas at lower frequency.- Example: emit detailed per-interface every 5–15m, and high-frequency rollups every 15–60s to keep dashboards responsive.

**4) Horizontal sharding & long-term store**- Option A — Sharded Prometheus fleet: shard by device ranges (e.g., 20 Prometheus instances each handling 10k interfaces). Each handles ~100k series (if 5 metrics/interface) => ~1M series per shard — tune down to 50k interfaces/shard.- Option B — Use Cortex/Thanos/Mimir with ingesters + querier, remote_write all scrapes. Keep a small Prometheus for scraping and remote_write to long-term store; use query frontend/caching.- Recommended: combine sharding + remote_write so head stays small and queries offload to long-term store.

**5) Expected series for alternatives (examples)**- Full detail in head: 2M series (unstable for single Prometheus)- Agg + lower freq (every 5m per-interface): 200k interfaces * 2 metrics * (12 per hour) ~ manageable for long-term store; head only stores rollups: ~200k series- Sharded (20 shards) with per-interface metrics at 15s: ~100k series/shard — workable with high memory.

**6) Monitoring & alerting for Prometheus saturation**- Metrics to monitor: - prometheus_tsdb_head_series > threshold (e.g., per-shard 150k) -> Alert - prometheus_tsdb_wal_fsync_duration_seconds > 0.5s -> IO saturation - prometheus_engine_query_duration_seconds (p95/p99) increases -> slow queries - process_resident_memory_bytes > 80% of RAM - TSDB WAL size growth rate high -> high churn - compaction_duration_seconds / compaction_chunk_range -> compaction backlog- Concrete alerts: - Critical: head_series > 120k for 5m or memory > 90% -> scale/shard now - Warning: WAL fsync > 0.5s or compaction backlog > 10m -> investigate disk/IO - Query latency p99 > 2s -> enable query frontend/caching or route to long-term store- Add dashboards: head series over time, churn (new series per minute), WAL size, compaction, scrape durations, and per-scrape error rates.

**7) Trade-offs & recommendation**- For 200k interfaces, do not run a single Prometheus. Best approach: scrape via agents that aggregate and relabel, shard Prometheus by device group, remote_write to a scalable store (Cortex/Thanos/Mimir) for queries/history. Keep head series intentionally small (rollups + critical per-interface metrics at lower frequency), use long-term store for high-cardinality per-interface detail and ad-hoc analysis.

This combination minimizes head memory/CPU, keeps queries responsive, and provides long-term analytics while controlling label cardinality.

Network Architecture and TopologyEasyTechnical

61 practiced

Explain the differences between active-active and active-passive redundancy models. Describe concrete mechanisms to implement gateway or router redundancy on the LAN (VRRP, HSRP, GLBP), explain basic failover behavior, and outline trade-offs for stateful services during failover.

Sample Answer

**Overview — active-active vs active-passive**- Active-active: multiple devices forward traffic simultaneously (load sharing, higher throughput, better utilization). Needs symmetric routing and state replication for stateful services.- Active-passive: one device handles traffic, others standby to take over (simpler, predictable failover, less complex state sync).

**LAN gateway redundancy mechanisms**- VRRP (open standard): elects single master via virtual IP; backups take over on master failure. Fast failover (priority, timers).- HSRP (Cisco): similar to VRRP but uses active/standby roles and proprietary messages; tracked interfaces and preemption options.- GLBP (Cisco): active load-balancing gateway—assigns virtual MACs to multiple routers so clients can be distributed across routers (active-active for L3 gateway).

**Basic failover behavior**- VRRP/HSRP: active sends periodic advertisements; on missed adverts, highest-priority backup assumes the VIP and MAC (gratuitous ARP may be sent to update ARP caches).- GLBP: monitors member health, reassigns virtual MACs; clients continue using their assigned MAC until readdressed.

**Stateful services trade-offs**- Stateless traffic (HTTP, UDP) generally tolerates router failover with brief interruption and ARP refresh.- Stateful services (TCP sessions, NAT, firewall connection tables, IPsec) can break because connection state is held on original device. Mitigations: - State synchronization between peers (session replication, stateful HA like Cisco Stateful Switchover or NSX edge HA). - Use connection draining, short TCP timeouts, clustering, or keepalives at endpoints (multipath, rebalancing). - Design to avoid single-point state (sticky sessions at app layer, external session stores).

**Trade-offs summary**- Active-active improves utilization but increases complexity for state sync and symmetric routing.- Active-passive is simpler and more deterministic but wastes resources and can cause longer failover for stateful flows unless state is replicated.

Switching and VLAN FundamentalsEasyTechnical

35 practiced

How does a switch handle unknown unicast frames when the destination MAC is not present in its MAC table? Explain the forwarding behavior, potential network impact of unknown-unicast flooding in large networks, and common techniques to mitigate excessive flooding.

Collaboration and Communication SkillsEasyBehavioral

70 practiced

Explain what active listening looks like during an incident call or heated meeting. Describe a situation where you used active listening to de-escalate tension or to clarify the real problem, and what concrete actions you took based on what you heard.

Network Troubleshooting and ToolsEasyTechnical

74 practiced

You run ping to a remote site and see: 0% packet loss, average RTT 120ms, but users report intermittent slowness while transferring files. What simple ping-based checks (size variations, counts, interval) would you perform to confirm or rule out latency spikes or packet fragmentation, and how would you interpret the results?

Sample Answer

**Approach (why):**Use targeted ICMP tests to reveal intermittent latency spikes, jitter, and whether large packets are being fragmented or dropped by MTU issues. Consistently sample over time and change payload sizes and DF flag to provoke failures that single short pings miss.

Checks and example commands:

- Baseline continuous small-packet latency (high sample count, short interval)

bash

ping -c 1000 -i 0.2 remote-host
# 1000 pings, 200ms interval

Interpretation: look at min/avg/max/stddev. Large difference between max and avg or high stddev indicates intermittent spikes/jitter even with 0% loss.

- High-frequency flood (if allowed) to stress queues

bash

sudo ping -f -c 200 remote-host
# rapid fire 200 pings

Interpretation: If RTT spikes or loss appears under load, it suggests queueing/congestion on a link or device.

- Size variation to detect fragmentation/reassembly cost

bash

ping -c 20 -s 64 remote-host
ping -c 20 -s 1400 remote-host
ping -c 20 -s 1472 remote-host   # 1472 + 28 ICMP = 1500 MTU

Interpretation: If larger sizes show higher RTT or fragmentation messages, suspect fragmentation or reassembly overhead. If 1472 fails but 1400 works, MTU is between them.

- Test with DF (don't fragment) to find path MTU

bash

ping -c 5 -M do -s 1452 remote-host
# adjust size down until no "Frag needed" error

Interpretation: "Frag needed" means path MTU < attempted size — either lower MTU or PMTUD blocked.

- Measure jitter explicitly

bash

ping -c 200 remote-host | awk -F'/' '/rtt/ {print "avg="$5", max="$6", min="$4", mdev="$7}'

Interpretation: high mdev => jitter that affects file transfers (TCP).

How to read combined results:- Consistent low avg but occasional very high max => intermittent congestion or device/CPU spikes.- Higher RTT with large packets or DF errors => MTU/fragmentation issue.- Failures only under flood/high-frequency tests => capacity/queuing problem, not basic connectivity.

Follow-ups: capture with tcpdump during tests to correlate ICMP spikes with TCP retransmits, and check interface counters and QoS/MTU settings on path devices.

IP Addressing and SubnettingMediumTechnical

50 practiced

Outline the main strategies for migrating from IPv4 to IPv6 in an enterprise: dual-stack, tunneling (examples: 6rd/ISATAP), and translation (NAT64/DNS64). For each approach list the operational benefits, limitations, and common pitfalls to watch for during deployment.

Network Architecture and DesignMediumTechnical

68 practiced

Create a phased IPv6 migration plan for an enterprise network that currently runs IPv4 only. Include addressing strategy, dual-stack deployment approach, transition mechanisms, security considerations, and validation/testing steps. Prioritize minimal user disruption and clear rollback points.

Sample Answer

**Phase 0 — Prep & requirements (1–2 weeks)**- Inventory: host OS/app IPv6 readiness, vendor IOS/firmware, firewall capability, DHCPv6/DNS.- Stakeholders, SLAs, maintenance windows, rollback owners.

**Phase 1 — Addressing strategy (1–2 weeks)**- Use provider-assigned global prefix (e.g., /48) split into /64s per VLAN/site. Reserve ULA (fd00::/8) for private-only segments.- Document plan: site prefix map, SLAAC vs DHCPv6 decisions, IPv6 NAT avoided unless required.

**Phase 2 — Lab & pilot (2–4 weeks)**- Deploy dual-stack in lab: routers, switches, firewall rules, DNS64/DHCPv6 test.- Pilot on non-critical subnet (guest Wi‑Fi or test VLAN). Implement SLAAC + DHCPv6 for managed hosts.

**Phase 3 — Dual-stack rollout (incremental, weeks–months)**- Enable IPv6 on edge routers and upstream peering.- Roll out site-by-site: enable IPv6 L3 SVI (/64), configure RA/DHCPv6, update DNS with AAAA records (staged).- Monitor for routing/latency issues; adjust MTU for tunnels.

**Transition mechanisms**- Prefer native dual-stack where available.- Use 6rd/IPv6-over-IPv4 tunnel for remote sites without provider IPv6.- For IPv6-only services/IPv4 clients: deploy NAT64/DNS64 selectively; for legacy IPv4-only services offer DNS-based split-horizon.

**Security**- Mirror IPv4 policies: stateful IPv6 firewalling, RA guard, DHCPv6 guard, ACLs on IPv6 prefixes, monitoring IDS/IPS signatures for IPv6.- Update ACLs, SIEM parsers, and logging. Test RA/DHCP spoof mitigation.

**Validation & testing**- Test plan per phase: ping6/traceroute6, AAAA resolution, app functional tests, perf tests, security scans.- Use synthetic traffic, NetFlow/IPFIX for visibility, and user acceptance testing.

**Rollback & minimal disruption**- Enable IPv6 per-segment behind feature flags; rollback by disabling RA/IPv6 or removing prefix advertisement at border.- Keep IPv4 intact until full validation; document rollback playbooks and automated scripts.

**Metrics & cutover decision**- Track reachability, error rate, CPU/memory on devices, and user-impact metrics. Only progress to next phase when KPIs met.

Network Troubleshooting MethodologyMediumTechnical

72 practiced

You need to analyze flow data (NetFlow/sFlow) to find the root cause of repeated short TCP sessions from many hosts to a single destination port. Describe a methodology to pivot from flow summaries to packet-level evidence, identify whether this is a legitimate microservice pattern, scheduled job, or malicious scanning, and recommend automated alerts to catch similar anomalies earlier.

Sample Answer

**Methodology overview**

1. **Clarify scope & gather flow summaries**- Query NetFlow/sFlow for destination port, time window, and metrics: src ip, dst ip, src/dst ports, protocol, packet count, byte count, start/end times, flow duration.- Tools: nfdump, Elastic/ELK, Kentik, or vendor flows.

2. **Pivot from flows to packet-level**- From flows, extract top offending dst IP and top source IPs and timestamps.- Generate a targeted capture: apply BPF filter like

text

host <dst_ip> and port <dst_port> and (src net <source_subnet1> or src net <source_subnet2>)

- Capture short window around peak with tcpdump/pcap-ng or pull archived PCAPs; use tshark to reconstruct 3-way handshake, RST/FIN patterns, payload, TLS fingerprints.

3. **Triage: microservice vs scheduled job vs scanning**- Microservice pattern: repeated short sessions from a small set of service IPs, consistent inter-arrival, predictable ports, successful application-layer handshakes, meaningful payloads or TLS ClientHello with expected SNI.- Scheduled job: bursts aligned to cron-ish intervals, consistent source set, identical session sizes and timing, likely internal origin and known automation hostnames.- Malicious scanning: many unique source IPs, varying ports/flags, many SYN without completing handshake, odd TTLs or geo-distribution, short flows with no payload, high source entropy.

4. **Evidence checklist (packet-level)**- TCP flags (SYN-only vs SYN/ACK/ACK)- Flow duration and packet counts- Payload presence, protocol negotiation (HTTP, TLS SNI)- Source diversity and ASN/geolocation- Timing periodicity (use autocorrelation)

5. **Automated alerts**- Alert when dst port receives > X short-duration (<Y sec) sessions from > N distinct sources within T minutes.- Alert on high source entropy or rapid growth in unique sources to a dst IP.- Alert on SYN ratio threshold: (SYN packets without ACKs) / total TCP attempts > Z.- Auto-whitelist known legitimate source-dst pairs (microservices, batch jobs) with exception lifecycle.- Integrate into SIEM with playbooks: trigger pcap capture, reverse DNS enrichment, ASN lookup, and notify Slack/pager with remediation steps.

6. **Follow-up**- If legitimate, document and whitelist; if malicious, block via ACL/NSG, throttle, and initiate incident response with captured PCAPs and flow evidence.

This approach moves from aggregate signals to concrete packet evidence, provides decision criteria to classify cause, and creates actionable automated detection to catch repeats early.

Network Scalability and Growth PlanningHardSystem Design

55 practiced

Design an approach to test network designs for scale in a lab or CI pipeline: how to simulate thousands of hosts, generate realistic traffic patterns (elephant and mice flows), test control-plane behaviors, and validate convergence and failure scenarios before production deployment.

Sample Answer

**Clarify goals & constraints**- Scale: thousands of hosts, realistic L2–L7 traffic- Test types: throughput/latency, control-plane (BGP/OSPF/ECMP/SDN), convergence, failures- CI friendly: repeatable, automatable, observable, resource-bounded

**High-level architecture**- Lab/CI pipeline orchestrator (GitLab/GitHub Actions + Terraform/Ansible)- Emulation layer: mix of lightweight network namespaces/containers (Linux netns, Docker) + accelerated dataplane (DPDK/VPP) for scale- Traffic generators: TRex (stateless + stateful), Scapy/pktgen for microflows, Gatling/Locust for L7- Control-plane simulators: FRR instances, Quagga, or virtual routers (VyOS) per namespace- Observability/validation: Prometheus+Grafana, ELK, packet captures (tcpdump), flow collectors (sFlow/IPFIX)

**Core components & responsibilities**- Provisioning: Terraform to spin VMs/containers and network topology templates (spine-leaf, BGP fabrics)- Host scaling: instantiate thousands of netns with veth pairs or simulate many hosts via TRex/generative profiles if CPU-limited- Traffic patterns: - Mice: Poisson arrivals, short-lived TCP/UDP, randomized endpoints - Elephant: Long-lived bulk flows, sustained high-throughput streams between selected endpoints - Use heavy-tailed distributions (Pareto) to mix sizes and inter-arrival times- Control-plane testing: - Emulate route churn: scripted BGP session flaps, route advertisements/withdrawals - Validate convergence times, RIB/FIB consistency, route dampening effects- Failure injection: - Link/node failures via ip link/netem, simulate device reboot, CPU exhaustion, partitioning - Chaos scheduler integrated into CI (Chaos Toolkit/Ansible)

**Data flow & scenarios**- CI job deploys topology → baseline tests (connectivity, capacity) → ramp traffic (mice → mixed → elephant) → inject failures/churn → record metrics- Post-run validators: check reachability matrix, packet-loss thresholds, CPU/memory, convergence SLA, flows rebalanced under ECMP

**Scalability & optimizations**- Offload heavy packet generation to DPDK-enabled hosts or hardware (Ixia) to avoid host-count explosion- Use host multiplexing (one container simulates many hosts via flow ID namespaces)- Parallelize CI stages and use cached images

**Metrics & success criteria**- Control-plane convergence time < target (e.g., BGP convergence < 5s)- Packet loss < X% under normal load; latency P99 within SLA- No routing inconsistencies (RIB vs FIB), no blackholes after failures

**Trade-offs**- Full-fidelity hardware tests costlier but more realistic; software emulation is cheaper and CI-friendly- Multiplexing reduces resource needs but can miss per-host state issues

Example tools: TRex, FRR, VPP/DPDK, Mininet/EVE-NG for topology modeling, Prometheus/Grafana, Chaos Toolkit.

Practice Network Engineer questions across all topics

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Network Engineer jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs

Senior Network Engineer Interview Preparation Guide - Google

Interview Process Overview

Interview Rounds

Recruiter Screening

What to Expect

Tips & Advice

Focus Topics

Role-Specific Experience

Practice Interview

Study Questions

Motivation for Google

Practice Interview

Study Questions

Career Trajectory and Progression

Practice Interview

Study Questions

Technical Phone Screen 1: Networking Fundamentals and Protocol Deep Dive

What to Expect

Tips & Advice

Focus Topics

DNS and Name Resolution

Practice Interview

Study Questions

Switching, VLANs, and Layer 2

Practice Interview

Study Questions

TCP/IP Protocol Suite

Practice Interview

Study Questions

Network Troubleshooting Methodology

Practice Interview

Study Questions

Routing Protocols and BGP

Practice Interview

Study Questions

Technical Phone Screen 2: Network Design and Troubleshooting at Scale

What to Expect

Tips & Advice

Focus Topics

Network Security in Design

Practice Interview

Study Questions

Network Monitoring and Observability

Practice Interview

Study Questions

Network Architecture Design for Scale

Practice Interview

Study Questions

Complex Troubleshooting Scenarios

Practice Interview

Study Questions

High-Availability and Redundancy Design

Practice Interview

Study Questions

Onsite Round 1: Network Architecture Design Interview

What to Expect

Tips & Advice

Focus Topics

Firewall and Security Architecture

Practice Interview

Study Questions

IP Addressing and CIDR Planning

Practice Interview

Study Questions

Capacity Planning and Growth Scenarios

Practice Interview

Study Questions

Data Center Networking and Inter-DC Design

Practice Interview

Study Questions

Network Topology Trade-offs

Practice Interview

Study Questions

Onsite Round 2: Network Operations and Troubleshooting

What to Expect

Tips & Advice

Focus Topics

Performance Analysis and Optimization

Practice Interview

Study Questions