NumPy Interview Questions for 2026: 16 Answers That Go Past the Definitions

An ndarray is a fixed-size, homogeneous n-dimensional array: one contiguous memory buffer plus metadata (shape, strides, dtype) that tells NumPy how to interpret it. A Python list is an array of pointers to individually boxed, heterogeneous objects scattered across the heap. That difference drives everything: an int64 element costs 8 bytes in NumPy versus roughly 28 bytes for a boxed Python int plus pointer overhead; arithmetic runs in compiled C loops over the buffer instead of per-element interpreter dispatch; and operators behave differently — arr * 2 doubles every element, while list * 2 concatenates the list with itself. Because the buffer is fixed-size, "appending" via np.append allocates an entirely new array each call, which is why building arrays element-by-element in a loop is an anti-pattern.

A dtype describes the type, size, and layout of every element — float64, int32, bool, complex128, fixed-width strings, even structured records. It matters for three reasons. Memory: switching a large float64 array to float32 halves its footprint, often the difference between fitting in RAM or not. Correctness: float32 carries roughly seven significant decimal digits, and fixed-width NumPy integers wrap on arithmetic overflow instead of growing arbitrarily like Python ints. Conversion: astype always returns a new array, and mixed-dtype operations promote to a common type. Worth knowing for 2026 interviews: NumPy 2.0 adopted NEP 50 promotion, so a Python scalar's value no longer influences the result dtype — a float32 array plus a huge Python float now stays float32 (overflowing to inf) rather than silently upcasting to float64.

np.arange(start, stop, step) generates values by repeatedly adding step, excluding stop — like Python's range but returning an array and accepting floats. np.linspace(start, stop, num) generates exactly num evenly spaced points and includes stop by default. The interview-relevant difference is floating-point behaviour: with a float step, arange accumulates rounding error, so whether a value near stop appears as the final element depends on that error, and the array's length becomes hard to predict. linspace computes each point from the endpoints and the count, so its length is deterministic and it hits the endpoint exactly. Rule of thumb: use arange for integer sequences, and linspace for float grids, plot axes, and anywhere you care about the number of samples rather than the spacing between them.

axis names the dimension an operation runs along — and for reductions, the dimension that disappears from the result. For a (3, 4) array, sum(axis=0) collapses the 3 rows, producing 4 column totals; sum(axis=1) collapses the 4 columns, producing 3 row totals. The reliable mental model: the axis you pass is removed from the shape, so (3, 4) with axis=0 gives (4,). Negative values count from the end — axis=-1 is the last dimension — which keeps code working on arrays of any rank. keepdims=True keeps the reduced dimension as size 1, preserving broadcastability; that is how you subtract a row-wise mean cleanly: x - x.mean(axis=1, keepdims=True). Getting axis direction backwards is one of the most common live-coding stumbles, so slow down and apply the shape rule.

Boolean masking filters with a same-shaped boolean array: arr[arr > 0] returns a new 1-D array (a copy) of the elements where the condition holds. Conditions combine with the bitwise operators & | ~, each clause parenthesised — (a > 0) & (a < 10). Using Python's and/or raises "truth value of an array is ambiguous", because a multi-element array cannot collapse to a single bool. Mask assignment writes through to the original: arr[arr < 0] = 0 zeroes negatives in place. Related tools interviewers expect: np.where(cond, x, y) for elementwise selection, np.count_nonzero(mask) to count matches, and mask.any() or mask.all() for existence checks. One trap: reading through a mask copies, so arr[mask][0] = 5 modifies a temporary and silently does nothing to arr.

Broadcasting lets NumPy operate on arrays of different shapes without copying data. The rules: align shapes from the rightmost dimension; two dimensions are compatible if they are equal or either is 1; a missing leading dimension is treated as 1; the result takes the larger size in each slot. Example: (3, 1) + (1, 4) gives (3, 4); an image of shape (H, W, 3) times a per-channel scale of shape (3,) works because the 3s align on the right. (3,) + (4,) fails — neither dimension is 1. Under the hood nothing is physically repeated: the size-1 dimension is given stride 0, so the same memory is read repeatedly at zero allocation cost. Interviewers often present shape pairs and ask for the output shape — practise until it is mechanical, including the failure cases.

