NumPy Interview Questions

An ndarray is NumPy's core data structure, a multi-dimensional array where every element has the same data type. It stores data in a contiguous block of memory, which is a big part of why NumPy operations are fast.

You pass the list to np.array(), like np.array([1, 2, 3]), which returns an ndarray with a dtype inferred from the list's contents. Nested lists create multi-dimensional arrays.

A NumPy array requires all elements to be the same type and stores them contiguously in memory, while a Python list can hold mixed types and stores references to objects scattered in memory. That uniformity is what lets NumPy vectorize operations efficiently.

The shape attribute is a tuple showing the size of the array along each dimension, like (3, 4) for a 3-row, 4-column 2D array. It's one of the first things to check when debugging unexpected array behavior.

A dtype describes the data type of the elements stored in an array, like int32, float64, or bool. Every element in an array shares the same dtype, which is what allows NumPy to store data compactly and operate on it quickly.

np.zeros(shape) and np.ones(shape) create arrays filled with 0s or 1s of the given shape, useful for initializing arrays before filling them with real values. Both accept a dtype argument if you need something other than the default float64.

np.arange(start, stop, step) generates an array of evenly spaced values within a given range, similar to Python's built-in range() but returning an array instead of a range object. It supports floating-point steps, unlike range().

np.linspace(start, stop, num) generates a specified number of evenly spaced values between two endpoints, inclusive of both by default. It's often preferred over arange() when you need an exact count of points rather than a specific step size.

The ndim attribute returns the number of dimensions, so a 1D array returns 1, a 2D array returns 2, and so on. It's a quick way to confirm an array's structure before applying an operation.

Indexing lets you access individual elements or subsets of an array using bracket notation, like arr[0] for the first element or arr[1, 2] for a specific row and column in a 2D array. NumPy indexing extends naturally to multiple dimensions with comma-separated indices.

Slicing extracts a range of elements using the start:stop:step syntax, like arr[1:4] to get elements at indices 1 through 3. Unlike a copy, a basic slice returns a view into the original array's memory.

arr.size returns the total number of elements in the array as a single integer, while arr.shape returns a tuple describing the array's dimensions. Multiplying the values in shape together always gives you size.

The reshape() method changes an array's shape without changing its data, as long as the total number of elements stays the same, like arr.reshape(2, 3) to turn a 6-element array into a 2x3 grid. It returns a new view where possible rather than copying data.

np.eye(n) creates an n by n identity matrix, with 1s on the diagonal and 0s everywhere else. It's commonly used in linear algebra operations.

arr.max() and arr.min() return the largest and smallest values in the array. Both accept an axis argument to compute the max or min along a specific dimension instead of over the whole array.

Broadcasting lets NumPy perform operations between arrays of different shapes by automatically expanding the smaller array without actually copying its data. It's what lets you add a scalar to an entire array or add a 1D array to each row of a 2D array without writing a loop.

arr.dtype returns the data type of the array's elements, accessed simply as arr.dtype. It's useful for catching unexpected type coercion, like an array becoming float64 after mixing integers with a single float value.

The numpy.random module provides functions like np.random.rand() for uniform random floats and np.random.randint() for random integers within a range. Newer code often uses the Generator API through np.random.default_rng() for better statistical properties.

np.array_equal() checks whether two arrays have the same shape and all matching elements, returning a single boolean. It's the right way to compare arrays for equality, since using == directly returns an element-wise array rather than a single true or false.

arr.sum() adds up all elements in the array, and passing an axis argument sums along just rows or just columns instead of the whole array. It's one of several reduction operations NumPy provides alongside mean, min, and max.

A 1D array is a single row of values, like a vector, with one dimension in its shape. A 2D array has rows and columns, like a matrix, with a shape of two values.

np.concatenate() joins arrays along an existing axis, while np.vstack() and np.hstack() offer convenient shortcuts for stacking arrays vertically or horizontally. All the arrays being joined need compatible shapes along the dimensions that aren't being concatenated.

Transposing flips an array's axes, so for a 2D array it swaps rows and columns. It's commonly written as arr.T for short.

You can use a boolean expression like value in arr for a 1D array, or np.any(arr == value) which works cleanly across any number of dimensions. The np.any() approach is generally more reliable for multi-dimensional arrays.

An array created from a Python list of integers defaults to an integer dtype like int64, while a list containing any float gets promoted to a float dtype like float64. NumPy picks the dtype automatically based on the input unless you specify one explicitly.

