Past ExamsRwanda ICT preparation

Network Engineer interview questions and answers

An engineering interview tests whether you can design a network, defend the design, and diagnose what goes wrong when it meets reality. Panels often start with a concept and keep asking "why" until they reach the edge of your knowledge. That is normal, and how you behave at that edge matters as much as the facts. These questions show the depth expected and a sound way to structure each answer.

How this guide was made

Written for this site with AI assistance, then checked automatically before publishing. The topic table, sample questions, worked examples and study plan are generated from this site’s question bank: each worked example is recalculated by separate code, and each sample answer says where it came from.

The guide deliberately states no salaries, grades, pass marks or exam dates. Those change, and they could not be checked here, so take them from the advert itself.

This site is independent and is not affiliated with MIFOTRA or any employer.

"How does a router decide which route to use?"

Give the three stages in order. The longest matching prefix wins first, regardless of where the route came from. If two sources offer the same prefix, the lower administrative distance wins, so a static route beats OSPF. Within one routing protocol, the lower metric wins, which for OSPF means the lower total cost.

Then show you can apply it. Explain, for example, why adding a static /32 route for a server pulls that server's traffic away from the OSPF path, even though OSPF carries the rest of the subnet.

"Explain how OSPF forms a neighbour relationship."

Walk through the states: Down, Init and 2-Way, then ExStart, Exchange and Loading, ending in Full. Hello packets discover neighbours, and two routers must agree on the area, the subnet, the hello and dead timers, and authentication before they become neighbours.

Add a troubleshooting angle. If two routers never reach Full, compare those parameters first, and suspect an MTU mismatch when they stall in ExStart or Exchange.

"Design the network for a branch office that must stay online if its main link fails."

Start by asking questions, because the answer depends on requirements: how many users, which applications, what budget, and how long an outage the business can tolerate. Then outline a design. Use a primary link and a backup from a different provider or technology, with the backup carried over an IPsec VPN if it crosses the internet. Let routing move traffic automatically, for example with a floating static route or a dynamic protocol, and test the failover before handover.

Panels value candidates who state their assumptions and weigh trade-offs aloud, such as the cost of a second provider against the cost of downtime.

"What problem does a first-hop redundancy protocol solve?"

Hosts normally have a single default gateway. If that router fails, they lose connectivity even when another router is available. HSRP or VRRP lets two routers share a virtual IP address that hosts use as their gateway. One router is active, and if it fails the standby takes over the virtual address, so hosts keep working with no change on their side.

Mention the details: priority decides which router is active, preemption controls whether a recovered router takes the role back, and interface tracking can lower a router's priority when its uplink fails.

"Users say the network is slow. How do you investigate?"

Separate perception from measurement. Find out who is affected, which applications, and since when. Check utilisation and error counters on the links in the path, and look for drops on congested interfaces. Compare latency and loss inside the network with latency to outside services, because the slowness is often beyond the local network.

With evidence in hand, the fix might be a link upgrade, quality of service for critical traffic, or removing an unexpected source of load. The panel wants to hear that you measure before you spend money.

"Tell us about a change that did not go to plan."

Choose a real example and be specific. Explain the change, what went wrong, how you noticed, and how you restored service. Then explain what you changed in your process afterwards: a better rollback plan, a lab test first, or a peer review of the configuration.

Engineers who have never had a change go wrong have usually not made many changes. Panels listen for ownership and learning, not for a spotless record.

"How would you approach automating network configuration?"

Begin with the problem: repetitive changes made by hand are slow and inconsistent. Describe starting small, for example backing up configurations automatically, then generating standard configurations from templates. Tools such as Ansible, Python libraries or vendor APIs make this practical. Stress version control and testing, because automation that pushes a mistake pushes it everywhere at once.

Open adverts for this position

No open Network Engineer advert matched when the jobs board was last checked. It is refreshed every morning.

Browse every open vacancy

Common questions

How deep will the technical questions go?

Usually until you reach the limit of what you know. When that happens, explain how you would find the answer rather than guessing, and connect it to something you do know well.

Should I draw diagrams in the interview?

If a whiteboard or paper is available, yes. A quick sketch makes a design explanation clearer and shows the panel how you think.

More Network Engineer guides

The same guide for related positions