Basic slicing (arr[1:5], arr[::2], arr[:, 0]) returns a view: a new array header over the same buffer, so writes propagate both ways. Transposes and, usually, reshape and ravel are also views. Fancy indexing with an integer array (arr[[0, 2, 5]]) and boolean masking always copy, because the selected elements cannot be described by regular strides over the original buffer. flatten() always copies; ravel() copies only when it must. To check, inspect arr.base — non-None means it is a view onto another array — or call np.shares_memory(a, b). Two classic bugs: mutating a slice of a large array and corrupting the original, and chained indexing like arr[mask][0] = 9, which writes into a temporary copy and is silently lost. When you deliberately need independence, call .copy().

A Python for-loop pays costs per element: bytecode dispatch, dynamic type checks, boxing numbers into objects, and reference-count churn. A vectorized call like np.sum or a + b pays those costs once, then executes a tight compiled C loop over a typed, usually contiguous buffer — sequential access the CPU can prefetch, with SIMD instructions where the build supports them. For numeric work the speedup is routinely orders of magnitude. Trade-offs worth stating in an interview: vectorized expressions allocate temporaries (a*b + c creates an intermediate array for a*b), which can hurt on very large inputs, and algorithms with loop-carried dependencies do not vectorize cleanly — those are cases for numba or Cython. A strong answer names the mechanism — interpreter overhead removed, cache-friendly access — rather than just saying "NumPy is written in C".

Both return a 1-D version of the array; the difference is copying. flatten() always allocates a copy, so mutating the result never affects the original. ravel() returns a view whenever the elements are already laid out contiguously in the requested order, and only copies when they are not — for example, ravelling a transposed array. That makes ravel cheaper but aliased: writing through it can change the source array. reshape(-1) behaves like ravel. Both accept an order argument ('C' row-major, 'F' column-major) controlling read order. In an interview, tie this back to the view/copy model and mention verification: after b = a.ravel(), checking b.base is a confirms it is a view. Choose flatten when you need safety, ravel when you need speed and will not write through the result.

Strides are the number of bytes to step in memory to move one position along each axis. A C-order (3, 4) float64 array has strides (32, 8): 8 bytes to the next column, 32 to the next row. Most "free" NumPy operations are just stride arithmetic on the same buffer: transpose swaps shape and strides — becoming (4, 3) with strides (8, 32) — in O(1) with zero copying; arr[::2] doubles a stride; broadcasting sets a stride to 0 so one value is reused along an axis. Strides also explain why some reshapes must copy: if no stride pattern over the existing buffer can produce the requested shape (common after a transpose), NumPy materialises a new array. For sliding windows, numpy.lib.stride_tricks.sliding_window_view builds overlapping views without copying — the safe cousin of as_strided.

* is elementwise multiplication and follows broadcasting rules — (3, 4) * (4,) scales column-aligned elements; it never performs matrix multiplication. np.matmul, exposed as the @ operator, is matrix multiplication: for 2-D inputs it is the standard product, for 1-D inputs an inner product, and for higher dimensions it treats the last two axes as matrices and broadcasts over the leading batch dimensions — (10, 3, 4) @ (10, 4, 5) gives (10, 3, 5). np.dot matches matmul for 1-D and 2-D, but its N-D rule is different — a sum-product over the last axis of the first argument and the second-to-last of the second — which produces surprising shapes and no batch semantics. Practical guidance: use @ for anything matrix-like, especially batched work; reserve * for Hadamard products; and remember @ rejects scalars while * accepts them.