np.zeros_like(arr) creates a new array of zeros with the same shape and dtype as an existing array. It's a convenient way to allocate an output array that matches another array's structure.

The copy() method, like arr.copy(), creates a completely independent array with its own memory. This matters because slicing returns a view by default, so modifying a slice without copying it first will change the original array too.

An element-wise operation applies a computation to each corresponding element of one or more arrays independently, like adding two same-shaped arrays together. This is the default behavior for arithmetic operators on NumPy arrays, unlike matrix multiplication which needs an explicit function.

arr.mean() computes the average of the elements, and arr.std() computes the standard deviation. Both accept an axis argument to compute along a specific dimension of a multi-dimensional array.

astype() converts an array to a specified dtype, returning a new array rather than modifying the original in place, like arr.astype(np.float32). It's commonly used to reduce memory usage or match a dtype another function expects.

A boolean mask is an array of True and False values, often produced by a condition like arr > 5, used to select elements from another array of the same shape. Indexing with a boolean mask, like arr[arr > 5], returns only the elements where the mask is True.

np.argmax() returns the index of the largest value in the array, and np.argmin() does the same for the smallest. Both accept an axis argument for multi-dimensional arrays.

np.sort(arr) returns a new sorted array and leaves the original unchanged, while arr.sort() sorts the array in place and returns nothing. Choosing between them depends on whether you still need the original unsorted order.

The axis parameter tells a function which dimension to operate along, like axis=0 to operate down columns in a 2D array and axis=1 to operate across rows. Leaving it unset usually applies the operation to the entire flattened array instead.

The flatten() method returns a 1D copy of the array's elements in row-major order, while ravel() does something similar but returns a view when possible rather than always copying. Both are commonly used before feeding array data into functions that expect a flat sequence.

I'd print the shapes of the arrays involved first, since broadcasting errors almost always come down to two dimensions that aren't equal and aren't 1. From there I'd check whether I actually meant to reshape one array, often by adding a new axis with np.newaxis, to align the dimensions the way I intended.

I'd reshape one set of points to introduce a new axis so broadcasting expands the subtraction into all pairwise combinations at once, then use vectorized operations like squaring and summing to get the distances without an explicit loop. This avoids the nested Python loops that would otherwise make the computation painfully slow for larger point sets.

I'd use boolean indexing when I want to select or modify a subset of an array in place, and np.where() when I need to build a new array that picks between two different values based on a condition. np.where() also handles the case cleanly where you want a default value for elements that don't meet the condition.

I'd check whether a smaller dtype, like float32 instead of float64, is acceptable for the precision the task actually needs, since that alone can cut memory usage significantly. I'd also look at whether the full array needs to be in memory at once, or whether it can be processed in chunks or memory-mapped with np.memmap.

I'd profile first to find the actual bottleneck rather than guessing, since it's often a hidden Python loop or repeated array copies rather than the core computation itself. Common fixes include replacing loops with vectorized operations, avoiding unnecessary intermediate arrays, and making sure operations aren't silently upcasting to a slower dtype.

I'd point out that basic slicing returns a view sharing memory with the original array, so modifying the slice modifies the original too, while operations like fancy indexing or explicit copy() return independent arrays. I'd suggest checking arr.base is not None as a quick way to see if an array is a view of something else.

I'd first check whether broadcasting rules naturally handle the combination, reshaping with np.newaxis if the dimensions just need aligning. If the shapes genuinely can't broadcast together meaningfully, I'd reconsider whether the arrays represent compatible data in the first place rather than forcing a reshape that doesn't make logical sense.

For a simple case I'd use np.convolve() with a uniform kernel, or build it with cumulative sums via np.cumsum() for better performance on large arrays. I'd avoid a manual sliding-window loop in Python, since that defeats the purpose of using NumPy in the first place.

I'd use the NaN-aware functions, like np.nanmean() or np.nanstd(), instead of their regular counterparts, since a single NaN in a standard operation propagates and silently corrupts the whole result. I'd also check upstream why the NaNs exist, since sometimes it's a data quality issue worth fixing rather than just working around.

I'd use np.allclose() or np.isclose() with an appropriate tolerance instead of a direct equality check, since floating-point arithmetic rarely produces bit-for-bit identical results across different computation paths. I'd pick the tolerance based on the actual precision the computation needs, beyond just the default.

For straightforward operations like matrix multiplication, determinants, or solving linear systems, numpy.linalg is usually sufficient and avoids adding a dependency. I'd reach for SciPy when I need more specialized algorithms, like sparse matrix support or advanced decompositions that NumPy doesn't cover.

