Mission

Au sein d’une squad polyvalente de 5-6 personnes comprenant data engineer, datascientist et dev, il est le développeur principal sur le back et à ce titre est en lead sur le versant back des features majeures, de la conception technique jusqu’à la réalisation.

Par ailleurs, au sein de sa squad et de manière transverse, il a pour objectif de faire progresser l’équipe grâce à son expérience et ses connaissances des bonnes pratiques de software engineering sur les dimensions de:

• choix d’architecture et de technologie
• qualité du code, bonne pratiques d’implémentation
• tests et CI/CD

Naturellement bon communicant, appréciant faire progresser les autres, il joue un rôle de coach et de référent pour les membres plus juniors de l’équipe (qualité de ses reviews, documentation des bonnes pratiques, coaching au quotidien…)

Résultats attendus

Après 2 mois

• Maîtrise la base de code et les différents composants de Goodwill,
• Contribue en tant qu’expert sur les conceptions techniques back de sa squad,

Après 4 mois

• Prend en propre un sujet back majeur d’ampleur depuis la conception jusqu’à la réalisation et la coordination des différents contributeurs,
• Est reconnu comme un bon coach / mentor par les autres membres de la squad et par son PM: donne de bons retours dans les pull request, est force de proposition pour l’amélioration de l’équipe pendant les rétros,

Après 6 mois

• A contribué à significativement faire progresser les membres de l’équipe, par son coaching individuel (pull request) et la mise en place de nouveaux standards,
• Est un contributeur important à la roadmap: il est capable d’évaluer la faisabilité et de challenger les propositions de l’équipe produit et est force de proposition (exploration d’une nouvelle technologie, refactoring d’un composant…)

Principaux enjeux techniques

Le produit Goodwill est structuré autour d’un actif de données textuelles, qui sont collectées et traitées quotidiennement, via des providers de données ou du web scraping. Nos principaux enjeux techniques sont:

• Assurer une collecte robuste et rapide de données non structurées et hétérogènes (web scraping).
• Apporter de la valeur ajoutée à la données et la structurer via des traitements de NLP (OCR, Reconnaissance d’entité, architecture serverless, architecture de datalake).
• Rendre accessible aux utilisateurs la donnée dans un front intuitif (UX/UI, Moteur de recherche, Backend).

Stack

• Côté FRONT

  • Angular 8

• Côté BACK / DATA

  • Python (SQL Alchemy, Alembic, Flask, Sklearn, Spacy, Scrapy)
  • ElasticSearch
  • PostgreSQL

• Côté INFRA

  • AWS
  • Elasticbeanstalk pour nos microservices
  • Lambda / SQS pour nos scripts serverless
  • S3
  • Cloudfront
• Côté qualité : Rollbar, Sonarcloud, Swagger, Openapi, Bitbucket
• Outillage divers : Jira, Prodigy, Mixpanel, Segment, Confluence, Draw.io …

Méthode de travail

Politique de remote

Remote possible jusqu’à 2 ou 3 jours par semaine après la phase d’onboarding.

Comment l’équipe produit / tech travaille chez eXplain ?

• Idéation - L’équipe produit construit la roadmap en impliquant fortement l’équipe tech dans l’idéation, l’évaluation de la faisabilité, le découpage des sujets.
• Spécifications fonctionnelles - Des spécifications fonctionnelles sont rédigées, précisant les fonctionnalités et le comportement attendu.
• Conception technique - Un tech est responsable du sujet, et doit mettre sur papier la manière dont il va être réalisée techniquement. A ce stade, pas de code ! Il s’agit d’identifier a priori la bonne architecture, les points difficiles, les interactions avec les autres sujets (cf. https://medium.com/qonto-way/reintroducing-engineering-thinking-in-the-development-world-1541f7cbf1d1).
• Réalisation - Une fois la conception technique validée (via une pull request), les tickets sont écrits et le sujet entre dans le backlog. On gère le backlog en Kanban, en réévaluant régulièrement la priorité des sujets. Les tickets sont rassemblés au sein d’une release cohérente qui a lieu toutes les 6 semaines environ.

Implémentation et qualité

• Pull request - Elles sont systématiques avec en règle général deux reviewers. Elles sont un moyen pour nous de faciliter la montée en compétence et d’assurer la cohérence de notre base de code.
• Code coverage - Sur tous les projets back, une pull request ne peut être fusionnée qu’avec 80% de coverage ou plus.

Pré-requis

• Bac+5 : école d’ingénieur ou master informatique.
• entre 5 et 8 ans d’expérience professionnelle (hors stage/alternance/freelance).
• Au moins 2 expériences différentes en tant que développeur back sur des logiciels SAAS.
• Maîtrise avancée d’un langage back orienté objet (Python idéalement, sinon Java ou Ruby)
• Appétence pour le mentoring et le coaching, goût pour la communication et la vulgarisation de sujets techniques.
• Bonne connaissance en architecture logicielle,
• Expérience et aisance dans les phases de conception technique et leur documentation (motivation des choix, diagramme d’architecture…)
• Appétence pour la qualité logicielle et les bonnes pratiques de software engineering,

Apprécié

• Expérience des architectures micro-service,
• Expérience en développement Python (natif + flask),
• Appétence pour le devOps,
• Appétence pour la data-science et le NLP

• Entretien filtre avec le CTO (30min): validation du fit et de l’adéquation du profil au poste
• Test technique à regarder chez soi. Les points évalués: conception et modélisation du problème, qualité de l’implémentation
• Entretien avec CTO et Lead architect (1h30min): debriefing du test technique, passage en revue détaillé des expériences passées.
• Entretien avec un fondateur (30min): validation du fit et de la motivation.