3rd Line Support Engineer interview questions and practice.
Handles the hardest escalations, root-causing complex infrastructure and application faults and driving permanent fixes. An interviewer hiring a 3rd Line Support Engineer is not testing whether you know what the job is. They are trying to establish whether the estate would be in a better state a year after you joined, and whether you would tell them honestly when something you changed caused the outage.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
What interviewers for 3rd Line Support Engineer actually ask
Three questions from the bank below, each scored against one competency. The follow-up is what separates a prepared answer from a memorised one.
Users say the application is slow. Everything is green on the dashboard. Where do you start?
Tell me about the worst outage you have been part of.
Tell me about a change you made that broke something.
What they are really assessing
That gets scored against 8 competencies: infrastructure troubleshooting under pressure, server, virtualisation & identity administration, network design & operation, security hardening & patch management, backup, disaster recovery & capacity, change management & automation, monitoring, documentation & handover and service mindset & ownership. Each one is assessed from the specifics in your answers, which is why "we improved the process" scores lower than a sentence with a number, a date and a decision in it.
At mid level they assume you can do the job and are testing how you handle the parts that go wrong. Expect them to push hardest on a complex outage to root cause, a change gone wrong, and backup or DR testing they did.
Infrastructure troubleshooting under pressure
Diagnoses outages and performance problems across servers, networks and services methodically, using the right tools and evidence, and restores service safely.
- Weak
- Outage stories are 'we rebooted the server'; cannot describe isolating a problem across layers (DNS, routing, firewall, application) or what tool confirmed the cause.
- Adequate
- Follows a layered approach and uses packet captures, logs and monitoring to isolate issues, but sometimes restores service without finding the root cause.
- Strong
- Gives a specific outage: how they scoped the blast radius, the layered hypotheses tested with named tools (tcpdump, traceroute, event logs), the root cause, the restore decision and the change that prevented recurrence.
Server, virtualisation & identity administration
Builds and maintains Windows and Linux servers, virtualisation, storage and identity services (AD/Entra, DNS, DHCP) to a consistent, documented standard.
- Weak
- Builds servers by hand with no standard; cannot explain group policy processing, DNS resolution order or storage performance basics.
- Adequate
- Maintains servers, virtualisation and AD competently with some standard builds, but configuration drift and undocumented changes still occur.
- Strong
- Describes standardised builds via images or configuration management, an identity or DNS design decision with rationale, and a drift or misconfiguration problem they eliminated systematically.
Network design & operation
Designs, configures and operates LAN, WAN, wireless, routing, switching and firewalls with attention to segmentation, redundancy and performance.
- Weak
- Can configure a switch port but cannot explain VLANs, routing decisions, spanning tree or why a firewall rule broke an application.
- Adequate
- Configures VLANs, routing, firewall policies and wireless competently and has redesigned part of a network, but redundancy and failover were not tested.
- Strong
- Describes a network design (segmentation, routing, redundancy) with the reasons, a failover test and its result, and a performance or loop issue diagnosed to root cause.
Security hardening & patch management
Keeps systems patched, hardened and least-privilege, manages certificates and access, and balances security against availability.
- Weak
- Patching is ad hoc; admin accounts are shared; cannot describe a hardening baseline or an expired certificate incident.
- Adequate
- Runs a patch cycle with testing and maintenance windows and applies hardening baselines, but privileged access and certificate lifecycle are managed reactively.
- Strong
- Describes a patch and hardening programme with compliance numbers, privileged access controls (tiering, MFA, just-in-time), and a security incident or near miss that led to a specific control.
Backup, disaster recovery & capacity
Ensures data and services can be recovered within agreed RPO/RTO through tested backups and DR plans, and plans capacity before it runs out.
- Weak
- Backups run but have never been restored as a test; cannot state RPO/RTO or describe a capacity problem they anticipated.
- Adequate
- Has backups with periodic restore tests and a DR plan, but full DR has not been exercised and capacity is managed when alerts fire.
- Strong
- Describes a restore or DR test with its results and gaps found, a real recovery performed, and a capacity forecast that drove a purchasing decision before an outage.
Change management & automation
Makes changes safely through planning, testing, rollback and communication, and automates repetitive work with scripts and configuration management.
- Weak
- Changes are made live without a plan; cannot describe a change that went wrong and the rollback; automation is limited to a few scripts.
- Adequate
- Follows a change process with rollback plans and has automated routine tasks in PowerShell, Bash or Ansible, but testing before production is inconsistent.
- Strong
- Gives a change that went wrong, how the rollback plan worked and what changed in the process, and an automation with measured time saved or errors removed.
Monitoring, documentation & handover
Keeps the environment observable and documented so problems are detected early and others can operate it.
- Weak
- Problems are reported by users first; documentation is in the admin's head; cannot describe a runbook they wrote.
- Adequate
- Has monitoring with alerting and maintains documentation and diagrams, but alert noise is high and documentation lags changes.
- Strong
- Describes tuning monitoring to reduce noise and catch real issues earlier, runbooks that let others resolve incidents, and evidence of a smooth handover or on-call rotation.
Service mindset & ownership
Treats the business as the customer: communicates outages honestly, negotiates maintenance windows, and owns problems across vendors and teams until resolved.
- Weak
- Communicates only when asked; blames vendors or users; cannot describe negotiating a maintenance window or chasing a vendor to resolution.
- Adequate
- Communicates outages and maintenance and manages vendor tickets, but updates are irregular and vendor issues drift.
- Strong
- Gives a case of managing a vendor issue to resolution with escalation, an outage communication that kept business trust, and a maintenance negotiation that balanced risk and business needs.
11 questions you should expect
What a strong answer contains, not a model answer to memorise. A memorised answer falls apart on the first follow-up, and there is always a follow-up.
Users say the application is slow. Everything is green on the dashboard. Where do you start?
Scored against: Infrastructure troubleshooting under pressureA strong answer contains: Establish scope and a timeline first (who, where, since when, what changed), then work the path end to end: client, network, name resolution, load balancer, application, database, storage. Naming what they would rule out cheaply and first is what separates strong from adequate.
And then they askIt is only the branch office. What are the three most likely causes?
Tell me about the worst outage you have been part of.
Scored against: Infrastructure troubleshooting under pressureA strong answer contains: The trigger, what was tried, what actually restored service, the duration, and the honest post-mortem including anything they did that made it worse. Candidates who describe an outage with no missteps are usually describing one they only watched.
And then they askWhat did the post-mortem change, and did it stick?
Tell me about a change you made that broke something.
Scored against: Change management & automationA strong answer contains: What it was, why the testing did not catch it, how quickly it was rolled back, and what they changed about the change process afterwards. Owning it plainly is the whole point of the question.
And then they askWhat was your rollback plan, and did it work as expected?
What have you automated, and what did it replace?
Scored against: Change management & automationA strong answer contains: A specific script or pipeline (onboarding, patching, certificate renewal, backup verification, reporting), with the manual work it removed and the time saved. Best answers mention what they deliberately did not automate and why.
And then they askWhat did you decide was not worth automating?
How does patching actually happen where you work?
Scored against: Security hardening & patch managementA strong answer contains: A real cadence, rings or waves, how they handle the server nobody is allowed to reboot, how exceptions are recorded and reviewed, and their compliance percentage. Aspirational answers with no number behind them are transparent.
And then they askWhat is your patch compliance, and which systems are the exceptions?
A critical vulnerability is published this afternoon. Walk me through the next four hours.
Scored against: Security hardening & patch managementA strong answer contains: Establish exposure before panicking (what runs it, is it internet-facing, is there a workaround), then a decision about emergency change versus mitigation, comms to the business, and verification afterwards.
And then they askHow do you find out what is actually running that version?
When did you last restore something, and how did it go?
Scored against: Backup, disaster recovery & capacityA strong answer contains: An actual restore rather than a successful backup job (a file, a VM, a database, ideally a full DR test), with the time it took against the RTO. "Our backups run nightly" without a restore is the answer that worries interviewers.
And then they askWhat is your RTO and RPO, and have you ever proved you can meet them?
How would you segment a flat network without breaking everything on the first Monday?
Scored against: Network design & operationA strong answer contains: Discover the traffic first, start in monitor mode, phase by site or by function, keep a documented rollback, and communicate before each phase. The best answers know that the risk is the undocumented dependency, not the VLAN design.
And then they askHow do you find the dependency nobody documented?
What is the state of identity where you work, and what would you fix first?
Scored against: Server, virtualisation & identity administrationA strong answer contains: Concrete: stale accounts, admin account sprawl, whether privileged access is separated, MFA coverage, service accounts with permanent passwords. Plus a first move that is achievable rather than a rebuild.
And then they askHow many domain admins are there, and how many should there be?
What would someone find in your documentation if you were hit by a bus tomorrow?
Scored against: Monitoring, documentation & handoverA strong answer contains: Honest, specific and slightly uncomfortable: what is documented well, what only lives in their head, and what they are doing about it. Runbooks, network diagrams, credentials in a vault rather than a spreadsheet.
And then they askWhat is the one thing only you know how to do?
How do you decide between the urgent user request and the important infrastructure work?
Scored against: Service mindset & ownershipA strong answer contains: A defensible split, protected time for the important work, and evidence they have actually held the line, plus how they communicate to users so the wait feels managed rather than ignored.
And then they askWhat infrastructure work has been on your list longest, and why?
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level 3rd Line Support Engineer and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns a set of systems or the network for a site: builds, changes, patching, monitoring and incident resolution.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: diagnosing an intermittent network problem with packet captures and logs, active Directory design: OUs, group policy, replication and trust issues and dNS and DHCP design and troubleshooting, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns routine administration tasks and first-response to alerts with review; participates in change and patching. | Owns a set of systems or the network for a site: builds, changes, patching, monitoring and incident resolution. | Owns infrastructure architecture and standards for the organisation or a large environment; accountable for availability, security and capacity. |
| Tolerance for ambiguity | Handles defined tasks and escalates unusual or risky situations. | Diagnoses unfamiliar problems independently and plans changes with risk assessment. | Designs solutions from business needs; makes technology and vendor decisions with incomplete information. |
| People leadership | No formal leadership. | Mentors juniors and service desk staff. | Technical lead for administrators, runs on-call, mentors, reviews designs. |
| Who they deal with | Own team, service desk, users. | Business users, application owners, security, vendors. | IT management, security, application teams, vendors, auditors. |
Where candidates lose this interview
Backups that have never been restored
Every candidate says backups run. The question that separates them is when you last restored something and how long it took. If nobody has tested a restore, you do not have backups, you have hope, and saying so honestly scores better than pretending otherwise.
Guessing before scoping
"I'd restart the service" on a vague slowness complaint tells an infrastructure manager how your outages will go. Establish who, where, since when and what changed before you touch anything, and say so out loud.
No change you have ever broken
Everyone who has run production has broken it. A candidate with no example either has not done the work or does not admit to it, and neither is what you want on a change advisory board.
Security described as a project rather than a habit
Patch compliance percentages, admin account counts, MFA coverage and exception registers are the language of someone who actually runs it. "We take security very seriously" with no number attached is the language of someone who does not.
Being the single point of failure and being proud of it
Candidates sometimes present indispensability as a strength. It reads as poor documentation and a risk to the business. The strong answer names what only they know and what they are doing to change that.
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong 3rd Line Support Engineer would have said them.
Users say the application is slow. Everything is green on the dashboard. Where do you start?
- Establish scope and a timeline first (who, where, since when, what changed), then work the path end to end: client, network, name resolution, load balancer, application, database, storage. Naming what they would rule out cheaply and first is what separates strong from adequate
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report