skip to content

A column of scores is glued beside a 1,000-row customer table and the scores land on the wrong customers - why?

level: seniorimportance: should knowfreq 47%

answer

  1. it pairs, it does not match
  2. position or labels, never the record
  3. a sort on one side breaks it
  4. right row count, wrong values
  5. carry the identifier and match on it

basics

~20 s

Because gluing side by side never compares a customer to a customer. It pairs rows by position, or by the row labels the tool carries, and both were fixed by whatever earlier step produced each side. Once one side was sorted or filtered independently, the pairing was wrong and nothing could say so.

solid answer

~50 s

A side-by-side glue adds attributes; it does not match records. It pairs the two sides on something you did not state: **position**, in tools that carry no per-row identifier, or the **row labels** each side happens to carry, in tools that do. Positional pairing trusts the current order of both sides, so any sort, filter, or re-derivation applied to one and not the other silently shifts the correspondence. Label pairing looks safer but has its own tell: labels present on only one side become extra rows with holes, so the result can be longer than either input. Either way, the customer number was never compared to a customer number. The reliable fix is to keep the identifying column with the scores and match the two tables on it, so the pairing is written down rather than inherited.

go deeper

for a junior

Remember that gluing side by side does not look at what is in the rows. It lines them up by position or by their labels, so if anything re-ordered one side, the values end up beside the wrong records.

for a middle

Explain both pairing rules and what each one costs: positional pairing trusts an order nobody stated, label pairing can change the row count by bringing through labels found on only one side. Say which one your tool uses before you rely on it.

for a senior

Diagnose it: equal row counts prove nothing under positional pairing, so verify by content on an identifying value, trace which step re-ordered or filtered one side, and replace the glue with a match on the identifying column.

for a principal

The question worth raising is where a pipeline keeps its row correspondence. Pairing by position makes every earlier ordering step load-bearing and invisible; insisting that derived values carry their key costs a little width and makes the correspondence something a reviewer can see.

## What the operation actually pairs on Gluing side by side means putting two tables next to each other so that each output row is one row of each, and the result is wider. The whole content of the operation is the correspondence between the two sides' rows - and that correspondence is **not** derived from the data. Nothing in the call reads a customer number on the left and looks for it on the right. The tool uses one of two rules, and which one it uses is a property of the tool. **Positional pairing.** In designs where rows have positions only, the glue is a zip: row one with row one, row two with row two, and the only check is that the two lengths agree - some tools refuse on a mismatch, others pad. The correspondence is therefore whatever the current order of each side happens to be, and neither side's order is part of its identity. **Label pairing.** In designs where each row carries an identifier beside the columns, the glue lines the two identifier sets up first. Rows whose label appears on both sides pair. Rows whose label appears on only one side still come through, with holes where the other side had nothing. That is why two tables of 1,000 rows each can come back as 1,700. ## How the scores ended up on the wrong customers The scores were derived from the customers, so at the moment they were computed the correspondence was real. Something then broke it before the glue ran. The usual culprits: - The customer table was **put into an order** after the scores were computed, or the scores were computed from an ordered copy and glued back onto the unordered original. - One side was **filtered** - a handful of customers dropped - so from that point on position *n* means two different customers. - The scores came from a **separate pass** over a source that returns rows in an order nobody promised. - The two sides carry labels, and one side's labels were **discarded or renumbered** by an intermediate step, so the pairing fell back to something else. Notice what all four have in common: none of them is an error. Each is an ordinary, reasonable step, and the glue has no way to know that it invalidated an assumption made two steps earlier. ## The two failure signatures | | Positional pairing | Label pairing | |---|---|---| | What is trusted | the current row order of both sides | the labels both sides carry | | Row count of the result | preserved, or the call is refused on a length mismatch | can grow: labels on one side only come through with holes | | What a wrong pairing looks like | right count, wrong values, no holes | extra rows and unexpected holes | | Broken by | a sort or a filter on one side only | labels discarded, renumbered, or repeated by an earlier step | | Caught by | spot-checking an identifying value on both sides | comparing the result's row count against the inputs' | The positional signature is the nastier of the two, because the count is exactly what you predicted and the table looks perfect. The only instrument is content: pick a handful of rows, and confirm that the identifying value and the score are the pair you expect. ## The reliable fix Carry the identifier with the values and **match the two tables on that column**. Matching compares a value on each side, so the pairing is stated in the code and survives any re-ordering or filtering of either input. It also makes failure visible: a record with no partner shows up as an unpartnered row rather than as a plausible wrong number. That means resisting the shortcut of computing a block of values and setting it down next to the table it came from. If the values are worth keeping, they are worth carrying their key. ## When you genuinely cannot Sometimes there is no identifier - the second block came from an external computation that returned values only. Then: 1. **Do the derivation and the glue in one step**, with nothing between them that could re-order or filter either side. 2. **Fix the order explicitly** on both sides immediately before the glue, on a column combination you know is unique, so the correspondence is at least reproducible rather than inherited. 3. **Check content, not shape.** Compare the row counts, then spot-check several rows by an identifying value, and include a row near the end where a one-row shift is easiest to see. 4. **Decide what the pairing rule is** rather than discovering it. If your tool pairs on labels and you want positional pairing, discard the labels deliberately; if it pairs positionally and you want identity, you are back to matching on a key. A candidate who says "I would not glue them side by side at all, I would match on the customer number" has given the best answer available, and the rest of this is what to say when they are asked why.

  • The row count after a side-by-side glue is exactly what you expected. What does that prove?
    Very little. In a positional pairing the count is preserved by construction, so it is the same whether the correspondence is right or wrong. It only carries information in a label-pairing design, where an unexpected count means unshared labels produced extra rows. Confirming the pairing needs content: an identifying value checked on both sides.
  • Is sorting both sides the same way before gluing an acceptable substitute for matching on a key?
    It is better than nothing and still fragile. It fails if the sort columns are not unique, because the order within a tie is unspecified; it fails if the two sides do not hold exactly the same records; and it re-breaks the moment someone inserts a step between the sort and the glue. Matching on a key has none of these failure modes.
  • Why can a side-by-side glue of two 1,000-row tables return more than 1,000 rows?
    Because in tools that carry an identifier for each row the glue aligns the two identifier sets before pairing, and a label found on only one side still produces an output row, with holes where the other side had nothing. The result is the union of the two label sets, which can be far larger than either input.

saying these in an interview costs you the question

  • Assumes a side-by-side glue matches records rather than pairing them.
  • Trusts that two separately derived tables kept the same row order.
  • Treats an equal row count as proof the pairing was right.
  • Believes carrying row labels makes a side-by-side glue safe automatically.
  • Sorts both sides and calls the correspondence verified.
  • Reaches for the glue when both sides carry the same identifying column.