I'd first check if the operation can be expressed with existing vectorized NumPy functions, since that's almost always faster. If a genuinely custom function is unavoidable, I'd use np.vectorize() for convenience on smaller arrays, while being aware it's really just a loop under the hood and won't give a real performance benefit at scale.

I'd be explicit about which axis represents which dimension, like height, width, and color channels, and document that convention clearly since it's easy to accidentally transpose axes when combining operations. I'd also double-check dtype when loading image data, since images are often stored as uint8 and need conversion before floating-point math.

I'd avoid growing an array incrementally with concatenate inside a loop, since each call allocates a new array and copies everything, making it quadratic in cost. Instead I'd preallocate an array of the final size upfront and fill it by index, or collect results in a Python list and convert to an array once at the end.

I'd check the dtype being used, since fixed-width integer types like int32 can silently overflow and wrap around instead of raising an error the way Python's native integers would. If the values involved could exceed the type's range, I'd explicitly use a wider dtype like int64 or cast before the operation that risks overflow.

For standard 2D matrix multiplication I'd use the @ operator, since it reads cleanly and maps directly to matmul() under the hood. I'd reach for np.dot() only when I specifically need its slightly different behavior with higher-dimensional arrays or scalars, since relying on that distinction without meaning to is a common source of subtle bugs.

I'd check whether the array is actually contiguous in memory and whether the operation is triggering an implicit copy or unexpected dtype conversion, since both can quietly erase the performance benefit of vectorization. I'd also verify the array isn't a view with a non-trivial stride pattern, since operations on non-contiguous views can be noticeably slower than on contiguous arrays.

I'd design the function to consistently expect a batch dimension, then have callers add a leading dimension of size one for a single sample rather than writing separate code paths. This keeps broadcasting behavior consistent and avoids duplicating logic just to handle the single-sample case.

I'd use tolist() for converting to nested Python lists when needed, but avoid doing it inside a performance-critical loop, since it defeats the purpose of using NumPy in the first place. When possible I'd keep computation in array form end to end and only convert at the boundary where Python-native structures are actually required, like serialization.

I'd use boolean masking or np.select() for multiple conditions, which lets me apply distinct logic to different subsets in a single vectorized pass rather than looping and checking conditions element by element. np.select() specifically handles the case of more than two mutually exclusive conditions more cleanly than nested np.where() calls.

I'd add explicit checks near the top of the function, like asserting arr.ndim or arr.shape matches expectations, and raise a clear error rather than letting a mismatched shape fail deep inside a broadcasting operation with a cryptic message. Catching it early saves significant debugging time for whoever calls the function incorrectly.

I'd create a seeded Generator instance with np.random.default_rng(seed) and pass it explicitly through the code that needs randomness, rather than relying on a global random state that can be inadvertently affected by other code. This makes tests deterministic and avoids the flakiness that comes from shared mutable random state.

I'd use np.pad() with an explicit mode, like constant or edge, rather than manually constructing a padded array, since it handles the boundary logic correctly and communicates the intent clearly to anyone reading the code. I'd pick the padding strategy based on what the downstream computation actually expects, since a wrong default like zero padding can quietly skew results.

I'd first isolate whether it's a logic error or a precision issue, since those need very different fixes, by testing the computation against a small known input with hand-calculated expected output. Precision issues often trace back to dtype choices, like accumulating a sum in float32 over a large array, or accidental integer division truncating results earlier than expected.

I'd look at shared memory approaches, like multiprocessing.shared_memory backing a NumPy array, when services run on the same machine, avoiding the serialization cost of repeatedly pickling large arrays between processes. For services on different machines, I'd weigh a binary format like NPY or a columnar format against JSON, since JSON handles numerical arrays poorly at scale.

I'd try vectorization first, since it usually gets most of the performance benefit with far less code complexity and no extra compilation step. I'd reach for Numba or Cython only when the logic genuinely can't be expressed as array operations, like an algorithm with data-dependent control flow that doesn't map cleanly to broadcasting.

I'd look for operations known to be numerically unstable in their naive form, like computing variance as the difference of squared sums, and replace them with more stable formulations or NumPy's built-in functions that already handle this correctly. I'd also consider whether rescaling the data before computation, rather than after, avoids the instability at its source.

I'd combine exact tests for simple known cases with tolerance-based comparisons using np.allclose() for anything involving floating-point arithmetic, since exact equality tests are fragile and often fail for reasons unrelated to correctness. I'd also add tests for edge cases like empty arrays, single-element arrays, and boundary dtype conversions, since those are where subtle bugs tend to hide.

