Nowadays, I’m an independent data & analytics consultant. I help mid-size organizations with their high-stakes data-related matters when their internal capability, for whatever reason, is not sufficient. Think non-technical leadership that can’t confidently assess where they stand, an expensive platform with fuzzy ROI, a data strategy nobody’s sure about, delivery that keeps slipping, or an assessment on whether the architecture will hold.

Before that, I spent more than a decade as a Data Engineer and Data Engineering Manager. My last FTE role was at Meta, where I spent almost 8 years helping or running ads ranking teams. I was also a key contributor to their hiring process, running hundreds of interviews across various levels and roles.

What are the different data team structures that you generally work with? In what cases do they shine?

In general, I see two extremes—let’s call them Factory and Artisan.

Factory is like an assembly line. You have many roles with very narrow and well-defined responsibilities. Some people do data quality, others support the platform, yet others do modeling, dashboarding, analysis, etc. You get the point.

Artisan is more like full-stack. The focus is on projects—not roles and responsibilities. In such a team, people do whatever is necessary to achieve the goal. A single person will talk to stakeholders, model data, write ETLs, build the dashboard, and maybe even do exploratory analysis on top of it.

Of course, you rarely see pure Factory or pure Artisan. It’s a spectrum. Usually, organizations are somewhere in between.

Further, these models can operate within centralized teams or decentralized units (data mesh-like).

It would be a lie to tell you one is better than the other. It all depends on context. No team operates outside its organizational background. AI changes things as well.

Statistically, I see more Artisan-like teams in startups, where budgets may be more constrained and people are simply forced to wear more hats. Mature organizations tend toward Factory, which aligns well with more bureaucracy and organizational guardrails.

But again—it’s a trend, not a rule.

I personally prefer an Artisan-like setup, both as an IC and as a leader.

I believe such a wider scope gives more satisfaction, opens the doors for higher impact for the company, and enables better personal growth.

The Interview Process

Nowadays, I do not run structured loops for a single organization. But let me focus on the structure that I’d use if it were up to me.

I will assume a Data Engineering-like position.

There are at least three parts I’d look at: technical skills (can you code?), data architecture design (can you design systems?), and business sense.

Of course, depending on role seniority, the scope would have to be adjusted. I don’t think it’s fair to expect, e.g., solid business sense or complex architecture design for graduate roles.

Why these areas, you may ask?

First, coding. You have to code. No matter what. I’m not buying the argument that because AI is doing coding for us now, we don’t need to know how to code. I see a significant difference between engineers who are strong technically and use AI for coding versus others who can’t and just “vibe code.” I don’t want to hire someone who can’t do a thing when, for whatever reason, Cursor is unavailable. Competition is high. I’d look for someone who can code and use AI efficiently—not just the latter. Being a good coder is, for me, a great proxy for problem-solving, technical fluency, systems thinking, etc.

Next, data architecture. Here, the focus is on design patterns and being able to craft a good design while keeping requirements and constraints in mind. I don’t care if someone knows all the names—it’s not about this or that tool. Data platforms are complex systems with a lot of moving pieces. I’d look for someone who can be pragmatic about design choices while understanding best practices and the consequences of their decisions.

Finally, business sense. I’d say this is the most controversial and least technical skill.

I think it’s highly underrated. When I think about senior engineers, I cannot afford to hire order-takers. I need people who genuinely understand the context, can assess business needs and impact, can challenge me, and proactively propose improvements. Understanding the business is key to this.

AI in Interviews

This is an interesting area. It’s certainly not a topic that can be ignored. AI skills are a must-have, and I’d pass on a candidate who bluntly claims AI is valueless and that they can do better without it. AI literacy has to be evaluated throughout the process.

The big question for me is how to do that. Should it be part of the categories I talked about earlier, or a new, separate one? I’m on the fence.

I’ve seen interview processes that are very AI-encouraging—something like: “Here is the problem, use whatever AI you want to solve it.” I get it. That’s how work happens in reality.

My problem with this approach is that I still want to test the person, not the AI model. The task at hand would have to force a scenario where the candidate evaluates, acts on, and improves the AI output. It can’t be as simple as: write a prompt and solve the problem.

I’m not looking for an AI interface—someone who writes a prompt and copy-pastes solutions. I’m looking for someone who can efficiently use AI alongside their own judgment to arrive at the best solution for the problem.

Sure, models are improving, but—especially in architecture design or when evaluating business decisions—they can still tell you complete BS. An LLM does not care. An LLM does not bear responsibility for what it writes.

It’s the engineer who should care, and it’s the engineer who will be responsible for the work.

I’ll give you a “funny” real-life anecdote. An engineer showed me a detailed design—clearly AI-assisted writing. It was a complete design, even broken down into tasks and time estimates, all produced at impressive speed. The problem? It was an over-engineered solution for an imaginary problem. It didn’t make any sense to build it. We redefined the initial conditions, and the high-level solution changed significantly. After that, the model was run again and outputted a much better design.

An LLM will do whatever you tell it to do. It will not challenge or question the engineer. It can’t do the exact thing I’m looking for in successful candidate.

Conclusions/Closing thoughts

AI is everywhere and here to stay (even if the bubble bursts). It definitely changes interviews. We spoke about the process, but that’s just the tip of the iceberg. There is also everything pre-interview (CVs, screening, and cheating). I’m really interested in how this will shape up over the next year.

There is one thing, though, that I think should not change—ever: we should not stop thinking and problem-solving. If you’re a curious problem-solver, you should be fine.

As for coding itself, I think it is still on the table for now. Maybe that will change in the future—who knows. I’m skeptical about that, but I try to remain open-minded.

If you meet me in an interview sometime in the near future, I will torture you with non-AI-assisted coding, though. Sorry. I don’t care if AI can do it—I need to know that you can do it as well.

I’ve been in data teams where there was not a shit umbrella, a roadmap or a prioritization process at all, that meant that ad-hoc requests drove 100% of the work for the data team. Ultimately, if no sensible process to process ad-hoc request is in place, that translates into the data team picking up the tasks that are more appealing, easier or that are coming from the loudest voice in the room or the folks that they are closer with.

What is an ad-hoc request?

Independently of whether you’re on a central data team, you are the only data person in the company or you are embedded to help a single organization or team, ad-hoc requests are going to come your way. What is exactly an ad-hoc request anyways?

I define ad-hoc requests as anything that is requested of the data team in an unplanned fashion. In the case of data teams that do not have any roadmaps, everything is reactive or unplanned anyways. Examples are:

• Your colleagues from finance asks you for help with a board report

• Engineering asks you to ingest a new data source

• Your lovely business analyst asks you to add yet one additional dimension to wrap up their analysis

• This number looks weird, can you look into it?

All of those examples are unplanned pieces of work that move you from your planned projects to work that you need to react to. Is that the right thing to do in all cases? You may think: “Saying yes to everything will make a lot of people happy in the company and get me promoted quicker, right?”

The problem with saying YES to everything

Saying yes to everything is the easy route. If you have watched the film “Yes, man” where Jim Carrey acts as Carl, saying Yes to everything and embracing life’s opportunities leads him from a boring to a completely new life with lots of adventures and unexpected turns of events.

That works the same way for data work, saying YES to everything leads to all sort of new tasks and unexpected projects you can help with. It is tempting because you’re helpful to a lot of people, you feel like you are moving the needle and doing a lot of work, but it is a bit random and there is not control over any of the work that you have in your plate (neither its value).

Saying YES to everything can be a trap that becomes hard to escape from:

• This behavior turns the data team into a service desk, instead of looking for impactful work to deliver the team optimizes for responsiveness and making people happy, which in the long term leads to not shipping anything strategic that moves the needle

• Burnout, promising to deliver any task that come your way can be a big undertaking, more often than not it leads to overwork and frustration when there is more work than you can possibly do

• When ad-hoc requests are one Slack message away with no-friction, requesters stop thinking much about the ask and send it your way with very little context even if the value is low, having no context make this work not attributable to the data team when valuable, you become invisible since you have no idea of what your work contributes to

• The more responsive you are the more requests you get, which increases the context switching costs and leaves you no time for foundational work (data modeling, documentation, etc) that is meant to reduce requests

There are better ways to manage ad-hoc work than this, they are not hard to learn but it requires of discipline and learning how to find the high value requests and say NO gracefully to the rest. This is how you can make this situation more manageable than flipping a coin in the air to pick the work the data team does and getting promoted quicker.

Instead of saying YES to everything, try and answer these questions in your mind, Is this piece of work valuable? How does it compare to the other projects that I have planned or on the backlog? Is this going to help the company with their goals? Is it helping your data career? Doing more of the same work is rarely the answer to any of those questions and won’t get you promoted. This can be a good time to take a step back and think about how to pick the right projects to work on.

This is a proven method that I’ve used over the years to find the needle in the haystack and reduce the amount of low value tasks I work on.

Handling ad-hoc requests, a simple framework

1. Make all requests visible and tagged, move those from DMs into the public where everyone can see what is requested, tag with the team that started the request

2. Ask follow up questions to find out both the scope and the estimated value of the task, even the problem the person is trying to solve and a bit of business context. You can even move these questions to a form where people have to fill them out before opening the request itself. You’d be surprised how many people would not fill out the request when they start thinking about these things. These questions should be approached from the lenses of trying to find out more information and never confrontational. A few good conversation starters:

   1. What decision is this going to support?

   2. What are you trying to solve with this?

   3. What happens if you don’t receive this?

3. Have a roadmap of key strategic data initiatives that align with company goals, then the conversation becomes about what do we move outside of the roadmap to support the ad-hoc request. In order to achieve this you need to know the business really well, go and talk to people in the business to achieve this one.

4. Analyze your intake to find patterns and commonalities, you can then enable self-service for those if they become a theme, ultimately the goal is to find out, what would have prevented this request in the first place?

5. Of course, and the most important one, we are humans, adding suddenly a lot of friction when there used to be a service desk can lead to rough times where people are unhappy in the short term, make sure you do it incrementally and not all in one go and that you have executive support in case anything gets escalated.

I hope this was useful, it has saved me tons of time working on non-valuable data work.

I’m new-ish to leading a formal data function but not new to data in general and definitely not new to hiring. I’ve spent most of my career in startups. First, in biotech, I spent 6 years in San Diego helping grow a diagnostics company from 5 to 120 employees, then building my own experiential marketing and scenic design business in Oregon to 30 people. I spent the past 5 years co-leading a tech consulting company in Seattle, and most recently have led the data transformation at Washington-based jeweler, GLDN — building out their data team mostly from scratch. You can find him on LinkedIn or his website here.

