In 2024, landing a face-to-face interview is harder than ever, so it’s frustrating when you realise you’ve sabotaged a great opportunity with a weak answer. This series is dedicated to the times I bombed—hard—during technical interviews, with the goal of learning from those mistakes.
The first example took place when I was discussing a Next.js app I was currently working on. It was an open-ended, free-flowing conversation and it became clear early on that the interviewer and I were both very passionate about emerging tools and trends. The discussion turned to the app I was working on, and I casually mentioned that the app was experiencing slow load times, and I was working towards reducing latency. The interviewer then asked me a very reasonable question:
“What’s your usual approach to troubleshooting latency?”
And what did I say?
”I usually just jump into the inspector and check out what’s happening in the network tab.”
Cringe.
My answer gave little room for the interviewer to ask a follow-up question and led to an awkward silence. This answer closed the door to further discussion about my skills and how I approach problems. It made it seem like I was stuck at surface-level troubleshooting without demonstrating any depth in understanding or process. The inspector’s network tab is useful, sure, but it doesn’t show any deeper knowledge of web performance optimization.
Why This Was a Bad Answer
- It’s vague – “Checking the network tab” sounds like a reaction rather than a process. Sure, I don’t have the solution, but I could have at least mentioned what I’d tried.
- Missed opportunity – I could have discussed my knowledge of what causes latency and solutions to mitigate them.
- No problem-solving framework – The answer didn’t demonstrate a clear, structured approach to diagnosing and fixing issues. It would be weird if I jumped into a STAR response (Situation, Task, Action, Response - a popular framework to structure responses during behavioural interviews), but I could have at least demonstrated a process of elimination.
What a Good Answer Would Look Like
A better response would have shown that I understood the root causes of latency, common solutions, and the steps I typically take:
“Latency can be caused by several factors, such as large asset sizes, network bottlenecks, or unoptimized code. My usual approach starts with analyzing server response times and network requests to see if there are any obvious red flags like uncompressed images, long TTFB (Time to First Byte), or excessive JavaScript. I also use tools like Lighthouse to get a performance audit and identify areas for improvement. From there, I look into optimizing static assets, implementing caching strategies like using a CDN, or reviewing server-side rendering to ensure I’m not unnecessarily blocking resources. If needed, I dig into my Next.js config to see if any specific optimizations can be applied, like lazy loading or code-splitting.”
Boom - the interviewer now knows:
- I have a solid understanding of latency and what can cause poor latency
- I can tackle problems methodically
- I have a breadth of knowledge of tools and optimizations to mitigate latency
From here the interviewer has more options for follow-up questions and the conversation can flow in a number of directions (likely towards the areas I’ve just mentioned).
Better yet, they might even gift you the answer to your problem.
Lesson learned: don’t just mention what you do, explain how and why you do it.