My Favorite Network Engineer Interview Question

Most networking interviews feel like certification pop quizzes.

What is the administrative distance of OSPF?

What port does BGP use?

What does DHCP option 150 do?

Those questions are useful. They can quickly tell you if someone has studied the basics or if they are trying to fake their way through the room. But they do not tell you how that person thinks when the network stops being a flash card and starts becoming a real place with users, buildings, remote sites, firewalls, WAN links, wireless, identity, and a help desk ticket that says "the internet is down."

That is why my favorite network engineer interview question is not really a question.

It is a task.

I hand someone a marker, or open a digital whiteboard if we are remote, and say this:

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.

Because the answer is not really the diagram.

The answer is how they think through the diagram.

The CCNA Answer Is Usually Where People Start

If someone is newer to networking, especially if they are coming straight out of CCNA study mode, I usually get some version of the classic three-tier campus design.

Core.

Distribution.

Access.

And honestly, that is not a bad place to start.

The CCNA teaches you that model for a reason. It gives you a clean way to think about a campus network. Access switches connect users. Distribution aggregates access. Core moves traffic fast between major blocks.

That is useful.

But if the prompt is 2,000 to 3,000 users with remote sites, that diagram is not enough.

It answers one slice of the problem. It does not answer how the business gets to the internet. It does not answer how remote sites connect. It does not answer where security inspection happens. It does not answer where DNS, DHCP, identity, wireless control, monitoring, or server access live.

In a certification diagram, the network can look clean.

In a real enterprise, the network has plumbing.

And plumbing is where things get interesting.

Start With What Users Actually Need

The first thing I want to hear is not vendor names.

I do not want someone to immediately say Cisco, Palo Alto, Fortinet, Meraki, Mist, Aruba, SD-WAN, or whatever else showed up in the last webinar.

I want them to start with users.

What do 2,000 to 3,000 users need from the network?

They need wired access.

They need wireless access.

They need internet access.

They probably need access to internal applications.

They need authentication.

They need name resolution.

They need IP addresses.

They need security controls.

They need redundancy, because one circuit, one firewall, one core switch, or one controller should not be able to ruin everyone's day.

That sounds simple, but this is where a lot of interviews split in half.

Some people start drawing boxes they memorized.

Stronger candidates start asking what the users and applications need, then draw the boxes that support that.

That is the difference between reciting networking and designing a network.

Internet Is Not Just A Cloud Icon

A lot of diagrams draw the internet as a little cloud at the top.

That is fine for a whiteboard. But for an enterprise network, I want someone to explain what sits between that cloud and the users.

Do we have redundant internet circuits?

Are they from different providers?

Do they enter different parts of the building?

Do we have edge routers?

Do we have firewalls?

Are the firewalls high availability?

Where does NAT happen?

Where does VPN terminate?

Where does inbound access live, if the business hosts anything publicly?

If you draw a single firewall connected to a single ISP and call it done, that may work for a small office. It is not where I want to land for a large campus with thousands of users.

This is also where I want to hear tradeoffs.

Not every business needs two of everything in every location. Not every remote site deserves the same design as headquarters. But if you are designing for thousands of users, you need to know where the single points of failure are, and you need to be able to explain which ones you are accepting on purpose.

That is real design.

Do Not Collapse Everything Just Because It Looks Cleaner

There is a design pattern that works fine in smaller environments: put routing, firewalling, WAN, and sometimes core switching into fewer boxes.

For a branch, that can make sense.

For a small site, that can make sense.

For a 2,000 to 3,000 user enterprise campus, I get nervous when everything collapses into one layer without a very 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.

So when someone draws the design, I want to see whether they understand failure domains.

Where does the WAN fail?

Where does the firewall fail?

Where does the core fail?

Where does wireless fail?

What happens if one access switch dies?

What happens if an ISP circuit dies?

What happens if a firewall pair fails over?

A good design is not just a pretty diagram. It is a diagram with blast radius in mind.

Remote Sites Change The Conversation

The remote sites in the prompt are there for a reason.

They force the candidate to leave the comfort of the campus diagram.

How do those sites connect back?

Private WAN?

VPN?

SD-WAN?

Direct internet access?

Backhaul through headquarters?

Local breakout?

Do remote users authenticate locally if the WAN is down?

Does DNS still work?

Does DHCP still work?

Can the site operate in a degraded mode, or does everything depend on the headquarters data center being reachable?

There is no single perfect answer here.