What are the different data team structures that you generally work with? In what cases do they shine?

I briefly sat on the software team at the biotech company. And it was definitely centralized. I was essentially a product manager, helping design custom diagnostic applications for the scientists to use. But this was less data and more app development. Epic didn’t really have a data team, though everyone was swimming in clinical and experimental data — just doing their own analyses.

At my own business and at ASMBL (consultancy) I was pretty much the data team, with a little support around me to help gather details and build technical scaffolding when needed. I did most of our KPI reporting and benchmarking, and I designed bonus plans around hitting various targets.

Now at GLDN, I sit on a 3-person data team with the occasional expanded contractor support, and I’m attempting to stand up a federated model where I have a BI champion in every department who understands our data and works with the data team closely but can build things for their departments, speeding up the time to delivery and serving as a first line of defense for new requests or bug reports. So far I’d say it’s going well but with mixed results. I underestimated the size of the leap from everyday business work to “data work” for the champions, and I overestimated how much time they’d have to do data work. So we’re doing a lot for them, but their skills are growing!

The Interview Process

I use early screening questions wherever possible. The ones I posted recently for an engineering role were:

1. Describe a data model or pipeline you built that had a measurable impact on a business decision. How did you identify the need, and how did you know it was successful?

2. Describe a time a major data pipeline you owned failed in production. How did you detect it, resolve it, and prevent recurrence? How did you manage stakeholders during the resolution process?

3. What’s a data governance or master data management challenge you’ve encountered, and how did you approach solving it without slowing the business down?

4. Have you designed or maintained data models for consumption by AI systems (e.g., LLMs, agents)? How does that change your modeling decisions compared to building for human analysts?

My goal with these is to focus on personal experiences that can’t be fabricated by AI.

Historically, I’ve been a huge fan of cover letters and would not even read an application if it didn’t have one. Now, thanks to AI, I don’t pay much attention to them anymore.

When it comes to the actual interview, I press them on details, trying to tease out how they think and what they learned from their experiences. I do the same thing based on their resume and/or cover letter. I’ll highlight various things that I want to ask about beforehand and then just probe during the interview.

As someone who has reinvented my career multiple times and had to develop a brand new skill set each time, I wouldn’t consider myself an “expert” in any one discipline and therefore am very rarely going to press on highly technical details. (If it feels necessary, I’ll get one of my more technical team members to do this.) Instead I’m looking for a few things:

• Does this person seem to know enough to be able to reasonably do the job? (I usually know enough about any subject area to at least gauge this.)

• What will it be like to work with them? Are they fun, curious, arrogant, needy?

• Will they fit in well with the rest of my team?

• Are they self-motivated? Can I rely on them to keep pushing even when I’m not around?

I often will ask questions that seem unrelated to the role. One of my favorite questions is, “What is your favorite project you’ve ever worked on, professionally or personally?” And I will get such a wide range of answers to this question. It tells me a lot about people. And I’m really just looking for one thing here: passion. I want to know that this person can get stoked about something, anything really. I’ve always felt that skills can be learned or taught. Passion, substance — those are harder to come by.

AI in Interviews

For candidates: Definitely do the final edits yourself. Use your own language anywhere you can. I think we’re all getting pretty good at recognizing AI slop. And I’m especially suspicious when the resume includes the exact skills I put in the job description, written in my own wording.

For me: I don’t really use AI to screen yet. I scan resumes on my computer, print out the ones I want to interview, and highlight things with a pen. One thing I am doing now is feeling better about assigning take-home assignments for final round candidates, as AI makes this not too big an ask. For example, I’ve got an analyst position open right now where I plan to ask the final candidates to do a quick analysis of GLDN’s competitive position based on any public data they can find. There’s no “right answer” here. I’ll just be testing for innovation, ability to leverage AI to pull things together quickly, analytical thinking, and data storytelling.

P.S. I wrote all the above responses the old-fashioned way. 😉

Conclusions/Closing thoughts

I’m a big culture guy. Just be yourself, be honest, stay vigilant, and you’ll find what you’re looking for. This goes for applicants and hiring managers alike.

Today I serve as a Director of Data Engineering & Analytics at trustandwill.com a series C startup in the USA. We I am responsible for sending out thousands of reports for direct to consumer, and business to business reporting, data governance, security, data platform, BI, AI where it makes sense, and all the stuff that entails for a 100+ person startup in a legal tech field.

I hold no degrees as I was homeschooled growing up, so I backed into data through an business analyst job at a grocery store after stocking selves for years, taught myself SQL because a problem in front of me needed it, then Python, then everything after. More than ten years on, I’ve built data teams from zero to teams of teams, stood up data lakes and lakehouses from scratch, ran data at a behaviour-change startup in NYC, did freelance the consulting stint full time, and interviewed and mentored across hundreds of candidates for engineering, analytics, and data product roles.

Outside of my day job, I write and podcast at Selftaught.engineer . There, I interview people who built their careers despite being told they needed a “degree,” just like I did but typically have unusual paths. This slant influences my hiring process. I don’t look for credentials; I look for people who can solve the problem at hand, time and time again.

I also do a lot of mentoring for early career developers. I help them build personal projects that highlight their actual skills. I want them to show off what they can build rather than listing their grades on a resume. This approach helps talented people stand out even when their background does not look traditional. My goal is to lower the barriers for anyone with a real passion for technology and volunteer and help organize a Data Meetup in Philadelphia https://dataphilly.com/

I also write and run a science parenting podcast with my wife where we talk parenting podcast with my wife

Little Big Humans

raising kids in a crazy ass world and using science to figure it all out

By Tim Frazer

I own/run littlebigthings.co where my wife and I invest in seed level (small cheques like $1-$10k investments into business), or provide advisor roles to companies that don’t have heads of data, or skillsets that we have access to, and we like everyone else with AI develop software to scratch our itches.

What data team structures do you generally work with? When do they shine?

I’ve run and coached most of the shapes: the solo data person, the small centralized team, the embedded/hybrid model at scale.

Solo and small centralized teams are where I’ve spent most of my career, and they shine early when the company needs one coherent foundation, shared patterns, and someone accountable for “is the data actually right?” A few months ago I was solo and the first data engineer in the startup; now we’re a team, and the thing that made it work wasn’t the org chart, it was shared patterns from day one write-audit-publish, testing, alerting and learning how to do data product intake so the team isn’t just a help desk.

Embedded or hybrid models when the bottleneck stops being infrastructure and starts being context. An analyst sitting inside marketing will always understand attribution pain better than one sitting in a central queue.

But honestly, when someone asks me where their data team should sit in the org, my answer isn’t a reporting line ( and I love team topologies). Find the most senior person running the part of the business that makes the money and go solve their problems for them. Proximity to the money beats proximity to the tech. When I coach data teams I ask: how does this company actually make money? A surprising number can’t answer it. And if you can’t, no structure will save and you’ll build beautiful pipelines nobody needed.

The Interview Process

I don’t run the same process for every role, and I don’t do homework assignments for most of them.

For analysts and data scientists, I do set a homework piece but it’s a “trap”.
It’s a complete, realistic-ish scenario, and I assume from the start that most people will use AI to solve it these days. I leave bugs in the gaps on purpose: broken joins in generated data, circular references, and the messy issues you’d find on a real data team. Then I pose questions on top. I’m not marking the code I’m watching whether they notice. The candidates who find the planted problems are the ones who read data instead of just processing it.

For engineers, I’ve moved away from perfect code and TDD purity toward systems thinking. Usually it’s as simple as an Excalidraw board and a bunch of scenarios. What happens if this system goes down? What if you need to scale and I don’t usually mean data volume; sometimes it’s your security posture, sometimes it’s the data model. Everything comes with trade-offs, and I want to hear you reason about them out loud. I do still expect a senior engineers to know the difference between functional and object-oriented programming and testing patterns and trade offs. But the signal I’m after is how you think, not whether you memorised the textbook, and practiced leet code until you barf.

Data modeling is my favorite depth-check. What do you think of dimensional modeling? What is it? Do you know anything beyond star schema? Give me a scenario where you’d use it. Where I work now we run a mixture facts and dimensions where they earn their keep, activity schema alongside. I’m looking for people who grasp the concepts and can iterate around them, not recite them.

And through all of it, one filter matters most to me is do they want to work with the business, or just be technical? The best people I’ve hired lead with business-first questions before they touch a keyboard/Wispr flow.

AI in Interviews

Technical interviewing is broken, and AI broke it faster than anyone wants to admit, I’ve written about this on my substack and linkedin. I’ve had a candidate on Zoom with his hands in the air while his cursor kept moving and code kept appearing. “I’m not using AI,” he said. Yeah right.

Over past year I ran 35+ technical interviews for senior roles & staff engineers, people with Amazon and Bloomberg and Meta on their CVs. Six could finish a 45-minute basic Python challenge, with AI allowed for syntax. Twenty-nine reached straight for pandas on a for-loop problem, and froze when I asked for plain Python.

The problem isn’t cheating. It’s that we’ve trained a generation to operate tools instead of solve problems. People are either capable with AI or helpless without it is what worries me.

So I recently I stopped fighting AI and designed for it:

• AI is allowed for syntax, not solutions most of the time Sometimes I’ll even say: solve it with AI, and let’s walk through your prompts together. How you direct the tool is a skill worth assessing.

• Explain the problem back to me before you code. Edge cases, approach, plain English. Jump straight to code and you fail, every time yeah I’m harsh.

• I plant a test that fails on purpose. I want to see whether you read the tests or just try to make them pass.

• Teach it back. Explain your solution as if I’m a junior engineer. If ChatGPT wrote it chances are you can’t.

For most candidates, my advice is simple. Do use AI I expect you to; pretending you don’t is the real red flag. Don’t outsource the thinking. If you can’t explain the basics of the code when asked, you’ve borrowed understanding. This borrowed thinking often catches up with you, usually around week three of the job after you go live.

Closing thoughts

Everything in my process comes back to one belief: fundamentals are getting more valuable, not less. I borrow a concept from DevOps that my friend Shane Gibson mentioned. Tools will keep changing, and the platforms are like cattle which are swappable every few months. The judgment, the context, the understanding of how the business actually makes money that’s the pet. That’s what I hire for.

And if your background is weird forklift driver, jazz musician, yoga teacher that’s not a gap in your CV. Some of the best engineers I’ve worked with came in sideways. You don’t need the credential. You need to solve the problem in front of you, and then do that again, a thousand times.

The tools genuinely got better and enabled some additional use cases. But the outcome did not change. When better tools stop producing better results, the tool was never the problem.

