Pandas Interview Questions and Answers

What interviewers are testing: Whether you know when to stay in SQL vs pull into pandas—warehouse scale and pushdown—not a blanket preference.

Many loops give SQL + pandas for the same business question—see SQL technical interview questions.

A strong answer is:

I keep filtering, joins, and aggregation in SQL when the data is large and already lives in a database or warehouse. I use pandas when the result fits comfortably in memory and I need flexible local analysis, feature engineering, or Python integration.

What interviewers are testing: Whether you define Series, DataFrame, and index alignment as pandas' core model—not just reading CSVs.

pandas is an open-source Python library for tabular data manipulation and analysis. Core structures:

• Series — one-dimensional labeled array
• DataFrame — two-dimensional table (columns + index)

Built on NumPy; integrates with CSV, Parquet, SQL, Excel.

A strong answer is:

pandas is Python's standard labeled table library—DataFrame for rows and columns, Series for single columns—with alignment by index at the heart of operations.

What interviewers are testing: Whether you know a DataFrame column is an aligned Series and when to think in one column vs a table.

A DataFrame column is a Series sharing the DataFrame index.

A strong answer is:

Series is one column or vector; DataFrame is a table of Series aligned on the same index—I think Series for single-metric ops, DataFrame for relational shape.

What interviewers are testing: Whether you name production vs test creation paths and set dtypes on load.

Common methods:

import pandas as pd

df = pd.DataFrame({"city": ["A", "B"], "sales": [10, 20]})
df = pd.read_csv("data.csv")
df = pd.read_parquet("data.parquet")

From NumPy: pd.DataFrame(arr, columns=[...], index=[...]).

A strong answer is:

From dicts for tests, read_csv/read_parquet in production—I set dtypes on read when I know the schema to save memory and errors.

What interviewers are testing: Whether you understand the index as the alignment backbone—not just default row numbers.

The Index labels rows (and can label columns). Enables alignment in arithmetic and joins without positional guessing.

reset_index() moves index to columns; set_index() promotes columns.

A strong answer is:

Index is the alignment backbone—operations line up on labels, which is why bad indexes after groupby cause silent bugs until I reset_index deliberately.

What interviewers are testing: Whether you connect dtype choice to memory, joins, and correctness—including pandas 3 string defaults.

dtypes control memory and correctness:

df.dtypes and df.info() for audit; astype() for conversion.

A strong answer is:

Wrong dtypes inflate memory and break joins—I use category for repeated strings, parse dates on load, and nullable Int64 when missing integers are real.

What interviewers are testing: Whether you have a repeatable EDA opening before transforms and merges.

First step on any new dataset in interviews and on the job.

A strong answer is:

info for dtypes and nulls, describe for numeric range, value_counts for keys—before any merge I verify uniqueness assumptions with value_counts on join keys.

What interviewers are testing: Whether you know pandas 3 CoW blocks chained assignment and that .loc is the safe assignment path.

pandas 3 enables Copy-on-Write (CoW) always. Chained assignment does not update the original object, and SettingWithCopyWarning was removed—pandas 3 instead emits a ChainedAssignmentError warning for chained assignment, which cannot update the original object under CoW.

Wrong (chained assignment):

df["score"][df["active"]] = 0  # does not update df as intended

Correct:

df.loc[df["active"], "score"] = 0

With CoW, defensive .copy() purely to suppress SettingWithCopyWarning is no longer the model—assign with .loc on the parent DataFrame or use explicit .copy() when you genuinely need an independent subset.

A strong answer is:

In pandas 3, CoW is always enabled. I assign to the original DataFrame in one step with .loc; chained assignment cannot update the parent and triggers a ChainedAssignmentError warning.

What interviewers are testing: Whether you distinguish label vs position indexing and avoid chained brackets after filters.

Boolean indexing: df.loc[df["sales"] > 10].

A strong answer is:

loc for label slices and boolean masks; iloc for positional access—I avoid mixing chained brackets without loc after a filter.

What interviewers are testing: Whether you build parenthesized boolean masks with & | ~—not Python and/or on Series.

Filter rows with a boolean Series aligned to the index:

high = df[df["amount"] > 100]
mask = (df["country"] == "IN") & (df["amount"] > 0)
filtered = df.loc[mask]

Use &, |, ~ with parentheses—not Python and/or.

A strong answer is:

Boolean masks filter with vectorized comparisons—I parenthesize each condition and use & for AND when combining masks.

What interviewers are testing: Whether you explain split-apply-combine and pick agg vs transform by output shape.

groupby splits rows by key, applies a function per group, combines results.

Phases:

1. Split — partition by city, user_id, etc.
2. Apply — sum, mean, custom
3. Combine — assemble result index

df.groupby("city", as_index=False)["sales"].sum()

A strong answer is:

groupby is split-apply-combine—I name the key columns, choose agg vs transform based on output shape, and reset_index when I need flat columns for merge.

What interviewers are testing: Whether you know agg shrinks to one row per group while transform broadcasts back.

# agg: one row per city
df.groupby("city")["sales"].sum()

# transform: each row gets its city's mean
df["city_mean"] = df.groupby("city")["sales"].transform("mean")

A strong answer is:

agg reduces to one row per group; transform broadcasts group stats back for row-level ratios—I skip apply when agg/transform express the logic.

What interviewers are testing: Whether you can write readable multi-metric groupby().agg() calls with named aggregations instead of dict-of-lists rename hacks.

pandas 0.25+ style for multiple metrics with clear column names:

df.groupby("region").agg(
    total_sales=("sales", "sum"),
    avg_price=("price", "mean"),
    orders=("order_id", "nunique"),
)

Cleaner than dict of lists for interviews.

A strong answer is:

Named aggregations make readable summary tables in one groupby call—total_sales equals sum of sales per region without manual rename hacks.

What interviewers are testing: Whether you know when a MultiIndex from groupby needs reset_index() or as_index=False for downstream column-based merges.

Grouping by multiple keys yields a hierarchical index:

df.groupby(["region", "product"])["sales"].sum()

With the default as_index=True, multi-key grouping can produce a MultiIndex. Use reset_index() when downstream code expects those keys as ordinary columns, such as a column-based merge or flat-file export.

A strong answer is:

Multi-key groupby often puts the keys in a MultiIndex. I use as_index=False or reset_index() when the next operation expects flat key columns.

What interviewers are testing: Whether you pick pivot_table when duplicates exist—plain pivot only for unique index pairs.

pd.pivot_table(df, index="region", columns="month", values="sales", aggfunc="sum")

Like Excel pivot tables / SQL PIVOT conceptually.

A strong answer is:

pivot_table for revenue by region and month with duplicates allowed; plain pivot only when index pairs are unique.

What interviewers are testing: Whether you reshape wide to long for tidy analysis with correct id_vars.

melt unpivots wide columns to rows:

pd.melt(df, id_vars=["id"], value_vars=["Q1", "Q2"], var_name="quarter", value_name="revenue")

Opposite of pivot—tidy data for plotting and groupby.

A strong answer is:

melt turns wide quarter columns into long format for groupby and charts—I use id_vars for entity keys I keep constant.

What interviewers are testing: Whether you map merge to SQL joins, join to index alignment, and concat to stacking.

pd.merge(orders, customers, on="customer_id", how="left")
pd.concat([df2024, df2025], ignore_index=True)

A strong answer is:

merge for key columns like SQL; join when indexes already align; concat to stack batches with same schema.

What interviewers are testing: Whether you choose how= based on which keys must survive and can build an anti-join.

Anti-join (rows in left not in right): left merge + indicator + filter _merge == 'left_only'.

Important pandas difference from SQL: if both key columns contain null values, pandas can match those null-key rows to each other. Audit or remove null join keys when SQL-style NULL semantics are expected.

A strong answer is:

I pick how based on which keys must survive—left for preserve-all-orders, inner for matched-only analysis, indicator for anti-join customers without orders.

What interviewers are testing: Whether you inspect join-key cardinality and use validate= so invalid many-to-many merges fail instead of silently inflating rows.

Duplicate keys on one or both sides create a Cartesian product within each key—row count multiplies silently.

Prevent:

pd.merge(a, b, on="id", validate="many_to_one")

Check before merge: df["id"].is_unique or value_counts().

A strong answer is:

Duplicate keys can multiply rows many-to-many. I inspect key cardinality first and use validate="many_to_one", one_to_one, or the expected relationship so an invalid merge fails instead of silently inflating the dataset.

What interviewers are testing: whether you merge on composite identity with clean dtypes and no surprise null keys.

pd.merge(
    df1, df2,
    on=["customer_id", "order_date"],
    how="inner",
)

