The Interview Question That Shows How You Think

My favorite network engineer interview question is not really a question. It is a whiteboard task.

You are in charge of designing an enterprise network for about 2,000 to 3,000 users with remote sites. Draw the network diagram. Show me what you would need.

Then I stop talking.

That is the whole point. I am not looking for the one perfect diagram, because there is not enough information in the prompt to have one. I am looking for how someone thinks when the network stops being a certification diagram and starts becoming a real place.

Newer candidates usually start with the classic core, distribution, and access model. That is not wrong. The CCNA teaches that for a reason. Access switches connect users, distribution aggregates access, and the core moves traffic between major parts of the network. Cool. That is a useful mental model.

But for a 2,000 to 3,000 user enterprise with remote sites, that answer is incomplete. It does not explain how the business gets to the internet. It does not explain how remote sites connect. It does not explain where firewalls, WAN routers, wireless controllers, identity, DHCP, DNS, monitoring, logging, or server access live.

In a cert guide, the network can look clean. In a real enterprise, the network has plumbing. And the plumbing is where things get interesting.

The stronger answer starts with users. What do they need? Wired access. Wireless access. Internet access. Internal applications. Authentication. Name resolution. IP addresses. Security controls. Redundancy, because one circuit, firewall, core switch, or controller should not be able to ruin everyone's day.

That is where the interview gets useful. Some people draw boxes they memorized. Stronger candidates draw the boxes that support what the users and applications actually need.

I also want to hear tradeoffs. Do we have redundant internet circuits from different providers? Where do the firewalls sit? Are they high availability? Where does NAT happen? How do remote sites connect back? Private WAN, VPN, SD-WAN, direct internet access, local breakout? Does the site keep working if the WAN fails, or does everything depend on headquarters?

There is no single answer here. It depends. I know that is the least satisfying answer in networking, but it is also usually the correct one.

For a branch or small site, collapsing routing, firewalling, WAN, and core functions into fewer boxes can make sense. For a 2,000 to 3,000 user campus, I get nervous when everything collapses into one layer without a good reason. Fewer boxes can be simpler. Fewer boxes can also mean one maintenance window, one bug, or one hardware failure takes out way more than it should.

That is what I want the candidate to understand: failure domains. Where does the WAN fail? Where does the firewall fail? Where does wireless fail? What happens when an access switch dies? What happens when an ISP circuit dies? A good design is not just a pretty diagram. It is a diagram with blast radius in mind.

The best candidates ask questions. How many buildings? How many remote sites? What applications are critical? Do we host our own data center? Are workloads in the cloud? What uptime does the business expect? What is already installed?

That last one is underrated. In the real world, you rarely design on a blank sheet of paper. You inherit old switches, circuit contracts, firewall rules nobody wants to touch, VLANs named after departments that stopped existing years ago, and documentation that was apparently written by someone fleeing the building.

So yes, draw the ideal design. But also show me you know real networks are inherited, migrated, and fixed while people are still using them.

That is the job.

→  If you are preparing for networking interviews, practice designing a campus network out loud. Do not just draw it. Explain why each piece belongs there.

→  Start with users and applications before vendors and products. The boxes should support the requirement, not the other way around.

→  Always call out failure domains. A design that looks simple can still be fragile if one outage takes out too much of the business.

→  Do not be afraid to ask clarifying questions. Confident assumptions are more dangerous than honest gaps.

Most Network Engineers Fail This Interview Question

The video version of this breakdown walks through the whiteboard prompt and the major design pieces I want candidates to think about.

Why it matters: Watching someone build the diagram is useful because design thinking is easier to see than memorize.

The full written version

I expanded the topic into a full post with the campus, internet edge, WAN, wireless, DNS, DHCP, identity, and failure-domain pieces in one place.

Why it matters: This is the kind of prompt you can practice repeatedly as you move from certification knowledge into actual design conversations.

Cloudflare's route leak incident write-up

Cloudflare's January route leak post is a good reminder that routing policy mistakes do not stay neatly contained just because the diagram looks clean.

Why it matters: Routing design is not only about reachability. It is also about guardrails, validation, and understanding what a bad change can affect.

The Weekly Packet by Kevin Nanns

Network engineer. Content creator. adjacentnode.com