skip to content

A labelled table is converted to a rectangle addressed only by position — what now carries each field's meaning, and what silently breaks it?

level: juniorimportance: should knowfreq 56%

answer

  1. the names do not cross
  2. meaning moves into the ordering
  3. position 2 is price by convention only
  4. an added field re-points every position
  5. name the fields at the conversion

basics

~20 s

Column order becomes the meaning: after the conversion each field is identified only by its position in the rectangle. Any upstream change to field order or count silently re-points every downstream reader at the wrong values.

solid answer

~50 s

A labelled table is a rectangle whose columns are named and typed one at a time; a uniform-type rectangle is one buffer of a single representation, addressed only by position, with no column names and no row identity. The conversion to an unlabelled rectangle throws both away, so the sentence `price times quantity` becomes `position 2 times position 4`. The fact that position 2 is the price now lives nowhere in the data — only in the head of whoever wrote the line, and in whatever ordering the conversion happened to produce that day. Insert a field upstream, reorder a selection, or let a source start emitting an extra column, and the arithmetic still runs and still returns numbers of the right kind; they are just the wrong ones. If you cross that boundary, name the fields explicitly at the conversion rather than trusting the ordering you got.

code

pseudocode · 10 lines
pseudocode
# before the conversion: the name carries the meaning
total = table.field("price") * table.field("quantity")

# after the conversion: the ordering carries the meaning
rect  = convert_to_positional_rectangle(table)
total = rect[every_row, 2] * rect[every_row, 4]

# nothing in rect records that 2 was price and 4 was quantity;
# one field inserted upstream re-points both of them, and the
# multiplication still succeeds

go deeper

for a junior

Recall the plain fact: the conversion keeps the values and drops the names and the row identity, so afterwards a field is only a number. Be able to say which line of your code would now be wrong if somebody added a column upstream.

for a middle

Explain why the failure is quiet: with no names there is nothing to mismatch, so the wrong pair of fields multiplies cleanly. Be able to name which upstream changes shift positions and which single case actually raises.

for a senior

Show the habit, not just the awareness. Convert an explicit ordered field list rather than the table, keep the rectangle inside the routine that needs it, and be able to point at where in your code the positional contract is recorded.

for a principal

Frame it as a contract that moved out of the data and into the codebase's memory. The question for a lead is how many places hold that contract and whether that number is known — not whether any single conversion is defensible.

## Two holdings, and the line where you choose between them A **labelled table** is a rectangle whose columns are named and typed one at a time, and whose rows may or may not carry an identity of their own. A **uniform-type rectangle** is one buffer of a single representation, addressed only by position: no column names, no row identity. The choice between the two is almost never made as an abstract preference. It is made at one line — the conversion that discards the names and the row identity and hands back a rectangle — and every line after it inherits the result. One of those inherited results is the subject here: **after the conversion, the ordering of the fields is the meaning of the data.** ## What the two sides of the line look like Before the conversion, an expression names what it computes. The line that multiplies a price by a quantity contains the words `price` and `quantity`, and if a source stops producing a field of that name, the lookup fails and somebody finds out on the spot. After the conversion, the same arithmetic is written over positions. Nothing left in the data records which position was the price. That fact now lives in exactly two places, neither of them checkable by the program: in the memory of whoever wrote the line, and in whatever ordering the conversion happened to produce on the day it was written. ## Why the failure is quiet The reason this is worth an interview question is that the two holdings fail on opposite events, and the positional one mostly fails without saying anything: | change made upstream | labelled table | positional rectangle | | --- | --- | --- | | a field is renamed | the lookup fails immediately | nothing changes; positions are untouched | | a field is inserted before the ones used | the lookup still finds them | every later position shifts by one | | two fields swap ordering | the lookup still finds them | the arithmetic pairs the wrong values | | a field is removed | the lookup fails immediately | positions shift, or an index runs off the end | The one case where the positional holding reliably raises is the last row, and only when the position being read is past the rectangle's new width. Everywhere else the program keeps running and returns numbers of the right kind, in the right quantity, computed over the wrong pair of fields. Nothing in the rectangle knows enough to object, because objecting needs a name to compare against, and the names are what the conversion threw away. ## The defences people offer, and why they do not hold - **A comment above the line.** A comment is not read by the program and is not updated by the person who adds a field three modules away. - **"The source is stable."** Field ordering in a source is a property nobody promised. It moves when a query gains a column, when a selection is reordered for readability, when the reading step's handling of the input changes. - **"It is only a few lines."** The positional contract is not held by the lines doing the arithmetic. It is held by every caller that produces the table those lines convert. - **"We would catch it in review."** Reordering is the one change that produces no diff at the point of use. The diff is upstream and looks harmless there. ## What to require instead 1. **Convert an explicit list of fields, not the table.** Name the fields you want, in the order you want them, at the conversion itself. A field added upstream then cannot join the rectangle by accident, and a reordering upstream cannot change what position 2 means. 2. **Keep the ordering beside the rectangle.** If the rectangle travels at all, carry the ordered list of names with it so that whatever receives it can check rather than assume. 3. **Do not let it travel far.** Convert as close as possible to the code that genuinely needs a positional holding, and turn the result back into named output in the same place. ## The judgment underneath None of this says the conversion is wrong. There are good reasons to cross the line: a routine that only accepts a rectangle, uniform numeric work where names carry no weight, a hot path where a second coordinate system is dead weight. What the conversion asks in exchange is that you accept a contract expressed as ordering — and a contract expressed as ordering has to be written down by you, because the data has stopped writing it down for you. The candidate who can say that has understood the trade. The one who says "we just take the values out" has not noticed there was one.

  • Why does reordering fields upstream produce wrong numbers rather than an error?
    Because there is nothing left to mismatch. The rectangle has no names, so every position within its width is a legal position and arithmetic over any pair of them succeeds. The only upstream change that reliably raises is one that shrinks the rectangle past a position the code reads.
  • The conversion produced the field ordering you expected today. What would you record so a later run can tell?
    The ordered list of field names you converted, written at the conversion site rather than inferred from the table. Passing that list in — instead of taking whatever the table offers — makes the expectation part of the code, so an upstream change either matches it or fails there rather than three steps downstream.

A packing list names what is in each crate. Strip the list and you have numbered crates: crate 3 is the fragile one because everyone remembers it is. Add one crate at the front and every number after it points at the wrong contents, and the truck leaves anyway.

saying these in an interview costs you the question

  • Says the names are still there, hidden somewhere inside the rectangle.
  • Assumes field ordering is stable because the source has never changed it.
  • Treats a positional rectangle as interchangeable with the table it came from.
  • Expects an added upstream field to raise rather than shift every position.
  • Claims a comment naming each position is as good as passing the field list.