Column names differ: left_on=["a_id"], right_on=["b_id"].

A strong answer is:

Multi-key merge when composite identity matters—I check compatible dtypes, understand duplicate cardinality, and explicitly decide how null keys should be handled before the merge.

What interviewers are testing: Whether you know axis=0 appends rows and axis=1 adds columns aligned on index.

Use ignore_index=True when appending batches without meaningful index.

A strong answer is:

axis=0 to append monthly files; axis=1 to add feature columns aligned on the same index—I watch duplicate indexes on axis=1 joins.

What interviewers are testing: Whether you justify imputation vs drop with domain context—not blind fillna.

Interviewers want justification—mean imputation vs drop vs model-based.

A strong answer is:

I quantify missingness by column and business key first. I drop rows only when the missing field is required and the impact is acceptable; otherwise I use a domain-appropriate imputation rule and document the assumption. For ML features, I fit imputation using training data only.

What interviewers are testing: Whether you dedupe with explicit subset and keep= policy tied to the authoritative record.

df.duplicated(subset=["email"], keep="first")
df.drop_duplicates(subset=["order_id"], keep="last")

keep=False marks all duplicates in a group.

A strong answer is:

duplicated with subset on business key—I keep first or last explicitly based on which record is authoritative, not default blindly.

What interviewers are testing: Whether you parse with errors='coerce' and timezone awareness so bad values surface as auditable nulls.

df["amount"] = pd.to_numeric(df["amount"], errors="coerce")
df["ts"] = pd.to_datetime(df["ts"], utc=True, errors="coerce")
df["code"] = df["code"].astype("category")

errors="coerce" turns bad values into NaT/NaN for audit.

A strong answer is:

to_datetime with utc when events cross zones; coerce errors so bad strings surface as nulls I can count in info().

What interviewers are testing: Whether you use .str for idiomatic, missing-value-aware string column operations instead of row-wise Python loops.

Vectorized string ops on text columns:

df["email"].str.lower()
df["name"].str.contains("test", na=False)
df["code"].str.split("-", expand=True)

Prefer .str methods for concise, missing-value-aware column operations instead of manually writing row-wise Python string logic.

A strong answer is:

.str gives pandas-native string operations such as lower, contains, and split. I use it before reaching for row-wise apply, then profile if performance actually matters.

What interviewers are testing: Whether you treat apply as last resort after vectorized, transform, and .str paths.

DataFrame.apply() runs a function per row or column; GroupBy.apply() runs per group—both are flexible but slower than vectorized paths on large data.

First look for direct Series operations, agg, transform, map, where, np.select, .str, etc.

Use apply when:

• Logic is not expressible with vectorized ops
• DataFrames are small or prototyping
• Custom per-group logic truly needs flexible Python

A strong answer is:

apply is last resort—I try vectorized arithmetic, np.where, transform, or .str first and reserve GroupBy.apply for small custom group logic that cannot be vectorized.

What interviewers are testing: Whether you recognize Python-level row iteration as a performance bottleneck and can replace it with columnar pandas/NumPy operations where possible.

# Vectorized
df["tax"] = df["price"] * 0.18

# Avoid on large data
df["tax"] = df.apply(lambda r: r["price"] * 0.18, axis=1)

Python row iteration often becomes dramatically slower than columnar operations as DataFrames grow, so benchmark the real transformation rather than quoting a fixed speedup.

A strong answer is:

Vectorized operations let pandas/NumPy/native kernels optimize execution—iterrows is for debugging small samples, not production transforms on millions of rows.

What interviewers are testing: whether you shrink memory with category, parquet, usecols and measure before claiming fixes.

df.memory_usage(deep=True) to measure.

A strong answer is:

I consider category when cardinality is low and categorical semantics fit; with pandas 3's default str dtype and optional PyArrow backing, category is not automatically best for every repeated string column. I measure with memory_usage(deep=True) and load only needed columns on read.

What interviewers are testing: Whether you chain to_datetime, resample, shift, and rolling for calendar and lag analysis.

Timezone-aware timestamps help handle cross-zone and DST-sensitive data correctly, but localization may still require explicit handling of ambiguous or nonexistent times.

A strong answer is:

Parse to datetime, set index, resample for calendar buckets—shift for period-over-period and rolling for smoothed trends.

What interviewers are testing: Whether you pick fixed rolling vs cumulative expanding windows and set min_periods.

