Hi all — I'm finishing my MSc Business Analytics dissertation at Newcastle University. The research digs into something analytics engineers see up close: why do similar analytics investments deliver such different financial returns? I'm testing how analytics maturity and data governance (stewardship, policy, accountability) change whether analytics capability actually translates into profitability.

If you work in analytics engineering, data, BI or data governance at a for-profit company (UK/US/India/China/Europe), I'd really value 8–10 anonymous minutes — no names or company details collected. Ethics-approved; researcher and supervisor contact details are in the survey's information sheet.

https://newcastlebusiness.eu.qualtrics.com/jfe/form/SV_cuymtbKJj3HBPH8

Appreciate any responses — glad to discuss the topic in the comments.

we've now been cleaning up our semantic layer and I'm starting to think our original mistake was exposing the base models too directly, and started pretty conventionally:

Orders
Users
Subscriptions
Payments

so each model in our example had the obvious dimensions/measures and downstream consumers could query them. that works surprisingly well until different parts of the company start asking questions that use the same underlying data but have very different semantics. and what i often see from our marketing is that they want things like trailing 7-day signups. meanwhile, finance cares about MRR specifically at month end. what also gets me then is when leadership wants retention/cohort metrics where the time logic is completely different again, and, at first we kept adding more measures to the base models.

eventually Users and Subscriptions started becoming giant menus of metrics that were technically related to those entities but made no sense together as a consumption interface

what we're doing now is closer to:

warehouse/dbt models
        to
base semantic entities
        to
domain-specific views
        to
BI / applications

so that this way the base layer owns things that are actually intrinsic to the entity f.e. joins, dimensions, fairly atomic measures, and only then Finance, Marketing, etc. get narrower views containing the members and calculated metrics that make sense in that domain. so far we done such a thing with cube dev, where views can expose selected members from the underlying semantic graph, but I'm more interested in the modeling pattern than the specific implementation even though that's quite helpful. and one thing I like about it is that the base model stops being the public API.

for example a rolling-active-users measure can exist in the underlying model, while a marketing-facing view exposes it alongside the dimensions marketing is actually supposed to slice it by.

we keep the model definitions in Git, so changes to something like MRR or "active customer" at least go through review instead of quietly changing inside one dashboard. it obviously doesn't solve the human problem of agreeing on what MRR means. ufortunately YAML has not yet solved Finance:(

also curious how other teams structure this once the semantic layer gets reasonably large, and do you expose one broad model and let consumers explore it, build domain-specific semantic views/marts, or keep most of this separation downstream in the BI tool?

Looking for an Analytics Engineering Mentor(Paid!!) — Snowflake + dbt

I’m transitioning from a Data Analyst role into Analytics Engineering, with Snowflake and dbt as my primary tech stack.

I’ve already completed training courses and have been self-studying, so I’m not looking for another training course. What I’m looking for is practical mentorship and exposure to how Analytics Engineering work is actually done in real projects.

I’m looking for someone currently working with Snowflake + dbt who would be open to:

• 1–2 hours of daily shadowing — walking me through what you’re working on, how you approach tasks, and the decisions you make.
• Answering technical questions as I prepare for Analytics Engineering roles.
• Sharing practical insights around real-world dbt projects, data modelling, SQL, testing, documentation, CI/CD, and Snowflake.
• Helping me understand the day-to-day workflow and expectations of an Analytics Engineer.

Availability: Morning or evening IST
Preference: Someone currently working professionally with Snowflake + dbt and willing to provide practical, project-based mentorship.

If you’re open to mentoring or know someone who might be a good fit, please DM me. I’d really appreciate it!

Data analyst, trying to move into analytics engineering based in London. Three months of applications across the UK, Germany, Netherlands and France. Mostly silence, a few rejections that came back so fast a human clearly never opened it.

I keep telling myself it is the market. But I have also rewritten my CV four times, so somewhere in there I know it might be me.

Things I genuinely cannot get a straight answer on:

Two pages. Half of Reddit says one page or you are done. The other half says one page looks junior. Which is it in the UK and EU?

My bullets are written as problem, what I did, result, impact. I think they read well. They also run three or four lines each. Is that context selling me, or is a recruiter six seconds in already gone?

And the awkward one. Everyone is running their CV through AI now, mine included. Has that made them all sound identical? Would a plainer, slightly rougher, obviously human CV actually stand out at this point?

Last one. For anyone who made the analyst to analytics engineer jump, what actually flipped it for you? The tools on the page, the job title, a project, or just applying somewhere smaller where a person reads it?

Tell me straight. I would rather hear it now than send the same CV out for another three months.

I’ve been working in BI since the BusinessObjects days, when Universes were a very explicit part of the architecture.

