Data Visualization — Interview Q&A

Q: How do you decide which chart type to use for a given dataset?

A: Start from the actual question being asked, not the data itself — a trend-over-time question needs a line chart, a category comparison needs a bar chart, a correlation question needs a scatter plot, a part-of-whole breakdown with few categories can use a pie chart. Picking a chart type because it "looks good" rather than because it directly answers the intended question is a common mistake — a pie chart with a dozen thin slices technically shows part-of-whole data, but a sorted bar chart communicates the same comparison far more clearly, since human perception is measurably better at comparing bar lengths than pie-slice angles.

Q: Why should a bar chart's y-axis always start at zero, but a line chart is more forgiving of that rule?

A: A bar chart encodes its value through the bar's length — and length only reads correctly, proportionally, when the axis starts at zero; truncating the axis makes a small real difference look dramatically larger than it is, even though the underlying numbers are unchanged. A line chart primarily encodes trend through slope and relative position rather than the absolute length of a filled bar, so a non-zero baseline distorts it less severely — though even there, it's worth being deliberate about, since a truncated axis can still exaggerate the visual magnitude of change.

Q: What's the practical difference between choosing color hue versus color saturation for encoding data, and why does the distinction matter?

A: Hue (distinct colors) should encode categorical data — different groups with no inherent order, capped at around 8 distinct colors before they become hard to reliably tell apart. Saturation or intensity of a single hue should encode continuous data — a heatmap where darker blue means a higher value is intuitively ordered in a way that switching between unrelated hues wouldn't be. Using multiple unrelated hues for what's actually a continuous variable falsely implies discrete categories rather than a smooth range, which is a genuinely common, avoidable mistake.

Q: A stakeholder says a chart you built is "confusing" — how do you diagnose what's actually wrong with it, rather than just guessing at a fix?

A: Check for the most common specific causes rather than redesigning blindly: is the chart trying to encode too many dimensions at once (color, size, shape, and position all doing different jobs simultaneously — viewers can reliably track roughly two encoded dimensions, not five); is the chart type actually mismatched to the underlying question; or is there a real pattern present that isn't annotated, leaving the viewer to notice and interpret it themselves without the context the chart creator already has. Each of those has a different, specific fix — reducing dimensions via small multiples, picking a chart type driven by the actual question, or adding direct annotation — rather than generically "making the chart nicer."

Q: Why would you choose small multiples over a single chart with more dimensions/categories crammed in?

A: Small multiples repeat the same simple chart across a grid, one panel per category, rather than trying to show every category in one chart with many competing colors or overlapping series. Once a single chart's dimensionality genuinely overwhelms a viewer — six overlapping trend lines in six colors that are hard to individually trace, for instance — several small, simple, identical charts side by side let a viewer compare shape and pattern across panels almost as easily as reading text, which is very often the better tradeoff than one increasingly complex chart trying to do everything at once.

Q: How would you visualize a forecast or any inherently uncertain estimate, and why does a single confident-looking line risk being misleading?

A: Pairing the point estimate with a confidence interval band (or error bars) shows the actual precision of the data honestly — a single line implies a value known with certainty, which is actively misleading for a forecast where near-term predictions are meaningfully more certain than further-out ones. Showing only the point estimate, with no visual indication of the underlying uncertainty, is a common simplification that overstates confidence in a way that can lead a stakeholder to over-trust a specific number the underlying model itself wouldn't claim that much certainty about.

Q: How do you approach rendering a scatter plot with millions of points, when a normal scatter call becomes slow and visually unreadable?

A: Naive point-per-point rendering is architecturally the wrong approach past a certain scale — it's both slow to render and visually meaningless once points overlap so heavily that individual points aren't distinguishable anyway. The right fix is a density-aggregation approach (Datashader or similar) that bins the data into a fixed-resolution pixel grid and renders density directly, conceptually similar to a dynamically-computed heatmap — this is a different rendering technique, not just a performance optimization on top of the same naive approach, and recognizing that distinction early avoids spending time tuning transparency/point-size parameters on a fundamentally mismatched rendering strategy.