A dbt model selects from analytics.stg_orders by full table name instead of ref() — what breaks?

## Why this is a senior question Everyone can recite "use `ref()`." The interview question is what actually goes wrong, in what order, and how you would find it in a project that already has the problem. The answer is interesting because the failures are staggered: one is intermittent, one is silent, one only bites during a refactor, and one disables the very safety net that would have caught the others. ## Failure 1 — non-deterministic build order dbt derives execution order from `ref()` and `source()` edges and runs independent branches concurrently, up to the configured thread count. A model whose only reference to its input is a literal string has **no incoming edge**, so from dbt's point of view it is a root node with no prerequisites. It may be scheduled first. The consequence is not a crash. The relation exists — it holds yesterday's data, or, on a warehouse where a rebuild is not atomic, a partially populated state. The run reports success and the mart is quietly stale. Change the thread count, add an unrelated model, and the ordering shifts; the symptom appears and disappears. Teams often chase this for weeks because a rerun "fixes" it. ## Failure 2 — every environment reads production `ref()` resolves per target; a literal does not. So a developer running against a personal schema builds *their* model from *production* `stg_orders`. That is bad in three directions: - Local changes to `stg_orders` are never exercised downstream, so a breaking change looks fine. - CI builds into a throwaway schema but reads production inputs, meaning the pull request is not actually tested against the version of the code it changes. - If anyone ever grants write-shaped access, a dev run can touch a production relation. The schema also becomes a deployment-time landmine: renaming or moving a schema requires finding every literal by hand, and a missed one fails at run time rather than at parse time. ## Failure 3 — lineage and documentation lie The generated documentation renders the graph from the manifest, which is assembled from references. A missing edge means the docs show a model with no parents and show `stg_orders` with one fewer child. Consumers doing impact analysis before a change — "who reads this column?" — get a confidently wrong answer. This is the failure that turns a routine refactor into an outage, because the person deleting a column checked the lineage graph and it told them nobody was downstream. ## Failure 4 — the safety nets are disabled Selection operators traverse the same graph: - `dbt build --select stg_orders+` after changing staging will **not** include this model, so its tests do not run. - A slim CI job using `state:modified+` will not rebuild it when its upstream changes. - A blast-radius query before a deprecation will not list it. So the exact automation you built to catch the first three failures skips the one model that has them. ## Finding the problem in an existing project - **Grep the model files** for schema-qualified patterns and for known schema names; hard-coded references are textually obvious once you look. - **Read the docs DAG** for models with no parents that clearly should have some — a mart with zero ancestors is a strong signal. - **Compare the compiled SQL** in `target/compiled/` against the graph: a relation appearing in the SQL that is not among the node's dependencies is the smoking gun. - **Add a CI lint step** that fails the build when a model file contains a schema-qualified identifier, with an allowlist for the rare legitimate case. Project-linting packages exist that codify checks of this kind; a ten-line grep in CI covers most of it. ## Fixing it safely Replacing the literal with `ref()` (or `source()` if the table is raw and outside the project) is a one-line change, but it changes the graph, so re-run with `--select +the_model` to confirm the ancestry now materialises, and check the compiled SQL resolves to the expected schema in dev. Where the referenced table genuinely is external — a table another team owns, not built by this project — the correct fix is a **source** declaration, not a literal: you get the edge, the lineage anchor and freshness checking, and the schema stays configurable in YAML. ## What a weak answer sounds like "It's not best practice" or "it won't be portable." Neither names a failure. The strong answer leads with the intermittent staleness — because that is the one that costs a business real money before anyone notices — and then explains why the tooling that should have caught it was blind by construction.