skip to content

After two name columns produced two-part column headers, you take the block of columns under one outer name — what do the returned labels carry?

level: middleimportance: should knowfreq 38%

answer

  1. the selection worked; the labels surprised you
  2. one part removed, or one part constant
  3. the trailing name repeats under every outer name
  4. check the labels before the next step

basics

~20 s

It varies by design: some hand back single-part labels with the part you selected on removed, others keep both parts with that part now constant. Assuming the first is where code breaks, because a lookup by a plain name then matches nothing.

solid answer

~50 s

The selection itself is unsurprising — you get the columns sitting under that one name. The residue is what catches people. Some designs remove the part you addressed and return labels with one part left; others keep the full pair and simply hold that part constant, so the label space still says two parts even though one of them now has a single value. A step written for plain names then fails on a name it cannot find, one step after the cause, and the header often *displays* as if it were already single-part. Two related traps: the trailing name alone never identified a column while the pair was intact, because it repeats under every outer name; and where labels are flat strings the equivalent move is a text match, which sweeps in any name starting with the same text.

go deeper

for a junior

Know that taking the columns under one header name gives you that block, and that you should look at what the resulting labels are called before using them.

for a middle

Explain the two possible residues — the selected part removed, or kept and now constant — and why a trailing name alone does not identify a column while the pair is intact.

for a senior

Diagnose the one-step-later failure: the selection succeeded, the label space did not change the way the next step assumed, and no count or shape check could have seen it.

for a principal

Make the hand-off a rule rather than a habit: reshaping steps publish labels of a stated shape, and the names are asserted at that boundary so no consumer has to guess.

## What the selection gives you After a widening — turning one column's distinct values into new headers, filled from a second column — driven by two name columns, each column is identified by a pair of names. Asking for "everything under `revenue`" is a perfectly ordinary thing to do, and in a structured label space, where each part of a label can be addressed, it is a supported operation. You get back the block of columns whose leading part is `revenue`. The interesting question is what those columns are **called** afterwards, and this is where designs diverge. ## The residue - Some designs **remove the part you selected on**. The result's labels have one part each — the region names — and the table behaves like an ordinary single-part table from then on. - Others **keep both parts**, with the part you selected on now holding a single constant value. The label space still says every label is a pair. Nothing about the printed header row necessarily shows this. Both are defensible. The first is convenient; the second is consistent, because a selection that filters columns has no obvious right to change what a label *is*. The defect is not either behaviour — it is assuming one of them. The failure it produces has a recognisable signature: 1. The selection succeeds and the header row looks like plain names. 2. A later step looks a column up by one plain name, compares the header row against a list of expected names, or hands the table to code written for single-part labels. 3. That step fails on a name it "can see", or quietly matches nothing and produces an empty result. The cause is one step upstream of the symptom, which is why the first move is always to print the labels the selection actually returned and count the parts in one of them. ## Why the trailing name is not an identifier While the pair is intact, the trailing name does **not** identify one column. The same measure name sits under every outer name, so an address that mentions only the trailing name is ambiguous, and what happens depends on the design: | you address | structured labels | flat string labels | |---|---|---| | the full pair | one column, unambiguously | one exact name, unambiguously | | the leading part only | the block under it | every name starting with that text, plus any accidental matches | | the trailing part only | needs you to say which part you mean, or matches several columns | every name containing that text, wherever it occurs | This is why a selection that "worked yesterday" can return two columns today: a new outer name arrived in the data, and a trailing-name address that used to be unique no longer is. ## The flat-string equivalent, and how it fails differently Where labels are a flat list of strings, there is no part to address, and the equivalent of taking a block is a text match over names. It fails in its own way: - a name that merely **starts with** the same text is swept in — asking for `rev` also takes `revenue_plan`; - if any part can contain the separator, the boundary between the parts is ambiguous, so even an exact-looking match can take the wrong columns; - the selection is wrong by **extra columns** rather than by unexpected structure, which a row-count check cannot see either. The two worlds therefore fail in opposite directions: structured labels surprise you with residual structure, flat labels surprise you with over-matching. ## Discipline at the boundary The habit that removes the whole class of bug is to make the label space explicit at the point you leave the reshaping step, rather than letting the next step discover it: 1. After a partial selection, **look at the labels**: how many parts does one of them have? 2. Reduce to one part **deliberately** — remove the now-constant part where the tool supports it, or compose the remaining parts into names you chose. 3. **Assert the resulting names** against the list you expect before handing the table on. This is cheap and catches both the residual-part case and the over-matching case. 4. When you address a column, name enough of the label to be unambiguous. A full pair is unambiguous; a trailing name alone is not, and stops being unique the moment a new outer name appears in the data.

  • The next step fails on a name it cannot find, right after a partial selection. What do you look at first?
    The labels the selection actually returned, and how many parts one of them has. The usual cause is that the label space still carries two parts with one now constant, so a lookup by a single plain name matches nothing — even though the header row displays as though it were already single-part.
  • Why can the same trailing-name selection return one column one month and two the next?
    Because the headers came from data values. A trailing name is unique only while it appears under a single outer name; when a new outer name arrives in the input, the same address matches under both. The fix is to address the full pair, or to assert the expected column count after the selection.

saying these in an interview costs you the question

  • Assumes a partial selection always leaves plain one-part names behind
  • Thinks a header that displays on one line has only one part
  • Believes the trailing name is unique across the whole table
  • Treats a text match over composed names as the same operation as addressing a part
  • Blames the failing step instead of checking what the selection returned