Senior Backend Engineer — Tokyo

Tokyo a un problème de backend engineers seniors. Pas un problème de talents — la scène tech japonaise en regorge — mais un problème d'alignement. D'un côté, des entreprises FinTech en croissance rapide qui ont besoin de systèmes robustes, scalables, construits avec des stacks modernes. De l'autre, des ingénieurs expérimentés souvent coincés dans des organisations legacy où Go et Kubernetes sont encore des buzzwords, pas des outils quotidiens.

Chez Abbeal Tokyo, on construit des plateformes backend critiques pour des clients FinTech japonais. Pas du conseil PowerPoint. Du code en production qui traite des transactions réelles, avec des SLAs qui ne pardonnent pas. On cherche un Senior Backend Engineer capable de rejoindre une équipe bilingue (JLPT N2 minimum) et de prendre ownership sur des systèmes qui comptent.

Cet article détaille ce qu'on attend concrètement, pourquoi cette position existe, et ce que ça implique vraiment de bosser dans une ESN senior en 2025 à Tokyo — sans le bullshit habituel des job descriptions.

Pourquoi cette position existe

Nos clients FinTech japonais ont des besoins spécifiques qui ne se résolvent pas avec des solutions off-the-shelf. Ils migrent des systèmes monolithiques Java vieux de 10 ans vers des architectures microservices modernes. Ils lancent de nouveaux produits financiers qui nécessitent des APIs temps réel avec des garanties de cohérence transactionnelle. Ils scale de 100k à 10M d'utilisateurs et découvrent que leur infra ne suit pas.

Le contexte japonais ajoute des contraintes : réglementations financières strictes (FSA), exigences de souveraineté des données, interfaces avec des systèmes bancaires legacy qui communiquent encore en JIS X 0208. On ne peut pas copier-coller une architecture AWS standard et appeler ça du jour.

On cherche quelqu'un qui peut naviguer cette complexité technique ET culturelle. Qui comprend pourquoi un système de paiement doit gérer les idempotency keys différemment selon qu'on traite avec Zengin ou les cartes internationales. Qui sait qu'une migration database sur un service critique ne se fait pas un mardi après-midi sans coordination avec 4 départements différents.

Stack technique : ce qu'on utilise et pourquoi

Go comme langage principal

On a standardisé sur Go pour le backend. Pas par dogme, mais parce qu'après 3 ans de projets FinTech, c'est ce qui marche le mieux pour nos cas d'usage : performance prévisible, déploiement simple (un binaire statique), concurrency model qui gère bien les I/O-bound workloads typiques des APIs financières, tooling mature pour les services distribués.

On attend que vous soyez à l'aise en Go idiomatique, pas juste capable de traduire du Java. Ça veut dire : comprendre les trade-offs entre channels et mutexes, savoir quand utiliser context.Context pour la cancellation, écrire des tests de table-driven qui ne sont pas une souffrance à maintenir.

Kubernetes en production

Tous nos déploiements passent par Kubernetes. On utilise GKE pour la plupart des clients, parfois EKS quand il y a des contraintes AWS existantes. On attend que vous compreniez non seulement comment déployer un pod, mais comment debugger une fuite mémoire dans un container, configurer des resource limits qui ne tuent pas les perfs, mettre en place des health checks qui détectent vraiment les problèmes.

La réalité : Kubernetes en prod FinTech, c'est 20% de config YAML et 80% de troubleshooting. Comprendre pourquoi un service met 30 secondes à répondre après un rolling update. Investiguer des timeouts intermittents qui apparaissent seulement sous charge. Optimiser des startup times parce qu'un cold start de 2 minutes n'est pas acceptable quand on scale horizontalement.

PostgreSQL et data consistency

PostgreSQL reste notre database relationnelle de référence. On travaille avec des transaction logs qui doivent être ACID-compliant, des schémas qui évoluent sans downtime, des query plans qu'il faut optimiser parce qu'un full table scan sur 50M de lignes casse le SLA.

On attend une vraie compréhension des databases, pas juste savoir écrire du SQL basique. Isolation levels et leurs implications. Index strategies (B-tree vs GIN vs BRIN selon les cas). Partitioning pour gérer la croissance. Replication lag et comment ça impacte l'architecture applicative.

