From translator to frontend engineer: how I actually switched careers in Japan

I never sat down and decided to become an engineer. I got a translation degree, took a customer support job in Osaka, moved into marketing, started writing code at work because my team needed tools, and kept going until writing code was the job.

That’s less exciting than a bootcamp story. It’s also the more common route, and the more repeatable one.

The path, in order

I studied literary and specialized translation in Buenos Aires from 2012 to 2015, then taught Japanese at the University of Buenos Aires language center for a year. I also translated mahjong guides and worked on the English version of Tenhou, the online mahjong site. None of that was a coding job (the closest I got was a small Python script to analyze my own mahjong results).

In 2016 I moved to Osaka. In 2017 I joined ZenMarket, a cross-border e-commerce service that ships Japanese products abroad, as a customer service support manager. Support is a good school for an engineer, even if nobody calls it that. You spend the day watching real people fail to do something in a product, and you learn to describe exactly what went wrong and when.

In 2018 I moved to marketing, and from 2019 I was directing it: multilingual marketing across 12 markets with a multicultural team, paid ads included. That’s where code became part of the job. The team needed tools, so I built internal marketing tools in JavaScript, Node.js and Google Apps Script, and automated the rest with Zapier.

Then I learned React and TypeScript, which is a different skill from writing scripts. A script only has to work; a component has to make sense to the next person who opens it. In May 2021 I joined Synergy Marketing as a frontend engineer, building production interfaces for enterprise CRM and marketing SaaS in React (Next.js), TypeScript and Angular, shipped through GitLab CI/CD. Later that year I moved to Vercel, where I’ve worked in customer success ever since. I still write code, and that’s a separate article.

Start with tools for your own team

Internal tools are the best practice project I know of, for a boring reason: they have users. A tutorial app has nobody who complains when it breaks. A script that builds the weekly report does, and they complain the same morning. You learn error handling, odd input and documentation (or at least a comment saying which button to press) because someone needs you to. Ask your team what they still do by hand every week, pick the most boring answer and build that.

If your team runs on Google Sheets, a first tool can be this small. It reads a sheet of copy with one column per language and writes down which translations are still missing:

// Google Apps Script. Sheet "Copy" has the columns: key, en, ja, es, missing
const LANGS = ["en", "ja", "es"]

function flagMissingTranslations() {
  const sheet = SpreadsheetApp.getActive().getSheetByName("Copy")
  const [header, ...rows] = sheet.getDataRange().getValues()
  if (rows.length === 0) return

  const cols = LANGS.map((lang) => header.indexOf(lang))
  const out = header.indexOf("missing") + 1 // getRange is 1-based

  const result = rows.map((row) => [
    LANGS.filter((_, i) => String(row[cols[i]]).trim() === "").join(", "),
  ])

  // One write for the whole column, not one per cell
  sheet.getRange(2, out, result.length, 1).setValues(result)
}

It covers reading data, looping, and writing back in a single batch instead of cell by cell, which is the first performance lesson everyone learns in Apps Script. And somebody on your team can use it next Monday.

What translation training gives an engineer

A translation degree looks like the part of an engineer’s CV that needs explaining. I’d argue it’s closer to the opposite.

Precision

In a contract, “shall” and “may” are different obligations, and a translation that blurs them is wrong even if it reads well. Translators keep glossaries so one term is always rendered the same way. That’s naming in code. If the design says “member”, the API says customer and the UI says “user”, somebody will eventually write a bug that comes from treating them as three different things, or as the same thing when they aren’t.

Context

The first thing you learn in translation is that a sentence without context can’t be translated. 「よろしくお願いします」 has no single English equivalent; it depends on who says it to whom, and when. Frontend work has the same problem. Put the string “Open” in a translation file with no note, and the translator has to guess whether it’s a button (開く) or a shop’s status (営業中). Engineers who have translated write the note. I wrote more about this in an article on localization.

Ambiguity

When a source sentence can mean two things, a translator has a few options: pick one and flag it, ask the client, or find a wording that keeps both readings (rarely possible). What you don’t do is pick one silently. A ticket that says “show the date the order was placed” is the same problem: in whose time zone? Write down both readings and ask before you build. It’s a cheap habit and it saves days of rework.

Reading specs

Specialized translation means contracts, manuals and technical documents, where a definition in section one decides what section twelve means. You learn to read the whole document before you translate the first line. That’s exactly how to read an API reference, an RFC or a shiyōsho (仕様書, the specification document most Japanese projects are built from): all of it, once, before you start, with a list of questions.

Advice for career switchers in Japan

Show it

A portfolio of tutorial clones tells a hiring manager you can follow instructions. One tool that five colleagues use every day tells them you can find a problem, ship something and keep it running after it breaks. The trouble is that nobody outside the company can see an internal tool. Rebuild a clean version with fake data, put it on GitHub with a README that says what problem it solved and who used it, and deploy it somewhere a hiring manager can click. Screenshots and a two-minute screen recording do more than a paragraph of description. Never publish your employer’s real data.

Rirekisho and shokumu keirekisho

Japanese companies ask for two documents: the rirekisho (履歴書), a standardized form with little room to make a case, and the shokumu keirekisho (職務経歴書, a free-form record of what you did in each job). The second is where a career switcher wins or loses. I cover both, with a skeleton you can copy, in the article on working in Japan. What changes for a switcher:

Put the technical work first. Under each non-engineering job, list the tools you built as projects: the problem, the stack, who used them. Add a skills section with languages, frameworks and tools, honest about your level in each, and link the GitHub repository, the deployed demo and your own site.

Don’t hide the previous career. Support, marketing or translation is domain knowledge a candidate who only ever wrote code doesn’t have, so say what it lets you do.

And don’t give up at “jitsumu keiken” (実務経験, professional hands-on experience) in the job listing. A tool your colleagues relied on at work is professional experience with code, even if your title wasn’t engineer. Describe it concretely and let the reader decide.