An interviewer says - our nightly load used to finish at 05:00 and now finishes at 08:30. The business has asked for hourly figures by the end of the quarter. There are 1100 tasks in the orchestrator and three engineers on the team. Where do you take this?

What the interviewer is testing

Whether you measure before you re-architect, and whether you can tell a capacity problem from a dependency problem. The 1100 tasks are a distraction; a nightly window is governed by its longest chain of dependent tasks, and that chain is usually a dozen of them. The second thing being tested is whether you treat "hourly" as a requirement to negotiate rather than a target to hit.

The clarifying questions that change the answer

• What is the critical path, in minutes? If the longest dependent chain is 3 hours of the 8.5, the problem is concurrency and the fix is pool sizing. If it is 7 hours, no amount of parallelism helps and the chain itself must be shortened.
• Did it get slower or start later? A feed arriving at 03:00 instead of 01:00 is an upstream conversation, not an engineering project, and the sensor waiting on it is probably holding worker slots.
• Who needs hourly, for which tables, and to make which decision? In most estates the honest answer is a handful of tables.
• What is the cost of being stale versus wrong? It decides what happens when the window closes.
• Is anything in the chain a full refresh that could be incremental? One full rebuild of a large model is the single commonest cause of this drift.

A strong answer's arc

Instrument the graph: per-task duration trend over 90 days, the critical path, and queue time against run time. Queue time means capacity; run time growth on one task means that task. Then act in order: shorten the critical path (incrementalise the full refreshes, split the one large MERGE, move the late feed's dependents off the chain), then widen concurrency, then re-time.

For the hourly ask, do not run a 1100-task graph 24 times a day. Tier freshness. Identify the tables with a real hourly need, give them a short dedicated path from source to a serving table - usually 20 to 60 tasks - and leave the rest nightly. The intraday path gets its own compute so it cannot queue behind the nightly load.

Then make the behaviour at the deadline explicit. When a feed is late, publish partial data with an as-of timestamp the dashboard displays, rather than blocking the dashboard or serving stale numbers silently. A visibly late number is recoverable; an invisibly stale one is the incident.

Common weak answers

• "Add workers." Does nothing to a serial chain, and it is the first thing a weak answer reaches for. Workers help queue time only.
• "Move to streaming." Replaces a sizing problem with a new failure class and a skill the three-person team does not have.
• "Run the DAG hourly." Multiplies 1100 tasks by 24 runs, and the on-call load with it.

What a strong answer adds

The organisational layer: a published freshness SLA per table, so the next request is a negotiation against a number; a quarterly prune of models with no consumers, because that is the cheapest reduction in build time and nobody owns it; and the observation that three engineers set the upper bound on how many distinct pipelines can exist - the design has to fit the team, not just the window.