CARMEN LÓPEZ Support Engineer

Interviewing for a support role

Support isn't a script—it's a decision-making discipline. These questions explore how to investigate unfamiliar issues, use evidence, and turn a resolution into reusable knowledge.


Each support interview question probes a different muscle: investigating without a map, diagnosing from evidence, exercising judgment under uncertainty, and making the next investigation easier. The examples below show how similar questions can look in a SaaS DevTools company and an e-commerce business.

1. Troubleshooting an undocumented, unique technical issue

What this tests: Systematic debugging, comfort with ambiguity, and whether you turn one-off firefighting into reusable knowledge. When no documentation exists, interviewers want to see how you build the map while walking the territory.

Sample questions

SaaS DevTools:

  • A customer's CI pipeline fails only on a specific runner image. There are no docs because the issue is a version-skew interaction between their SDK and a runtime. How would you investigate, what would you capture, and what would you leave behind for the next person?
  • A developer reports that your CLI tool silently exits with code 0 on one OS but fails on another. There's no known issue or runbook. How do you proceed?

E-commerce:

  • Checkout fails only for one payment method in one region during high traffic. There's no playbook. How do you reproduce, isolate, and document it?
  • A discount code applies correctly in the cart but disappears at payment for a subset of accounts. No documentation covers this. Walk us through your investigation.

A strong answer structure

  1. Reproduce: Establish a reliable reproduction, or explain clearly why you cannot yet.
  2. Isolate: Narrow the variables, such as environment, version, region, device, or account.
  3. Hypothesize: Name the most likely cause and the evidence that would confirm or disprove it.
  4. Instrument: Capture the exact error surface: logs, stack traces, requests and responses, or gateway telemetry.
  5. Confirm: Test the hypothesis with a controlled change.
  6. Document: Write an internal runbook and, where appropriate, a public troubleshooting page or decision tree.
  7. Reflect: Explain what you would do differently next time, such as capturing a reproducible artifact earlier.

Example answer: SaaS DevTools

“Last year a customer opened a ticket saying their CI pipeline failed, but only on one runner image. It worked on every other image, and there was nothing in our docs because it turned out to be a version-skew interaction between their SDK and a runtime.

I started by reproducing it. I pulled their pipeline config and spun up a sandbox with the same runner image, and I got the same failure—so at least it was real and not a one-off. Then I isolated variables: the same image with a different SDK version passed, so I bisected across SDK versions and found the break point. I captured the exact error surface—the stack trace and the runtime error—and read the source to understand what changed between those versions. My hypothesis was that the SDK was calling a runtime API that had shifted behavior, and I confirmed it by pinning the runtime version and watching the failure disappear.

The fix for the customer was a version pin plus an upgrade path. But the more important output was the documentation: I wrote an internal runbook with the exact version matrix and a public troubleshooting page so the next person doesn't start from zero. What I'd do differently is capture the reproduction artifact before I touched anything—I changed a couple of things early on that I had to unwind, and that cost me time.”

2. Using logs to solve the issue

What this tests: Whether you can turn raw telemetry into a causal story and actively look for evidence instead of stopping at the first plausible cause.

Sample questions

SaaS DevTools:

  • API calls intermittently return 401s. Logs suggest an auth token-refresh race. How would you correlate request IDs across the auth service and gateway, find the pattern, and confirm it?
  • A customer's webhook deliveries succeed in the dashboard, but their endpoint never receives them. What log evidence would you gather and how would you trace it?

E-commerce:

  • Orders are marked “paid” but never fulfilled. How would you trace order IDs across payment webhook logs and fulfillment queue logs to find the break?
  • A subset of customers report order confirmation emails arriving hours late. What log evidence would tell you where the delay enters the pipeline?

A strong answer structure

  1. Start from the symptom: State precisely what's broken and what “normal” looks like.
  2. Form a hypothesis: Name the most likely failure point.
  3. Look for disconfirming evidence: Don't only seek confirmation; test what could disprove your hypothesis.
  4. Correlate: Follow correlation IDs, request IDs, order IDs, and timelines across services.
  5. Name the tool: Mention the log aggregator, tracing, or dashboards, while keeping the focus on your reasoning.
  6. Resolve: Fix the root cause and add a safeguard, such as a retry, idempotency, or timing fix.
  7. State what you ruled out: The elimination process is part of the answer.

Example answer: E-commerce

“We had a spike where orders showed as ‘paid’ in the admin but were never fulfilled. The customer-facing symptom was silence—no shipping confirmation—so I started from the fulfillment queue and worked backward.

My first hypothesis was that the queue consumer was down, but the logs showed the consumer was healthy and idle. That was the disconfirming evidence I needed, so I shifted to the payment side. I traced a handful of affected order IDs across the payment webhook logs and the fulfillment queue logs, and the pattern was clear: the webhook fired, but the retry was dropped when the payment provider returned a transient error. The order was marked paid at the payment layer, but the fulfillment event never got replayed.

I confirmed it by replaying one of the affected events manually and watching the order flow through to fulfillment. The resolution was to replay the backlog and add an idempotency and retry safeguard so a dropped webhook doesn't orphan an order. What I'd emphasize is that the queue being healthy was the red herring—the evidence that mattered was the gap between the two logs, not either one alone.”