It depends.

I know that is the least satisfying answer in networking, but it is also usually the correct one.

The point is not whether someone picks the exact design I would pick. The point is whether they can explain why they picked it and what breaks when one part of it fails.

Wireless Is Not Magic Dust You Sprinkle On Later

Wireless is another place where the basic diagram often falls apart.

In a real enterprise, wireless is not just "add access points."

Where do the access points connect?

How are they powered?

Do the switches have enough PoE budget?

Are we using a wireless LAN controller?

Is it physical, virtual, or cloud-managed?

Where do guest users go?

How are corporate users authenticated?

Are we using 802.1X?

What VLANs or policy segments exist?

How does roaming work across the campus?

You do not need to be a wireless wizard to answer the interview question. But you should know that wireless has a control plane, an access layer, authentication, addressing, and security decisions just like the wired network.

If the design treats Wi-Fi like an afterthought, the actual users will find out very quickly.

DHCP, DNS, And Identity Are Not Side Quests

This is one of the biggest gaps between textbook diagrams and real networks.

Textbook diagrams love switches, routers, and firewalls.

Real users care whether they can log in, get an IP address, resolve a name, and open the application they need.

That means DHCP matters.

DNS matters.

Active Directory or whatever identity system the company uses matters.

Certificate services may matter.

Network access control may matter.

Monitoring and logging matter.

If someone draws a beautiful Layer 3 design but never mentions how clients get addresses or resolve names, the design is incomplete.

Because when DHCP breaks, the user does not say "DHCP is broken."

They say the network is down.

When DNS breaks, they do not say "name resolution is failing."

They say the app is broken, the VPN is broken, the internet is broken, or everything is broken because apparently DNS likes wearing disguises.

A real network design has to include the boring services that make the pretty network useful.

Security Is More Than A Firewall Box

I do want to see firewalls in the design.

But I also want to see whether the candidate thinks security stops there.

Where are users authenticated?

How are admins authenticated?

Are network devices managed through a separate management network?

Are logs going somewhere useful?

Is guest wireless segmented?

Are remote sites using the same policy model as headquarters?

Are servers separated from users?

Are there different zones for different application types?

A firewall is important, but it is not a magic safety rectangle.

Security is also segmentation, identity, policy, visibility, and operational discipline.

That does not mean every interview answer needs to include a full zero trust architecture and seventeen acronyms. Please do not do that to anyone.

But I want to know if the person understands that a big enterprise network needs more than "inside good, outside bad."

The Best Candidates Ask Questions

The strongest answers usually start with clarifying 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 kind of uptime does the business expect?

Do remote sites need to keep working if the WAN fails?

What is the budget?

What is already installed?

That last one is underrated.

In the real world, you rarely design on a blank sheet of paper. You inherit things. Old switches. Circuits with contracts attached. Firewall rules nobody wants to touch. VLANs named after departments that stopped existing twelve years ago. 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.

What I Am Really Looking For

I do not expect a perfect diagram.

Honestly, I would be suspicious of a perfect diagram in an interview because real design depends on details I have not given you.

What I want is the thought process.

Can you start with user and business needs?

Can you identify the major building blocks?

Can you explain where redundancy belongs?

Can you separate campus, edge, WAN, data center, wireless, and remote site concerns?

Can you talk through DHCP, DNS, identity, monitoring, and security services?

Can you explain tradeoffs without pretending there is one universal answer?

Can you say "I would need more information" without freezing?

That last one matters more than people think.

Looking things up, asking clarifying questions, and admitting what you do not know are not weaknesses. That is how real engineering works. The dangerous person is not the one who asks questions. The dangerous person is the one who confidently designs around assumptions they never checked.

If You Are Studying For Networking Interviews

If you are preparing for a networking job interview, practice this.

Draw a network for a large campus.

Then make it harder.

Add remote sites.

Add guest wireless.

Add redundant internet.

Add a data center.

Add cloud applications.

Add a WAN outage.

Add a firewall failure.

Add a user who can connect to Wi-Fi but cannot reach anything useful, because apparently we are all here to suffer a little.

Do not memorize one perfect diagram.

Memorize the questions you should ask.

Memorize the building blocks.

Understand what each piece does.

Then practice explaining why it belongs in the design.

That is what separates someone who studied networking from someone who is starting to think like a network engineer.

And that is why I love this interview question.

It does not just test what you know.

It shows how you think when the network turns into a real place.