Data Science Interviews Are Broken Because No One Agrees What a Data Scientist Is

A thread in r/datascience hit a nerve recently. A candidate venting about DS interview prep laid it out plainly: Meta tests SQL and experimentation, Google tests statistics, Amazon tests a bit of everything, startups give you a take-home. The poster’s conclusion was that grinding Leetcode for SWE would have been more predictable, more efficient, and frankly more honest about what the job requires.

The rant got traction because it’s accurate. But the frustration points to something deeper than interview design choices. DS interviews are non-standardized because the job itself is non-standardized. Companies haven’t agreed on what a data scientist is, so every company’s interview reflects a different internal answer to that question.

This isn’t an HR problem, but a structural one.

The Reddit poster framed this as an interview design complaint. Fair enough. The prep overhead is real, and the context-switching cost is significant. But the more interesting signal is what the variation tells us about how companies think about data science as a function.

Meta’s DS interview is, functionally, a senior product analytics interview. The core question, ‘how would you measure success for this feature,’ is a product management question with a statistical wrapper. If you pass Meta’s DS loop, you’re being hired to do applied measurement work in service of product decisions.

Google’s DS interview looks more like a research scientist interview. Statistics from first principles, experimental design, Bayesian reasoning. The job they’re hiring for requires deeper methodological thinking and less operational throughput.

Amazon’s DS interview reflects Amazon’s organizational complexity. SQL, ML intuition, applied stats, and behavioral readiness for Leadership Principles. The breadth isn’t random. It matches the actual surface area of DS work inside Amazon, where the function touches logistics, recommendations, advertising, and supply chain simultaneously. Instead of being stylistic differences, they’re essentially different jobs under the same title.

Software engineering interviews converged around algorithms and data structures. You can prep for them the same way whether you’re targeting Google, Amazon, or a 50-person startup. The signal-to-noise is imperfect, but the format is consistent.

DS never developed an equivalent convergence. The field emerged from multiple directions simultaneously: statistics, computer science, business analytics, and academic research all contributed different versions of what a data scientist does. The job title became a catch-all rather than a specific function.

The result is that every company built its own definition of the role, then built its own interview around that definition. Candidates are left reverse-engineering what the company actually wants from a 400-word job description and whatever Glassdoor threads they can find.

For SWE candidates, the standardization is itself a filter: can you think algorithmically under pressure? For DS candidates, the filter is murkier, and figuring out which filter you’re even facing is itself a significant overhead cost.

IQ’s company-specific interview guides exist because of exactly this fragmentation. A generic DS prep plan leaves too much on the table when different companies are testing for categorically different skills.

The practical implication is that DS job search requires a targeting step that SWE job search doesn’t. You can’t just ‘prep for DS interviews.’ You have to identify which kind of DS role you’re targeting and build your prep around that archetype.

This isn’t impossible, but it adds a layer of complexity that catches candidates off guard. If you spread applications across Google, Meta, and three startups simultaneously without a deliberate plan, you’ll feel underprepared everywhere, because you’re effectively prepping for three different jobs at once.

The better approach is to map your target companies to archetypes before you open a textbook. Is the role product-adjacent? Stats-heavy? Operationally broad? Each maps to a different prep focus, a different question type, and a different definition of a strong candidate.

Sequencing matters too. Interviewing at Amazon before Meta before a startup, for example, lets you build SQL depth early (useful everywhere) and then layer in the stats or product sense that Meta specifically requires.

Some fields develop canonical interview formats over time as the role matures. DS is moving in the opposite direction. The rise of AI tools and the proliferation of ‘AI engineer’ and ‘ML engineer’ titles is further fragmenting the function, not consolidating it.

Companies experimenting with how they use data science internally will reflect that experimentation in how they hire for it. A company that’s shifting DS work toward model deployment will start screening for engineering skills. A company centralizing experimentation will screen for product analytics chops. The interviews will keep shifting as the jobs shift.

Candidates who build adaptable, modular prep strategies will have a structural advantage over those who treat DS interview prep as a single monolithic problem. Understanding the archetypes, and knowing which one you’re facing, is the skill that transfers across all of them.

If you’re in the middle of DS prep and feeling scattered across too many formats, IQ’s coaching service can help you build a targeted plan based on your specific companies and timeline. The fragmentation is real, but it’s workable once you understand the map.

DS interviews are non-standardized because DS is non-standardized. The Reddit rant isn’t evidence of bad interview design. It’s evidence that companies are hiring for fundamentally different jobs under the same title, and have been for years.

Until the field develops a clearer shared definition of what a data scientist actually does, the interviews will keep reflecting each company’s internal answer to that question. For candidates, that means the targeting work comes before the prep work.

Know what type of DS role you’re going for before you open a textbook. The prep problem is solvable. The ambiguity problem is structural and unlikely to resolve on its own.