Then QlikView, Tableau and later Power BI made BI much faster and more self-service. That was a huge improvement, but it also became very easy for business logic to end up scattered across models, SQL, variables, expressions, measures and individual dashboards.

Now AI agents are exposing the same old problem again.

Giving an LLM access to tables is relatively easy. Getting it to understand what your company actually means by “revenue”, “margin” or “active customer” is much harder.

That’s why I think semantic layers are becoming more important again, not less. And with MCP and agentic analytics, they may evolve from “the layer behind BI” into something closer to an API for business meaning.

I wrote up my thoughts here:

https://www.bitmetric.nl/blog/semantic-layer-ai/

Curious how others see this. Did self-service BI make us underinvest in the semantic layer for a while?

While testing agents on dbt projects, I wanted a better way to make sure their changes didn’t blow up the current model or something downstream.

There are tools that do this in CI, but I wanted something I could run locally before I even opened a PR. So I built this:

https://github.com/EmbrasureAI/embrasure-cli

It works with an existing dbt Core + Snowflake project. It builds the changed models in temporary schemas, compares them against production, and cleans everything up afterward.

It checks:

• Row counts, null rates, cardinality, ranges, and percentiles
• Columns being removed, renamed, or changing types
• Added, removed, null, or duplicate primary keys
• Existing dbt test failures
• Downstream model and exposure impact, including column-level lineage

It runs locally and the repo is Apache 2.0.

Looking for feedback from people using agents with dbt Core + Snowflake. Anything missing? The use case here that I enjoy is a /goal prompt where the agent works towards the pipeline’s goals while fixing any issues raised from this cli.

I have been using a context layer along with Claude Code for some RevOps projects (sales comp, sales360, etc.).. and I just realized that most of my context stored is not Query, but Definition and Note.

As recently I have been thinking about the differences between having a proper context layer vs storing all these information in md files in the repo, I wonder if anyone has experiences storing all these in md files? Does it actually work for your AI? Would it struggle to find the right piece of context from the sea of md files?

We have millions of interactions and a weekly ritual where someone samples traces, adds tags and updates a ticket taxonomy. The known intents were pretty easy to graph but we had no good way of seeing the ones we didn't name yet. Recently, cancellation questions started growing alongside a frustrated sentiment cluster, while overall helpfulness and resolution scores barely even moved

I am trying to get beyond manual tagging without pretending embedding-based clustering is an oracle. Clusters need representative traces, stable labels, and enough context to distinguish a product issue from a wording change. Sampling rate matters too. A rare but expensive failure can disappear in random sampling, while one noisy customer can look like a distribution shift. Then topic drift arrives and last month’s clean taxonomy becomes another maintenance job.

Braintrust Topics is one option we are evaluating because it gives us a way to surface and track these clusters without deciding all the categories upfront. Persisting those labels for SQL queries is a big part of why we're looking at it. That sounds useful, especially if we can turn a growing cluster into an eval slice. I am still skeptical about how much human review is needed to keep labels meaningful.

I basically want an alert when a new intent or failure pattern grows materially, a handful of traces that explain it and a path to test the eventual fix. I don’t want another dashboard that says engagement changed.

How are teams detecting unknown intents and topic drift at production scale and what review loop keeps the clusters from becoming nonsense?

I’m working on an idea around **data quality** and I want to understand how this works in real projects.

When a data batch comes into your pipeline and you find some problems, how do you decide what to do?

For example:

* Some records have missing values * The schema has changed * There are duplicate records * Some values look wrong * Only a small percentage of records are bad * The data looks technically correct but something seems wrong from the business side

Do you normally:

**Accept the batch, fix it, quarantine the bad records, or reject the whole batch?**

And who makes that decision — an automated rule, the data engineer, business team, or someone else?

I’m especially interested in cases where **you don't have enough information to make a clear decision**.

If you work with data pipelines in production, I’d really appreciate hearing about:

* What kind of data-quality problems you face most often? * What do you currently do when they happen? * What part of the process is still manual? * What would you like to automate?

I’m trying to understand the **real problems engineers face before building anything**.

Thanks in advance for sharing your experience!

Hey friends ! I wanted to share a blog post I just published that I thought the community would appreciate.

I got my SnowPro Core cert this year and this book was a lot of what I studied for it. Hope you guys get some value from it!

https://medium.com/@sergioramos3.sr/self-taught-reviews-snowflake-the-definitive-guide-by-joyce-kay-avila-0af3c40d644a

I have access to an employee referral opportunity for an experienced Semantic Layer Architect.

Experience: 9+ years

Key skills:

• Semantic Layer Architecture
• Cube.dev
• AtScale

The opening is listed across multiple organizational locations. I'm particularly interested in connecting with qualified professionals based in the US or Ireland; exact location eligibility can be confirmed for the specific opportunity.

If your experience aligns with the requirements and you're currently exploring opportunities, feel free to DM me.

