An ordering step is given region ascending and amount descending — what does each key govern in the result?
answer
- priority, then direction
- later keys only break earlier ties
- one direction per key
- reversing the result flips every key
basics
~20 sRegion sets the overall order and groups the rows into blocks; amount only arranges rows inside a block where the region is equal. Each key carries its own direction, so mixing ascending and descending in one step is normal.
solid answer
~50 sAn ordering step — the operation that puts rows into an order you specify, taking one or more keys each with its own direction — reads its keys in priority order. Region ascending decides the whole result and collects the rows into per-region blocks. Amount descending is consulted only where the region is equal, so it arranges rows inside a block and can never move a row out of one. The two directions are independent of each other. Reversing the finished result is a different operation: it flips every key at once, so the regions would come back in the opposite order too. Designs differ in how the direction is expressed — some take one direction per key, some take a single direction for the whole step and expect the key you want reversed to be wrapped or negated — so write the direction against the key it belongs to.
code
pseudocode · 8 lines# keys are read left to right; each carries its own direction
ordered = ORDER_ROWS(table, keys = [ (region, ASCENDING),
(amount, DESCENDING) ])
# NOT the same output: reversal flips the region key as well
reversed_all = REVERSE(
ORDER_ROWS(table, keys = [ (region, ASCENDING),
(amount, ASCENDING) ]))go deeper
Recall that an ordering step takes keys in priority order and that each key can run ascending or descending on its own. Be able to say in one sentence what the second key does and what it cannot do.
Explain that a later key is consulted only where the earlier keys compare equal, and that reversing the finished result is a different operation because it inverts every key rather than the last one.
Show that you write directions against their keys in shared code. A step that takes one direction for everything and a step that takes a direction per key read almost identically at the call site, and the difference only shows once a second key exists.
The angle is portability and review: a descending key expressed as a reversal of the result is a latent defect that fires when somebody adds a key, so the standard worth setting is that direction is always written next to the key it governs.
## What the step is actually given An **ordering step** is the operation that puts a table's rows into an order you specify. What you hand it is not a single instruction but two things at once: a **list of ordering keys in priority order**, and **a direction attached to each key**. "Region ascending, then amount descending" is two keys and two directions, and the whole result follows from reading that list left to right. This matters because the two halves of the specification are independent. Priority decides *which* key gets consulted *when*; direction decides which way each one runs. Candidates who collapse the two — who think of the step as having one order that the keys somehow contribute to — get the everyday cases right and the interesting ones wrong. ## Priority: a later key is finer, not stronger Keys are consulted in the order given, and a later key is looked at **only where every earlier key compares equal**. - The first key partitions the output into blocks. All the rows of one region end up adjacent, and the blocks themselves run in ascending region order. - The second key arranges rows **inside** a block. It cannot lift a row out of its block, however large its amount is: the largest amount in the alphabetically last region still appears at the bottom of the listing. - A third key would arrange rows where region *and* amount are both equal, and so on down the list. - If the first key happens to be unique across the table, no later key is ever consulted, and adding one changes nothing about the output. Said out loud: **the last key is the finest distinction, not the most powerful one.** ## Direction belongs to the key, not to the finished result The direction you attach to a key applies to that key alone. This is where the most common wrong answer lives — producing a descending key by ordering everything ascending and then reversing the result end to end. | What you ask for | Region comes back | Amount within a region | |---|---|---| | region ascending, amount descending | A to Z | high to low | | region ascending, amount ascending | A to Z | low to high | | region ascending, amount ascending, then the result reversed | Z to A | high to low | The third line is the trap. Reversal acts on the finished sequence and knows nothing about keys, so it inverts the primary ordering along with everything else. The two forms agree only in the degenerate case of a single ordering key. ## Designs disagree about how you say it, not about what it means The meaning above is common across tools in this space. The expression is not: - Some designs accept a direction per key directly — as a parallel list of directions, or as a pair per key. - Some take a single direction for the whole step and expect the key you want running the other way to be wrapped in something that reverses it, or negated if it is numeric. - Some let an ordering key be an expression rather than a stored column, which makes a derived key cheap to introduce. - Some treat the key list as ordered and some make the ordering explicit in the call shape, but none of them consult a later key before an earlier one. So "can I mix directions in one step?" has the same answer everywhere — yes — while "how do I write it?" does not. Answer the mechanism, then say the expression varies. ## What to write 1. **Name the keys in priority order and attach each direction where the key is named.** A reader should not have to look elsewhere to find out which way a key runs. 2. **Never produce a descending key by reversing the finished result.** It works while there is one key and silently corrupts the output the day somebody adds a second. 3. **When the order you need is not the natural order of the values** — a business priority, a severity ladder, a custom calendar — derive a key that compares in that order and use the derived key, keeping the original column for display. A derived key is an ordinary comparison, so every design agrees about it. One last distinction worth having ready: the order the rows arrived in, the order this step imposed, and the order the row labels happen to be in are three different things. An ordering step constrains only the second. When a later step depends on ordering, say which of the three it depends on.
- Why is reversing the finished ordered result not the same as ordering by the last key descending?Reversal walks the finished sequence backwards, so every key's direction inverts at once, including the first. Ordering by the last key descending leaves the earlier keys running the way you asked and changes only the arrangement inside each block of equal earlier keys. The two agree only when there is exactly one key.
- The regions must appear in a business priority order, not alphabetically. How do you express that as an ordering key?Derive a key that compares in the order you want — map each region to its rank in the priority list — and order on the derived value while keeping the original column for display. Because the derived key is an ordinary comparison, the result is identical under any design, which a tool-specific custom-order facility would not be.
saying these in an interview costs you the question
- Thinks one direction applies to every ordering key at once.
- Believes a later key can move a row out of its first-key block.
- Reverses the whole ordered result to get one key descending.
- Treats the key list as unordered, so priority does not matter.
- Assumes every design lets you attach a direction per key.