Python Interview Questions for Data Scientists: A Complete Guide (2026)

Quick Answer: Python Interview Questions for Data Scientists

The Same Twenty Questions

Run five or six of the big "Python interview questions for data science" round-ups side by side and a pattern shows up fast: the same twenty or so questions, in a different order, on every list. List versus tuple. is versus ==. Why NumPy is faster than a plain list. All still worth knowing. None of them tell an interviewer anything current about a candidate, since anyone can memorize a definition off the fourth search result the night before.

The questions that actually separate candidates are the ones a memorized definition doesn't survive: the ones where the correct answer changed recently, or where the only real way to answer is to have actually run the code.

How These Interviews Actually Work

Most data science interviews mix three formats. A live coding round, usually shared-screen, working through a small problem while narrating the reasoning out loud. A take-home assignment, a messier and more open-ended dataset with a few days to turn around a notebook or short report. And a conceptual round, questions answered in conversation rather than code, checking whether the syntax knowledge has an actual mental model behind it.

The foundations below matter for all three. The section after it matters more for the conceptual round, and especially for the follow-up question a good interviewer asks right after the first answer.

Foundations You'll Still Be Asked

What's the difference between a list and a tuple?

A list is mutable, ordered, and built with square brackets. A tuple is immutable, ordered, and built with parentheses. Immutability makes a tuple hashable, which is why tuples can be dictionary keys and lists generally can't. Article 2 covers both in full, including the aliasing bug immutability sidesteps entirely.

What's the difference between is and ==?

== compares values. is compares identity, whether two names point to the literal same object in memory. Two separate lists with identical contents are == equal but not is identical.

What's the difference between a list comprehension and a generator expression?

A list comprehension builds the whole result in memory immediately. A generator expression produces one value at a time and can only be walked through once. Article 9 has the exact memory numbers, not just the theory.

Why is a NumPy array usually faster than a plain Python list for numeric work?

A NumPy array stores one fixed data type in a single contiguous block of memory and runs operations in compiled code. A Python list stores references to separate objects scattered in memory, so a loop over it goes through the Python interpreter for every item, the exact mechanism Article 11 benchmarks directly.

What Actually Separates Candidates

What does this code actually do?

df[df["amount"] > 100]["status"] = "high"

Nothing to df. As of Pandas 3.0, copy-on-write means every selection behaves as an independent copy, so this chained assignment updates a temporary object that's discarded immediately, and raises a warning in the process. The fix is df.loc[df["amount"] > 100, "status"] = "high", in one step. Article 6 covers why this changed, and Article 10 shows the identical trap with fillna specifically.

What's the difference between .agg(), .transform(), and .apply() after a groupby?

agg() reduces each group to one summary row. transform() keeps the original row count and broadcasts a group-level result back onto every row. apply() is the flexible fallback for whatever the other two can't express, at the cost of speed. Article 7 has the full breakdown, and the live-coding prompt below tests a specific detail about agg() that's easy to overgeneralize.

Does .join() default to the same join type as .merge()?

No, and this one catches people who assume consistency. merge() defaults to an inner join. join() defaults to a left join. The same two tables can return a different row count depending only on which method wrote the line. Article 8 walks through it with one dataset across all four join types.

Is .apply(axis=1) the same as writing vectorized code?

No, even though it's often described that way. It still runs the given function once per row in plain Python. A direct benchmark in Article 11 timed it at roughly 1,400 times slower than the equivalent vectorized operation on 50,000 rows.

Does pandas still store dates in nanosecond precision?

Only for one narrow case: converting a raw integer epoch with no unit specified. Parsing a date string, the far more common situation, defaults to microsecond precision as of Pandas 3.0, verified directly in Article 12 rather than assumed from older documentation.

A Live-Coding Style Prompt

A quick prediction exercise, the kind a live round often opens with. Before running anything, guess what result.columns looks like:

import pandas as pd

orders = pd.DataFrame({
    "customer": ["Alex", "Sam", "Sam"],
    "amount": [50, 30, 90]
})

result = orders.groupby("customer")["amount"].agg(["sum", "count"])
print(result.columns.tolist())

The honest answer is ['sum', 'count'], a completely flat, ordinary set of column names. That surprises people who've learned the general rule that a list of functions in .agg() always creates a MultiIndex. The MultiIndex only appears when .agg() runs on the whole grouped DataFrame at once, applying the same functions across every column. Selecting a single column first, the way this example does, skips that entirely. It's a small enough distinction that even a careful explanation can round it off to "always," which is exactly the kind of thing worth actually running before stating with confidence, in an interview or anywhere else.

Mistakes Candidates Make

• Reciting a memorized definition without being able to demonstrate it with two lines of actual code when asked to.
• Not asking a clarifying question about messy or ambiguous data before diving straight into a take-home assignment.
• Answering confidently with outdated information instead of saying "I'd want to check the current docs," which reads as more credible than a wrong guess stated with certainty.
• Treating a live coding round as a silent test instead of narrating the reasoning out loud, which is usually what's actually being evaluated.
• Not having a real example ready when asked about a time a bug or a wrong assumption was caught in their own analysis.

Practice: Do These Three Before Your Next Interview

Frequently Asked Questions

Conclusion: Verified, Not Recited

The foundations still get asked, and they're worth having ready without hesitation. The questions that actually separate candidates are the ones a search result from a few years ago answers incorrectly: the copy-on-write trap, the agg versus transform versus apply distinction, the join default mismatch, the vectorization gap, the datetime resolution change. Every one of them is something this cluster verified directly rather than assumed, which is exactly the habit worth bringing into the interview itself.

Practice the three exercises above, then move to the next article in this cluster, which compares NumPy, pandas, and Polars directly: not which one is best, but which one actually fits the job in front of you.