I think I finally understand what was actually going on. I also think it is changing, for the first time, in a way that is not just another wave. I put a shorter version of this argument on LinkedIn and the replies made it clear I am not the only one who noticed. This is the longer version.

Every wave was built on the same four assumptions

Different vendors, different decades, same underlying bet. Each generation of self-serve tooling assumed four things about the person on the other end. All four are wrong.

Business users want to learn the tools

They don’t. They want answers.

This is not laziness. A product manager has a job, and that job is not becoming proficient in your BI tool. Every hour spent learning saved views, drag-and-drop filters, and why the date picker behaves strangely is an hour not spent on the work they were actually hired to do. We built tools that require training, then treated low adoption as a training problem. It was never a training problem. Nobody woke up wanting to learn Looker.

Business users understand the data

They don’t, and there is no reason they should.

Schemas, grain, and metric definitions are specialized knowledge. I audited a customer reporting dashboard recently where the same metric had three different definitions depending on which filter you clicked. The time series used created_at. The dimension breakdown used closed_at. The summary card at the top used a third timestamp. All three called themselves monthly revenue.

Three analysts made three reasonable decisions in isolation, and the result was a dashboard nobody could trust. If people who work with data full time drift that far apart, expecting a sales lead to pick the correct join and the correct grain is not a reasonable ask.

The right abstraction layer will close the gap

It never did, because the gap is cognitive, not technical.

Semantic layers, catalogs, and metrics stores are genuinely useful. I have built them. What they do is make correct data reachable. What they cannot do is tell someone which question to ask or how to read the answer. Every abstraction we shipped moved the interface closer to the business user while leaving the actual thinking exactly where it was. Tools amplify whatever they are pointed at. Point a friendlier interface at an unsolved comprehension problem and you get a faster route to a confidently wrong number.

Business users know what question to ask

This is the one we underestimate most.

People rarely arrive with a precise analytical question. They arrive with a vague intuition. “Something feels off with churn this month.” “I think the new pricing page is working.” Neither is answerable as written. Turning a feeling into a question with a defined population, a time window, and a metric definition is most of the analysis. It is what a good analyst does in the first ten minutes of a conversation, usually without noticing they are doing it.

Self-serve tools handed people a query builder and assumed that part had already happened.

What changes when an agent sits in the middle

Every one of those assumptions put the burden on the consumer to meet the data halfway. That is the part that is finally shifting.

An agent can interpret fuzzy intent. It can refine a vague feeling into a precise question through conversation, which is exactly those first ten minutes. It can navigate a schema without being taught. It can return an answer without the person on the other end knowing SQL, sitting through training, or being onboarded onto the data model.

The gap does not close by making the human meet the data halfway. It closes by putting something in the middle that speaks both languages.

I have seen this work. On one engagement, 60 people across the company now answer their own data questions daily (That is more than 90% of the company). Most of them DO NOT write SQL. Each saves somewhere between thirty minutes and an hour of waiting per question, and the data team got that time back too.

The catch that decides whether any of this works

Agents inherit whatever you point them at.

Point one at raw tables and hope, and you get hallucinated SQL and confidently wrong numbers, which is worse than a slow answer. A slow answer delays a decision. A wrong answer with a plausible explanation attached corrupts it.

The setup that worked exposed only the curated layer of the warehouse. The same models already trusted for dashboards, with the right joins, the right grain, and metric definitions already baked in. If a model is trustworthy enough for a dashboard, it is trustworthy enough for an agent. If it is not, the agent will find the cracks faster than any human ever did.

Governance and feedback matter as much as modeling. The agent files a ticket whenever a question touches a metric that is not defined or a model that does not cover what is being asked, instead of guessing. Repeat questions upvote the same ticket. The gaps become a ranked backlog of exactly which definitions are hurting the most people, which is the most useful prioritization input I have had in years.

Clean models, well-defined metrics, rich metadata, real governance, deliberate context management. The unglamorous work we have been advocating for a decade is now the infrastructure that enables more use cases to be self-served via agentic data experiences. It stopped being hygiene and became a prerequisite.

To be clear, this still DOES NOT makes full self-service a reality, but it enables more use cases to be solved via this method.

Where the data job goes

The shift is not that AI replaces data people.

It is that the job changes. Less time answering the same basic question for the fortieth time, more time building the context layer that lets an agent answer it reliably. Less ticket triage, more of the specialized analysis that genuinely requires someone who understands both the business and the data.

That is a better job. It is also a harder one, and it rewards a different skill set than the last decade did. The person who can define a metric so precisely that a machine cannot misinterpret it is now worth more than the person who can write the query fastest.

Self-serve was never a broken idea. We just kept asking the wrong side of the conversation to do the hard part.

Know someone whose company is about to buy another BI tool hoping it fixes self-serve? Send this their way. It might save them a procurement cycle.

If your team is drowning in ad-hoc requests and wondering whether an agent layer would help, I help companies build the foundations that make agentic data experiences actually work through data consulting. DM me on LinkedIn/Substack.

Honestly, query.new came out of where the data team was spending its time. So much of the week had become the same handful of things on repeat:

• Pulling the same queries over and over for different people around usage and token spend

• Granting access to the data platform and walking folks through how to pull data themselves, or how to do it in the BI tool

• Building and editing too many dashboards for what were often very simple changes

• “Digging into” analyses that were usually fairly straightforward, but still required a long chain of follow-up questions before I could get people the answer they needed

• Writing reports that were too technical for most of the audience, even though the work often didn’t really require a data person

The pattern that really pushed us over the edge was the start of each month. My backlog of “business critical” requests would pile up, and most of them were simple. They didn’t need a data person specifically; they just needed an easy way to get to the right data.

So query.new is our attempt to take repetitive, self-serve-able work and make it actually self-serve. The goal is to let people get their own answers, build their own dashboards, and dig into questions without waiting on the data team.

The other big motivation is collaboration. We’re spread across the globe, and data work shouldn’t be blocked on one person’s timezone. query.new is meant to make async analysis easier, more accessible, and less dependent on a single data person being online.

What information does the agent have access to?

The agent has access to the following pieces of information via tools in order to run analysis and answer users' questions:

• Curated list of datasets and semantic models from the data warehouse, not every dataset is accessible in order to increase accuracy and only expose the data that is more trusted

• Access to the full transformation layer, from source to curated assets so that the agent can understand how a given column is computed end-to-end, descriptions for columns, sources and datasets, tests etc

• Metric catalog with metric definitions together with tier of importance, business owners, gotchas, filters etc

• Product documents, it is useful to understand how the product works to answer certain questions or identify gaps in our data tracking and modeling assets

• Question <> Query pairs, trusted queries to pull certain business critical common questions

• Global memory, how the same question has been answered in the past

Apart from this we give the agent instructions on how to use those tools and good patterns on how to chain them together and in what order to get the most out of them. Think about how and in what order a data analyst would use these tools to answer a question.

How do we know it’s working at scale?

query.new is an AI agent, not a fixed report. It decides which tools to call, writes its own SQL, and reports numbers back in plain language. That power is also the risk: every time we change a prompt, swap a model, or add a tool, the agent could silently start picking the wrong tool or reporting a wrong number, and nothing would obviously break.

So the real question isn’t “does it run?” it’s “does it still give the right answer after we change something?” We answer that with a regression test suite (we call them evals) built around three questions:

1. Do the right tool calls happen? Does the agent pick and sequence the right tools: e.g. describe a table before querying it, and not run a query when it doesn’t need to?

2. Is the data quality there? There are groups of question and answer pairs we ask the agent that are known to be immutable to evaluate response accuracy and consistency

3. Did functionality drop? Every run is scored and compared against a saved baseline, so any regression shows up as a number going down.

Three tiers, increasing realism

Tier 1: fast, free, automated tests over the tool logic (no AI, no database). These run automatically every night in CI and catch the mechanical breakages: chart vs. Python routing, the “SELECT-only” safety guard, error handling, etc.

Tier 2: the real agent, end-to-end. This drives the actual agent loop against a real (read-only) data warehouse, then grades the result on two dimensions:

• Tool usage: were the right tools called, in the right order?

• Data quality: the hard part: instead of hard-coding an expected number (which goes stale the moment the data changes), we run a trusted reference query at test time to compute the true value, then have a separate AI “judge” compare the agent’s answer against that ground truth. So the test stays valid even as the underlying data drifts.

Tier 3: the whole product. This drives a real session: log in → ask a question → watch the agent work → check the UI; to confirm the full experience holds together, not just the backend.

Catching regressions over time

Each Tier-2 run is scored against a committed baseline. If any case drops by more than a few points, it’s flagged. This is what lets us upgrade models or rewrite prompts with confidence: we can A/B a new model against the suite and see whether quality went up or down before shipping it.

Because Tier 2 and 3 are slower and costlier, they run on-demand/locally rather than on every commit; the fast, free Tier 1 is what gates the nightly automation.

Keeping evals up-to-date

As the product evolves and the data model changes, we automatically get suggestions of areas of the business that get asked questions but do not have eval coverage so that we can act on it.

All this happens automatically, via analysis of past questions and whether the particular area has any evals on the tiers we define.

The agent has to say no

If the answer is not clearly covered by curated datasets, we instruct the agent to say no and flag the data gap in our internal ticketing system. This helps the data team identify gaps and prioritize fixing them. The tool also allows the user to add context on why the data is needed and what is the expected impact of having this data to prioritize the work.

This area is also covered by evals: we want to ensure the agent says no reliably to questions that it can’t answer.

Direct user feedback

The agent gives the user all the pieces of information it can on how the data was pulled, including:

• how the metric is defined

• what entities were used to give an answer

• how they were combined together (in plain English)

• SQL queries (in case you need to share with the data team)

All this information is collapsed by default but the user can expand it to get more confidence in the answer. There are calls to action underneath each agent response: share the conversation with the data team for review, or give thumbs up/down feedback (with optional comments). This helps the data team monitor whether a particular domain is degrading in quality and act on it quickly.

We’re constantly working on improving this agentic Data Platform to give users the best experience we can. At this point 90% of the company is using it on a monthly basis to answer their data questions, while the data team is focusing on fundamentals and the business critical data analysis and explorations.

What’s not fine is how far some companies have pushed it. The interview process for data roles has quietly become something that would be unreasonable in any other context, and most candidates just go along with it because they want the job.

This isn’t me being difficult. It’s recognizing that how a company treats you during the interview tells you exactly how they’ll treat you after you sign. Here are a few real examples where I hit that line.

The full workday disguised as a “round”