I'd check whether the array's memory order, row-major versus column-major, matches the access pattern, since operating against the grain of the layout causes cache misses that slow computation significantly. I'd use np.ascontiguousarray() or specify order explicitly at array creation when the access pattern is known in advance.

I'd check whether NumPy operations are already releasing the GIL during heavy computation, which many do, since that allows genuine parallelism across threads for CPU-bound array work. If that's not enough, I'd look at multiprocessing to parallelize across independent chunks of work, or consider whether the workload is a better fit for a distributed array library.

I'd prioritize the loops in the hottest code paths first, based on profiling rather than intuition, and convert them to vectorized operations incrementally with tests in place to catch regressions. I'd resist rewriting everything at once, since a large numerical codebase can have subtle behavior baked into loop-based logic that's easy to break in a big-bang rewrite.

I'd set a default dtype standard, usually float64 for general computation, and require explicit justification for deviating to something like float32, since silent precision loss from inconsistent dtypes is a common source of hard-to-trace bugs. I'd also add checks in critical code paths that assert expected dtypes rather than assuming array inputs always arrive as expected.

I'd validate shape and dtype expectations explicitly at the function boundary and raise clear errors early, rather than letting a malformed array propagate deep into the computation before failing cryptically. I'd also document whether the function mutates its input in place or returns a new array, since that ambiguity is a frequent source of bugs for callers.

I'd check for differences in underlying BLAS or LAPACK libraries, since NumPy's linear algebra operations can produce different results at the level of floating-point rounding depending on which backend is linked. I'd also verify both environments are running the same NumPy version, since internal implementation details of certain operations have changed across releases.

I'd weigh this against actual data scale and computation patterns, since distributed frameworks add real operational complexity that isn't justified until single-machine NumPy genuinely becomes the bottleneck. I'd look for concrete evidence, like workloads that no longer fit in memory on the largest practical machine, before recommending the migration.

I'd mandate explicit seeding through the newer Generator API rather than the legacy global random state, since implicit global state is a common source of non-reproducible results across runs or parallel processes. I'd also require that seeds and library versions be logged alongside results for any pipeline where reproducibility genuinely matters, like scientific or financial computation.

I'd push teams toward NumPy's built-in vectorized functions as the default, since they're well-tested and maintained upstream, reserving custom optimization for the small number of code paths where profiling shows it's genuinely the bottleneck. Spreading custom low-level optimization broadly across a codebase tends to create a maintenance burden that outweighs the marginal performance gain in most of those places.

I'd plan for a layered approach, where NumPy remains the foundation for correctness and prototyping, while performance-critical paths get identified through profiling and selectively optimized or moved to specialized tooling as scale demands it. I'd avoid prematurely over-engineering the whole stack for scale the platform hasn't actually reached yet.

I'd require a documented test suite with known reference outputs for any shared numerical function, along with tolerance thresholds appropriate to the domain, since numerical correctness bugs are often subtle and don't surface as obvious crashes. I'd also mandate that changes to shared numerical code go through review from someone with domain expertise in the relevant math, beyond just general code review.

I'd tie the case to measurable outcomes, like reduced compute cost at scale or faster iteration cycles for teams doing research or analysis, rather than optimization for its own sake. If the numerical computation isn't actually a bottleneck for cost or speed that matters to the business, I'd deprioritize deep optimization work in favor of other engineering investments.

I'd require clear inline documentation of array shapes and units at function boundaries, since broadcasting-heavy code can be genuinely hard to follow without that context, especially for engineers newer to NumPy idioms. I'd also invest in onboarding materials that walk through the team's actual codebase patterns, since generic NumPy tutorials don't cover the specific conventions a given team has settled on.

I'd base that decision on sustained profiling data across realistic production workloads, not isolated benchmarks, since the overhead of maintaining compiled extensions is real and only worth it where the performance gain clearly matters at scale. I'd also weigh the loss of easy debuggability that comes with moving code out of pure Python and NumPy into compiled extensions.

I'd track deprecation warnings actively rather than waiting for a major version bump to surface breaking changes all at once, since NumPy has historically deprecated certain behaviors, like implicit type casting rules, well ahead of removing them. I'd also stage upgrades through a shared internal package registry so teams can adopt a new version on their own schedule rather than a forced simultaneous cutover.

I'd layer type hints and shape-checking utilities on top of NumPy's own runtime behavior, since NumPy itself won't catch a shape or dtype mismatch until the operation actually runs. I'd push for that kind of validation especially at the boundaries between teams' code, where mismatched assumptions about array structure cause the most costly bugs.

