Code review interviews in Japan: find risk and write comments people can use

Code review interview formats vary. You may receive a diff, a repository, or a short function and add comments in a shared editor. Ask for the requirement, language version, production constraints, and expected review depth. Then summarize what the change is meant to do.

Read tests and public interfaces early. They often reveal the intended contract faster than scanning every implementation detail. If context is missing, state an assumption and turn uncertainty into a question.

Use this order: behavior and data integrity, security and privacy, failure and operability, tests, maintainability, then style. The order prevents a naming preference from consuming time while a deletion path can lose data.

For each concern, ask: which input triggers it, who is affected, how severe is the outcome, and what evidence would resolve it? A concrete failure mode is more useful than a label such as "not robust."

A strong comment has four parts: severity, observation, consequence, and request. Example: "Blocking: this update reads the balance before the transaction begins. Two concurrent requests can both pass the check and overspend the account. Could we move the read and write into one transaction and add a concurrency test?"

Comment on the code, not the author. "This branch can return stale data" is clearer and less personal than "you forgot the cache." If the issue is optional, label it as a suggestion or nit so the author knows it does not block approval.

Imagine a new endpoint deletes an interview record by ID. The handler returns 204 and has a happy-path test. Before discussing naming, check that the record belongs to the current user, dependent records have an intentional policy, repeated deletion has defined behavior, and the audit or application state remains consistent.

Close with a review summary: one blocker on ownership, one question about dependent data, and one suggestion for an idempotency test. A prioritized summary shows judgment better than a long list of equal-weight comments.

Take a public pull request or write a deliberately flawed 30-line change. Give yourself twenty minutes. Score the review on coverage, prioritization, specificity, tone, and whether each blocking comment has a reproducible consequence.

Do a second pass in Japanese or English as needed. You do not need elaborate keigo in a Japanese interview. Clear phrases such as "確認です", "この条件では", and "必須修正と考えます" are easier to trust than indirect wording that hides severity.

Do you need to find every bug? Usually no; demonstrate a repeatable review and catch the highest risks. Should you propose code? A small sketch can clarify a fix, but do not rewrite the whole change. What if you do not know the language? Review the contract, data flow, failure modes, and tests, and mark language-specific uncertainty honestly.

Before the interview ends, ask what the team treats as blocking, how it resolves disagreements, and which production signals reviewers own. Those answers also tell you how engineering work is done after hiring.