Infrastructure as Code avec Pulumi

On utilise Pulumi (TypeScript principalement) pour gérer l'infrastructure. Choix délibéré vs Terraform : on préfère du vrai code avec type checking et tests unitaires plutôt que du HCL. Ça permet de construire des abstractions réutilisables entre projets clients.

Vous n'avez pas besoin d'être expert Pulumi — on a des templates et des patterns établis. Mais il faut être à l'aise avec l'approche IaC en général : tout versionné, tout reviewable, tout reproductible.

Le profil qu'on cherche

Senior chez nous, ça ne veut pas dire "X années d'expérience". Ça veut dire capacité à prendre ownership sur un système complet, de l'architecture aux détails d'implémentation. Capacité à débloquer une équipe quand elle est coincée. Capacité à dire non à un choix technique foireux même quand ça vient d'un client.

• Expérience backend substantielle : 5+ ans à construire et maintenir des systèmes en production, idéalement dans des domaines où la fiabilité compte (FinTech, healthtech, e-commerce haute volumétrie)
• Mindset ownership : vous ne livrez pas du code et passez à autre chose. Vous suivez en production, vous vous réveillez la nuit si ça casse, vous améliorez progressivement
• Communication technique claire : capable d'expliquer des trade-offs complexes à des stakeholders non-techniques, en japonais ET en anglais
• Pragmatisme : vous savez quand optimiser et quand shipper du code "assez bon". Vous comprenez le business context de vos décisions techniques
• Curiosité technique : vous lisez des postmortems pour le plaisir, vous testez des nouvelles approches dans des side projects, vous avez des opinions argumentées sur les outils

La contrainte langue : pourquoi JLPT N2+

On demande JLPT N2 minimum (ou équivalent démontrable). C'est non négociable. Pourquoi ? Parce que nos clients sont des entreprises japonaises où les décisions se prennent en japonais, où les specs sont écrites en japonais, où les incidents sont reportés en japonais par des équipes locales.

En interne chez Abbeal, on fonctionne en bilingue — Slack mix anglais/japonais selon les threads, meetings en japonais pour les clients, en anglais pour les discussions techniques pures. Mais vous ne pouvez pas être efficace si vous dépendez d'un traducteur pour comprendre les requirements ou participer aux retrospectives avec le client.

N2 suffit. On ne demande pas une maîtrise native. Mais il faut être capable de suivre une réunion technique de 60 minutes en japonais, de lire une spec sans Google Translate toutes les 3 lignes, d'écrire un rapport d'incident compréhensible.

Ce que vous ferez concrètement

Les premiers 3 mois, vous serez en ramp-up sur un projet client existant. Ça ressemble à :

1. Semaine 1-2 : Setup environnement, code review du codebase existant, pair programming avec les autres seniors pour comprendre l'architecture et les gotchas
2. Semaine 3-6 : Ownership sur des features de complexité moyenne, participation aux on-call rotations (avec backup), premiers meetings clients en observation
3. Semaine 7-12 : Design et implémentation de features complètes, lead technique sur un microservice, participation active aux décisions d'architecture

Après le ramp-up, le quotidien ressemble à ça :

• 40% développement : vous codez encore, régulièrement. On n'est pas une boîte où les seniors ne font que des slides.
• 30% design et architecture : vous menez les discussions techniques sur les nouvelles features, vous rédigez des RFCs, vous challengez les approches proposées
• 20% client interaction : meetings de spec, démos, discussions de trade-offs, parfois du troubleshooting en temps réel pendant un incident
• 10% ops et amélioration continue : on-call rotation (1 semaine toutes les 4-5 semaines), optimisations de perfs, refactoring de dette technique, amélioration du CI/CD

L'environnement de travail

Remote flexible, présence client occasionnelle

On fonctionne en remote-first à Tokyo. Vous pouvez bosser de chez vous la majorité du temps. On a un bureau à Shibuya pour les meetings en présentiel quand nécessaire, mais ce n'est pas obligatoire 5j/7.

Par contre, attendez-vous à des déplacements occasionnels chez les clients — typiquement 1-2 fois par mois pour des workshops, des sessions de planning, ou des incidents critiques qui nécessitent d'être sur place. Les clients FinTech japonais apprécient la présence physique aux moments clés.

