Just finished the Mistral DE loop last month. Going to write this up while it's fresh because honestly the internet has almost nothing on their data engineering interview process.
For context: I have about 7 years in DE, mostly on event streaming infrastructure at mid-size tech companies. Applied for what they called a Data Infrastructure Engineer role.
Recruiter screen Short, 20 minutes. She confirmed I had hands-on pipeline experience (not just "I've heard of Spark") and asked if I was comfortable working in a hybrid Paris/remote setup. That came up a few times. Mistral is clearly building the team for time-zone overlap with France even if you're remote in the US.
Technical screen (1 hour) SQL first. The prompt was about model inference logs: given a table with columns for modelid, userid, requesttimestamp, inputtokens, outputtokens, and errorcode, write a query to find the p95 latency per model per hour over the last 7 days, excluding requests where error_code is not null. Then they asked how you'd optimize it if the table had 500M rows. Index strategies, partitioning, materialized views. Standard but you have to actually know it cold.
Then they switched to pipeline design. They gave me a scenario: you're ingesting model usage events from a Kafka topic at 50k events/second. Some events are late by up to 2 hours. Design a pipeline that computes per-user hourly usage totals with at-most-2-hour lag, handles late arrivals, and can be replayed from scratch if something goes wrong. The key things they were looking for: watermarks, windowing strategy (event time not processing time), idempotent writes, and how you'd handle schema evolution as the event format changes.
I talked through Flink but they were also fine with Spark Structured Streaming. The question is about the concepts, not the specific tool.
Onsite (5 sessions, all remote) System design, a pipeline debugging round, another SQL round (heavier on window functions), behavioral, and a "data modeling" round that was more like schema design for a multi-tenant usage tracking system.
The debugging round was interesting. They showed me a Spark job that was running fine but slowly (stage skew on a join). They wanted to see if I could read the Spark UI to identify the problem, which is a more practical skill than most interviews test.
Behavioral was pretty low-key. One thing they pressed on: tell me about a time a pipeline you owned caused a data quality issue downstream. They want to hear that you actually understand the downstream impact of your work, not just "I wrote a great pipeline."
Total loop: about 6 weeks. The pace was steady, not frantic. They seem deliberate.