df["ma7"] = df["sales"].rolling(7, min_periods=1).mean()

A strong answer is:

rolling for last-N behavior; expanding for cumulative from series start—I set min_periods when early windows are sparse.

What interviewers are testing: Whether you can explain when pandas remains sufficient and when another dataframe engine or SQL system better fits the workload.

The interview-worthy skill is explaining why you would switch, not claiming one library is universally faster. If the work no longer fits pandas comfortably, also consider pushing computation into SQL or a distributed engine rather than assuming another in-process DataFrame library is always the answer.

A strong answer is:

I stay on pandas for notebook EDA and sklearn pipelines until profiling shows a bottleneck; then I compare Polars, SQL pushdown, or a distributed engine based on data size and join complexity—not a blanket library swap.

What interviewers are testing: Whether you use chunked reads for independent batch reduction or push work to SQL/Parquet.

for chunk in pd.read_csv("big.csv", chunksize=100_000):
    process(chunk)

Or filter at source with SQL/Parquet column pruning.

A strong answer is:

I use chunksize when I can process or aggregate each batch independently. If the workload needs broad joins or repeated scans beyond memory, I push work into SQL or another engine rather than forcing pandas to act like an out-of-core database.

What interviewers are testing: Whether you solve top-N per group with sort plus groupby().head() rather than slow apply() when possible.

If the source contains transaction-level rows, aggregate revenue by region and product before ranking; if it is already product-level, sort and groupby().head(3) directly.

product_revenue = (
    df.groupby(["region", "product"], as_index=False)["revenue"]
      .sum()
)

top3 = (
    product_revenue
    .sort_values(["region", "revenue"], ascending=[True, False])
    .groupby("region")
    .head(3)
)

When df is already one row per region/product, the sort-and-head(3) pattern applies directly without the preliminary aggregation.

DataFrameGroupBy.apply() is flexible but typically slower; in pandas 3, grouping-column behavior in apply() also changed. Ask how ties should be handled if the interviewer cares about rank semantics.

A strong answer is:

I clarify whether rows are transaction-level or product-level, aggregate by region and product if needed, then sort and groupby("region").head(3)—I also clarify tie handling if the interviewer asks.

What interviewers are testing: Whether you find left-only rows via indicator merge or isin membership—and handle null keys explicitly.

merged = customers.merge(orders[["customer_id"]].drop_duplicates(),
                         on="customer_id", how="left", indicator=True)
never_ordered = merged[merged["_merge"] == "left_only"]

Alternative: customers[~customers["customer_id"].isin(orders["customer_id"])] for a simple key-membership anti-join.

A strong answer is:

I use a left merge with indicator=True when I want explicit join diagnostics, or ~isin() for simple key membership. I also decide explicitly how null customer IDs should behave.

What interviewers are testing: Whether you bucket with Grouper, sum, and pct_change and handle the first-period NaN.

monthly = df.groupby(pd.Grouper(key="date", freq="ME"))["revenue"].sum()
growth = monthly.pct_change()

diff() for absolute change; pct_change() or diff() / shift(1) for relative growth. pct_change() returns fractional change (0.10 = 10%); multiply by 100 only when you need percentage-point display.

A strong answer is:

Grouper to month buckets, sum revenue, pct_change for MoM—I sort by date first and handle first month NaN explicitly.

What interviewers are testing: Whether you narrate a cleaning audit trail with shape and null counts after each step.

Checklist:

1. read_csv with na_values, dtype hints
2. drop_duplicates on business key
3. to_datetime / to_numeric with errors="coerce"
4. dropna or impute with stated rule
5. astype("category") where appropriate
6. Document before/after shape and null counts

A strong answer is:

I narrate each cleaning step with shape and null counts—parse dates, coerce numerics, dedupe on order_id, then aggregate—so interviewer sees audit trail.

What interviewers are testing: Whether you structure readable transformation pipelines with named .pipe steps.

.pipe(func, *args) passes DataFrame through functions—method chaining style:

result = (
    df
    .pipe(clean_orders)
    .pipe(add_revenue_column)
    .groupby("region")["revenue"].sum()
)

Improves readability in notebooks and interviews.

A strong answer is:

pipe names transformation steps in a left-to-right pipeline—cleaner than nested temp variables in live coding.

What interviewers are testing: Whether you know to_numpy, CoW read-only views, and nullable dtype copy behavior.