L'équipe

L'équipe Tokyo compte 12 personnes actuellement : 8 engineers (mix backend, DevOps, frontend), 2 product managers techniques, 2 roles business/client management. Tous bilingues japonais-anglais. Background mixte : japonais ayant bossé à l'étranger, étrangers installés au Japon depuis longtemps.

Culture d'équipe : pragmatique, direct, anti-process inutile. On fait des standups quand c'est utile, pas par rituel. On documente les décisions importantes, on ne perd pas 3 heures en réunion pour ce qui peut se résoudre en 20 minutes de pair programming. On challenge les idées, pas les personnes.

CDI ou freelance

On recrute en CDI (正社員) ou en freelance long-terme selon votre préférence. Le CDI offre la stabilité classique + avantages sociaux japonais. Le freelance offre plus de flexibilité et typiquement un rate journalier plus élevé, mais vous gérez votre propre structure.

Dans les deux cas, vous êtes basé à Tokyo avec visa de travail valide (on ne sponsorise pas de visas pour cette position — vous devez déjà avoir le droit de travailler au Japon).

Ce que ça implique de bosser en ESN senior

Abbeal n'est pas une ESN classique. On ne fait pas du body shopping. On ne vous envoie pas solo chez un client pour remplir un siège. On intervient en équipe sur des projets structurants, avec ownership de bout en bout.

Concrètement, ça veut dire :

• Vous travaillez avec d'autres engineers Abbeal, pas seul embedded dans une équipe client. On construit ensemble, on se supporte mutuellement.
• Vous avez un say sur les choix techniques. Le client définit les objectifs business, on définit comment les atteindre techniquement. Si un client veut une mauvaise architecture, on le challenge.
• Variété des projets : les missions durent typiquement 6-18 mois. Vous ne restez pas 5 ans sur le même legacy codebase. Vous voyez différents domaines FinTech, différentes échelles, différents challenges.
• Pas de bullshit commercial : on ne vous demande pas de faire semblant de facturer 10h quand vous en avez bossé 6. On ne gonfle pas artificiellement les estimations. Le client paie pour de la valeur, pas pour du temps.

Le trade-off : vous n'aurez pas l'equity d'une startup, ni le prestige de travailler pour une FAANG, ni le confort d'un produit interne que vous optimisez pendant des années. Mais vous aurez l'impact sans la politique, la variété sans l'instabilité, et le challenge technique sans la bureaucratie.

Comment postuler (et comment on évalue)

Pas de process à rallonge. On valorise votre temps autant que le nôtre.

1. Premier contact : envoyez CV + lien GitHub/GitLab (ou équivalent montrant du code que vous avez écrit). Un court paragraphe sur pourquoi cette position vous intéresse. Pas besoin de cover letter formelle de 2 pages.
2. Screening technique (60 min) : discussion sur votre expérience backend, cas concrets que vous avez résolus, deep dive sur un système que vous avez construit. On veut comprendre comment vous pensez, pas tester votre mémoire des algorithmes.
3. Exercice pratique (take-home ou pair programming) : design d'une API backend pour un cas d'usage FinTech simplifié. On regarde vos choix d'architecture, comment vous gérez les edge cases, comment vous testez. Pas de whiteboard coding bullshit.
4. Meeting final avec l'équipe : discussion plus informelle sur la culture, les attentes mutuelles, les questions logistiques. Si tout le monde est aligné, on fait une offre.

Timeline totale : 2-3 semaines de bout en bout, selon les agendas. On ne fait pas traîner les choses pendant 2 mois.

Conclusion : si ça vous parle

Cette position existe parce qu'on avons des projets concrets, des clients qui ont des vrais problèmes techniques à résoudre, et besoin de quelqu'un de solide pour les adresser. Pas de bullshit, pas de fausses promesses. Du backend engineering sérieux, dans un contexte FinTech exigeant, avec une équipe qui sait ce qu'elle fait.

Si vous êtes à Tokyo, que vous voulez construire des systèmes qui comptent sans les conneries corporate habituelles, et que le profil décrit correspond à votre expérience, on devrait discuter. Envoyez-nous votre profil via le site Abbeal, section Careers Tokyo, ou contactez directement l'équipe engineering si vous avez des questions techniques spécifiques avant de postuler.