dbt Skills for Contract Roles: What Clients Now Expect

Three years ago, a client screening for a data engineer would ask about your SQL and maybe your Airflow experience. Now the first technical question is often: "Walk me through your dbt project structure." If you cannot answer that in under two minutes, the screen is effectively over.

This is not a fad. It is a signal that the transformation layer — the step between raw ingested data and the tables analysts and models actually query — has become its own discipline with its own tooling expectations. Clients writing statements of work for analytics engineers, data engineers, and even some ML engineers now assume dbt fluency the way they used to assume Git fluency.

If your resume says "dbt" but you have only run dbt run a handful of times against a demo project, you are exposed in the interview. Here is what "dbt experience" actually means in a screen right now, and what to build this weekend so the claim holds up.

What "dbt Skills" Actually Means to a Hiring Manager

Recruiters and hiring managers use "dbt experience" as shorthand for a cluster of distinct competencies. Screeners increasingly probe each one separately, because they have been burned by candidates who know one piece and bluff the rest.

• Models and refs — writing modular SQL models and chaining them with ref() and source() instead of hardcoded table names, so the DAG resolves dependencies automatically.
• Testing — using built-in tests (unique, not_null, relationships, accepted_values) and writing custom singular or generic tests for business logic.
• Snapshots — implementing slowly changing dimension tracking with dbt snapshot for source tables that overwrite history.
• Exposures — documenting downstream consumers (a dashboard, a reverse-ETL sync, an ML feature set) so the team understands blast radius before changing a model.
• CI on pull requests — running dbt build against a slim or ephemeral environment on every PR, often via GitHub Actions, dbt Cloud, or a custom CI job, so broken models never reach production.
• The semantic layer conversation — familiarity with dbt Semantic Layer or MetricFlow, and being able to discuss how metrics get defined once and consumed consistently across BI tools.

Notice what is missing from that list: raw SQL skill. Clients assume you can write a join. What they are screening for is whether you understand dbt as a software engineering discipline applied to analytics — version control, testing, CI, and documentation as first-class citizens, not afterthoughts.

Why This Became Table Stakes on Contracts Specifically

Contract engagements have a shorter runway than full-time hires. A client bringing in a consultant for a six-month data platform build cannot afford a ramp-up period where the consultant learns the team's dbt conventions from scratch. They need someone who can open the repo, read the DAG, and start contributing to models on day two.

This is also a cost-of-rework issue. Bad dbt hygiene — models without tests, no CI gate, undocumented exposures — creates silent breakage that surfaces weeks later as a wrong number in an executive dashboard. Clients who have been burned once now write dbt competency directly into the technical screen, sometimes as a live exercise: "Here is a broken model, fix the ref and add a test."

The Interview Questions You Should Expect

dbt interview questions have become fairly standardized across the market. Practice answering these out loud, not just reading them:

• How do you decide the boundary between staging, intermediate, and mart models?
• What is the difference between an incremental model and a table materialization, and when do you choose each?
• How do you handle a source table that changes schema without notice?
• Walk me through what happens when a PR breaks a downstream model — where does CI catch it?
• How would you set up a snapshot for a dimension table that gets hard-deleted rows in the source system?
• What is your opinion on defining metrics in the semantic layer versus in BI-tool-native calculated fields?

That last question is increasingly common and increasingly a filter. Clients consolidating BI tools (Looker, Tableau, Power BI) want metrics defined once in dbt's semantic layer so numbers do not drift between reports. If you have an opinion backed by a reason — governance, single source of truth, reduced tool lock-in — you separate yourself from candidates reciting a feature list.

dbt Versus Adjacent Tooling: Know the Boundary

Part of sounding credible is knowing what dbt does not do. Interviewers test this by asking where dbt fits relative to orchestration and ingestion tools.

Being able to draw this table from memory, unprompted, tells an interviewer you understand the modern data stack as a system rather than a list of logos on a resume.

A Realistic One-Weekend Path to a Demonstrable Project

You do not need six months of production dbt experience to have a credible answer in a screen. You need one working project you can actually walk through, hosted publicly, that touches every competency above.

1. Friday evening (2 hours): Set up dbt Core against a free-tier warehouse (Snowflake trial, BigQuery sandbox, or DuckDB locally). Pull in a public dataset — NYC taxi data or a Kaggle e-commerce set works fine.
2. Saturday morning (3 hours): Build a staging layer with sources and refs. Add not_null, unique, and relationships tests on every model. Commit to a public GitHub repo.
3. Saturday afternoon (3 hours): Build one intermediate model and one mart model with a real business question behind it — customer lifetime value, order fulfillment time, whatever fits your dataset. Add a custom singular test that checks a business rule (for example, revenue never negative).
4. Sunday morning (2 hours): Add a snapshot on a table that simulates slowly changing data. Write an exposures.yml entry pointing at a hypothetical dashboard. Generate and review dbt docs.
5. Sunday afternoon (2 hours): Wire up a GitHub Actions workflow that runs dbt build on every pull request. Break something on purpose, open a PR, and let CI catch it. Take a screenshot for your portfolio notes.

Total time: roughly twelve hours across a weekend. The output is not a toy — it is a repo you can screen-share in an interview and speak to model by model, test by test, which is exactly what the screen is checking for.

What This Means for Your Next 90 Days

If dbt is not currently on your resume with specifics — model counts, test coverage, CI setup, whether you have touched the semantic layer — treat that as a gap to close this quarter, not next year. Analytics engineering tooling has consolidated fast, and clients writing SOWs in Q4 are already assuming this baseline.

If you already run dbt on a client engagement, spend some time this month documenting what you built in language a screener will recognize: models and refs, test coverage percentage, CI on PRs, any semantic layer work. Specificity is what moves you past the recruiter screen and into the technical round.

Josh Pros LLC works with consultants across the data stack — cloud, analytics engineering, and platform roles — and we talk to clients every week about exactly this kind of tooling expectation. If you want a read on how your dbt background stacks up against current contract requirements, email contact@joshpros.com or visit https://joshpros.com.

#dbt #AnalyticsEngineering #DataEngineering #ContractTech #ITStaffing #DataStack #SemanticLayer #dbtSkills #TechConsultants #DataContracts #CloudSkills #CareerGrowth

Back to all insights