A user can reach an internal service by IP address but not by name. Another user on the same subnet has no problem. The route table looks ordinary. The fastest way to learn whether a networking candidate can work the problem is not to ask for the definition of DNS. Give the candidate a terminal, a bounded fault, and enough evidence to choose the next test.
That setup reveals more than recall. It shows whether the candidate can separate symptoms from causes, establish what is known, protect the environment, and explain why each command earns the next one. A good networking screen follows that chain from address planning through packet inspection.
Start with a fault, not a vocabulary list
A useful scenario has a clear user-visible symptom, a defined environment, and a safe stopping point. For example: a workstation in one private subnet can reach its default gateway but cannot establish a session with a service in another subnet. The candidate receives interface details, a route table, and access to approved diagnostic commands.
The task is not to produce as many commands as possible. The task is to narrow the fault. A candidate should be able to state what a successful gateway test proves, what it does not prove, and which observation would move the investigation from the local host to routing, name resolution, filtering, or the destination service.
Keep the prompt small enough that the work can be observed. A sprawling lab measures stamina and guesswork. A bounded incident measures decisions.
Subnetting belongs inside the investigation
Subnet questions are useful when they affect a real choice. Ask the candidate to identify the network, broadcast boundary, and usable host range for the address in front of them. Then make that answer matter: should the destination be treated as local, sent to the default gateway, or rejected as an invalid configuration?
For private IPv4 space, RFC 1918 defines three reserved blocks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Knowing the ranges is basic. Applying the prefix to a specific interface and predicting the host's forwarding decision is the stronger signal.
A recruiter does not need to grade mental arithmetic. A defined rubric can separate the observable checkpoints: correct network boundary, correct next hop, correct explanation, and no unsafe configuration change. That makes the evidence easier for a hiring manager to review.
Watch the order of operations
Strong troubleshooting usually has an order. It begins with the local facts, then moves outward. The exact commands vary by operating system, but the reasoning can remain visible:
- Inspect the interface. Confirm address, prefix, link state, and expected interface.
- Inspect local routes. Determine which route should match the destination and which next hop will be used.
- Test the nearest dependency. Check the gateway or another known local endpoint before testing a remote service.
- Separate name resolution from reachability. Compare a name-based test with an address-based test without assuming DNS is the cause.
- Inspect the path and service. Use approved reachability, route, socket, and capture tools to locate where expected traffic stops.
The sequence matters because it limits noise. A candidate who changes DNS settings before checking the configured resolver may fix nothing and destroy evidence. A candidate who captures every interface without a question may create a large trace without creating understanding.
Packet capture should answer a stated question
Packet capture is not a final flourish. It is a test. Before starting, the candidate should say what traffic they expect to see, where they will observe it, and what result would support or reject the current hypothesis.
The Wireshark documentation distinguishes capture filters from display filters. Capture filters limit what is collected and use libpcap filter syntax. Display filters operate on packets that have already been captured and can test protocol fields and values. Confusing the two is a practical error, not a trivia miss.
A compact exercise can ask the candidate to collect only traffic between a client and a service, then use a display filter to inspect a handshake or error response. Cisco's packet-capture guidance similarly makes source, destination, address family, and mask or prefix part of capture setup. Those choices show whether the candidate understands the scope of the evidence.
Score evidence, not style
Two capable engineers may type different commands. The screen should not reward resemblance to one preferred transcript. It should evaluate observable outcomes against a defined rubric: did the candidate establish the local configuration, choose a relevant next test, constrain the capture, interpret the result correctly, and avoid unnecessary changes?
Communication belongs in the same evidence set. Ask for a short handoff at the end: symptom, tests performed, observations, current hypothesis, and safe next action. Networking work often moves between support, systems, security, and application teams. A technically correct finding that cannot be handed off cleanly is incomplete operational work.
Structured checkpoints also make review more consistent. The hiring manager can inspect the work and the explanation instead of relying on confidence, speed alone, or familiarity with a particular tool.
Keep the environment safe and fair
Use a sandbox or isolated lab. Provide the same starting state, permissions, time box, and reference material to every candidate. State which commands and changes are allowed. Remove secrets and production data from packet traces. If a task includes privileged access, make the boundary explicit and log the actions that matter to the rubric.
Do not hide a trick in the prompt. The fault can be difficult without being ambiguous. If the scenario depends on a platform-specific fact, provide the relevant context or allow documentation. The goal is to observe networking judgment, not to reward whoever has memorized the same appliance menu.
What the reviewer should receive
The final review packet should be short: the scenario, the starting state, the candidate's terminal work, the relevant capture evidence, the handoff note, and the completed rubric. That is enough to discuss the work in a structured interview without pretending the assessment replaces the interview.
OpsTicket provides terminal-based IT skills assessments across multiple career tracks for candidates and hiring teams. Candidates can use OpsTicket free. Recruiter Pro access is $49 per month at tryopsticket.com/pricing. OpsTicket is a product of IT Custom Solution LLC.
Takeaway: a networking screen should move from a bounded symptom to observable decisions. Test address boundaries, route selection, dependency isolation, capture scope, interpretation, and handoff. The command list is secondary to the evidence.
Hiring teams that need help defining the role, scenario boundaries, or review handoff can see IT Custom Solution's services and start with the operating problem, not a generic test bank.