Technical Interviews
Live debugging interviews in Japan: show a method, not a lucky guess
Use a repeatable observation, hypothesis, test, and verification loop when debugging unfamiliar code in a Japanese or English technical interview.
Sources
What you can use right away
- Separate observed facts from explanations you have not tested.
- Change one thing at a time and predict what the test should show.
- Finish by proving the fix and naming the regression test you would keep.
What the interviewer can actually evaluate
A live debugging task usually gives you unfamiliar code, a failing behavior, and limited time. The useful signal is not whether you recognize the bug immediately. It is whether another engineer can follow your investigation, challenge an assumption, and trust the final fix.
Start by asking about the expected behavior, available tools, time limit, and whether you may run tests or inspect logs. In Japan, the round may be conducted in Japanese, English, or both. Confirm the working language and narrate in short sentences rather than trying to sound polished.
Try this checklist
- Ask what is known to be correct and what evidence defines the failure.
- Confirm whether documentation, search, tests, and a debugger are allowed.
- Restate the symptom before touching the code.
Use the OHTV loop
Work in four steps: Observe, Hypothesize, Test, Verify. Observation is a fact such as "the API returns 200 but the list is empty." A hypothesis is an explanation such as "the date filter uses the wrong time zone." A test must distinguish that hypothesis from another one. Verification proves both that the symptom is gone and that nearby behavior still works.
Keep a small log with four columns: fact, hypothesis, test, result. It stops you from repeating failed ideas and gives the interviewer a compact view of your reasoning.
Try this checklist
- Say "I observe..." before "I think...".
- Predict the result before running each test.
- Cross out a rejected hypothesis instead of quietly abandoning it.
Worked example: records disappear around midnight
Suppose a test says records created at 00:10 JST are missing from a daily report. First reproduce it with one record inside the boundary and one just outside it. Then trace where the date becomes a timestamp. If the query converts a local date to UTC twice, state that as a hypothesis and write the smallest test that exposes the boundary.
A useful think-aloud line is: "The failing case is tied to the date boundary. I will compare the timestamp before and after serialization. If both are correct, I will move to the database predicate." This is specific enough to evaluate and short enough to leave room for the work.
Recover cleanly when a hypothesis is wrong
A wrong hypothesis is normal. The weak move is to patch several lines until the test passes. The stronger move is to say what the result ruled out, update your model, and choose the next observation that carries the most information.
If you are stuck, narrow the system: input, transformation, storage, output. Find the last point where the value is correct. Ask for a hint only after summarizing what you tested; that lets the interviewer help without taking over.
A 45-minute practice drill
Use a small repository you did not write. Spend five minutes reading the failure and mapping the entry point, twenty minutes investigating, ten minutes fixing and testing, and five minutes explaining the cause. Save the final five minutes for a regression risk and a follow-up improvement.
Record the session once. Listen for silent jumps from fact to conclusion, repeated tests, and long monologues. Store the problem, hypothesis log, and final explanation in your interview notes so the next drill targets a real weakness.
Try this checklist
- Practice one data bug, one state bug, and one concurrency or timing bug.
- Repeat the same task in the language you expect to use in the interview.
- Afterward, write a three-sentence cause, fix, and prevention summary.
Common questions
Should you talk continuously? No. Announce the next test and its purpose, then allow quiet time while reading. Should you optimize after fixing the bug? Only if the prompt asks or you have verified the fix first. Should you use AI or web search? Follow the stated rules; technical access does not equal permission.
If the environment itself fails, show the exact command, error, and one controlled retry. Ask the interviewer whether to repair the environment or continue by reasoning from the code.