Data Visualization Interview Questions — Practice Real Interview Topics

A pie chart explicitly represents parts of a whole: each slice's angle is proportional to its share of the total. Scatter plots show correlation between two continuous variables, line charts show trends over a continuous interval, and histograms show the distribution of a single continuous variable — none of which are designed for part-to-whole comparison of a small number of categories.

Small multiples trade one complex chart for many simple, identical ones. The identical scale and layout across panels is what makes the comparison work — if one panel used a different y-axis range than the others, the visual comparison would silently become invalid even though nothing about the panels' appearance would signal that. This is the standard fix when a single chart with too many overlapping lines or bars becomes unreadable: split by the category causing the clutter instead of trying to force everything onto one set of axes.

The 'jet' colormap (line 4) interleaves red and green bands, making it difficult for red–green colorblind viewers to distinguish values. It also has non-uniform luminance, creating misleading perceptual bands. Matplotlib's 'viridis' colormap is perceptually uniform and colorblind-safe. The other options are factually wrong: imshow accepts float arrays, plt.colorbar works without an explicit handle, and plt.title accepts a string title.

A diverging palette exists specifically for data with a meaningful zero or reference point and two directions of deviation from it — shrinking versus growing headcount is exactly that shape, so blue-to-white-to-red (or similar) lets a viewer read both the direction and the magnitude of change at a glance. A sequential palette assumes one direction with no meaningful midpoint, like population density, so applying it here would make -30% and +45% look like points on the same one-way scale instead of opposite outcomes. A categorical palette is for unordered nominal groups, not an ordered numeric quantity, and a rainbow palette is actively harmful for quantitative data because its luminance isn't monotonic — it introduces perceptual boundaries that don't correspond to real jumps in the underlying value.

The data-ink ratio is the proportion of a graphic's ink that represents actual data, and Tufte's advice is to maximize it by erasing ink that isn't data and toning down data-ink that's more prominent than it needs to be. A 3D bevel on a bar chart, heavy dominant gridlines, and decorative shadows/textures are the textbook chartjunk examples — none of them encode a value, and the gridlines in particular actively compete with the bars for visual attention they should be supporting instead. Tick labels and a legend are not chartjunk: they're exactly the annotation a viewer needs to decode the data-ink correctly, so removing them wouldn't raise the ratio, it would just make the chart unreadable.

False. Pie charts encode value as angle and area, which people judge far less accurately than position or length — and that weakness compounds as slice count grows and slices approach similar sizes, since the visual differences between wedges shrink toward the limit of what the eye can distinguish. A bar chart encoding the same values as bar length along a shared baseline lets a viewer rank and compare eight-plus categories far more precisely, which is exactly why style guides at most data teams cap pie charts at a handful of slices with clearly different sizes, or avoid them entirely in favor of a sorted bar chart.

Bar charts work because length is read as proportional to value from a zero baseline — that's the entire visual contract. Truncating the axis away from zero keeps the numbers honest in the axis labels but makes the bars themselves lie: a 3% real difference renders as a dramatic visual gap, which is a textbook example of the kind of chart manipulation (deliberate or accidental) that erodes trust once a stakeholder notices the axis doesn't start at zero. Bars should start at zero; if the goal is to show fine variation in a narrow range, the right tool is a chart type where position rather than length-from-baseline carries the signal, or an axis break that's impossible to miss.

Pre-attentive processing is why a single red dot in a field of gray dots is found instantly regardless of how many gray dots surround it, while finding a specific number in a grid of numbers takes time proportional to how many numbers there are. Designers use this deliberately — highlighting an anomaly with color, or an important series with a heavier stroke — but the effect is exclusive: if every series on a chart is a different bright color, nothing is pre-attentively distinct anymore and the viewer is back to reading the legend one item at a time.

Small multiples repeat the same visual structure for different data slices, leveraging consistent scales so the viewer's eye can compare panels without re-learning the chart each time.

