Your Data Warehouse Is a Graveyard of Untrusted SQL Scripts. dbt Was Supposed to Fix That.
dbt (Data Build Tool) has revolutionized the world of analytics engineering. It brings the discipline of software engineering—version control, testing, documentation, and CI/CD—to the often chaotic world of data transformation. It promises to turn your data warehouse from a black box of fragile, interdependent SQL scripts into a clean, well-documented, and reliable data factory.
But this promise is only fulfilled when dbt is used by engineers who have truly internalized this software engineering mindset. In the hands of a data analyst who has only ever written ad-hoc queries, dbt does not create a reliable data platform. It creates a more organized and automated version of the same chaos: a sprawling DAG of undocumented, untested, and unmaintainable models. You get a CI/CD pipeline that runs `dbt run` on a collection of buggy SQL.
An engineer who knows how to use a `ref()` function is not a dbt expert. An expert can design a modular project structure that scales to hundreds of models. They can write generic data tests to enforce quality across the entire warehouse. They can optimize model materializations for performance and cost. They treat their dbt project as a critical software product, not as a folder of SQL files. This playbook explains how Axiom Cortex finds these true analytics engineers.
Traditional Vetting and Vendor Limitations
A nearshore vendor sees "dbt" on a résumé, often next to "SQL" and "Looker," and assumes competence. The interview might involve asking the candidate to write a simple SQL `SELECT` statement. This process finds people who know SQL. It completely fails to find engineers who have had to debug a complex circular dependency in a dbt project or design a blue-green deployment strategy for their dbt models.
The predictable and painful results of this superficial vetting become apparent across your data organization:
- Model Sprawl and "Spaghetti" Dependencies: Your dbt project has 500 models, but no one understands how they connect. The lineage graph looks like a plate of spaghetti. A change to a single upstream model breaks 20 downstream dashboards, and no one knows why until the CEO complains that their numbers look wrong.
- Slow, Expensive dbt Runs: Your daily `dbt run` takes three hours and costs thousands of dollars in data warehouse compute because models are being unnecessarily rebuilt. The team doesn't understand how to use incremental models, snapshots, or other materializations to run their jobs efficiently.
- Testing Theater: The team adds `not_null` and `unique` tests to a few columns and claims they have "100% test coverage." They are not writing custom, business-logic tests that actually validate the correctness of their transformations. The data can be unique and not null, but still completely wrong.
- Lack of Documentation: Models and columns have no descriptions. A data scientist trying to use a table has no idea what a specific column means, where it came from, or how it was calculated. They are forced to reverse-engineer the SQL, wasting valuable time.
The business impact is a complete loss of trust in the data platform. You have invested in a modern data stack, but you are still making decisions based on unreliable data and gut instinct.
How Axiom Cortex Evaluates dbt Developers
Axiom Cortex is designed to find the engineers who think like software developers first and data analysts second. We test for the practical skills and the disciplined habits that are essential for building and maintaining a professional analytics engineering platform with dbt. We evaluate candidates across four critical dimensions.
Dimension 1: dbt Project Architecture and Modularity
A well-structured dbt project is the foundation of a scalable and maintainable data platform. This dimension tests a candidate's ability to design a project that can grow to hundreds or thousands of models without collapsing under its own complexity.
We provide candidates with a set of requirements for a new data domain and ask them to design the project structure. We evaluate their ability to:
- Layer the Data Models: A high-scoring candidate will immediately talk about organizing models into logical layers, such as staging (source data cleanup and type casting), intermediate (reusable, complex transformations), and marts (business-facing, aggregated models).
- Use Packages and Project Dependencies: Can they explain how to use dbt packages to incorporate reusable code (like the `dbt-utils` package) or how to set up dependencies between multiple dbt projects?
- Manage Configuration with `dbt_project.yml`: Do they know how to use the `dbt_project.yml` file to configure models, set materializations, and define variables, avoiding the need to clutter individual model files with configuration?
Dimension 2: Advanced Modeling and Performance
This dimension tests a candidate's mastery of dbt's more advanced features for building efficient and sophisticated data models.
We present a complex data modeling problem and evaluate if they can:
- Choose the Right Materialization: Can they explain the difference between a view, a table, an incremental model, and an ephemeral model, and articulate the performance and cost trade-offs of each?
- Implement Incremental Models Correctly: A high-scoring candidate can write a correct and efficient incremental model, using `is_incremental()` and a unique key to update the model without requiring a full table scan.
- Write Powerful Jinja Macros: Can they write a custom Jinja macro to encapsulate a piece of repeated SQL logic, making their models more DRY and maintainable?
- Use Snapshots for Slowly Changing Dimensions: Do they know how to use `dbt snapshot` to track historical changes to a source data table, a critical pattern for many analytical use cases?
Dimension 3: Testing and Data Quality
A data platform without automated testing is a liability. This dimension tests a candidate's discipline in building a robust data quality safety net.
We evaluate their ability to:
- Write Generic and Singular Tests: They must be proficient in writing both the standard tests (`unique`, `not_null`, etc.) and custom, business-specific data tests (e.g., "the sum of all order payments must equal the total revenue reported in another table").
- Use Packages for Advanced Testing: Are they familiar with packages like `dbt-expectations` for writing more expressive and powerful data tests?
- Integrate Testing into CI/CD: A high-scoring candidate will advocate for running `dbt test` on every pull request to ensure that no bad data ever reaches production.
Dimension 4: CI/CD and Deployment
A professional analytics engineer owns the entire lifecycle of their code, from development to production deployment.
Axiom Cortex assesses how a candidate:
- Designs a CI/CD Pipeline for dbt: How would they set up a pipeline to run, test, and deploy their dbt project? They should be able to discuss concepts like slim CI, blue-green deployments, and running `dbt build`.
- Manages Documentation: Do they understand the importance of `dbt docs`? Do they consistently write clear, business-focused descriptions for every model and column they create?
From a SQL Swamp to a Data Factory
When you staff your data team with analytics engineers who have passed the dbt Axiom Cortex assessment, you are making a strategic investment in the quality, reliability, and trustworthiness of your entire data platform.
A SaaS company was struggling with data chaos. Their analysts were all writing their own complex SQL queries against raw data, leading to inconsistent metrics and a complete lack of trust in the numbers. Using the Nearshore IT Co-Pilot, we assembled a "Data Platform" pod of two elite nearshore analytics engineers.
In their first quarter, this team:
- Built a Centralized dbt Project: They created a single, version-controlled dbt project to house all of the company's core business logic and data transformations.
- Created a "Golden" Set of Data Marts: They worked with the business stakeholders to build a set of clean, tested, and well-documented data marts that provided a single source of truth for key business metrics.
- Empowered the Analysts: They taught the company's data analysts how to build their reports on top of the trusted dbt models, rather than writing their own complex SQL from scratch.
The result was transformative. The time it took to generate a new business report went from days of manual SQL wrangling to a few hours of building on top of trusted models. For the first time, the entire company—from the CEO to the marketing team—was looking at the same, consistent numbers.
What This Changes for CTOs and CIOs
Using Axiom Cortex to hire for dbt competency is not about finding a good SQL writer. It is about insourcing the discipline of modern software engineering and applying it to your data assets.
It allows you to change the conversation with your CEO and CFO. Instead of talking about the data warehouse as a cost center, you can talk about it as a reliable, strategic asset. You can say:
"We have built our data platform on a foundation of software engineering best practices, managed by a nearshore team that has been scientifically vetted for their ability to build reliable and testable data systems. This ensures that every decision we make is based on data we can trust, giving us a significant competitive advantage."