Did the Tesla DS loop for a role on their Demand Forecasting team earlier this year. Full breakdown of what they tested because the DS interview varies a lot by company and Tesla is not well-documented.
Rounds: 5 total (virtual)
SQL round. One 60-minute round, pure SQL in a shared environment. Problems ranged from medium to hard by my estimation. I got: a window function problem involving running totals across time partitions, a self-join to find pairs meeting a condition, and a query optimization question where I had to rewrite a slow query. They asked me to explain query plans verbally, which some DS interviews don't bother with. Know your indexes, know when a subquery vs CTE makes sense, know how GROUP BY + HAVING interacts with window functions.
Stats / probability round. 60 minutes with a DS lead. Mix of conceptual and applied. Questions I got: explain the difference between Type I and Type II error in the context of A/B testing a Tesla feature (I talked about new feature rollouts on the mobile app). Then a probability word problem involving vehicle fleet events. Then a question about p-hacking in the context of running many experiments simultaneously, which they clearly care about because Tesla runs a lot of OTA experiments.
Case / product analytics round. Given a hypothetical scenario: Tesla introduced a new charging network feature and the usage rate is 20% below forecast. How do you diagnose and what do you recommend? This is a mini product sense round. Know what metrics matter (utilization rate, session completion, network latency, pricing sensitivity) and be ready to decompose the funnel.
Python / coding round. Not leetcode-hard, more applied DS. I implemented a basic time series decomposition and answered questions about seasonal vs trend components. Then a pandas exercise on a sample dataset. Know your numpy and pandas well. Scikit-learn syntax came up as a discussion point but I didn't have to implement ML from scratch.
Behavioral round. Same themes as other Tesla roles: bias to action, ownership, working with ambiguity. One question was specifically about disagreeing with a business stakeholder on a data interpretation. They want to see you pushed back with data, not just deferred.
Overall bar: legitimately hard on SQL and stats. Easier than Google DS but harder than most Series B/C DS interviews I've done. Come with your SQL skills sharp.