I once got asked to complete a take-home test where I had to be available for six hours straight. Not six hours to do the work on my own time. Six hours blocked out, with a meeting right before the slot and another one right after. That’s a full workday. Unpaid. And that was one round. There were several more after it.

I said no.

A take-home that eats an entire day of your time, on someone else’s schedule, without compensation, is not an assessment. It’s a shift. If the company needs that much time to figure out whether you can do the job, either the process is broken or they’re getting free labor out of it.

The “design our entire platform” take-home

I’m not against take-homes. A well-scoped exercise that takes a few hours, that you can spread across a week, and that actually reflects the work you’d be doing? Fine. That’s a reasonable way to evaluate someone.

But another time, I got a take-home that asked me to design an end-to-end analytics platform for a company that didn’t have one. From scratch. Ingestion, modeling, tooling, governance, the whole thing.

I asked what part specifically they wanted me to focus on. The answer was all of it. I tried to scope it down to a specific use case or a specific layer of the stack. They weren’t interested in narrowing it.

That’s not an interview question. That’s a consulting engagement. One that would normally take weeks of discovery calls, stakeholder interviews, and scoping before I’d even start writing a proposal. They wanted it as a take-home.

When the exercise looks indistinguishable from real work that the company needs done, and they won’t let you reduce the scope, it’s hard to read that as anything other than getting a solution for free. Whether that’s the intent or not, the signal is the same: they don’t respect your time.

The fly-out to work for free

One company offered to fly me out to their HQ for a couple of days to work with the team on real tasks, on their real setup. Not a simulation. Not a case study. Actual production work, with actual colleagues, on actual problems the company needed solved. Additionally, the flight would take me more than 20 hours each way.

That’s a trial period. An unpaid one. Dressed up as an interview step.

I get the appeal from the company’s side. You want to see how someone works in the real environment, how they collaborate, how they handle ambiguity. But there’s a word for when someone shows up, does real work for your company, and you don’t pay them. And “interview” isn’t it.

The interview that has nothing to do with the job

This one is subtler but just as telling. When the interview rounds test things you’ll never do in the actual role, that’s a signal. If the job is building dbt models and maintaining a warehouse, but the interview is three rounds of LeetCode and a system design for a distributed streaming platform, something is off.

It means one of two things: the team doesn’t know what they actually need, or they have a template process they apply to everyone regardless of the role. Both are bad. If they can’t design an interview that reflects the real work, imagine what the job expectations look like once you’re inside.

Unreasonable expectations during the interview are a preview of unreasonable expectations on the job. Every time.

The one-round, one-person interview

This one might seem like the opposite problem. No endless rounds, no take-homes, no panels. Just one conversation with one person, and you’re in.

Sounds great until you think about what it means. If one person can hire you after a single conversation, that person is probably the only decision maker. Nobody else’s opinion mattered enough to be in the room. No future teammate got to evaluate you, and you didn’t get to evaluate them.

That tells you something about how the team operates. If hiring decisions are made by one person with no input, what do project decisions look like? What about promotions, priorities, conflict resolution? You’re walking into a place where one person runs everything, and everyone else just goes along with it.

A good interview process isn’t just the company evaluating you. It’s you evaluating the company. When you only talk to one person, you’re making a career decision based on a single data point. You don’t know what the team dynamics are like, how people collaborate, or whether the culture the interviewer described is the one that actually exists.

Where I draw the line

I want to be evaluated. I want the company to feel confident that I can do the work. And I want to feel confident that the role is what I think it is. A good interview process does both.

But I’ve stopped pretending that every process is reasonable just because it’s what the company decided. Some of them are broken. Some of them are extractive. And the only way they change is if enough people say no.

If the interview respects your time and tests what the job actually requires, I’m all in. If it doesn’t, that tells you everything you need to know about what comes after.

What’s are some interview experiences you’ve had? And what do you think a good interview process actually looks like? I’d love to hear it.

Estelle’s path into data wasn’t a straight line. She started in hard sciences, picked up a data science specialization with a minor in entrepreneurship, then bounced through business analyst, data scientist, data engineer, and finally analytics engineer before landing in management. Each pivot was driven by the same question: how do I get closer to the business without giving up the technical side? Analytics engineering was the answer she stuck with.

I talked with her for about an hour about how she structured the data team at Vercel, the trap of embedding data people inside business functions, the four-stage interview process she ran for her hires, and why the loudest voice in the room is the wrong one to optimize for.

Who is Estelle

Estelle came up through engineering — sciences first, then a data science specialization at the end of college. Her first job was as a business analyst at a startup, which she took on purpose: she wanted to understand how finance, sales, marketing, and customer success actually worked before getting more technical. Then she swung the other direction into data science, found it too disconnected from the business, and finally landed in analytics engineering when the role was just starting to gain traction. That mix of business context and technical depth is what made it click.

She’s worked as an analyst, a data scientist, a data engineer, and an analytics engineer across multiple startups (and one big company). She framed that T-shape — knowing a little about everything before specializing — as a useful mindset for data people, since data jobs naturally pull from a lot of different skill sets. Her last role was Senior Analytics Engineering Manager at Vercel, the frontend and AI cloud platform.

She became a manager because she liked mentoring people long before it was officially in her job description. Coaching, helping people grow, that part of the work is what made the transition feel natural.

How the Data Team at Vercel Was Structured

Centralized, with horizontal and vertical layers. The functions were analysts, analytics engineers, and data engineers. No data scientists. Each person had a specialty area — marketing, sales, product — because building data for a function requires real context, and Estelle didn’t want her team constantly switching between domains.

The thing she was strict about: no embedding. Even though analytics engineers had a specialty, they did not “belong” to the business team they supported. That distinction matters more than it sounds.

Her reasoning: when you embed a data person inside a business team, that team starts treating them like a member, which means they get asked for whatever pops into someone’s head. The job of a data team, in Estelle’s view, is closer to a product team. You extract the underlying problem the business is trying to solve, then design a solution that actually answers it. If you ask people what they want, you’ll get faster horses. The job is to deliver the car.

There’s a framing from this part of the conversation I want to surface, because I think a lot of people need to hear it:

“I never want the loudest voice in the room to set the priority list.”

The way she depersonalizes prioritization: think about what the data is about, not who’s asking about it. Customer success wants product data. Product wants product data. If they each get their own model, you end up with two different numbers for the same question and a credibility problem you can’t easily walk back. Centralize the source of truth, prioritize by ROI to the company, and the politics get a lot quieter.

She also talked about the temptation to chase shiny new requests — what she called butterfly chasing. The better move is to step back and ask: can I build a dataset that will answer this question, and the next ten variants of it? Reactive work feels productive, but it traps the team in a loop of answering the same question with slightly different framings forever.

The Interview Process

Vercel ran four core interview stages. Same shape as most tech companies, with one structural choice that’s worth calling out.

Getting into the pipeline

The first hurdle is the screening algorithm — keyword filters, experience filters, AI or otherwise. Estelle’s advice on this part is direct, especially for women in the industry:

Apply even when you don’t match every requirement. There’s well-documented research showing women only apply when they hit close to 100% of the listed requirements, while men apply at 50–60%. And the requirements themselves are often nonsense — she’s seen listings asking for ten years of experience with dbt when the tool has only existed for four. If the role looks like a real fit and you hit 60–70% of the asks, apply.

Beyond the resume, she emphasized two things hard. One, use AI properly: feed your resume and the job posting to an LLM and ask it where the gaps are, what to rephrase, how to mirror the language. Two, use your network. Half the pipeline at some companies is referrals, and some roles never even make it to the public listing. The version of networking she means isn’t cold-DMing strangers on LinkedIn — it’s genuinely connecting with the people you work with, taking the time for small talk, building relationships you don’t immediately try to extract value from.

Screening interview

For data team hires, the first recruiter screen checked the basic technical baseline — SQL, Python, whatever the role required. Roughly the same conversation you’d get at most tech companies.

VP interview

A short, high-level conversation with the VP. An early read on cultural and experience fit before the rest of the loop.

Hiring manager interview

This was Estelle’s stage. Equal weight on technical and cultural signal.

Stakeholder interview

For analytics engineering specifically, this round simulated the day-to-day of working with the business: how do you handle a stakeholder request, how do you ask clarifying questions, how do you communicate trade-offs. An analyst or business partner ran this one.

One thing she deliberately doesn’t do

A separate culture interview. Her view: culture is something you should be reading throughout every conversation in the loop, not extracting in a forced 30-minute round. The people running dedicated culture interviews are often disconnected from the actual work, and the questions (”do you like tech?”) almost answer themselves. She’d rather give every interviewer a small section in the rubric to note their read on values across the full conversation.

The Technical Round

The thing she pushed back on hardest in our conversation: SQL puzzles and “make this query better” tasks. She doesn’t do them. Take-homes either.

Her technical interview is one open-ended problem. Big, ambiguous, deliberately under-scoped. Her job is to watch how the candidate thinks, not whether they arrive at a correct answer. She adapts as the conversation goes, plays the stakeholder, throws in “what if this happens?” follow-ups. The point is to simulate real work, where problems show up unscoped and someone has to figure out what’s actually being asked before writing a single line of code.

Her framing of engineering: it’s the practice of making trade-offs between imperfect solutions. The candidates who can reason about those trade-offs out loud, who ask the right clarifying questions, who can sketch a path forward without freezing — those are the ones who keep being useful when the technology stack changes underneath them. Tools come and go. The thinking doesn’t.

AI in Interviews

Two layers, and they’re both worth getting right.

The first is whether you use AI at all. Most tech companies now expect you to. Showing up to an interview pretending you don’t use it is the wrong instinct. The interesting question is how you use it — and specifically, how you handle the moments when it’s wrong.

The second is critical thinking. AI is good at answering questions where the answer is well-documented, which is why software engineering tooling has gotten strong fast. The data world is messier. Best practices are recent, contested, and often domain-specific. Estelle still tests for whether candidates can push back on what an LLM tells them, recognize when the answer doesn’t quite fit, and reason from first principles when the documentation isn’t clear yet.

Her standard: use AI to augment your work, but keep the steering wheel in your hands.

The thing that stuck with me

The “loudest voice in the room” line stuck, but the deeper version of that idea is what I keep coming back to.

Most data team dysfunction I see in coaching conversations isn’t a tooling problem or a technical skill problem. It’s a prioritization problem, and it usually comes from teams that have lost the ability to push back on the next loud request. Estelle’s structural answer — centralize, specialize but don’t embed, prioritize by what the data is about rather than who’s asking — is one of the cleanest framings I’ve heard for keeping a data team out of that trap.

