Quick Answer: what an analytics engineer does and what four weeks buys you
Twenty working days, about an hour a day, ending in one tested, documented dbt model in a repository your team reviews. An analytics engineer owns the transformation layer: the person who turns raw warehouse tables into tested, documented, version-controlled models that the rest of the business queries.
One number from our own database, queried on 2026-09-30. Learners here have built 1,582 paths. 196 of them, 12.4 percent, are SQL, data analysis or analytics topics, built by 180 learners, and those paths hold 732 of the 5,668 video slots in the whole corpus. Across all 5,668 slots, zero video titles name dbt, zero name BigQuery, zero say data warehouse, and zero paths name the job title analytics engineer at all. That is an observation about our own learners, not a claim about the world.
It still says something. People teach themselves SQL in large numbers and almost nobody teaches themselves the layer directly above it, which is the exact layer this job title is named after. That is the gap this plan walks into.
Analytics engineer vs data analyst vs data engineer: what actually changes
The boundary is ownership, not tooling. The analyst owns the question and the dashboard. The data engineer owns the pipes and the platform: ingestion, orchestration, storage, cost. The analytics engineer owns everything in between, which is the set of models the other two argue about when a number looks wrong.
Start with two videos that draw the line without selling you anything. Seattle Data Guy has a short one called "What Is An Analytics Engineer?" and a longer comparison called "Data Engineer Vs Analytics Engineer Vs Analyst - Which Position Is Right For You?". Watch both. He has hired for these teams, and he is blunt about the fact that at a small company the three roles are one person wearing three hats, while at a large one the boundary is a real org chart with real handoffs.
Then watch two talks from DataTalksClub, because a conference talk is a different kind of evidence. "Analytics Engineer: New Role in a Data Team - Victoria Perez Mola" describes the role as it lands inside an existing team, which is your situation exactly. "Foundations of Analytics Engineer Role: Skills, Scope, and Modern Practices - Juan Manuel Perafan" is the scope conversation: what you are on the hook for and what you are not.
Here is the part those videos will not say as directly as you need. The SQL does not change much. What changes is everything around the SQL.
Your query stops living in a BI tool and starts living in a file, in a repository, on a branch. Somebody reads it before it merges. It has tests attached that run without you. It has a name that follows a convention you did not invent. It has documentation, because six people will query it and only one of them will ever ask you what a column means. And when the revenue number on the executive dashboard is wrong on a Monday morning, the question "who owns this model" has your name as the answer.
That last one is the real transition. An analyst is judged on whether the answer was useful. An analytics engineer is judged on whether the number was right, at three in the morning, when nobody was watching. It is a better job and a heavier one, and the four weeks below are about earning that weight, not learning new syntax.
What you already have as an analyst, and the four things you are missing
You are not starting from zero, and the parts you already have are the expensive parts. You know SQL, you know which numbers the business actually acts on, you know who to ask when a definition is ambiguous, and people trust your answers. Four things are missing, and all four are learnable in a month.
Be honest about how valuable the existing half is. Companies hire analytics engineers from outside and then spend six months teaching them that the orders table has three kinds of refund and only one of them counts. You already know that. Business context is the slowest thing to acquire and you acquired it by accident. If you are earlier than that and still building the analyst foundation, our guide on becoming a data analyst with no experience is the step before this one.
Gap one: SQL that survives other people. Your SQL works. That is not the same as SQL somebody else can read, change and trust. The specific skills are common table expressions instead of nested subqueries, window functions instead of self-joins, and consistent formatting so a diff shows what changed. Days 3 and 4 are this. If your SQL is shakier than you would like to admit, our walkthrough of learning SQL from YouTube is the honest place to spend a preliminary week.
Gap two: dbt. dbt is the tool that turns a folder of SELECT statements into a managed project: dependencies between models resolved automatically, tests defined next to the code, documentation generated from the same files, and one command that builds everything in the right order. It is the single highest-leverage thing on this list, and Week 2 is entirely about it.
Gap three: dimensional modeling. This is the thinking half. Which table is a fact, which is a dimension, what the grain is, how you avoid the situation where three dashboards define an active customer three ways. It is older than every tool in this post and it is why the models you build stay useful. Week 3.
Gap four: software engineering habits. Git, branches, pull requests, code review, tests that run in continuous integration, and separate development, CI and production environments so an experiment cannot break a live dashboard. Analysts often find this the strangest week, because none of it is about data. Week 4.
Four gaps, four weeks, one each. That is the whole design.
The 20-day plan
Twenty working days, five days a week, about an hour each. Every day names one or two videos and one thing to produce. The plan assumes you have a warehouse you can query at work and a table you actually care about, because the whole point is to build on something real rather than on sample data.
If you do not have that, Day 5 gives you three free ways to get one.
Week 1: the role, and SQL that holds up under review
Day 1: what the job actually is. Watch "What Is An Analytics Engineer?" from Seattle Data Guy, then "Analytics Engineer: New Role in a Data Team - Victoria Perez Mola" from DataTalksClub. Produce one paragraph in a notes file: what you would be accountable for in this role at your own company, named specifically. Not a job description copied from a posting, yours.
Day 2: where the boundaries are. Watch "Data Engineer Vs Analytics Engineer Vs Analyst - Which Position Is Right For You?" from Seattle Data Guy and "Foundations of Analytics Engineer Role: Skills, Scope, and Modern Practices - Juan Manuel Perafan" from DataTalksClub. Produce a two-column list: what you already do, and what would be new. That list is your evidence in a conversation with your manager later this month.
Day 3: common table expressions. Watch "SQL WITH Clause | How to write SQL Queries using WITH Clause | SQL CTE (Common Table Expression)" from techTFQ. Then take the ugliest query you personally own, the one with subqueries nested three deep, and rewrite it as a chain of named CTEs. One hour is enough because this is a formatting and naming skill, not a new concept. The output should read top to bottom like a paragraph.
Day 4: window functions. Watch "SQL Window Function | How to write SQL Query using RANK, DENSE RANK, LEAD/LAG | SQL Queries Tutorial" from techTFQ. Produce one query that answers a real question you have been asked before: most recent order per customer, rank within category, change versus previous month. Window functions are enough today because they are the single most common thing that separates a query that scales from a self-join that does not.
Day 5: pick the warehouse you will practice on. Watch "Database vs Data Warehouse vs Data Lake | What is the Difference?" from Alex The Analyst for the vocabulary, then "Data Warehouse Basics Visually Explained | Data Engineer Portfolio Project | #SQL Project 2" from Data with Baraa. If you want the architecture argument too, "Data Warehouse vs Data Lake vs Lakehouse: Which One Should You Build?" from the same channel covers it in one sitting.
Then choose, today, and open an actual connection. The default recommendation is the BigQuery sandbox, because it requires no credit card and no billing account. Read the limits before you lean on it, though: per Google Cloud's sandbox documentation as of 2026-09-30, you get a lifetime 10 GiB of storage that is not refunded when you delete data, 1 TiB of query processing a month, and every table, view and partition expires automatically after 60 days. That expiry matters for a plan whose whole point is an artifact somebody can open later, so keep your models in the repository, which is the durable copy, and treat the warehouse as scratch space. Watch "How to get started with BigQuery" from Google Cloud Tech and get a query running.
If your employer runs Snowflake, learn that instead. Snowflake's own signup page, read on 2026-09-30, offers a 30-day trial with $400 in free credits and no credit card required. Watch "Getting Started - Architecture & Key Concepts" and "Getting Started - Introduction to Snowflake Worksheets & Queries", both from Snowflake Inc. And if your company will not let you put anything in a cloud warehouse, which is a real constraint in plenty of regulated teams, use DuckDB on your laptop. "5 ways that DuckDB makes SQL better" from Learn Data with Mark is the fastest way to see why that is not a downgrade for learning purposes.
Produce: a warehouse you can query, and one table loaded into it that you care about.
Week 2: dbt, from nothing to a tested and documented model
Day 6: what dbt is, and your first project. Watch "What is dbt?" from dbt Labs first, because it is short and it frames the problem before the tooling. Then follow "Intro to Data Build Tool (dbt) // Create your first project!" from Kahan Data Solutions and actually build it as you watch. dbt Core is licensed under the Apache License 2.0 and is free to install and run locally; the dbt-core repository on GitHub was close to 14,000 stars when we read the GitHub API on 2026-09-30. Produce: a dbt project on your machine that connects to the warehouse you set up on Day 5 and runs one model successfully.
Day 7: a repeatable process for writing models. Watch "A simple 4-step process for creating dbt models" from Kahan Data Solutions. This one video is worth more than the next three tutorials you would have found on your own, because it gives you a procedure to follow when you are staring at a raw table with no idea where to start. Produce: one staging model of your own, built on the real table from Day 5, that renames columns to your conventions and casts types properly. Nothing clever. Clean.
Day 8: tests. Watch "Creating a Data Model w/ dbt: Tests (Part 3/3)" from Kahan Data Solutions. It is part three of a series you will watch the rest of next week, and taking it out of order is deliberate: tests are the habit you want forming from your very first model, not the thing you bolt on at the end. Produce: not-null and unique tests on your staging model's key, plus one relationship test, all passing. Then break one on purpose and watch it fail, because a test you have never seen fail is a test you do not trust.
Day 9: documentation. Watch "Simplify dbt documentation with docs blocks" from Kahan Data Solutions. Produce: a description for every column in your model, written for the colleague most likely to misread it, and generated docs you can open in a browser. This is the day that feels least like engineering and pays back the most, because documentation is how a model stops being yours and starts being the team's.
Day 10: source freshness. Watch "How to monitor your source freshness in dbt" from Kahan Data Solutions. Produce: a freshness check on the source your model reads from, with warn and error thresholds you can defend. Enough for today because freshness is the single most common cause of the failure mode you already know well, which is a dashboard that looks completely fine and is quietly two days stale.
Week 3: dimensional modeling, the thinking half
Day 11: the star schema. Watch "Data Modeling Tutorial: Star Schema (aka Kimball Approach)" from Kahan Data Solutions, then "Data Modeling - Walking Through How To Data Model As A Data Engineer - Dimensional Modeling 101" from Seattle Data Guy for a second pass at the same ideas by someone drawing it out as he goes. Produce: a hand sketch, on paper or in any diagram tool, of one business process at your company as a star. One fact in the middle, dimensions around it.
Day 12: fact tables. Watch "The 3 Common Types of Fact Tables | Data Modeling 101" from Kahan Data Solutions. Produce: a written statement of the grain of your fact table. One sentence, in the form "one row per X". If you cannot write that sentence, you do not have a model yet, and finding that out on Day 12 is the cheapest possible time to find it out.
Day 13: dimensions. Watch "The 4 Common Types of Dimensions | Data Modeling 101" from Kahan Data Solutions. Produce: your dimension list, with a note on each one about whether its attributes change over time and whether anybody would ever want to see history. That is the slowly changing dimension question, and you only need to recognize it today, not solve it.
Day 14: build the model in dbt. Watch "Creating a Data Model w/ dbt: Dimensions (Part 1/3)" and "Creating a Data Model w/ dbt: Facts (Part 2/3)" from Kahan Data Solutions, back to back. You already watched part three on Day 8, so today closes the loop. Produce: one dimension model and one fact model in your dbt project, both building, both tested, built on the sketch you made on Day 11.
Day 15: models that last, and naming. Watch "Modeling for success: Building data structures that last" from dbt Labs. If you want the deeper version and have a longer evening, "Analytics Engineering with dbt Workshop - Juan Manuel Perafan" from DataTalksClub is the workshop recording, but treat it as optional. Produce: a written naming convention for your project. Model prefixes, column naming, how dates are named, what counts as a staging model versus a mart. One page. Boring on purpose, and the thing a reviewer will thank you for.
Week 4: engineering habits, and shipping the thing
Day 16: version control. Watch "Why Your Data Team Needs Version Control" from Kahan Data Solutions, then "How to create a new branch on GitHub // Commit & Push" from the same channel. Produce: your dbt project in a Git repository, on a branch that is not main, with commits that have readable messages. If your company has an internal GitHub or GitLab, put it there rather than somewhere personal, because the goal is a repository your colleagues can open.
Day 17: continuous integration and environments. Watch "Get Started With Github Actions" from Kahan Data Solutions, then "The 3-Environment Design for Your Database (DEV vs CI vs PROD)" from the same channel. Produce: a workflow file that runs your dbt build and your tests when you push, and three separate targets configured so that a broken experiment in development cannot touch the tables a live dashboard reads. This is the day that most changes how your team sees you.
Day 18: incremental models and cost. Watch "How to Build Incremental Models | dbt tutorial" from Kahan Data Solutions, then "Strategies for optimizing your BigQuery queries" from Google Cloud Tech if you chose BigQuery. One warning if you took the sandbox route on Day 5: the same Google documentation lists data manipulation language statements as unsupported in the sandbox, and dbt builds incremental models with exactly those, so this exercise needs a billed project or a warehouse at work. On the sandbox, do the reasoning and write the note instead. Produce: either your fact model converted to incremental, or a written note explaining why a full rebuild is still the right call at your data volume. Both are correct answers. The wrong answer is not having considered it, because somebody in finance will eventually ask what this costs.
Day 19: build it for real, end to end. Use "SQL Data Warehouse from Scratch | Full Hands-On Data Engineering Project" from Data with Baraa as your reference build. Do not watch the whole thing passively. Pull up the section covering the layer you are on and follow the structure while building against your own tables. Produce: your fact and dimension models, staging through to mart, running from raw source to final table with one command.
Day 20: ship it. Open a pull request. Ask a data engineer or a developer to review it, and say plainly that you are learning and want the review to be real. Address the comments. Merge it. Then point one existing dashboard at your new model instead of at whatever ad hoc query it was running before, and tell the person who owns that dashboard what changed.
Produce: one tested, documented dbt model in a repository, with a reviewed and merged pull request, built on a table your team actually uses, and one dashboard now reading from it.
That is the artifact. Everything in this post exists to produce it.
What to skip
Everything below is real work that real teams do. None of it gets a tested model into your repository inside twenty days, and several of them are the reason analysts who try this stall in week three. Skip them now, and note the condition that makes each one worth picking up later.
Airflow and orchestration. Scheduling is a real problem and dbt does not solve it. But you do not need a scheduler to have a model, and learning Airflow while also learning dbt means you will debug your scheduler instead of writing models. Pick it up when you have more than about ten models and somebody asks why the run did not happen. Our roundup of the best YouTube channels for data engineering in 2026 is where that month lives.
Spark and streaming. Spark matters at data volumes where a warehouse query genuinely cannot cope, which is a much higher bar than most teams hit. Streaming matters when the business needs an answer in seconds rather than hours. Both are the data engineer's territory. Learn them if you end up on a team that actually has the problem, not in advance.
Kubernetes and infrastructure. Nothing in the analytics engineer job requires you to run a cluster. If your team asks you to, they are asking you to be a platform engineer, which is a different transition and a different post.
Rewriting your BI layer. The temptation on Day 20 is enormous: now that there is a clean model, surely every dashboard should be rebuilt on it. Move one. See whether the numbers match. Rebuilding forty dashboards is a quarter of work and it is not how you prove this skill.
Python for data engineering. Genuinely useful and genuinely not now. The job is SQL, dbt and Git first. Python earns its place when you need custom ingestion or a dbt package, which is month three at the earliest.
The full DataTalksClub Zoomcamp. It is a serious multi-week course, published free on their own channel as the Data Engineering Zoomcamp playlist, and it is better than this plan for somebody with a clear three-month runway. It is the wrong shape for a deadline in twenty working days, because it teaches orchestration, cloud infrastructure and streaming alongside analytics engineering. Take the individual talks named in Week 1 and Week 3, and save the full course for after you have shipped something.
dbt macros and Jinja beyond the basics. You need to know what a macro is and you need the ref function. You do not need to write a macro that generates SQL from a YAML config in your first month. That is the classic trap: a beautifully abstract project with two models in it. Write twenty plain models, then extract what actually repeats.
How the options compare
There is more than one honest route into this role, and the right one depends mostly on whether you have money, time or an employer who will invest in you. Here are the five realistic options, including ours, with the catch stated for each rather than buried.
| Route | What it costs | How long | What you end up with | Honest catch |
|---|---|---|---|---|
| Self-directed YouTube on your own | Nothing beyond your time | 4 weeks at an hour a day, if you hold the line | A model you built, and the habit of finding good teachers | No sequence and no deadline. Most people collect videos instead of finishing one, and nobody tells you when you are wrong |
| The DataTalksClub workshop talks and Zoomcamp | Free | A few hours for the talks, several months for the full course | Real depth, real community, and exposure to orchestration and cloud work | Much broader than analytics engineering, and the full course is the wrong shape for a four-week deadline |
| A paid bootcamp or course | Paid, and the spread between providers is wide enough that you have to price the specific one | However long that provider schedules, which is the thing you are really buying | A curriculum somebody sequenced for you, deadlines, and often a human to ask | You pay for the sequencing, which is the part this post gives away. Quality varies enormously and the certificate rarely carries weight on its own |
| Your employer's internal mentoring | Free to you, and the best option if it exists | Months, at whatever pace the mentor has | Your own company's data, conventions and politics, which is exactly the context you need | It depends entirely on one busy person. Ask for it, but do not make your progress hostage to their calendar |
| LearnPath | Free to build a path. The completion certificate is on the Pro plan | Your own pace, structured as a sequence | A path of free YouTube videos on a topic you name, with a quiz generated from each video's transcript | It sequences videos and checks whether you watched them. It cannot review your pull request or tell you whether your grain is right. Only a person can do that |
If your employer will pay for a course and give you time in working hours, take it. That is a better deal than anything free. This plan exists for the much more common situation, which is that you have an hour a day and nobody is going to arrange it for you.
Proving it: what to show at the end of four weeks
At the end of Day 20 you should be able to send someone a link, not a description. It goes to a repository holding a dbt project: your fact and dimension models, tests running in continuous integration, generated documentation, a merged pull request with a colleague's comments, and one dashboard now reading from your model.
Say it precisely when you talk about it. Not "I learned dbt" but "I built the customer orders mart our revenue dashboard now reads from, it has tests that catch duplicate order rows, and a data engineer reviewed the pull request." The first sentence is a course you watched. The second is a contribution, and it is checkable. Hiring managers and your own manager hear the difference immediately.
Bring three things to the conversation about a title change or a new role. The repository link. The one-page naming convention from Day 15, because it shows you think about the team and not just the query. And the two-column gap list from Day 2, updated, because it shows you know what you still do not know, which is the most reassuring thing a candidate can demonstrate.
LearnPath's own certificate is secondary proof and it comes with the Pro plan. Be honest about what it is: LearnPath builds a learning path of free YouTube videos on a topic you name and generates a quiz from each video's transcript, and Pro learners get a certificate when they finish. That certificate is evidence that you completed your own plan on a skill almost nobody schedules. It is not accredited and no employer has heard of it. The repository is the thing that gets you the job.
The deadline is doing most of the work here, not the video list. A dated four-week plan with an artifact at the end finishes; an open-ended intention to learn dbt does not. Our own data shows the shape of that gap precisely: of the 5,668 video slots learners here have queued, 12 teach dimensional modeling and all 12 of them sit inside those 196 analytics paths, while not one slot anywhere in the corpus names dbt at all. The thinking half gets sampled. The tooling half never gets scheduled. Pick the table, book the twenty hours, and build yourself a work-ready analytics engineering path before your next planning cycle starts, so you walk into your next review with a merged pull request instead of a reading list.
Frequently Asked Questions
Six questions that come up between deciding you want this role and having something to show for it. The short version of all six: the SQL you already have is most of the way there, and the missing part is not harder, only less familiar.
What is an analytics engineer, and how is it different from a data analyst?
An analytics engineer owns the transformation layer between raw warehouse tables and the dashboards analysts build. The analyst owns the question and the answer. The analytics engineer owns the model the answer is computed from, plus its tests, its documentation and its version history. Same SQL, different accountability.
Can a data analyst really learn analytics engineering in four weeks?
Enough to do the work on one model, yes. Twenty days at roughly an hour covers the role, SQL that survives review, dbt, dimensional modeling and the engineering habits. It will not make you senior. It ends with a tested, documented model in a repository, which is more than most applicants have.
Do you need to know Python to become an analytics engineer?
Not to start. The core of the job is SQL, dbt and version control, and plenty of analytics engineers write very little Python. It becomes useful later for custom ingestion, for orchestration and for the occasional package. Learn it in month three, after your first model is running in production.
Is dbt free, and which warehouse should you learn it on?
dbt Core is licensed under the Apache License 2.0 and is free to install and run locally. Learn it on whatever your employer already runs. If you have no warehouse, the BigQuery sandbox needs no credit card, per Google Cloud documentation read in 2026, and DuckDB runs on your laptop.
What is dimensional modeling, and do you still need it in 2026?
Dimensional modeling splits your data into facts, the measurable events, and dimensions, the things you slice by. It is how you get one agreed definition of a customer instead of nine. Cheap storage has not retired it in 2026, because the problem it solves is disagreement between people, not disk space.
What should a data analyst build to prove they can do analytics engineering work?
One model, in a repository, on a table your team actually uses. It should have tests that fail when the data is wrong, documentation a colleague can read, a pull request someone reviewed, and one dashboard now reading from it. That artifact beats any certificate, including ours.
