Debug the demo without losing the audience

A live debugging task can reveal whether an advocate understands the example or has memorized its successful path. Start by naming the observed symptom and the layer where it appears. A failure before a request is sent differs from an authentication rejection, a rate limit, or an incorrect transformation after a successful response.

Think aloud in a way that helps the audience follow the evidence. State a hypothesis, identify the next observation, and explain what each possible result would mean. Avoid narrating every keystroke. The audience needs to understand the decision, not the mechanics of opening a file.

Bound the time spent on uncertain infrastructure. A presentation can spend one minute checking the endpoint and response, then switch to a known local fixture if the external service remains unavailable. Label that switch. In an interview explicitly assessing debugging, continue the investigation according to the task rather than hiding behind a recording. The assessment context determines whether a fallback satisfies the brief.

Do not expose secrets while gathering evidence. Inspect token presence, scope, or expiry through safe metadata rather than displaying the token. Redact customer identifiers from shared logs. A developer advocate's technical credibility includes knowing which details are safe to place on a projected screen.

A fictional sample calls an endpoint and immediately parses JSON. The terminal shows a parsing error at the first character. The candidate inspects status and content type and finds 404 with an HTML page. The configured URL contains /event instead of the documented /events path. Correcting the path produces the expected JSON fixture.

The candidate explains that the parser was reporting a downstream symptom. The earlier assumption that every response matched the success schema was wrong. A stronger sample checks response status before parsing and includes a concise failure message with safe context. It does not log authorization headers.

The parsing error does not by itself identify the root cause. It says the received bytes did not match the parser's expectation. The next check should separate a wrong route, a non-JSON error response, and malformed JSON from an otherwise correct endpoint.

Do not choose a repair solely because it worked in the previous lesson. Changing /event to /events fits the supplied 404 case, but it is not a universal remedy for parsing errors. A 200 response with invalid JSON requires a different investigation.

1Observed: parser fails before expected object exists.2Check1: status404, content-type text/html.3Hypothesis: configured route does not match the API path.4Check2: local configuration has/event; reference says/events.5Change: correct that one path.6Verification: documented success status, JSON shape, expected fixture result.7Remaining limit: no claim about every endpoint or production availability.

This transcript teaches the audience why the candidate changed the path. It also leaves a useful handoff if time expires. Avoid narrating every editor action; explain the relationship between observation and next decision.

If the second check shows the path is already correct, update the hypothesis. A reverse proxy or base URL may route the request somewhere else. The failure to confirm a hypothesis is useful evidence. Do not keep changing the path until something appears to work without understanding where the response came from.

For a teaching presentation, one minute of diagnosis may be enough before a labelled local fallback. For a debugging interview, switching to a recording can avoid the task being assessed. Clarify the purpose and follow it. A good candidate can say which investigation would come next even when the allotted time is insufficient.

Use a stop rule such as one safe discriminating check, then summarize or switch modes if the presentation requires teaching to continue. The rule prevents the entire session from becoming an unbounded environment repair. It should not prevent an easy confirmed correction already within reach.

A fallback must preserve the distinction between expected and observed behavior. A saved response can show the parser's expected shape. It cannot prove the current live request succeeded, that the credential works, or that the service is available now. State the remaining unverified boundary explicitly.

Project only the evidence needed for the decision. A request ID, status, content type, and redacted path can be enough to diagnose the case. Do not reveal authorization headers, full environment files, or customer records to prove that a token exists. Use safe metadata and a synthetic fixture.

A command that dumps every environment variable is a poor default troubleshooting step on stage. It gathers far more than needed and can expose unrelated secrets. Prefer a specific presence check or a documented tool that shows permission metadata without token value. The principle is relevance: collect only what can distinguish the current hypotheses.

One misconception is that thinking aloud means constant narration. Useful explanation states hypothesis, evidence, and decision; excessive narration can obscure all three. Another is that admitting an unresolved boundary is failure. In a bounded interview, a precise next check can demonstrate more understanding than an unsupported success claim.

Exercise: status 200 and content type application/json arrive, but the body ends halfway through a quoted value. The URL matches reference. Write the next two steps. Preserve safe metadata and verify whether the body is truncated at the transport/intermediary/server boundary, then reproduce with a small known response or inspect the relevant request ID through an authorized path. Do not change field names or rotate credentials without evidence. Award one point for leaving the wrong-route hypothesis, one for preserving the parse failure, one for a bounded reproduction, and one for stating the current uncertainty.

The final answer should summarize what is known, what was changed, what verified the change, and what remains. That structure lets the audience learn from the debugging even if the network remains unavailable.

Now the endpoint returns 429 with documented retry guidance. Should the candidate apply the same path correction? No. The request reached a rate-limited endpoint. Respect the guidance, bound attempts, and use the local fixture if the presentation allows it. Award one point for changing the hypothesis, one for a bounded retry response, and one for an honest fallback. Reinstalling the runtime is unrelated to the observed response.

What if you cannot resolve the failure in the allotted time? A strong answer summarizes confirmed facts, rejected hypotheses, the next discriminating check, and the example's remaining unverified boundary. Follow up with how you would update the tutorial after discovering the defect. A weak answer either claims success or keeps changing unrelated settings. Good live debugging turns uncertainty into a clear next step that another engineer could continue.