The data teams that hold their shape under pressure aren’t the ones with the best stack. They’re the ones that have decided, on purpose, what they’re optimizing for — and have a manager willing to defend it.

Know someone preparing for a data interview, or building out a data team and trying to figure out the right structure? Send this their way. The structural and interview decisions Estelle talked about are the kind of thing that’s hard to find written down.

Brandon has been at dbt Labs for almost five years. Long enough to have seen the data team grow from early scrappy days to a structured four-function organization. He came up through analytics, then analytics engineering, then shifted left into data engineering. The classic path. But he started somewhere unusual: an undergraduate degree in Business and Competitive Intelligence, which he describes as “the intersection of how businesses can use data.” Not many people can say that.

I talked with him for about an hour about how dbt Labs thinks about its data function, the stages of their interview process, and something that came up twice in our conversation from two very different angles, how AI is reshaping what it means to hire and be hired as a data professional.

Who is Brandon?

Brandon started in analytics after college, pulled in by that competitive intelligence foundation from his undergrad. The shift from analysis to something further upstream happened the way it usually does: you keep running into problems that live one step before the data you’re working with, and eventually you decide to go fix them yourself. He moved into analytics engineering, then data engineering, and has been managing the DE function at dbt Labs for several years.

What makes his context different from most data managers is that dbt Labs isn’t just a company that uses dbt. It’s the company that built it. He’s managing a data team that also contributes to the product they work with every day — and a dbt project that almost everyone in the business touches in some form. That’s a different kind of scope.

What is dbt Labs?

dbt Labs brings software engineering best practices like testing, versioning, and documentation to the world of analytics, helping data teams build with confidence. The core idea: you store all your business logic as models within a project and execute those models against your data warehouse. First class testing, organization, version control for your transformations. dbt Labs has also built orchestration, a semantic layer, and cataloging on top of that.

If you’re in data, you already know what dbt is. But it’s worth naming what it means to work on the data team there. You’re not just a user of the tool. You’re expected to understand it well enough to contribute feedback, help the rest of the company use it well, and in some cases contribute to the project directly.

The Data team at dbt Labs

Four functions. Data engineering handles making data accessible — ETL pipelines, event streams, the infrastructure that makes analytics possible. Analytics engineering embeds business context into that data: modeling, metrics, sometimes reporting. Analysts sit closer to what other companies would call data scientists, working through ambiguous questions that don’t have a clean query behind them. And a BI team manages the central artifacts and owns the self-serve culture.

That last part is specific to dbt. Everyone in the company has access to data and is expected to use it in their day-to-day. The BI team’s job isn’t just to build dashboards. It’s to make sure the whole organization knows how to use them.

The architecture is centralized, with spokes in go-to-market and other functions that the data team supports. And because so many people across the business contribute to the dbt project itself, “centralized” means something slightly different there than it does elsewhere. You’re managing a shared artifact, not just a team.

The Interview Process

Before you apply

Brandon partners with the talent acquisition team before a role opens. They align on hard skills, but also on the type of person they need at that specific moment in the team’s growth. An early team might need someone who can operate autonomously and move fast. A more mature team might need someone focused on process and operational rigor. That profile gets defined upfront and shapes everything that follows.

Resume and cover letter review

Brandon and the TA team review applications together. If you’ve hit the core criteria, you move to a TA partner review stage before any interviews start.

Talent acquisition screen

The first human conversation. Hard skills validation, confirming genuine interest in the role, work authorization. Standard stuff.

But Brandon mentioned something I hadn’t heard from other hiring managers quite so directly: they’ve added a step to verify that you’re a real person. The volume of AI-assisted applications has climbed sharply. Polished resumes that look like a great fit, followed by a no-show on the first call. The TA team now explicitly looks for signs of authentic, lived experience from the very first conversation.

Hiring manager screen

Brandon runs this one. It’s designed to go both ways.

On his side, he’s listening for examples from your past — things you’re genuinely proud of and mistakes you’ve actually learned from. The question about failure isn’t a trap. It’s one of the more useful signals he has. He wants to know if you’re the type of person who can be honest when something didn’t go well and clear-eyed about what you’d do differently.

On the candidate side, he leaves real space for questions. His job at this stage is to make sure the role is genuinely a good fit, not just to sell it. If you’re asking thoughtful questions about the team and the work, that’s something he’s actively paying attention to.

Technical round

No take-homes. dbt Labs uses whiteboarding for all their team interview rounds.

The technical round is a system design or problem-solving session in a relevant area. Brandon described their evaluation framework in a way worth capturing directly. It moves through four levels:

1. The candidate is unfamiliar with the concepts this role requires.

2. The candidate knows the theory.

3. The candidate has done this before.

4. The candidate has done this before, considered the edge cases, and could teach you something in the process.

That fourth level is the thing. Not someone who can execute. Someone who has thought deeply enough about the problem to surface things you hadn’t considered.

Business context round

This round simulates working with stakeholders. At dbt, the data team is expected to act as advisors to the business — even data engineering. How you partner with stakeholders, how you ask questions before jumping to solutions, how you communicate clearly about what’s possible — those are the things being tested here. The whiteboarding session is designed to surface whether you’ve developed your own real approach to that over the years, or whether you’re still figuring it out.

Values and culture alignment

The final team round. Technical ability and business fit are established. This one is about how you handle conflict, whether you communicate openly, and whether you contribute to the knowledge loop rather than hoarding context.

At dbt specifically, there’s one more question embedded here: do you have any interest in contributing back to how the product is developed? The data team isn’t just a user of dbt. They’re part of the feedback loop that shapes it. It’s not a hard requirement, but it matters.

The thing that stuck with me

Brandon brought up AI twice, and both times from a different angle.

The first was the operational problem: AI-assisted applications have made the early screening process harder. Volume is up, the signal is noisier, and the team now explicitly validates lived experience throughout every stage.

The second was more interesting. He doesn’t want candidates to hide their AI usage. He expects it. Every candidate he interviews should have a perspective on how they use AI, the situations they’d apply it to, and the guardrails they’ve developed for themselves. Not “I use AI sometimes.” Something more specific: here’s how I’d use it in this kind of problem, here’s where I wouldn’t, here’s what I’ve learned about where it falls short.

A year ago, showing AI usage in an interview felt like admitting to something. At dbt Labs, not talking about it is the flag.

The data professionals who stand out in the next round of hiring won’t be the ones who avoid AI. They’ll be the ones who’ve developed a real, considered relationship with it — and can talk about it honestly.

dbt Labs is looking for a Senior Data Engineer right now, DM me “dbt Labs“ on LinkedIn if you’re interested.

I offer 1:1 and group coaching sessions focused on interview preparation for data roles — from application strategy to hiring manager screens to technical rounds. DM me “MENTOR” on LinkedIn if you want to learn more.

That’s a problem. Because recruiters aren’t just reading applications, they’re actively searching LinkedIn for candidates. If your profile doesn’t contain the keywords they’re searching for, you don’t show up. It’s that simple.

I mentored someone who had completely neglected his LinkedIn profile. After we optimized it together, 60% of his interviews came from recruiters reaching out directly. He didn’t apply for those roles. They found him. That shift came from making his profile match what recruiters were actually typing into their search bar.

Profile picture

Your profile picture is one of the few visual elements in an otherwise text-heavy profile. It shows up everywhere — next to your posts, your comments, your name in search results. Not having one makes your profile feel incomplete. Think about it the other way around: if a recruiter reached out to you from a blank profile with no photo, you’d probably ignore it. Same applies in reverse.

It doesn’t need to be a professional studio shot. A smartphone photo against a clean wall with decent lighting works. The bar is lower than people think. There are some AI services that generate professional quality pics.

Headline

Your headline appears under your name everywhere on the platform: search results, posts, comments, your profile page. But depending on where it’s shown, it gets truncated. In the feed, only the first part is visible. Everything after that gets cut off.

This means the most important information needs to go first. If your headline starts with certifications, emojis, or motivational phrases, the part that actually says what you do might never be seen.

I’ve reviewed hundreds of LinkedIn profiles through mentoring and my workshop. The ones that work put the role and core skills upfront. If a recruiter searches for “data engineer” and your headline doesn’t say it, you’re not showing up.

Experience section — impact over tasks

Each role has a title, company, description, and skills. The title matters more than people think, it’s searchable and it signals your level. If your company gave you an internal title nobody outside the org would understand, consider using the industry-standard equivalent.

Titles also show career progression. “Data Engineer” at one company, “Senior Data Engineer” at the next, that tells a clear story without the recruiter reading a single description.

For descriptions, focus on what changed because of your work. “Built dashboards” tells me nothing. “Built a self-serve dashboard layer that reduced ad-hoc requests by 40%” tells me the impact. I wrote about this in detail in the CV Roast Series. The same principles apply to your LinkedIn experience section. Quantify where you can.

Skills

You can add skills per role, and they’re searchable. If a recruiter filters for “Snowflake” and you don’t have it listed, you’re invisible to that search.

Don’t repeat the same skill on every role. Spread them out to show breadth and progression. Data modeling on one role, pipeline orchestration on another, stakeholder management on a third. Also add them to the dedicated skills section. The more keywords you match, the more searches you appear in.

Messaging settings

This one is surprisingly common and easy to fix. Some people have their LinkedIn settings configured so that people outside their network can’t message them. If a recruiter finds your profile and can’t send you a note, that opportunity disappears and you’ll never know it existed.

I’ve seen this happen from the hiring side. You find someone who looks like a strong fit, try to reach out, and the platform won’t let you. You move on to the next candidate. It takes five seconds to lose an opportunity you didn’t know you had.

Check your settings and make sure recruiters can contact you. A few spam messages are a small price compared to missing the right role.

Your narrative

Every piece of your profile (photo, headline, about, experience, skills) should support one story. Decide what that story is before you touch anything. That’s your narrative. Everything else either supports it or dilutes it.

Applying for jobs is one channel. Making yourself findable is another. Do both.

Know someone whose LinkedIn profile could use some work? Send this their way. A few small changes can be the difference between being invisible and getting found.

I offer 1:1 and group coaching sessions focused on interview preparation and career strategy for data roles, including LinkedIn profile optimization. DM me “Invisible” on LinkedIn if you want to learn more.

Thomas didn’t come up through a traditional data path. He spent time in the Navy, then transitioned into teaching, and it was there that he started noticing how quantitative and qualitative thinking intersect. That observation eventually pulled him toward a master’s degree in predictive analytics, and from there into a career in data across a range of companies, each one teaching him something different.

