For an L1 or L2 engineer, roughly how much of a typical workday is spent testing, troubleshooting, performing root-cause analysis, and identifying and documenting issues? Do these engineers usually investigate software deeply when necessary, or do they generally remain focused on infrastructure?
I'm applying for L1 and L2 roles and freelance work, and I'm building case studies that demonstrate how I identify problems, determine root causes, and document findings involving WordPress servers, Nginx, Apache, and OpenLiteSpeed. Would this be a useful way to build my portfolio?
4 Answers
There isn’t a reliable percentage because it depends heavily on the company, support model, and current incidents. Some days may involve almost no troubleshooting, while an outage or difficult escalation can consume the entire day. Job titles also vary—some managers consider databases, application servers, and clustered systems part of “infrastructure,” so the boundaries can be very broad.
Modern logging and AI-assisted observability tools can speed up first-pass analysis by correlating logs, network events, application errors, and infrastructure metrics. They don’t replace fundamentals, though—you still need to verify the suggested cause, understand what the system is doing, and recognize when the tool is wrong. Learning both traditional troubleshooting and these newer tools would make your portfolio stronger.
Your case studies sound useful for a portfolio. Make each one show the symptoms, initial hypotheses, commands or tests used, evidence collected, root cause, fix, validation steps, and any preventive recommendations. Include sanitized logs or diagrams where possible. Showing a clear investigation process is more valuable than simply listing technologies such as Nginx or Apache.
Yes, L1 and L2 engineers often need to investigate software as well as infrastructure. The depth depends on the role, but troubleshooting might include reading logs, reproducing the issue, checking configuration and dependencies, reviewing code or scripts, and occasionally examining a proprietary application in detail. L3 work generally involves deeper engineering, but the levels can overlap.
A typical investigation starts by clarifying the impact and timeline, then checking monitoring data, logs, recent changes, configuration, dependencies, and resource usage. The engineer tries to reproduce the issue or narrow the scope, tests one hypothesis at a time, applies a fix or workaround, and confirms the result before documenting the root cause and follow-up actions.