Mission

Le logiciel Goodwill est appuyé sur un datalake alimenté quotidiennement de 50 000 documents textuels qui sont traités dans un pipeline constitué de plusieurs dizaines de micro-services AWS : scraping et collecte, OCRisation, normalisation, tâches de NLP (classification, NER, layout, etc.). Etant donné la croissance du produit, ce pipeline va être de plus en plus complexe : hausse du volume, nouveaux types de données, traitements NLP plus avancés et plus lourds, internationalisation.

Au sein d’une squad polyvalente de 5-6 personnes comprenant datascientist, dev front et dev back, le dataengineer est responsable des étapes de collecte et de normalisation des documents, ainsi que de la scalabilité et des performances du pipeline global. Grâce à son expertise, le dataengineer est capable d’identifier les architectures et les outils permettant de mettre en production des traitements avancés, opérant sur des gros volumes avec de bonnes performances.

Des exemples de sujets:

• paralléliser un algorithme de classification des documents administratifs,
• collecter en continu les documents sur les sites des administrations américaines,
• mettre en place une architecture de tracking de l’activité utilisateur

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, Hugging Face, pour le machine learning

• 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 : ingénieur ou master informatique
• Entre 2 et 5 ans d’expérience professionnelle (hors stage/alternance/freelance),
• Maîtrise avancée d’un langage back orienté objet (Python idéalement, sinon Java ou Ruby)
• Maîtrise en base de données relationnelle (par exemple postgresql)
• A travaillé dans un contexte de production sur un pipeline de traitement de données ou d’ETL
• Expérience en modélisation de données
• État d’esprit ingénieur : optimisation des performances, architecture

Apprécié

• Experience avec ElasticSearch/OpenSearch
• Expérience avec les outils et l’environnement AWS (s3, Athena, Glacier),
• Appétence pour le NLP, et idéalement première expérience sur des pipeline de traitement de données textuelles,
• Appétence pour les sujets de société.

• 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.