I spoke with him for about an hour about his background, how he thinks about data work, and what the hiring process actually looks like from his side of the table. A lot of what he said lines up with what I’ve seen in coaching, but hearing it directly from someone doing the hiring adds a different kind of weight to it.

Who is Thomas

Thomas started in business intelligence at a smaller company in New Orleans, one he’s candid about not fully understanding at the time. “I didn’t really understand what the term ‘intelligence’ in business intelligence meant,” he told me. Someone took a chance on him, gave him the opportunity to learn on the job, and that experience shaped a lot of how he thinks about hiring today.

That company was eventually acquired, and he moved on to join GitHub before the Microsoft acquisition, which he describes as a fascinating transition to witness. It gave him an unusually clear view of how metric culture shifts when a company changes ownership and scale. This is where Thomas started his data interviewing journey, running business and technical screeners.

From GitHub he went to Vercel, where there was no data team to join. He helped build it from scratch, which forced him to think on multiple levels at once: how do you answer questions today while also laying infrastructure that won’t need to be rebuilt every time a new question lands in the queue? The invisible work that only becomes visible when it breaks.

He’s now at StackBlitz, working on a developer tool product where the infrastructure and data models were already in good shape when he arrived. The current work is less about building and more about optimizing, helping people get the most out of what’s already there.

Outside of work, he builds machine learning models from scratch in his free time. His master’s is in predictive analytics, and it’s a space he’s never stopped caring about even when the day job didn’t call for it.

What is StackBlitz

StackBlitz is a developer tool company, and Bolt.new is their flagship product, an AI-powered development platform that lets you describe what you want to build in plain language and get working code back. Think full web apps, landing pages, SaaS tools, mobile apps, all generated through conversational prompts. It integrates with GitHub, Figma, Stripe, and Expo, and includes built-in databases and hosting. The pitch is simple: code when you want, prompt when you want. It’s a startup, smaller in size, with a data team that was already functioning when Thomas joined. The scope of data work there is broad by design: you’re touching many different systems rather than going deep on one.

He made a distinction I thought was worth capturing. When I asked about the kind of data engineer they’re looking for, he was clear: not someone who’s spent five years deep in Kafka managing petabyte-scale distributed systems. That might be the right hire at Amazon or Meta. At StackBlitz, the role is more general, pipelines, analytical systems, working with tools like Snowflake, supporting business questions across functions. The specificity of what companies look for in a data hire is tightly correlated with their size and maturity.

The Data Team at StackBlitz

Thomas has worked across multiple data team structures over his career, centralized, decentralized, and hybrid, and he frames the choice between them as a trade-off rather than a preference.

In a decentralized model, a data person might sit embedded in a product or business function, acting almost like an unofficial member of multiple teams at once. In a centralized model, the data function operates more like an internal consulting group, sometimes contractually assigned to a department, but ultimately reporting back to a central team. The hybrid tries to get the benefits of both, though it comes with its own friction.

His read on the trade-off: it comes down to how much error tolerance you’re willing to accept versus how quickly you want to ship and get insights in front of stakeholders. There’s no universally right answer. It depends on what the business actually needs at that moment in time.

He also talked about something that I think is underrated in how data professionals think about their own work: the difference between levers and metrics. His view is that the instinct to directly optimize your final metrics, ARR, revenue, whatever the “boss metric” is. You want to identify and to work on the upstream inputs or “levers”, the things you can actually manipulate that then influence those final numbers. You pull on a lever; the metric responds. That framing shapes how he thinks about what data work is really for.

The Interview Process

Thomas has been a hiring manager at both Vercel and StackBlitz, exclusively for data roles, engineers, analysts, analytics engineers, data scientists, and occasionally adjacent roles like strategic finance.

Here’s how the process typically runs, from his perspective:

Stage 1: The automated filter

Before a human ever sees your application, it goes through a boolean pass/fail filter. Location, years of experience, work authorization, if the job says remote, it might mean remote in specific countries only. These filters exist in the initial application questions. If you don’t pass, you don’t make it to review. Read the application carefully before you submit.

I covered how this works in more detail in what actually happens after you click apply.

Stage 2: Application review (key terms matter here)

This is where a recruiter or hiring manager scans your resume and cover letter. They’re looking for key terms and 95% of those terms are directly on the job description. Mirror that language in your resume. Thomas was clear that he personally doesn’t weight any one keyword more heavily than another, but he does look for whether someone has a holistic understanding of the function. A resume that reads as if you understand why the role exists is more compelling than one that’s just a list of technologies.

On cover letters: he reads them when they’re included, but cares less about keywords there. He wants the cover letter to feel human, not like a second copy of your resume with different formatting.

Stage 3: Recruiter screen

Short, high-level. The recruiter is checking for culture fit and whether you can speak to your experience beyond just reciting your resume back to them. They already read it. What they want is a bit more context, why this role, why this company, why does your background make sense here.

Stage 4: Hiring manager screen

This is Thomas’s stage. And his framing was direct: he’s not primarily evaluating technical skills. He’s evaluating whether this is someone he’d genuinely enjoy working with.

“I just look for someone I enjoy spending my time with,” he said. “A smile goes a long way. I’ve had interviews where someone was visibly nervous, and I’ll say: hey, I get nervous too. You’re allowed to be nervous.”

Once that human connection is established, he moves into the substance: How does your background apply to the business? Not just the data problems but also the business problems. What have you failed at? How did you learn from it? How do you answer questions today in a way that builds reusable systems instead of creating a queue of one-off requests? He’s also explicitly looking for people who don’t want to be the hero on the team but who want to be a teammate.

Stage 5: Cross-team and technical review

The cross-team meetings are largely about confirming you can work across the organization. The technical take-home, if there is one, is a thin slice of actual day-to-day work, but it’s not really about getting the right answer. It’s about watching how you think: what assumptions you make, how you approach an unfamiliar problem, whether you can navigate ambiguity without falling apart.

I’ve written about this from the interviewer’s side in the context of SQL screeners, the same principle applies to take-home exercises. The artifact matters less than the thinking behind it.

Stage 6: Founder or C-level interview

The final stage before an offer. Usually brief a gut check from leadership that they’re aligned on the hire and cultural fit.

The thing that stuck with me

Thomas has worked at companies ranging from pre-acquisition GitHub to Vercel to a startup in New Orleans. The common thread isn’t a specific tool or a particular data stack. It’s a consistent belief that data work is about understanding the relationship between what users do and what the business needs and building systems that can answer that question today, and again six months from now when the question has changed.

The best data professionals he’s hired aren’t the ones who knew every tool. They’re the ones who could sit across from him and talk through a problem like a teammate would.

That’s a harder thing to fake than a keyword match.

Know someone navigating data interviews right now? Send this their way. Hearing the process from the hiring manager’s side changes how you think about every stage.

I offer 1:1 and group coaching sessions focused on interview preparation for data roles, from application strategy to hiring manager screens to system design conversations. DM me “THOMAS” on LinkedIn if you want to learn more.

I’m not going to cover SQL preparation, there are tons of great resources for learning syntax, window functions, CTEs, etc. If you need to brush up on that, do it before the interview. The screener is not the place to learn SQL.

What I am going to cover is how to execute the interview itself. The stuff that separates candidates who know SQL from candidates who actually pass. I’ve been on the interviewer side of this hundreds of times and the patterns are clear, most people don’t fail because of SQL knowledge. They fail because of how they approach the problem.

If you’re an interviewer, this is also what I’d recommend looking for when evaluating candidates. The SQL is table stakes. Everything else is signal.

The most common mistakes

Rushing past the problem statement

I’ve seen candidates start writing SQL within 10 seconds of receiving the problem. They skim the description, glance at the schema, and go. Then halfway through they realize they misunderstood what was being asked and have to start over.

Take a minute. Read the full problem statement. Read it again. Look at the table schemas, check the column names, understand the relationships. If there’s sample output, study it, it often tells you exactly what the expected granularity is (one row per user? per day? per transaction?).

The time you “save” by jumping in fast is almost always lost later when you’re debugging a query that was solving the wrong problem from the start. I’d much rather see a candidate spend 2-3 minutes reading and thinking before writing than someone who starts immediately and backtracks twice.

Not talking

This is the number one killer. I’ve watched candidates write perfectly correct SQL in complete silence for 30 minutes. They get the right answer and still don’t get picked.

Why? Because I can’t evaluate what I can’t see. If you’re silent, I don’t know if you understood the problem, got lucky, or memorized a pattern. I don’t know if you considered edge cases and decided to skip them, or if you didn’t think of them at all. The SQL is just the output, your thought process is also graded. If 2 candidates get the right answer but one of them walks me through the thought process, it gets more chances to get picked.

There’s a practical side to this too. When you don’t explain your thinking, I have less to work with to help you. A good interviewer wants to nudge you in the right direction if you’re going off track, but if you’re silent, I have to stop you and ask follow-up questions to figure out where your head is at. That takes time away from you actually solving the problem, and it takes a lot more effort from both sides.

Talk through your approach before you write. Explain why you’re choosing a LEFT JOIN over an INNER JOIN. Say out loud “I’m filtering before the aggregation because...” It’s how you show me you actually understand what you’re doing vs reproducing something you practiced, and it gives me the context to support you if you need it.

Not asking questions

A surprising number of candidates get a problem statement and immediately start writing. No questions. No clarification. Nothing.

This is a red flag. In the real job, requirements are never perfectly clear. If you don’t ask questions in an interview, a controlled environment where the interviewer expects it, I have no confidence you’ll ask them when it actually matters.

Before you write a single line, ask things like: “How do we define an active user here?” “Should I include nulls or exclude them?” “What time zone are these timestamps in?” “Is this a one-time analysis or something that would run daily?” These questions show me you think about the problem before you think about the code. That’s exactly what I want in someone who’s going to work with stakeholders.

Even if you think you understand the problem, ask anyway to validate your assumptions. You might surface an assumption you didn’t realize you were making.

Not knowing how to debug

Your query will fail. It almost always does on the first try. That’s fine, I expect it. What I don’t expect is someone staring at a broken query with no idea what to do next.

The most common version of this: the query returns unexpected results (too many rows, wrong numbers, nulls everywhere) and the candidate just... tweaks things randomly. Adds a DISTINCT. Changes a JOIN type. Throws in a WHERE clause. No reasoning, just trial and error until something looks right.

What I want to see is structured debugging. “I expected 100 rows but got 500, so there’s probably a many-to-many relationship in my JOIN, let me check.” Or: “This column is showing NULL for every row, let me verify the join key is matching correctly.” Read the error message. Actually read it. A lot of candidates glance at an error and immediately start rewriting instead of reading what the database is telling them.