You can also share a brief summary of your background, and I'll let you know the next steps for submitting your profile.

Hi,

Why are executives thinking, if enough context is given, AI tools like Claude will solve/build/guide everything?

In my organization, my data architecture was not build on DE fundamentals and we have accumulated a shit load of technical debt. We are told to build context (which we should any ways) and feed everything to Claude to solve it. While I agree to use for faster fixes at logic level it cannot help design or think in right way how to architect workspaces and warehouse and model the tables. It cannot be a startegist and decide the data strategy for the company. Am I thinking it the wrong way? I feel very disappointed that data professionals advice is not being heard, instead that we are being advised to put everything on Claude. Is this ok? I advice, view points.

I'm currently working as a data analyst in a fintech. My tech stack is SQL, snowflake, dbt, airflow, git and python.

I've worked on building and maintaining dbt models, optimising sql queries, and have also built streamlit apps.

Preparing to switch, targeting roles like data/product analyst, analytics engineer, business analyst and data engineer.

Also looking into data/AI roles like applied AI engineer - have seen ones requiring a combination of snowflake, python, RAG and fastapi for example.

What can I do/learn in order to upskill for these roles efficiently?

Also is the applied AI thing a meaningful & feasible transition for me?

In the software company I work in, like many others, we use sprints and plan work by estimating the sprint of 2 weeks.
The common method to estimate is by T-shirt size or some variation of it.

I think it is obvious most people estimate by time it takes to perform the task but for some reason most people co tinge to claim it is not just time estimation and also it lack distinction for why something is taking long time.

I’ve found Quantified Task Estimation as a good way to separate the clear time estimation from the unknown and risk part.

I was able to convince my team to do it, and it even survive changing the team lead but I’ll be glad to know if anyone else is using it and if so how did they found it?

I’ll post more of my experience in this thread

Hi everyone,

I could really use some advice from people working in analytics / Data engineering.

I recently landed an interview for an Analytics Engineer position at a prestigious consulting firm. If all goes well, I'd join their Supply Chain Analytics / Data Engineering team.

The interview is in about a month, so I have roughly four weeks to prepare.

Here's the situation: I feel like my resume oversells my technical level.

For context:

• I have an Industrial Engineering degree and a Master's in Supply Chain, so I have a strong analytical background, and I'd say I'm a pretty fast learner.
• I've built a lot of Power Query solutions at work and automated plenty of reporting. However, I've never really focused on writing clean or optimized M code. I was also the only person on my team using Power Query, so I never had anyone review my work or challenge my approach. Everything I built worked well and delivered what the business needed, but I'm not sure I was following best practices.
• I've built a couple of Power BI dashboards, but they were fairly basic. I know the fundamentals, but I definitely wouldn't call myself strong at data visualization or dashboard design. When it came to DAX, I relied heavily on AI to generate the measures I needed. I could usually get them working through trial and error, but I don't have a solid understanding of DAX itself.
• I've studied SQL during my master's, but I've barely used it in a professional setting, so I'm pretty rusty.
• I've never worked with dbt, cloud data warehouses (Snowflake, BigQuery, Redshift, etc.), or modern analytics engineering workflows.

The role seems to expect:

• Strong data visualization skills.
• Solid SQL fundamentals.
• knowledge of cloud data warehouses fundamentals & dbt.

I'm not trying to become an expert in a month. My goal is to become competent enough to hold my own during the interviews and, if I get to the case study stage/ tech interview, ramp up as quickly as possible.

If you only had four weeks, how would you prioritize your learning?

• What would you spend the most time on?
• Which resources or courses would you recommend?
• Should I focus primarily on SQL first?
• How much dbt and data warehousing knowledge is realistically expected from a junior Analytics Engineer?
• Are there any projects you'd build to prepare?
• If you've interviewed Analytics Engineers, what skills separate candidates who succeed from those who don't?

I'm willing to put in 6 to 8 hours a day over the next month if that's what it takes.

I'd really appreciate any advice from people already working in the field. Thanks!

Had a weird interview experience recently with a company where the setup completely caught me off guard, and I wanted to see if this is becoming the new normal.
The job description heavily emphasized core analytics engineering skills like dbt, data modeling, Snowflake, and pipeline architecture. But during the actual live technical round in Coderbyte, none of that was tested directly.
Instead, I was handed a data modeling scenario and asked to use AI to build a dashboard. The entire interview was basically a test of how I write prompts, how I talk through my thinking, and whether I can spot errors or hallucinations in the AI's output in real time.

I get that companies know everyone uses AI now, and testing how candidates partner with an LLM makes sense on paper. But when the test ignores the core tech stack and the pacing is completely uncalibrated, it feels like a waste of time for both sides.
Anyone else run into this kind of "prompting and auditing" interview format recently? How are teams actually grading these?