- The Routing Intent by Leonardo Furtado
- Posts
- So You Want to Work at a FAANG as a Network Engineer? Here's What You Really Need to Know
So You Want to Work at a FAANG as a Network Engineer? Here's What You Really Need to Know
12 Unfiltered Realities of Building and Operating Networks at Hyperscale

In my last post, I walked you through what it’s like to be a network engineer at a hyperscaler, especially within the so-called FAANG (or Magnificent Seven) companies.
Now, let’s take that a step further.
This post is more than just a continuation; it’s a practical roadmap of what to expect, what skills matter most, and why working in these environments is unlike anything you’ve ever seen.
Let’s dive in.
1. Forget Manual Work. It Doesn’t Exist Here
Let’s get this out of the way:
Manual processes are banned.
No SSHing into routers.
No pushing changes via CLI.
No tribal knowledge passed over coffee chats.
At FAANG-level scale, manual operations become bottlenecks and risk multipliers.
Even a single manual operation can introduce unacceptable risk, delay, or inconsistency. A mistyped command, an undocumented change, or an engineer manually intervening in a deployment pipeline becomes a single point of operational fragility.
Multiply that across thousands of devices and dozens of services, and the margin for error evaporates. That’s why manual touchpoints are treated not just as inefficiencies, but as systemic liabilities.
Whether it’s deploying a new routing policy or performing a rollback during a critical event, these actions must be automated, validated, and repeatable by design. There’s no room for manual improvisation, not in production, not in staging, and not even in pre-staging testbeds.
2. Network Automation Is Not Just Automation: It’s Software Engineering
Network automation goes far beyond the obvious and what most engineers use nowadays. Even tasks that are semi-automated in other companies, like Ansible playbooks or Rundeck jobs, are considered legacy and insufficient.
In most environments, network automation means writing a script, pushing a config, or running a scheduled job.
We see these at many companies, but they simply do not reflect the reality of a FAANG. If your automation doesn't scale, validate, and auto-reconcile by design, it won’t be accepted.
At hyperscale, that’s the bare minimum.
Here, automation is treated like any other software system: modular, testable, version-controlled, and built for continuous improvement.
It blends everything together: business logic, telemetry with vast amounts of data to capture and manage network states and network intents, and multiple layers of software with APIs everywhere for you to pull, consume, normalize, and transform the data required to implement any code you need to achieve your objectives.
You’ll work with:
Infrastructure-as-Code pipelines
Custom orchestration frameworks
Network state compilers and validators
Automated reconciliation agents
Telemetry-based feedback loops
Modern hyperscale automation frameworks go far beyond pushing configuration deltas or triggering pre-defined workflows. These systems are fully aware of the network’s intent and current state, constantly reconciling the two in near real-time.
They don’t just execute changes; they observe the network to understand what it is actually doing, compare it against what it should be doing, and take corrective action autonomously. This level of intelligence requires deeply integrated telemetry, robust state machines, and code that can reason across distributed systems.
If your experience as a network engineer is limited to tools like Ansible or Nornir, valuable as they are, understand that’s just the entry point. It's just Chapter One of the automation playbook.
At hyperscale, network automation is indistinguishable from infrastructure software engineering.
3. Everything Is Software-Centric — Even the Way You Think
Hyperscale networks are more than just cables, routers, and packets. They’re distributed systems, governed by business logic and expressed through software.
At hyperscale, the network is no longer a passive transport layer; it is a core part of the distributed system itself. Every routing decision, path preference, or policy enforcement must reflect the broader application and business requirements.
This means network behavior is not driven by device-centric thinking, but by high-level intent, which is codified, abstracted, and orchestrated across multiple layers of software.
Latency budgets, redundancy policies, service placement strategies, and more are all encoded in software, continuously evaluated, and shaped by business logic. The result? A network that acts not just as infrastructure, but as a dynamic, policy-aware extension of the application ecosystem.
Here’s how the layers interact:
Business Logic: Why the network must evolve; cost, availability, customer impact.
Telemetry: What the network is actually doing; performance, anomalies, intent compliance.
Abstraction Layers: Define services, topologies, and intent in a hardware-agnostic way.
APIs Everywhere: Whether it’s device state, topology data, customer paths, or service dependencies, it’s all available, queryable, and scriptable.
You won’t be logging into devices to "check things" or running ad hoc scripts to extract state. Instead, you’ll interface with a rich ecosystem of APIs, spanning inventory systems, topology graphs, telemetry platforms, fault managers, and service registries.
Your job is to ingest this data programmatically, clean it, model it, and feed it into control loops that drive autonomous decision-making.
Whether you’re provisioning capacity, rerouting around failure, or deploying a new service class, every action is informed by dynamic signals and tied directly to a business-level objective.
In short: you’ll architect systems that turn intent into action continuously, at scale, and without human bottlenecks.
4. Your Job Is to Engineer at Scale by Using Software Thinking
Being a world-class network engineer isn’t enough anymore. You need to think in terms of software systems, lifecycle management, and scalability.
Deep protocol knowledge and troubleshooting skills are still essential, true, but they are no longer the full measure of success. At this level, you must operate with the mindset of a distributed systems engineer, not just a network specialist.
You’ll need to think in terms of end-to-end lifecycles: from design and provisioning to deployment, observability, auto-remediation, and continuous evolution.
Every solution must be scalable by default, resilient to failure, and capable of adapting at the pace of the business.
You’re no longer solving isolated networking problems. You’re engineering platforms that solve them for the entire fleet.
Ask yourself:
How do I model this topology in code?
Can I simulate, validate, and roll back this change safely?
Will this work for 10,000 routers, or only for the 10 in my lab?
Can this system run and heal itself without human intervention?
Your value isn’t in knowing the protocol inside-out.
Your value is in building systems that understand, express, and enforce protocol behavior at hyperscale.
5. Expect to Spend 60% of Your Time in Code, and 40% in Documents, Meetings, and Ops
That’s not an exaggeration. Your weekly breakdown might look like:
Writing and maintaining orchestration pipelines
Implementing validation logic
Parsing telemetry data and normalizing it into state models
Crafting + presenting or reviewing design docs or HLDs in Design Review meetings
Participating in postmortems, WBRs (Weekly Business Reviews), MBRs (Monthly Business Reviews)
Going on-call for Tier 1 services
These companies run 24/7. There’s no “quiet week.”
You’re expected to operate across both proactive engineering and reactive operations with a level of rigor, discipline, and calm under pressure that leaves no room for guesswork or emotional volatility.
Whether you're designing a new network service, deploying a major architecture change, or responding to a real-time incident during an on-call shift, your decisions must be deliberate, your actions precise, and your mindset steady.
At this level, composure isn't optional: it’s a core part of your engineering DNA. Because when you’re responsible for infrastructure that powers millions of users and billions of transactions, the quality of your execution defines the quality of the business.

Subscribe to our premium content to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content. No fluff. No marketing slides. Just real engineering, deep insights, and the career momentum you’ve been looking for.
Already a paying subscriber? Sign In.
A subscription gets you:
- • ✅ Exclusive career tools and job prep guidance
- • ✅ Unfiltered breakdowns of protocols, automation, and architecture
- • ✅ Real-world lab scenarios and how to solve them
- • ✅ Hands-on deep dives with annotated configs and diagrams
- • ✅ Priority AMA access — ask me anything