to_numpy() converts/exposes a DataFrame or Series as a NumPy array when possible—whether it shares memory or copies depends on dtype/layout. Under Copy-on-Write, shared arrays can be read-only to prevent NumPy mutation from changing the pandas object. Prefer to_numpy() over .values.

Watch: nullable dtypes and index alignment—NumPy arrays lose labels.

A strong answer is:

to_numpy when feeding sklearn without index—I'm careful that nullables may copy or need fill, and that CoW can make shared arrays read-only.

What interviewers are testing: Whether you pick parquet vs csv vs to_sql by downstream consumer and reset_index when needed.

A strong answer is:

parquet for downstream pipelines, csv for human handoff—I reset_index before export if flat files need key columns.

What interviewers are testing: Whether you fit aggregations on train only—never global target stats before split.

Rules:

• Fit aggregations only on train split, apply to test
• No future data in shift for prediction targets
• Group stats computed inside cross-validation folds

# Fit mapping on train only
means = train.groupby("category")["feature"].mean()
train["category_mean"] = train["category"].map(means)
test["category_mean"] = test["category"].map(means)
# For target encoding, compute train features out-of-fold

For broader ML leakage questions, see data science interview questions.

A strong answer is:

Any learned group-level statistic used as a feature should be fit from training data only. I never compute target means or similar fitted statistics on the full DataFrame before splitting, and target encoding for training rows should be out-of-fold.

What interviewers are testing: Whether you test transforms with assert_frame_equal and edge-case fixture frames.

• pytest with small fixture DataFrames
• pandas.testing.assert_frame_equal for output compare
• Property checks: row count, key uniqueness, no null in required cols

A strong answer is:

assert_frame_equal on expected output for pure functions—I build minimal frames covering edge cases like duplicate keys and null join keys.

What interviewers are testing: Whether you explain CoW as deferred copying—returned objects behave independently from the user perspective while pandas may share underlying memory until mutation.

Copy-on-Write (CoW) defers physical copies until a write would affect another object sharing the same memory.

In pandas 3, CoW is always enabled:

• Subsets and slices may share backing arrays until one is modified
• Returned objects behave as copies from the user perspective while memory is shared until mutation
• NumPy arrays from to_numpy() may be read-only when they share data with the pandas object
• Chained assignment cannot update the parent (see the chained-assignment card for .loc migration)

Use explicit .copy() when you genuinely need an isolated object.

A strong answer is:

CoW in pandas 3 means subsets can share memory until a mutation forces a copy—returned objects behave independently while pandas avoids unnecessary duplication until write time.

What interviewers are testing: Whether you use as-of joins on sorted timestamps for nearest-key alignment—not exact equality.

merge_asof() joins on the nearest key rather than exact equality—ideal for time-series alignment.

Use cases:

• Match transactions to the latest price as of each timestamp
• Align sensor events to irregular sample times
• Event streams where exact key match would miss valid prior records

pd.merge_asof(trades.sort_values("ts"), prices.sort_values("ts"),
              on="ts", by="symbol", direction="backward")

Requires both frames to be sorted ascending by the on/as-of key.

A strong answer is:

merge_asof is my tool for as-of joins on timestamps—backward direction picks the latest prior price for each trade without exact time equality.

What interviewers are testing: Whether you distinguish pd.NA, NaN, NaT and when nullable extension dtypes matter.

pandas 3 distinguishes the default inferred str dtype, which uses NaN, from the opt-in nullable dtype="string", which can use pd.NA:

Nullable integer/boolean/string dtypes preserve integer-like columns with missing values—unlike float64 columns that coerce integers to floats.

A strong answer is:

I use nullable Int64 and boolean when missing is real—pd.NA is the dedicated missing marker for nullable dtypes, distinct from NaN on floats, NaT on datetimes, and the default str dtype in pandas 3.

What interviewers are testing: Whether you know Arrow-backed dtypes and Parquet I/O in analytics pipelines.

Modern pandas interoperates with Apache Arrow for columnar memory and I/O:

You do not need deep Arrow internals for most interviews—awareness that pandas can use Arrow-backed dtypes and exchange data with Arrow ecosystems is enough.

A strong answer is:

I know pandas can read/write Parquet and use Arrow-backed dtypes for performance—I do not assume every Arrow operation is zero-copy without checking dtype and conversion path.