I'd start by profiling to find where time and memory are actually spent, since it's common for a small number of operations to dominate both cost and runtime. From there I'd evaluate dtype reduction, batching, and whether some workloads are better suited to specialized hardware acceleration than general-purpose compute running plain NumPy.

I'd require explicit, documented handling of these cases at function boundaries rather than letting them propagate silently, since NaN and overflow bugs are notorious for surfacing far from their actual source. I'd also build shared validation helpers that flag these conditions early, so individual teams aren't each solving the same problem differently.

I'd weight genuine understanding of broadcasting, memory layout, and vectorization thinking far more heavily than memorized API syntax, since the syntax is easy to look up but the underlying mental model of how NumPy actually computes is what determines whether someone writes efficient, correct numerical code. I'd design interview problems around real scenarios, like optimizing a slow loop-based computation, rather than trivia-style questions.

I'd invest in shared libraries and validation utilities that encode good practices, like consistent dtype handling and shape validation, so teams inherit good defaults rather than each rediscovering the same pitfalls independently. I'd also build a lightweight forum or review process for sharing performance techniques across teams, since numerical optimization knowledge tends to stay siloed otherwise.

I'd translate the tradeoff into terms stakeholders already track, like compute cost or how long an analysis takes to run, rather than talking about dtypes or memory layout directly. I'd also be clear about what's at risk on either side of the tradeoff, since a stakeholder needs to understand the downside of a decision, beyond just its cost.

I'd anchor the vision to realistic projections of data volume and team growth rather than the newest tooling trend, since infrastructure decisions made for hypothetical future scale often add complexity that never pays off. I'd also keep the vision flexible enough to revisit as actual growth patterns become clearer, rather than locking in a multi-year architecture too early.

I'd push for that expertise to be documented and shared actively through code review, internal talks, and pairing, rather than staying concentrated in a few people's heads. I'd also rotate ownership of critical numerical code paths periodically, so more than one person genuinely understands the trickiest parts, beyond just having read access to them.

I'd build the case with concrete evidence, like maintenance cost or how it blocks adopting newer NumPy capabilities, and pair that with a realistic migration path for teams depending on it. I'd also involve the heaviest users of the library in planning that migration, since a deprecation with no input from affected teams tends to stall.

I'd focus on making good numerical practices the easy default, through shared tooling, templates, and code review presence across teams, rather than relying on a standards document nobody reads closely. Real influence at this level comes from what you make convenient to do correctly, not from what you formally mandate.

I'd keep postmortems focused on systemic gaps, like missing validation or inadequate test coverage for edge cases, rather than blaming the individual who wrote the code, since numerical bugs are often genuinely subtle and easy for anyone to miss. I'd also track whether the resulting fixes, like adding shared validation utilities, actually get built and adopted, beyond just documented as a good idea.

I'd stay closely involved in a meaningful slice of real numerical code, since that's what keeps my intuition sharp and my recommendations grounded in what's actually happening in production. The organizational influence work, like shaping shared standards, has to be scoped so it doesn't crowd out that hands-on involvement entirely.

I'd define levels around observable capability, like the complexity of performance problems someone can diagnose independently or their ability to design numerically stable algorithms, rather than vague seniority labels. I'd also make sure the framework values deep technical specialization as a legitimate senior path, not only one that funnels toward general management.

I'd break the modernization into phases that each deliver measurable value, like specific performance wins or reduced compute cost, so leadership sees return along the way rather than betting on a distant, all-or-nothing finish line. I'd also revisit the plan periodically, since both the organization's priorities and the numerical computing ecosystem itself shift meaningfully over a multi-year timeline.

I'd bring concrete data on the actual cost of the status quo, like rising compute spend or slow iteration cycles for teams doing analysis, since abstract arguments about code quality rarely move stakeholders focused on near-term delivery. I'd also propose a specific, bounded optimization effort rather than an open-ended ask, since that's usually easier for stakeholders to commit to.

I'd involve consuming teams early in shaping shared numerical utilities rather than designing in isolation and handing down a finished API, since utilities built with real input tend to actually get adopted. Consistently shipping libraries that measurably save those teams time is what builds lasting trust, not documentation alone.

I'd prioritize making sure the standards and shared tooling I helped build keep working well without needing me to sustain them, which means investing in documentation, mentorship, and distributed ownership rather than being the one person who understands the trickiest parts. A good sign it worked is that the codebase's numerical quality holds up well after I've moved on to something else.