Pandas & NumPy Interview Questions
Technical interviews for data analyst, data scientist, and ML engineer roles reliably probe a candidate's fluency with pandas and NumPy because these libraries are the daily working surface for most data manipulation tasks. Interviewers are usually less interested in memorized trivia and more in whether you understand *why* certain operations are fast or slow, *why* a piece of code produces a SettingWithCopyWarning, and how you would approach cleaning and reshaping messy real-world data under time pressure. This topic collects the questions that recur most often, organized by theme, with answers that explain the underlying mechanism rather than just stating the fact.
Cricket analogy: Interviewers testing a young all-rounder don't just ask him to recite stats; they want to see he understands why a yorker beats a full toss in the death overs - similarly, pandas interviews probe why an operation is fast, not trivia recall.
Core Conceptual Questions
'What is the difference between .loc and .iloc?' is nearly universal: .loc selects by label (and is inclusive of the end label in slices), while .iloc selects by integer position (and is exclusive of the end position, matching Python slicing conventions). 'What is broadcasting in NumPy?' expects an explanation that operations between arrays of different but compatible shapes are automatically stretched along size-1 dimensions without copying data, following specific alignment rules from the trailing dimension inward. 'What is the difference between a view and a copy?' tests whether you know that NumPy slicing returns a view (a new array object sharing the same underlying buffer) while fancy indexing and most pandas chained operations return a copy, which is the root cause of the infamous SettingWithCopyWarning.
Cricket analogy: .loc is like selecting overs by label ('the 20th over', inclusive of that over), while .iloc is like selecting by ball count position, exclusive of the final index - and broadcasting is like a fielding drill stretching one instruction across every fielder without copying the plan per player.
import numpy as np
import pandas as pd
# Q: Why does this raise SettingWithCopyWarning?
df = pd.DataFrame({'score': [55, 72, 88, 40], 'passed': [False]*4})
subset = df[df['score'] > 50] # subset may be a view OR a copy - ambiguous
subset['passed'] = True # pandas can't guarantee this writes back to df
# A: Use .loc on the original DataFrame instead, which is unambiguous
df.loc[df['score'] > 50, 'passed'] = True
# Q: What does broadcasting do here?
a = np.array([[1, 2, 3], [4, 5, 6]]) # shape (2, 3)
b = np.array([10, 20, 30]) # shape (3,)
result = a + b
# b is 'stretched' across the first axis without copying:
# [[11, 22, 33],
# [14, 25, 36]]Performance and Vectorization Questions
'Why is a for loop over a DataFrame slow compared to a vectorized operation?' The expected answer: Python-level loops incur per-element interpreter overhead and repeated type dispatch, while vectorized NumPy/pandas operations push the loop into compiled C code operating on contiguous memory, avoiding both the interpreter overhead and Python object boxing. A strong follow-up answer mentions that .apply() is still a disguised Python loop under the hood and is usually only marginally faster than iterrows(), so true vectorization (arithmetic, .str accessor methods, np.where, boolean masks) should be preferred whenever possible. 'How would you speed up a slow groupby-apply?' often expects mention of built-in aggregation methods (.sum(), .mean(), .agg() with named functions) over custom Python callables, and possibly numba or Cython for genuinely custom logic that can't be vectorized.
Cricket analogy: A commentator narrating ball-by-ball is slow compared to a scoreboard auto-updating totals in bulk; similarly a Python for-loop over rows is slow, .apply() is still a disguised loop, and true vectorized aggregation is the fast, compiled path.
A great signal in an interview is naming the actual mechanism, not just the vocabulary: instead of saying 'vectorization is faster,' explain that it replaces N Python bytecode dispatches with a single call into a tight, statically-typed C loop operating on a contiguous memory buffer — that level of specificity is what separates memorized answers from real understanding.
Practical Coding Prompts
Live-coding rounds commonly ask candidates to: find and handle missing values (isna(), fillna(), dropna()); deduplicate rows on a subset of columns (drop_duplicates(subset=[...])); merge two DataFrames and reason about which join type (inner, left, outer) produces which row count; group data and compute a per-group ranked or normalized metric using groupby().transform(); and reshape data between wide and long formats with melt() and pivot(). Being able to narrate your reasoning out loud — 'I'll use left here because I want to keep every row from the orders table even if there's no matching customer' — matters as much as producing correct code, since interviewers are evaluating your decision process, not just the final output.
Cricket analogy: A live-coding round is like a fielding drill under match pressure: find and patch a fielding gap (fillna), remove a duplicate player from the XI (drop_duplicates), pick the right pairing for a partnership (merge join type), and narrate why you chose it.
A frequent trap in live coding is confusing merge()'s default how='inner' with the intent of the question — if the prompt says 'keep all transactions even ones without a matching customer record,' an inner join silently drops rows, producing a subtly wrong answer that still runs without error.
.locis label-based and inclusive of slice endpoints;.ilocis position-based and exclusive.- Broadcasting stretches smaller-shaped arrays across compatible dimensions without copying data.
- NumPy slicing returns views; fancy indexing and ambiguous pandas chains return copies, causing
SettingWithCopyWarning. - Vectorized operations beat Python loops (and
.apply()) because they execute in compiled C over contiguous memory. - Merge/join type (
inner/left/outer) directly determines which rows survive and must match the question's intent. - Interviewers weigh your explained reasoning as heavily as your final working code.
Practice what you learned
1. Which statement correctly distinguishes `.loc` from `.iloc`?
2. What commonly causes a `SettingWithCopyWarning` in pandas?
3. Why does a vectorized NumPy operation typically outperform an equivalent Python `for` loop?
4. If you need to keep every row from a 'orders' DataFrame even when there is no matching row in 'customers', which join should you use?
5. Why is `.apply()` often a misleading optimization target in interviews?
Was this page helpful?
You May Also Like
Common Pandas & NumPy Pitfalls
A field guide to the mistakes that trip up even experienced users of pandas and NumPy — chained assignment, dtype surprises, mutable defaults, and silent misalignment.
Pandas & NumPy Quick Reference
A condensed cheat sheet of the most-used NumPy and pandas syntax — array creation, indexing, aggregation, merging, and reshaping — for fast lookup while coding.
Vectorized Operations and Broadcasting
Vectorization applies operations across whole arrays without explicit loops, and broadcasting extends this to arrays of different but compatible shapes.
Indexing with loc and iloc
Master the two primary pandas selection accessors — .loc for label-based indexing and .iloc for integer-position-based indexing — and the pitfalls of chained indexing.