The Okabe-Ito palette (Okabe & Ito, 2008) defines exactly eight colors — orange, sky blue, bluish green, yellow, blue, vermillion, reddish purple, and black — chosen so each pair remains distinguishable under the most common color vision deficiencies.

Red-green confusion is the hallmark of the most prevalent color vision deficiencies (deuteranopia and protanopia). Colorblind-safe palettes therefore avoid red-green pairings and instead rely on hues that differ in luminance or fall along the blue-orange axis.

Cleveland and McGill's 1984 study ranked the elementary perceptual tasks people use to decode a chart, from most to least accurate: position along a common scale, then position along non-aligned scales, then length, then direction/angle, then area, then volume, then color shading and saturation near the bottom. Position along a shared baseline is at the top because judging where something falls on a ruler is close to exact; area and angle require the viewer to mentally compare non-linear quantities, which is measurably less accurate and gets worse as the number of items grows. That's the empirical reason a bar or dot chart beats a pie or bubble chart whenever precise comparison matters — it isn't taste, it's how accurately the human visual system decodes each channel.

The three real fixes all attack the actual problem, which is hue confusability: a palette specifically vetted for color-vision deficiency (a), a non-color backup channel so color is never load-bearing on its own (b), and avoiding the single most common confusable pair, red/green, as the two colors doing the distinguishing work (c). Cranking up saturation on an arbitrary palette doesn't change which hues are confusable to a deuteranope — it can make the problem worse by pushing colors further into the exact wavelength range that's hard to tell apart. A rainbow/jet colormap is a well-documented anti-pattern for a different but related reason: it isn't perceptually uniform, it creates false visual boundaries where the data has none, and it's especially bad for colorblind viewers because several of its bands collapse into similar-looking colors for them.

False. A log scale plots the logarithm of each value, and log(0) is undefined while the logarithm of a negative number isn't a real number, so any zero or negative point simply has nowhere to go on a plain log axis — most plotting libraries either drop it or throw. Handling data that legitimately includes zero or negative values means either shifting/offsetting the data before taking the log, using a symmetric-log ('symlog') scale that switches to linear near zero, or picking a different scale entirely. This trips people up in practice most often with metrics like profit/loss or year-over-year change, where a log axis looks attractive for the wide dynamic range but the series routinely crosses zero.

pyplot is a stateful wrapper: plt.plot(), plt.title(), and plt.legend() all act on whatever matplotlib currently considers the 'current figure' and 'current axes', and that state persists across loop iterations by design — it's what lets a notebook cell build up a chart across several plt calls. Because this loop never calls plt.figure() to open a new figure, or plt.clf()/plt.close() to clear the one it's reusing, every dataset's line gets added to the same growing figure, and plt.savefig() just renders whatever is currently on it — which is every series plotted so far, not just the current one. The fix is either plt.close() (or plt.clf()) at the top of each loop iteration, or switching to the object-oriented API (fig, ax = plt.subplots() per iteration) so each chart owns its own explicit figure instead of sharing pyplot's global state. Option (b) is independently wrong — an f-string genuinely produces a distinct filename per name, that part of the code works correctly.

Tufte defined the data-ink ratio as data-ink divided by the total ink used in a graphic, and argued good design pushes that ratio up by erasing ink that carries no data and toning down data-ink that's louder than necessary. It isn't a call to strip everything — labels, legends, and axis ticks are data-ink's supporting cast and stay — it specifically targets ink that adds visual weight without adding information: heavy gridlines competing with the marks, decorative borders, 3D bevels, background textures. The workplace payoff is direct: a dashboard with a lower data-ink ratio takes longer to read because the eye has to filter out the noise before it gets to the signal, which matters most exactly when someone's glancing at a chart in a stand-up or a live incident.

Each step narrows the previous one's decision, so reordering them breaks the logic: you can't pick a palette family before knowing whether the data is nominal, ordinal, or quantitative, because that's exactly what determines whether categorical, sequential, or diverging is even the right shape. You can't choose a specific palette before settling on the family, since ColorBrewer's schemes are organized by family for that reason. Simulating color-vision deficiency only makes sense once an actual palette has been chosen — there's nothing to test against beforehand — and adding a redundant non-color encoding is the last line of defense, reserved for whatever confusability the simulation step surfaces, since if the palette alone worked perfectly there'd be nothing left to compensate for.