A big part of this comes down to understanding how SQL actually executes. If you don’t know that WHERE runs before GROUP BY, or that you can’t reference an alias in the same SELECT clause where you defined it, you’ll make mistakes you can’t explain. Knowing the execution order of SQL helps you debug systematically instead of guessing.

Forgetting edge cases

This one separates good from great. Most candidates write a query that works for the happy path. But real data is messy.

What about users who signed up but never made a purchase? What about duplicate records? What about NULL values in the join key? What about time zone differences in timestamps?

You don’t need to handle every edge case, the interview has a time limit. But mentioning them matters. “I’m assuming there are no duplicate orders here, but in production I’d add a dedup step” shows me you think about data quality. Silently ignoring edge cases tells me you didn’t notice them.

Know someone preparing for data interviews? Send this their way

It’s a simulation of the first week on the job. Can this person take a vague business question, sit down with a dataset they’ve never seen, and get to an answer on their own?

That’s it. That’s what I’m evaluating.

What the SQL screener actually looks like

The format

The format varies by company, but the core is always the same: you get a dataset, one or many business questions, and somewhere between 30 and 60 minutes to write SQL that answers it.

The tools

Some companies use platforms like HackerRank or CoderPad, where you type into a browser-based editor and run queries against a pre-loaded database. Others do it over a video call with a shared screen — the candidate works in their own SQL environment while the interviewer watches. A few will hand you a schema diagram and sample data and ask you to write queries without executing them, though that’s less common now.

The questions

The business question is usually something like “find the top 10 customers by revenue in the last 90 days” or “calculate the month-over-month retention rate for users who signed up in Q1.” Sometimes there’s expected output to compare against. Sometimes there isn’t, and part of the evaluation is whether you can figure out what the answer should look like.

What the interviewer is watching

On the interviewer side, I’m watching everything. Not just the final query — how you read the problem, how long you spend before typing, whether you explore the schema, how you react when something breaks. The SQL is the artifact. The process is the evaluation.

Writing SQL is part of it, obviously. But it’s the minimum. What I really want to know is: can you operate independently? Can you read a problem, figure out what’s actually being asked, make decisions about how to approach it, and unblock yourself when something goes wrong? Because that’s what the job looks like every day. Nobody is going to sit next to you and tell you your JOIN is wrong or that you misread the requirements.

The candidates who pass aren’t always the ones who write the best SQL. They’re the ones who show me they can think through a problem end to end — from understanding what’s being asked, to writing something that works, to catching their own mistakes.

The ones who struggle usually aren’t struggling with SQL. They’re struggling with everything around it: reading the problem carefully, asking the right questions, talking through their approach, debugging when things break, and noticing edge cases that would bite them in production.

If you’re preparing for a SQL screener, stop thinking of it only as a coding test. Think of it as: “can I convince this person I’d be productive on day one?”

That reframe changes how you prepare.

Know someone interviewing for data roles right now? Send this their way. Understanding what the interviewer is actually looking for changes everything about how you prepare.

If you want to practice this in a live setting with real feedback, I’m working on something. DM me “SQL“ and I’ll keep you posted.

Some of them were genuinely excellent. Clear, focused, easy to scan. Others had the same mistakes I’ve seen many times over the past decade reviewing CVs at Meta, GitHub, and Vercel. The good news? The gap between a forgettable CV and a strong one is usually smaller than people think.

I’m turning the patterns I found into a series. Each edition will focus on one specific thing you can fix. All examples are real (anonymized, of course), from both the CVs that impressed me and the ones that need work.

This first one is about the single biggest issue I saw across almost every submission: how people talk about their experience.

Why Impact Matters More Than Anything Else on Your CV

Yesterday I talked about the three filters your CV goes through: ATS, recruiter, hiring manager. Each one spends seconds deciding if you’re worth a conversation. In those seconds, they’re not stopping to admire your tool list or count your years of experience. They’re looking for one thing: did this person can work here effectively and make a difference?

That’s impact. Not what you were assigned to do but what changed because you did it.

Most CVs I reviewed describe tasks. “Built pipelines.” “Created dashboards.” “Managed data sources.” These tell me you had a job. They don’t tell me you were good at it. Every other candidate applying for the same role has similar tasks on their CV, because the tasks come from the job description, not from you. What separates you is the outcome, because that’s the one thing that’s unique to how you did the work.

Impact is what makes a recruiter stop scanning and actually read. It’s what makes a hiring manager want to interview you. Without it, your CV is just a list of things you were told to do.

There’s a framework that makes this easier than it sounds.

The XYZ Formula

It was popularized by Laszlo Bock, Google’s former SVP of People Operations, and it goes like this:

Accomplished [X], as measured by [Y], by doing [Z].

X is what you achieved. Y is the number that proves it. Z is how you did it.

One important thing: numbers need context. “Improved performance by 12%” doesn’t mean much on its own. Is that going from $100 to $112, or adding $1.2M to a $10M portfolio? When you can, pair the percentage with a dollar amount or a baseline comparison so the reader can calibrate the scale of what you did.

And this isn’t just for senior roles or people with access to revenue numbers. Even a service role can use it: “Served 85 customers per day with 100% accuracy, compared to an average of 70 customers at 90% accuracy for peers.” This one does not have revenue figures or fancy title, just a clear comparison that shows you were above average. Whatever your role, you can find a way to quantify your work relative to something (it is stronger if you use a business metric)

Let me show you with real examples from CVs I received. These are all from actual submissions, anonymized.

Needs work

“Replaced manual ingestion and laptop-run dbt with a production platform.”

This tells me something changed, but not why it mattered. How manual was it? How long did it take before? What does “production platform” mean for the team? A hiring manager reads this and thinks: okay, you set up infrastructure. So did a lot of other folks applying for this role. What’s missing is the impact. How much time was the team losing to the manual process? How many pipelines moved to production? Did reliability improve? Did it unblock other work?

Something like this is immediately stronger:

“Migrated the team from manual data ingestion and laptop-run dbt jobs to a production-grade platform, eliminating X hours of weekly manual work and reducing pipeline failures by Y% increasing visibility on errors when they did due to centralized logging.”

The work is the same. But the second version makes me want to ask about it.

“Guided the instrumentation of data for a global purchase system. Collaborated with PMs to establish top-level KPIs and visualized them to drive platform improvements.”

There’s a good story hiding in here. You worked on a global system, partnered with PMs, and built KPIs that drove real improvements. But it reads like a job description. “Guided the instrumentation” is vague. “Collaborated with PMs” does not tell a lot about your specific contribution. And “drive platform improvements”, what improvements? By how much? This bullet point is doing too much in two sentences and landing on nothing concrete.

Try something like:

“Led data instrumentation for a global purchase system serving X markets, partnering with PMs to define top-level KPIs that identified $Y in conversion improvements across the platform by reducing purchase errors by Z%.”

Now the scope is clear (global, X markets), your role is specific (led, not “guided”), and there’s a measurable outcome.

Getting closer

“Scaled testing coverage from 27% to 91% in just two months.”

Now we’re talking. There’s a clear before and after (Y), a specific metric, and a timeframe. You can immediately picture the improvement. What would make this even stronger? The X: the actual accomplishment. Right now “scaled testing coverage” reads more like a task. What did that coverage increase actually achieve? Something like: “Scaled testing coverage from 27% to 91% in two months, reducing production incidents by X% preventing 3 major production outages over the last month and saving X hours of manual testing, this unblocked the team’s migration to a new data platform.” Now the number (Y) supports a real outcome (X), and the reader understands why it mattered.

Strong examples

“Launched the first integrated GTM performance dashboards in Power BI, enabling teams to improve account targeting, lead-to-deal conversion, and pipeline coverage, contributing to a $4.5M QoQ increase in marketing-sourced bookings (+35%).”

This one nails it. Clear deliverable (GTM dashboards), the business areas it touched (targeting, conversion, pipeline), and a concrete result ($4.5M, +35%). A hiring manager reads this and wants to hear more. That’s the whole point of a bullet point.

“Presented GTM reporting insights in recurring business reviews, increasing stakeholder demand for more advanced analytics; helped secure executive approval for the company’s first cloud data platform and a 2x expansion of the data team.”

I like this one for a different reason, it shows influence beyond the technical work. You didn’t just build reports, you changed how the organization thought about data. Securing budget for a platform and doubling the team? That’s leadership impact, even without “lead” in the title.

The pattern

Look at what separates the weak examples from the strong ones. It’s not better writing or fancier words, it’s specificity. The strong bullet points answer “so what?” right away. The weak ones leave you guessing.

The strong examples also signal scope. “$4.5M in bookings,” “global purchase system,” “2x expansion of the data team.” These tell me the scale you operated at and the impact to the business. That matters because hiring managers use scope to calibrate your level, managing a pipeline for 10 users is different from managing one for 10,000, and they need to know which one you did. Even if your scope is smaller, naming it helps. “Built the ingestion layer for a 3-person data team serving 200 daily users” is way more useful than “Built data pipelines.” It shows self-awareness about where you operate, and it gives the hiring manager the context to calibrate your experience correctly. Don’t hide your scale, own it, whatever it is.

You don’t always have exact dollar amounts or percentages. That’s fine. Time saved, errors reduced, manual hours eliminated, number of users served, all of these work. The point is to quantify something. A number forces you to be specific, and specificity is what gets remembered during a seconds-long scan.

One thing though: don’t make numbers up. I’ve seen CVs with suspiciously round, impressive-sounding metrics that fall apart the moment you ask about them. A recruiter might not question “reduced costs by 40%,” but the hiring manager will. They’ll ask how you measured it, what the baseline was, what else changed. If you can’t back it up in a conversation, it’ll hurt you more than a vague bullet point ever would. Use real numbers, even if they’re less dramatic. Honest and specific always beats impressive and made up.

Skill Progression: Tell a Story, Not a List

Most CVs read like a collection of unrelated jobs. You did this at Company A, that at Company B, something else at Company C. Each role exists in isolation.

The CVs that stood out to me did something different, they showed a progression. Reading the experience top to bottom, I could see a trajectory. Started building basic reports, then designed data models, then architected platforms and mentored juniors. That arc told me more than any individual bullet point could, because it showed me not just where you are but where you’re going and whether you’ll keep growing in the role I’m hiring for.

When you’re writing your CV, look at each role and ask: what did I learn here that I couldn’t have done at my previous role? That’s your progression signal. Make it visible.

If you went from “wrote SQL queries for ad-hoc requests” to “designed the company’s first semantic layer serving 50+ stakeholders”, that’s a story. Don’t bury it. Make sure the reader can connect those dots without having to guess.

