Pleo's Intelligence function covers the full analytical picture - product behaviour, GTM performance, commercial data science, financial reporting, and operational intelligence. The Analytics Engineers who serve these teams own the data modelling layer that all of it runs on: dbt models, metric definitions, and semantic layer contributions that analysts, product teams, and AI tools depend on to get consistent, trustworthy answers.

You'll be embedded in the Product Intelligence team, building the tracking, experimentation, and data modelling foundations that make product data trustworthy and self-serve. You'll join a close-knit team actively migrating our analytics stack onto a new Analytics Warehouse and Omni, moving off legacy tools like Looker and Hippocampus. If you want to build the infrastructure that other people's product decisions run on rather than just report on what exists, this is the opportunity for you.

Who you'll work with and reporting to

You will report to an Analytics Manager leading Product Intelligence and Growth Intelligence. You'll partner closely with Product Managers, Product Analysts, and Engineering to get tracking, experimentation, and metric definitions right from the ground up. You'll also engage with the broader Analytics Engineering community across Pleo to drive shared standards, especially around the semantic layer that keeps metrics consistent across the organization.

What you'll be doing

• Build and maintain dbt models in our new Analytics Warehouse, using a clean, layered architecture and migrating logic off legacy tools as you go.
• Own tracking plan implementation and QA directly in Segment and Amplitude in close partnership with Product and Engineering.
• Support experimentation by modelling assignment and outcome data into structured formats that analysts and PMs can query directly.
• Define and document metrics in our semantic layer, ensuring a single authoritative definition so downstream BI tools and AI applications yield consistent answers.
• Apply AI-augmented data modelling practices as a standard part of how you write, review, and migrate code.
• Partner with Product Managers and Analysts to turn one-off questions into durable, reusable data models.
• Maintain data quality in your domain through dbt tests, freshness SLAs, and proactive monitoring.

What you bring

• Solid SQL and dbt experience, with a clear comfort owning models end to end.
• Working knowledge of event-based tracking tools like Segment or Amplitude.
• Experience with Git-based development workflows, including opening and reviewing pull requests.
• Clear communication skills to explain data definitions and structures to both technical and non-technical stakeholders.
• Genuine day-to-day use of AI tooling as part of your standard coding and workflow routine.
• Comfort navigating ambiguity and untangling legacy logic to build modern foundations.

This role is NOT a good fit if

• You only want to write dashboards without touching or owning the underlying data models.
• You require rigid processes and heavy upfront structure before taking initiative.
• You prefer to avoid data migration, cleanup work, and legacy system refactoring.

Your first 6 months

• Ramp up: Master our dbt project structure, tracking plans, and migration roadmap while shipping small, reviewed code changes early on.
• Take ownership: Own a dedicated slice of the migration, such as an event domain or our core experimentation data models.
• Drive consistency: Establish semantic layer definitions for your domain so analysts and PMs can self-serve accurate metrics without custom workarounds.

Our tech stack context

• Data warehouse: GCP / BigQuery (new Analytics Warehouse)
• Transformation: dbt
• Orchestration: Airflow
• Tracking and Oroduct Analytics: Segment, Amplitude
• BI and Analytics: Omni (migrating off legacy Looker and Hippocampus)
• Languages: SQL

Show me the benefits!

• Your own Pleo card (no more out-of-pocket spending!)
• Lunch is on us for your work days—enjoy catered meals or receive a lunch allowance based on your local office.
• Comprehensive private healthcare depending on your location (coverage options include Vitality, Alan, or Médis).
• 25 days of annual holiday plus public holidays, with the option to purchase 5 additional days through salary sacrifice.
• Flexible working options supporting both hybrid and fully remote setups.
• Free mental health and well-being support through MyndUp.
• Generous paid parental leave policies to support growing families.

The interview process

• Intro Call: 30 minutes with our Talent Partner
• SQL Test: Completed via CoderPad
• Hiring Manager Interview: 45 minutes with our Data & Analytics Manager
• Team Interview & Live Case: Data modelling case via CodeSignal
• Final Interview: 30 minutes with our VP of Data & AI

Transparency is important to us so we also wanted to share some insights about what we’re looking for in applications to ensure you can set yourself up for success!

Last time we hired an Analytics Engineer, we received a total of 173 applications but only 10 were selected for an intro call. Some of the key reasons why previous candidates didn’t make it past the application screening stage include:

• CV writing and content: it was very clear that many of the CVs we saw were very generic and AI generated. There is no issue with leveraging AI to help with CV writing, there was little indication of what real impact the candidates had in their previous experience. You might have heard of the “Achieved X, as measured by Y, by doing Z” formula (credit Laszlo Bock ~2014), this is a great way to give a clear picture of what you have actually worked on. Some link or quick description of the companies you’ve worked with is also a great help.
• Application care: every single application we receive is reviewed by a human (yes, hundreds of them) because we believe that candidates' efforts should be matched by an equal level of human care. This means that we expect a similar level of attention put into your application. Read and answer the application questions carefully, they make a huge difference in our decision-making process.
• Profile to role fit: there was misunderstanding about the type of experience we expect from an Analytics Engineer and we received many applications from candidates who had never been exposed to a product-led environment or had been exclusively focused on SQL/dbt work when we’re looking for both technical and stakeholders management and team collaboration experience. To be perfectly clear, this is NOT a Data Engineer role or a Data Analyst role! This is a heavily-driven dbt modelling role, experience in this area is critical. We’ve taken great care in writing this role description to reflect the reality of the job as best as possible, please ensure you read it carefully and highlight on your CV the experience relevant to what we are looking for.

About your application

• English first. Since it's our company language, please submit your application in English. You’ll be using it a lot if you join us.
• A fair look for everyone. Our talent team reads every single application to ensure the process is fair. To keep things running smoothly, we only accept applications through our system—our support team can’t pass on calls or emails.
• Diversity drives us. We can only reach our goals if our team reflects the world around us. That starts with you hitting apply, even if you don't tick every single box. We encourage people from all backgrounds and experiences to join us.
• Interview at your best. We want you to feel comfortable throughout the process. If you have any accessibility requirements or need a specific format, email . We’ll design a process that works for you.
• Applying for multiple roles? Nothing is stopping you, and we assess every role independently. However, we do look for alignment, so make sure you can explain why your interest and experience are right for each specific role.
• Reapplying. If you’re applying for the same role again, please wait six months from your last decision before hitting submit.