
It tests the candidate's structured troubleshooting logic, networking fundamentals (OSI model, TCP/IP, DNS, DHCP), and ability to think critically under pressure, which are core to a technical support engineer role.
Explicitly reference OSI layers as you walk through your steps, from physical to application. Demonstrate that you prioritize quick wins for the user but have a full mental checklist. Mention how you would document findings for escalation if needed.
Work through the OSI layers from bottom to top so nothing gets skipped. Physical layer: check modem, router, and cable status and any indicator lights. Data link layer: check the network adapter status and confirm the device sees the network at all. Network layer: verify the device has a valid IP address, correct subnet, and can reach the default gateway, using a ping test if available. Transport and application layers: check whether a firewall or security software is blocking specific ports, then test DNS resolution separately from raw connectivity by trying a known IP address directly versus a domain name. Prioritize the fastest likely fix for the user first, such as a restart or cable reseat, while still keeping the full layered checklist in mind. Document which layer the issue was isolated to and the diagnostic results, so if it needs to go to another team, they can pick up from where you left off instead of starting over.
Some candidates jump to assumptions like 'Baka expired na promo ninyo, sir,' without checking basics. This can misdirect the entire call. Instead, always verify physical connectivity and IP configuration first before speculating about account issues.
Situation
In a hypothetical technical support call, a remote employee reports that their laptop suddenly cannot reach any websites or company resources, though they can log in normally. They are on a tight deadline and sound stressed.
Task
I need to methodically identify whether the issue is at the user's end, the local network, or beyond, and guide them to a resolution while keeping them reassured.
Action
I would begin at the physical layer: ask if the Ethernet cable is plugged in or if WiFi is enabled, and check for link lights. Then move to data link: verify the network adapter status and whether they have a valid IP address via ipconfig (if Windows). I'd ping 127.0.0.1 to confirm the TCP/IP stack works, then ping the default gateway to test local network connectivity. If that works, I'd ping 8.8.8.8 to see if external traffic reaches the internet. If local but not external, I'd check DNS by pinging a domain name versus an IP, and inspect proxy or firewall settings. I'd also ask them to try a different device on the same network to isolate the problem.
Result
By following this bottom-up OSI-model approach, I would isolate the fault in under ten minutes, whether it's a loose cable, DHCP misconfiguration, DNS outage, or ISP issue, and either resolve it or escalate with clear diagnostic notes.
Layered troubleshooting proves that assumptions waste time, but structured checks save it.
Write your own answer, then get instant AI feedback graded against:
Get AI feedback on your answer — free.
3 free AI-graded answers + 1 free mock interview, no card needed.
Sign Up FreeAlready have an account? Log in
Sign in to join the conversation.
No answers shared yet — be the first to show how you'd approach this.