Stacked bar charts, treemaps, and pie charts all encode a part-to-whole relationship: each segment's area or length represents its proportion of the total. Line charts encode trends over a continuous axis (typically time), and scatter plots encode the relationship between two independent continuous variables — neither shows composition of a single total.

Cleveland and McGill's 1984 experiments established the accuracy hierarchy of perceptual tasks. Position along a common scale (e.g., dot/line plots) is decoded most accurately, followed by length (bar charts), then angle (pie chart slices), then area (bubble charts), and finally color hue, which is perceptually ordinal-imprecise and ranked lowest for quantitative comparison. This ordering directly informs chart-selection best practices: prefer position-based encodings over area- or hue-based ones for quantitative data.

selection.data() splits the joined selection into three parts — enter (new data with no existing element), update (data still present), and exit (elements whose data disappeared) — and this code only ever handles enter and the merged enter+update. Nothing calls bars.exit().remove(), so a <rect> bound to an id that's no longer in data is simply left in the DOM forever; the next render adds new bars on top without ever clearing the stale ones, and after a few filter/render cycles the chart is silently drawing far more bars than the current dataset actually has. The one-line fix is adding bars.exit().remove(); right after the .data() call. Option (c) is a genuine misconception worth naming: .merge() is required precisely because attribute updates chained after .enter().append() only apply to the newly-entered elements — without merging in the update selection, existing bars would stop getting repositioned on every re-render, a separate and equally real D3 bug.

While stacked bars do show part-to-whole composition and overall totals, they are inferior to grouped bars for the specific task of comparing individual subcategory values across primary categories. Only the bottom segment of a stacked bar shares a common baseline; all higher segments are offset by the variable height of the segments below them, making it difficult to judge or compare their magnitudes visually. Grouped bars place every subcategory on the same axis baseline, enabling direct, accurate comparison at the cost of not showing totals — but for the stated task (comparing subcategory values), grouped bars are the better choice.

With n=7 and max_cols=3: cols = min(7,3) = 3. rows = (7+3-1)//3 = 9//3 = 3. Since rows > 1, last_row_count = 7 − (3−1)*3 = 7 − 6 = 1, so the last row holds only one panel. empty_last_row = 3 − 1 = 2. The tuple returned is (3, 3, 2).

n_groups=12 is not > 20 and not <= 1, so we skip the first two branches. n_points_per_group=50 is not > 1000, so we skip the density/heatmap branch. We reach the final return: has_time_axis is True, so the ternary selects "small_multiples_line". This reflects the design rationale: with a moderate number of groups (≤20), a manageable point count per group (≤1000), and a temporal axis intended for cross-group comparison, small-multiples line charts are the recommended encoding.

Each step depends on the one before it, which is what makes this a genuine pipeline rather than a set of independent actions. You can't bind data to elements you haven't selected yet, so select comes first. .data() needs to run before .join() because join reads the enter/update/exit split that .data() just computed — calling join first would have nothing to act on. .join() has to happen before the attribute updates because those updates are applied to the selection join() returns (the merged enter+update set); applying attrs to the pre-join selection would miss the newly entered elements entirely. And the browser can only paint the attributes that have actually been set on the DOM, so that's last by definition. This ordering is also exactly why .join() replaced the older explicit enter()/exit()/merge() pattern — it collapses steps two and three of the old five-step version into one call while preserving this same dependency chain.

The core perceptual limitation is baseline alignment: in a stacked bar, only the first segment sits on the axis baseline; every higher segment's length must be inferred from two floating boundaries, which the human visual system does poorly—particularly with 7 segments and 12 bars. Small multiples (faceted bar charts, one per category) give every sub-source a shared zero baseline within its panel, solving composition comparison, while sorting panels by total preserves total-magnitude comparison.