19 Security Candidates, 2 Hires and the Language Question I Was Asking Backwards — 7 Steps for Tokyo

We ran a Tokyo security search that took eleven weeks and produced two good hires. Five of those weeks were avoidable, and they were lost to a single line that had been copied from a previous specification without anyone examining it: “business-level Japanese required”.

When we finally sat down with the hiring manager and listed what the role would actually do in its first six months — threat modelling for a new service, reviewing authentication code, tightening cloud permissions, setting up dependency scanning — we could not identify a single task that required Japanese. The tooling was in English. The codebase comments were in English. The one genuinely Japanese-language responsibility, an annual audit conversation, belonged to someone else entirely.

We removed the line. The qualified pool roughly tripled overnight, and both hires came from candidates who had been filtered out by it. Here is the process I run now.

Step 1 — Choose the security discipline first

“Security engineer” describes at least four jobs that share almost no day-to-day overlap. Deciding which one you are hiring for determines the pool, the interview and the language requirement.

A strong detection-and-response engineer will usually be a mediocre application security hire, and vice versa. If you cannot name which of these four you need, you are not ready to open the role — and you will interview candidates against a standard that shifts between conversations.

Step 2 — Map where Japanese is genuinely required

This is the step that cost us five weeks, so I now do it explicitly and in writing. Take the role, list its first-six-months responsibilities, and mark each one with the language it actually happens in.

The pattern that emerges is consistent across the companies we work with:

• Application security — overwhelmingly English. Code, tooling, standards and the security literature are all in English.
• Cloud and infrastructure security — overwhelmingly English, for the same reasons.
• Detection and response — mixed. Alert triage is English-heavy; communicating with business stakeholders during an incident frequently is not.
• Governance, risk and compliance — genuinely requires strong Japanese. Regulators, auditors and internal policy documents operate in Japanese, and pretending otherwise sets the hire up to fail.

Then write the honest version into the advert. Something like: “working language English; conversational Japanese helpful for incident communication but not required at hire”. Candidates trust a specific statement far more than a vague one, and specificity is what recovers the applications a blanket bar destroys.

Step 3 — Write a specification that filters

Most security adverts list certifications and frameworks. Those attract people who collect certifications. Describe your stack, your threat model and your on-call reality instead — the people who find that interesting are the people you want.

Being honest about on-call is particularly important. Candidates discover the truth in week two regardless, and a role misrepresented at advert stage produces an expensive early departure.

Step 4 — Screen for incident reasoning

Security knowledge is easy to check and easy to fake with recent reading. Reasoning under uncertainty is neither. Open with: “walk me through a security incident or finding you personally handled — what did you know at each point, and what did you decide?”

Listen for four things:

• Do they separate what they knew from what they assumed? The best security engineers are precise about this distinction, because acting on an assumption during an incident is how small problems become large ones.
• Did they consider blast radius before acting? Pulling a production service offline at 14:00 is sometimes right and sometimes catastrophic; the reasoning matters more than the choice.
• How did they communicate? Who they told, when, and in what terms. Security work is largely persuasion.
• What changed afterwards? A candidate who cannot describe a durable fix is describing firefighting, not engineering.

Candidates who have only done compliance work struggle visibly with this question, which is exactly the discrimination you want if you are hiring for engineering rather than governance.

Step 5 — Run a scenario exercise, not a trivia quiz

Give a realistic artefact and 45 minutes. Three that work well, matched to discipline:

1. Application security: a pull request adding an authentication endpoint, containing one subtle authorisation flaw and two cosmetic issues. Do they find the real one, and do they explain the impact in terms a product manager would accept?
2. Cloud security: an IAM policy document that is over-permissive in a non-obvious way. What do they notice, what do they check next, and how would they roll out a fix without breaking production?
3. Detection and response: three alerts from the same hour, one genuine and two noise. How do they prioritise, and what do they ask for first?

Score prioritisation and communication, not exhaustiveness. A candidate who finds the critical issue, explains why it matters and proposes a staged fix is far stronger than one who lists nine findings without ranking them — because ranking is the job.

Step 6 — Benchmark JPY bands against the discipline

That last row is the economic argument for step 2. Security depth combined with business-level Japanese is one of the scarcest and most expensive combinations in the Tokyo market. If the role does not require it, requiring it means paying a premium for a skill you will not use — on top of waiting far longer to fill the seat.

Step 7 — Close in two weeks, and plan the visa timeline honestly

Strong security engineers in Tokyo are overwhelmingly passive and, once they engage, typically in two or three processes at once. Run screen, scenario and final conversation inside two weeks, decide within three days, and issue the written offer within two more.

If the candidate is relocating, start the visa conversation at offer stage rather than after acceptance, and give a realistic start date. Three to five months from offer to first day is normal for a relocating hire. The failure mode is not the length of the timeline — candidates accept it — it is discovering the length after accepting an offer made vague on purpose.

A note on the regional pool

Tokyo has genuine depth in security engineering; the constraint for international employers has always been access rather than supply. Removing an unnecessary language bar is the cheapest way to widen access, and it costs nothing but an hour of honest analysis.

Relocation is also a live option at mid-level. Colleagues at HireDeveloper.sg report strong application-security supply in Singapore, where regulatory demand has built a deep pool, and the team at HireDeveloper.ae sees cloud-security engineers in Dubai open to Asia-Pacific moves. Both pools work in English by default, which is precisely the point.

If you are building a security function rather than filling one seat, our guide on how to build a security engineering team covers the sequencing and which discipline to hire first.

Frequently asked questions

The bottom line

Security hiring in Tokyo fails for two repeatable reasons. The first is treating “security engineer” as one role when it is four, which produces an interview loop that measures nothing consistently. The second is applying a blanket Japanese requirement that nobody has tested against the actual work — which, for application and cloud security roles, removes most of the qualified pool in exchange for a skill the job will not use.

Pick the discipline. Map the language need task by task and write the honest version into the advert. Screen for reasoning under uncertainty rather than for certifications. Then move fast, because the people you want are not waiting for you. Our second search took six weeks and both hires came from candidates the original specification had quietly excluded.