12 Questions About Analytics Engineering
My honest answers about the role.
A follower sent me these questions in a DM a few weeks ago. All about moving from data analyst to analytics engineer, and everything that comes with it.
I don’t usually get the chance to answer questions like this in full, so I wrote it all out here instead of a short DM reply. If you’re an analyst thinking about the same move, or already doing this job and curious how someone else sees it, hopefully something in here is useful.
“You started as an Analyst and transitioned to Analytics Engineering. What motivated that transition?”
⚡️ I worked as a data analyst for about 8 years and in every job I had difficulties that followed me everywhere: excel reports needs to be updated manually, every data export was an exploration journey, two different dashboards had different numbers, and most annoying question was when stakeholders “are you sure this number is correct?”. For a long time I blamed myself and the quality of my work, e.g. I had to be more careful, I had to check the query, I had to perform more thorough analysis and so on. But the problem wasn’t with my skill. The problem was the inefficient process of building the analytical foundation.
Around 2020 I started looking into data engineering. And it was a field that followed a strong engineering rigor: code best practices, automations, curated datasets, proper data modeling. It felt all correct, but was overwhelming at time. The shift from data analysis to data engineering felt massive. And this is where I found out about dbt and analytics engineering.
This new title had best of both worlds: practical analytics and engineering best practices. And the more I learned about the role and the dbt framework, the more I was convinced that AE is something that I want to do: build scalable analytics and be useful to the business.
“Was there a particular project or experience that helped you get your first Analytics Engineer role?”
⚡️ Yes, there was a particular project that helped me transition to the AE role which could greatly demonstrate my desire to switch to AE full time.
At the time I was working as BI engineer working with Looker. If you are not familiar, Looker is a BI tool with the built-in semantic layer. And I’ve got a big project to work on: implement a Metrics overview dashboard for Monthly Board meetings. It was a great opportunity to structure the business metrics on a single canvas and showcase my ability to deliver quality data product.
At first I was excited about the project and quickly build a first prototype with a couple of first main KPIs. However, the more I worked on the dashboard, the more I realized that our data was a mess. Some datasets missed needed dimensions. Some metrics definitions were scattered across multiple dashboards. Some data transformations were done in the data warehouse, but some in the looker’s transformation tool. It was really hard and time consuming to find proper ways of delivering the project.
At the same time, our data platform engineers introduced dbt to our stack. So knowing about the best practices of using the correct tool for job, I’ve decided to implement all data marts in dbt, and use Looker only for visualization and complex metrics definitions.
And it worked very well! Using SQL I was able to create datasets that included all necessary dimensions and measures, add data tests and document every single column and source I used for it. Using those clean and analytics-ready datasets I was able to quickly rework the dashboard and deliver a clean and tested metrics to the Board.
“Looking back, what were the biggest skill gaps you had to bridge?”
⚡️ My two main skill gaps were data modeling and requirement gathering.
Working as data analyst I rarely thought about scalability and reusability of my datasets. Often my queries were just one-off scripts that took a lot of time, but gave almost no practical value for the future reuse. I lacked proper data modeling practice.
Another gap was a proper requirement gathering from stakeholders. When all my work looked like an endless ad-hoc cycle, there was no time for me to proper think about all edge-cases or further application of my solution. That led to re-work and back-and-forth with the business people whose real desire wasn’t satisfied with the numbers that I provided.
“What does a typical week look like for you?”
⚡️ My typical week is a combination of multiple types of work.
First type of work is individual contribution. It is a meaningful time for working on my tasks and writing code. This usually includes writing new data models for new product features and creating dashboard and semantic layer for those new models.
Second type of work is data maintenance. This includes fixing broken tests, implementing changes to the models according to changes in the business, helping with incoming data questions from stakeholders, fixing outdated dashboards and efforts to keep our data code clean and pristine.
Lastly, I spend time on meetings and mentoring. Meeting could be syncs with the team, cross-functional syncs and aligning on the roadmap. Additionally we spend some time on mentoring and self-education. For example, in my team we run BI office hours, where everyone can come and ask question about building a dashboard, metric definition or any blockers they experience with the dashboards. Sometimes we also spend time with the team going for workshops, doing internal trainings or participating in hackathons.
“Roughly, what's the tool or thing that takes up most of your time?”
⚡️ My answer to that question would be very different a year ago, but now it’s definitely an AI. With the advent of strong models and new ways of collaborating with AI, my new everyday tool is Claude Code and Codex. They now automate a big chunk of my work, leaving me with the work that cannot be automated (yet).
Also, I’m trying to learn and experiment with the latest developments in this field. Because it’s a fast growing topic that can really elevate my career, so skipping it may cost me a lot.
“Must have skills for beginners/data analyst trying to transition or looking for analytical engineering role?”
⚡️ Here are skills that I believe are important today:
SQL — daily tool to manipulate the data. Still valuable, even in the AI era
dbt — the most popular framework for data transformation lifecycle
Data Modeling — learn how to build scalable and maintainable datasets
Claude Code or Codex — hot new skills that are becoming must have
Collaboration with stakeholders — learn to ask question, clarify requirements, follow up on projects and be a great data partner
“How deep does someone really need to know Python?”
⚡️ Although the classic AE role doesn’t require Python, I’d suggest to know at least basics of Python to be more valuable as a specialist.
A lot of companies today have blurred lines in responsibilities between data engineers, analytics engineers and data analysts. It means that sometimes you may need to read and write Python to be on the same page with the team. For example, you may need to understand how the data is gathered and transformed in Apache Airflow. Or you may need to read Pandas data transformations created by analysts in order to translate them to SQL.
Obviously, with the AI you can ask it to do the job, but you still need a way to verify the output. So it would be good to not only rely on the AI, but also be able to apply your own judgment.
“Which dbt concepts you use often?”
⚡️ Well, dbt has a lot of concepts and they all applicable in different situations. So there is no list of my favourite or most used concepts. But I like to think about this from a different angle.
dbt provides you a suit of tools that you should know and use:
Transformations — the core feature. Learn about refs and source macros, materializations, model configs.
Testing — almost on the same level of importance as transformations. Learn about data tests, custom SQL tests, unit testing.
Documentation — becoming especially important in the AI age, because agents can get additional context from documented dbt models and column
Advanced features — stuff that pushes your project to maximum efficiency: variables, macros, packages, observability
“If you interviewed me, what portfolio project would immediately make you think, “This person understands Analytics Engineering”?”
⚡️ As an interviewer, I rarely look at portfolios. But it doesn’t mean they are not useful. Because they are needed for you, not for the interviewer.
Portfolios can be good for practicing project architecture, data modeling, and data storytelling. At the interview I’m usually less interested about technical advancements you worked on, but more interested on how you tell me the story of the project. What insights you found, what data supports that, what are your recommendation to the business.
A person who understands Analytics engineering can tell a great data story without showing a single line of code.
“What are the top and most important interview questions that candidates struggle with? And what makes a candidate stand out?”
⚡️ When I ask “tell me about your past experience” many candidates start to explain the technical stacks and frameworks they worked with. But I want to hear what they achieved: were there clear business requirements, how this person clarified them, how the outcome helped the business.
Candidates who start with the business outcome are usually stand out more than those who start with the code and technical talks.
“If I have to learn skills important for this role, what would you recommend should be at the top?”
⚡️ I’d say two: data modeling and AI. Both are now essential to the role, and both can differentiate good analytics engineer from a great one.
“Lastly, what are some best practices you follow for documenting data models?”
⚡️ I have a couple of rules regarding data documentation:
Document everything for both humans and AI. You most definitely won’t remember why you applied a specific logic in your code unless you explicitly point that in the docs. Also, as I mentioned earlier, AI agents can extract useful context from data docs, so don’t skip that.
Another form of documenting models is adding useful comments. Don’t explain what the code is doing, explain the why behind it. It could be again a specific business logic, or gaps in the data.
Finally, always document the staging layer (input), marts layer (output) and every new business logic that gets generated in the intermediate layer.
Summary
If you're an analyst thinking about this move, most of what's holding you back probably isn't the tools. It's deciding to actually start. So just start, and probably one day I’ll learn something useful from you :)
If you liked the post, give it a heart and share with a colleagues.
Subscribe here or on LinkedIn to learn more about analytics engineering and AI!
Thank you for taking the time to answer every single one in so much detail. The point that really stayed with me was that the real problem wasn’t SQL or analysis, but the analytical foundation. This has given me much more clarity on what I should prioritise learning. Really appreciate you sharing your experience!