np.nan is an IEEE-754 floating-point value, which has three interview-relevant consequences. First, equality with NaN is always False — even nan == nan — so arr == np.nan never finds anything; use np.isnan(arr). Second, NaN is a float, so it cannot live in an integer array; introducing it forces an upcast, which is why integer columns with missing values become float in pandas. Third, NaN propagates: arr.sum() or arr.mean() returns nan if any element is nan. The nan-aware family — np.nansum, np.nanmean, np.nanstd, np.nanmax — skips them instead. Also note that any comparison involving NaN returns False, so boolean filters silently drop NaN rows regardless of the condition's direction — a subtle source of wrong analytics. For genuinely missing data at scale, masked arrays or pandas' nullable dtypes are the cleaner tool.

NumPy stores data in one linear buffer; order='C' (the default) is row-major, meaning the last index varies fastest, while order='F' is column-major. Layout matters because CPUs fetch memory in cache lines and prefetch sequential access: iterating in an order matching the layout streams through memory, while striding across it wastes most of each cache line. Concretely, on a large C-order 2-D array, reducing along the contiguous axis is typically measurably faster than along the other. Contiguity is tracked in arr.flags; a transposed C-contiguous array is no longer C-contiguous, though it is F-contiguous. This bites at boundaries: BLAS routines, Cython code, OpenCV, and zero-copy protocols often require contiguous input, so you call np.ascontiguousarray and pay a copy. A senior answer connects layout to symptoms: the same reduction differing several-fold by axis, or a "random" copy appearing after a transpose.

np.einsum expresses multiplications, transposes, and sum-reductions in Einstein index notation: label each axis of each operand; an index repeated across operands is multiplied and summed; indices omitted from the output are reduced. So 'ij,jk->ik' is matrix multiply, 'ij->ji' is transpose, 'ij,ij->i' is a row-wise dot product, 'bij,bjk->bik' is batched matmul, and 'ij->' sums everything. Its value: one call can fuse what would otherwise be a chain like (A[:, :, None] * B[None]).sum(axis=1) — clearer, and without materialising the large intermediate. With optimize=True, multi-operand contractions get a computed evaluation order, which can be dramatically faster than naive left-to-right evaluation. The honest caveat interviewers like to hear: for a plain 2-D matmul, @ dispatches to tuned BLAS and usually beats einsum, so reach for einsum when the contraction is genuinely complex.

np.tile physically repeats data: tiling a (1000,) vector into a (10000, 1000) array allocates every copy. Broadcasting achieves the same arithmetic with no allocation, because the virtual repetition is a stride-0 view; np.broadcast_to makes that view explicit — and marks it read-only, since writing through aliased memory would update every "copy" at once. So the first rule of memory-efficient NumPy: never tile when broadcasting suffices. The flip side is intermediate explosion: computing pairwise distances as ((X[:, None, :] - Y[None, :, :])**2).sum(-1) broadcasts into an (n, m, d) temporary — at n = m = 10000 and d = 128 in float64, that is on the order of 100 GB. Mitigations: chunk one axis, restructure algebraically (expand the squared norm so it becomes a matmul plus two vector norms), or fuse the contraction with einsum. Knowing which side of this line an expression falls on is a genuinely senior signal.

Every arithmetic op in an expression allocates a result, so y = a*b + c creates a temporary for a*b before the add; on multi-GB arrays those temporaries dominate memory and bandwidth. Tools: in-place operators (a += b reuses a's buffer, unlike a = a + b); the out= parameter on ufuncs — np.multiply(a, b, out=scratch) then np.add(scratch, c, out=scratch) — to recycle one scratch buffer; the where= keyword to skip masked elements without building intermediates; and einsum to fuse multiply-and-reduce chains into one pass. Caveats a good candidate volunteers: in-place operations on a view mutate the base array; in-place with an incompatible dtype raises rather than truncating (int_array += 0.5 fails under same-kind casting); and aliasing inputs with out= is safe for elementwise ufuncs but needs care in general. When fusion really matters, numexpr or numba compile the whole expression into a single pass.