Why Data Engineers (sometimes) suck at interviews
It's not your technical skills—it's how you talk about them
I've been thinking about this for a while, and it keeps coming up in conversations with other data people. We all know technically brilliant engineers who struggle to advance their careers, while others with less technical depth seem to move up faster.
The difference isn't what you'd expect.
What I've seen happen
We were hiring for a senior data engineer role a couple of years ago. This one candidate comes in—incredible background, years of experience with Spark and Kafka, has built some genuinely impressive data platforms. But during the HR screening, he completely fell apart trying to explain what he'd worked on. Came across like someone who'd never led a project, even though his resume said otherwise.
The same week, we interviewed a mid-level analyst. Technically, he was pretty average, but when HR asked about his experience, he had this clear story about helping his previous company reduce customer churn through better data models. He explained it simply, connected it to business results, and made it sound important.
The senior engineer destroyed the technical interview by solving problems the analyst couldn't touch. But leadership already had doubts from that first conversation. The analyst didn't pass the technical bar.
We ended up hiring neither, but it made me realise something: all those years the senior engineer spent optimising data pipelines meant nothing because he couldn't explain why any of it mattered to people outside engineering. From my previous experiences, I had a hunch that if we hired him, I'd end up doing all the communication work anyway, even though someone at that level should be able to handle stakeholder conversations without supervision.
The uncomfortable pattern I keep seeing.
This isn't just about interviews. I know data engineers who've been stuck at the same level for years because they focus on the wrong things. They'll spend weeks optimising a Spark job to run 40% faster, then present it as "reduced processing time from 6 hours to 3.5 hours" instead of explaining what that enables for the business.
Meanwhile, someone else will say, "I made our customer segmentation model faster, so now marketing can launch targeted campaigns same-day instead of waiting until next week." The same technical achievement, completely different impact.
The people who get promoted aren't necessarily the best engineers. They're the ones who can connect their technical work to outcomes that non-technical people care about. Honestly, in some cases, people get promoted because they're just uncomfortable to work with—you end up moving them to a different position so you don't have to deal with them anymore. I know a couple of examples where this happened.
The bigger problem is that the best "sales" people often get the promotions and attention without doing much work, just because they're the loudest person in the room. Meanwhile, the people building things stay quiet and get overlooked. This is why more technical people need to learn to articulate their ideas better—for their and the company's good. We also shouldn't promote people because they've been around the longest.
Why is this getting worse?
Here's what's frustrating: as data tools get easier, technical skills matter less. I can teach someone basic dbt in a few days. Modern data platforms are so user-friendly that business analysts can build their own models.
The technical complexity that used to protect our jobs is disappearing. But what's not getting commoditised is the ability to figure out which data problems are worth solving and explain why your solutions matter.
Companies don't need another dashboard. They need someone who can examine their data infrastructure and say, "Here's how this helps us compete better" or "here's how this saves us money."
The skills that actually differentiate
The most successful data engineers treat communication like any other technical skill. They practice explaining their work to different audiences. They learn how their company makes money. They ask questions about business problems, not just technical requirements.
They don't just reduce query runtime—they explain how faster queries enable real-time pricing or better customer recommendations. They don't just improve data quality—they talk about how clean data leads to more accurate forecasting or better product decisions.
It's still technical work, but framed in a way that makes sense to people who control budgets and make promotion decisions.
What actually works
Start small. Next time you finish a project, practice explaining it without using technical jargon. Focus on what changed for the business, not how you implemented the solution.
Learn how your company works. What metrics do executives care about? How does data influence essential decisions? Where does your technical work fit into the bigger picture?
The combination of strong technical skills and clear communication is scarce in data engineering. Most technical people can't explain business value, and most business people don't understand technical constraints.
If you can bridge that gap, you become indispensable. More importantly, you can explain why during your next interview.