Most job interview prep guides treat the process like a clean, linear function: you answer their questions, they like you, and you get the offer. But after twenty years of maintaining legacy payment systems, I know that the “happy path” is a lie. When you’re actually sitting in that chair, the real danger isn’t failing a technical test; it’s realizing three months into the job that you’ve inherited a distributed nightmare you weren’t prepared for. If you don’t use your turn to ask the right questions to ask your interviewer, you aren’t just looking for a job—you’re signing a contract to fix someone else’s unmitigated disasters.
I’m not interested in helping you sound “passionate” or “driven.” I want to help you perform a stress test on the company before they hire you. In the following five points, I’m going to show you how to dig beneath the polished surface of the recruitment process to find the architectural and cultural debt hiding in plain sight. We are going to look for the cracks in the foundation so you don’t end up being the one left alone to patch them when everything inevitably breaks.
Table of Contents
The On-Call Reality Check
Most interviewers will tell you they have a “balanced work-life culture,” but that’s a hollow phrase until you ask about the on-call rotation. I want to know exactly how many times a developer is woken up at 3:00 AM by a P1 incident, and more importantly, what the expectation is for the following morning. If the answer is vague, it usually means the system is fragile and they haven’t figured out how to stop the bleeding yet.
The Legacy Code Tax
Every company has technical debt, but there is a massive difference between “we are migrating to microservices” and “we are terrified to touch the monolith.” Ask them what the ratio of new features to maintenance looks like in a typical sprint. If they can’t give you a straight answer, you are likely walking into a role where you will spend 80% of your time deciphering spaghetti code written by someone who left the company five years ago.
The Definition of "Done"
In a tutorial, “done” means the code passes the tests and is merged. In a real production environment, “done” is much more complicated. I ask candidates to clarify their deployment pipeline and what the testing requirements are before a PR is even considered. If their definition of done doesn’t include automated integration tests or a clear staging process, you are going to be the one cleaning up the mess in production.
The Incident Response Autopsy
I like to ask about the last time a major system outage occurred. I don’t care about the technical details as much as I care about the human response. Did the team scramble to find someone to blame, or did they focus on the telemetry and the logs? How they handle failure tells you everything you need to know about the psychological safety of the engineering department.
The Tooling and Ownership Gap
It is easy to talk about a modern tech stack, but I want to know who actually owns the infrastructure. Ask if the backend developers are responsible for their own CI/CD pipelines and deployment scripts, or if there is a separate DevOps team that acts as a gatekeeper. Being stuck in a cycle of waiting for “the infrastructure people” to provision a resource is one of the fastest ways to lose your productivity and motivation.
The Bottom Line
Stop looking for reasons to say yes and start looking for the technical debt that will keep you up at 3:00 AM.
A “we’ll see” regarding documentation or testing processes is a definitive “no”—it means they’ve already accepted the chaos.
The most important thing you’ll learn isn’t about the tech stack; it’s about whether the team has a plan for when the system inevitably fails.
The real interview starts when they stop talking
Don’t waste your time asking about their “tech stack” or their “values”—those are just marketing brochures. Ask them what the most expensive mistake a developer made last month was, and how the team actually handled it. If they can’t give you a straight answer, they aren’t looking for a colleague; they’re looking for someone to absorb the fallout.
Pernille Askeland
The Final Commit
At the end of the day, these questions aren’t about performing for the hiring manager; they are about performing a sanity check on the environment you are about to enter. You’ve moved past the surface-level queries about benefits and office snacks to probe the actual architecture of the team. By asking about technical debt, incident response, and how they handle the inevitable fallout of a failed deployment, you are looking for the cracks in the foundation. If they stumble or give you a rehearsed, polished answer that avoids the reality of their legacy codebases, you have your answer. You aren’t just looking for a job; you are looking for a system that won’t collapse under its own weight the moment things go wrong.
Remember that an interview is a two-way synchronization, not a one-sided deployment. You are bringing twenty years of logic and experience to the table, and you deserve a role that respects the complexity of the work. Don’t be afraid to dig into the messy parts of their stack. The most stable careers aren’t built on the “happy path” described in job descriptions, but on the ability to navigate the unforeseen errors that occur in production. Go into your next interview with the intent to find the truth, even if that truth is a little bit broken.
Frequently Asked Questions
What if the interviewer gives me a vague, "happy path" answer that feels like corporate fluff?
When they give you the “everything is great here” speech, they’re giving you the happy path. It’s useless. You need to force them into the edge cases. If they say, “We have a great work-life balance,” push back. Ask, “When was the last time a production outage forced the team to work through a weekend, and how was that handled?” If they can’t give you a specific, messy example, they aren’t being honest.
Is it actually risky to ask about technical debt or legacy code during the first round?
It’s only risky if you frame it like a complaint. If you ask, “Is the codebase a mess?” you sound like a liability. But if you ask, “How do you balance feature velocity with managing technical debt?” you sound like a professional. I’ve spent two decades untangling spaghetti code in payment systems; I know the difference between a system that’s growing pains and one that’s terminal. Asking shows you actually care about the long-term stability of what you build.
How do I pivot the conversation if I realize halfway through the interview that the role is just glorified maintenance?
Don’t panic and don’t pretend you haven’t noticed. If you realize you’re being recruited to be a glorified janitor for a legacy monolith, pivot by asking about the roadmap. Ask, “What is the balance between sustaining the current architecture and migrating toward the new stack?” Their answer tells you everything. If they dodge the question or focus solely on stability, you aren’t being hired to build; you’re being hired to keep the lights from flickering.