Connected Experiences Over Discrete Events

This ties into progression, but within a single role. Most people write their bullet points under one job as a list of unrelated things they did. Built a pipeline. Made a dashboard. Wrote some documentation. Each one floating on its own, no connection to the others.

The problem is that a hiring manager reading disconnected bullet points has to piece together what your role actually looked like. And they won’t. They don’t have the time.

When your bullet points within the same role connect, when one thing clearly led to another, it reads like a narrative instead of a task list. A hiring manager stops seeing “this person did five separate things” and starts seeing “this person found a problem, solved it, and kept building on it.”

Instead of:

- “Built automated data quality checks”

- “Created a monitoring dashboard for pipeline health”

- “Reduced time spent on data incident triage”

Try something like:

- “Built the team’s first automated data quality framework after identifying recurring silent failures in production pipelines. Used that framework to create a real-time monitoring dashboard, reducing incident triage time from hours to minutes.”

It’s the same work, but now there’s a thread. You noticed a problem, built a solution, and extended it. That matters because hiring managers aren’t just looking for someone who can execute tasks, they want someone who sees what comes next without being told. Connected bullet points are the easiest way to show that on paper.

You don’t need to connect every single bullet point that would be exhausting to read. But within each role, try to have at least one thread that shows how your work compounded instead of just accumulated.

Mention Your Stack (But Don’t Lead With It)

I talked about this a bit in the last newsletter. Tools matter, but they’re context, not the headline. Why? Because every candidate lists the same tools. If you and 50 other applicants all have “Snowflake” in a skills section, it tells the hiring manager nothing about who actually knows what they’re doing with it.

When you write “Reduced query costs by 60% by migrating legacy stored procedures to dbt models on Snowflake,” the tools are there (dbt, Snowflake) but they’re supporting the story. They tell me you know the tools without making the tools the point.

Compare that to: “Experience with Snowflake, dbt, Python, SQL, Airflow, Fivetran, Tableau, AWS, Docker.” That’s a grocery list. It tells me nothing about depth, nothing about what you actually built, nothing about whether you used these tools on a toy project or in production at scale.

Weave your stack into your accomplishments. If the job posting asks for Snowflake experience, I should be able to find Snowflake in one of your bullet points attached to something you actually did with it. Not sitting in a skills section that every other candidate also has.

Same logic applies to your job title. If you’re applying for “Data Engineer” roles, make sure that’s what your CV says, not “Data Specialist” or “Analytics Developer” or whatever creative title your company gave you. Recruiters search ATS by job title. If they type “Data Engineer” and your title says something different, you might never show up in the results. Match the language of the roles you’re targeting. You can always clarify the nuance in the interview.

Putting It All Together

Your CV is a highlight reel, not a job description. Every bullet point needs to pass the “so what?” test. Your experience should show progression, connected work, not isolated blocks. And your tools belong inside the story, not listed above it.

Pick three bullet points from your current CV right now. Rewrite them using the XYZ formula. I promise at least one of them is currently just describing a task. Turn it into an accomplishment with a number attached, and you’ll feel the difference immediately.

Next week in CV Roast Series #2: the summary section at the top of your CV. Most people either skip it entirely or fill it with generic fluff that could belong to anyone. I’ll show you what actually works there and what’s costing you the first impression before a recruiter even gets to your experience. Plus more real examples from the submissions.

Got someone in your network who’s rewriting their CV right now? Forward this to them. One better bullet point might be the difference between getting screened out and getting a call.

First Stop: The ATS

Your CV doesn't land on a human's desk. It lands in an Applicant Tracking System, software like Greenhouse, Lever, or Workday. Nearly 99% of Fortune 500 companies use one, and over 93% of recruiters have some form of ATS in their workflow.

The ATS strips your CV down to raw text and extracts structured data: your name, email, job titles, companies, dates, skills, education. All that formatting you spent time on? Colors, images, layout? Gone. The system grabs the text and throws away the rest.

That parsed data is what lets recruiters search and filter candidates. They type "dbt" or "data engineer" and pull up matching profiles from hundreds of applications. That's really all an ATS is, a search and organization tool. Not a gatekeeper.

The ATS Myth That Won't Die

You've probably seen the viral stat that "75% of resumes get rejected by ATS before a human ever sees them." It has no credible source. It gets recycled on LinkedIn and career blogs constantly, but the actual data looks very different.

Only about 8% of recruiters enable broad content-based auto-rejection. The other 92% still rely on human review. Over 90% of applications get at least a brief look from a real person. Automated rejection is rare outside of hard knockouts like "must have work authorization" or minimum degree requirements.

So the real risk isn't some algorithm throwing your CV away. It's a human never finding it because your relevant experience didn't surface when they searched.

What Can Actually Break ATS Parsing

Formatting does matter though, but not because the ATS will reject you, but because bad formatting garbles how your information gets parsed. If the parser can't extract your data cleanly, a recruiter searching for your exact skills might never see you.

The usual culprits:

• Multiple columns, tables and text boxes → these misorder text and confuse parsers

• Scanned PDFs or image-based files → the system can't extract text from pictures

• Custom headers and banners → these get interleaved with your actual content

• Creative section titles → "My Journey" instead of "Work Experience" breaks categorization

• Unusual job titles → "Data Ninja" won't show up when someone searches for "Data Engineer"

And no, PDFs aren't a problem. Modern ATS systems parse PDFs and Word docs at nearly identical rates. The format matters far less than the structure inside it.

Standard fonts, standard section headings, reverse chronological order. Not to "beat the algorithm", just so your data gets extracted correctly and a human can find you.

Second Stop: The Recruiter

If your CV surfaces in a search or sits in the application queue, and most do, a recruiter looks at it. And this is the part nobody wants to hear: they spend seconds on it. Not minutes. Seconds.

They're scanning, not reading. They want to know:

• Does this person's experience level match the role?

• Have they worked with relevant technologies or in a similar domain?

• Do the job titles and company names make sense for this level?

• Does anything immediately stand out, good or bad?

In seconds, they're making a gut call: "worth a conversation" or "move on." They might skim through hundreds of applications in a day. There's no way they can give yours more time than that.

Your CV's job isn't to tell your full story. It needs to survive a few-seconds scan and make someone want to learn more.

Also, timing matters. Early applications tend to get more attention. Once a recruiter has a shortlist forming, everything that comes in after gets a faster, less generous look.

Third Stop: The Hiring Manager (Maybe)

If the recruiter says yes, your CV gets forwarded to the hiring manager. This part is a bit more thoughtful, but only a bit. The hiring manager reads with a more technical eye:

• Specific projects or systems that signal you've solved similar problems

• Depth vs breadth → did you actually do things, or just touch things?

• Signs that you understand the business side, not just the technical side

The catch: the hiring manager usually sees a shortlist of 5 to 10 candidates. The recruiter already filtered out the vast majority. If your CV didn't communicate your value in those first seconds, the hiring manager never sees it.

So What Is the Goal of a CV?

Not a career biography. Not a skills inventory. Not a document designed to prove you're qualified.

Your CV has one job: get you into a conversation.

Every line should be evaluated through that lens. Does this bullet point make someone want to ask me about it? Does it make me look like someone who can solve their problems? If not, it's wasting space.

I like thinking of it like a movie trailer. A trailer doesn't show you the whole film, just enough to make you want to see it. Your CV should make a recruiter want to hear the full story, not tell it for them.

Why Does This Matter?

Most CV advice out there is about formatting, keywords, and "beating the ATS." It's not wrong, but it misses the point. The ATS is just a filing system. Formatting won't save you if the content doesn't land. Keywords won't help if the context around them is forgettable.

Once you understand the process, ATS to recruiter to hiring manager, you start thinking about every line differently. You stop writing for completeness and start writing for impact. You stop listing what you did and start showing why it mattered.

Next week, I'm breaking down the single biggest shift that separates forgettable CVs from ones that get callbacks. Real examples from the CV roasts. Stay tuned.

Know someone in data who's job hunting right now? Send this their way. Sometimes understanding how the game works is the first step to playing it better.

I'm Going to Roast Your CV (So Recruiters Don't Have To)

I'm going to publicly roast every data CV that got submitted. For free. Completely anonymous.

No names. No companies. No identifying details. Just an honest, experienced look at what's working, what's not, and what I'd change, based on everything I've learned reviewing hundreds of CVs through real hiring processes.

Think of it as the feedback you wish someone had given you before you hit "Apply." The kind of straight talk that a recruiter is thinking but would never actually tell you.

Whether you submitted or not, you'll walk away with something useful. I'm going to highlight the patterns that kill otherwise strong CVs, what actually catches a hiring manager's eye versus what makes them scroll past, and the specific fixes you can apply right away.

Most CV advice out there is generic. "Quantify your impact." "Use action verbs." You've heard it all. What I want to show you is the *specific, real-world* version of what goes wrong, with actual examples drawn from actual CVs (anonymized, of course).

Want Your CV Roasted?

Submissions are now closed — the response was overwhelming. I'll be reviewing every single CV that came in and breaking them down right here in the newsletter. Completely anonymous.

I guarantee you'll recognize yourself in at least one of the mistakes I highlight. That's the whole point, these are *that* common.

Stay Tuned — Results Drop Next Week

I'll be posting the full breakdown with my findings, feedback, and recommendations by mid next week.

Subscribe if you haven't already. And remember, your CV gets about a minute of a recruiter's attention. Let's make sure that minute is saying exactly what you think it's saying.

Know someone in data who's job hunting? Forward this their way. Sometimes the smallest fix makes the biggest difference.

Getting a data engineering interview is harder than passing one right now.

Hundreds of applications land on every open role within minutes. Recruiters are buried. Your CV gets maybe a minute or two before a decision is made. The amount of effort it takes just to land that first interview is higher than it's ever been.

Don't let that effort go to waste by showing up unprepared.

That's the part I can't wrap my head around. You survived the hardest filter, the one where you're competing against hundreds of people for a recruiter's attention and then you wing the actual conversation.

→ Only preparing for technical aspects.
→ No research on the company.
→ Vague answers about past work.
→ No questions prepared.

The interview is the easy part. You already have their attention. You already made it past the pile. That's the moment to show up sharper than everyone else, not relax just because you made it through.

Prepare like getting the interview was the hard part. Because right now, it is.

If you're actively interviewing and want help making every opportunity count, follow along and subscribe. I'm going to post a lot more about data interviewing and preparation in the coming weeks, ranging from practical tips on how to prepare for the different type of interview processes to what interviewers actually look for when and what you can do to stand out and be noticed.

Subscribe now