5 Red Flags of Mediocre Data Engineers
These 5 signs mean you may never become a senior engineer unless you address your flaws.
Greetings, Data Engineers,
There are some obvious signs of mediocre data engineers. I don’t need to tell you that somebody is not a great data engineer when they refuse to learn, or do 0 testing, or never meet deadlines.
Today, I will tell you about 5 less obvious red flags of mediocre data engineers.
No matter whether you see yourself in these or manage somebody who possesses these behaviours, you will find something in this article.
Red Flag #1: “Smart” Solutions Everywhere
Every pipeline, every function, every other line of code of a mediocre data engineer does something “special”.
They over-engineer solutions. They think about crazy edge cases that might never happen. They write code so short and so clever that even they cannot read it three months later.
Here’s the thing. You read code way more often than you write it.
If you ever have a choice between “clever” and “clear”, choose clear.
Simple code is what scales. Simple pipelines are what your future self will thank you for. Embrace YAGNI. You Are Not Gonna Need It.
Before you add a twisty shortcut, ask yourself: Would a new teammate who just joined yesterday understand this in five minutes?
If the answer is no, rethink it.
Red Flag #2: 0 Curiosity; Only Surface-Level Knowledge
You meet them all the time.
They know the basics of a tool, they can string a few things together, and they stop there. They think learning the surface-level features is enough.
They can build a pipeline, but ask them why it works the way it does, and you get blank stares.
A mediocre engineer is always rushing to “get it working” without ever really understanding why it works.
The danger is not in being a beginner. The danger is in thinking you are done learning.
Here’s the thing: Companies are not hiring button-clickers anymore. They are looking for people who actually understand systems. People who can explain trade-offs.
I’ve already written about why curiosity matters to hiring managers like me.
So, if you really want to dive deep, do this:
Pick one tool you already use every day. Now go deeper.
Learn how it handles scaling. Learn how it deals with failure.
Learn what trade-offs the designers made when they built it.
Depth beats breadth every time.
Red Flag #3: Loads of Words; 0 Action
You know the type. Always reading blog posts. Always forwarding articles. Always talking about what could be done.
But when it comes to actually doing the work, they freeze.
They throw around words like "best practices" and "industry standards" without ever rolling up their sleeves.
If you ask them a few more questions like "How would you set this up?" or "Can you show me a prototype?", you will find a lot of hand-waving and very little clarity.
Real learning lives in doing.
Books are great. Reading is important. But nothing replaces building. Shipping. Fixing.
And if you see yourself being like this, make sure you spend more time coding than consuming. Otherwise, you are building castles in the sky.
Red Flag #4: Spend 70% of Their Time Firefighting
Busy does not mean effective.
Some engineers live in firefighting mode. All they do is fix one emergency after another.
At first, it might even feel good. Like you are valuable because everybody needs you.
But here’s the truth:
If you spend all your time fixing, you are probably not fixing the right thing.
The real leverage comes when you zoom out and tackle the root causes.
Refactor bad pipeline designs.
Improve broken processes.
Propose better tools.
You are not a hero for putting out the same fire every day. You become a hero by building a system that does not catch fire in the first place
Red Flag #5: Code Monkey With 0 Influence
Mediocre engineers act like code monkeys.
They wait for instructions. They pick up tickets. They move Jira cards from left to right.
No real thinking. No real ownership.
The problem is, if you are only doing what you are told, you are not better than AI.
A good data engineer is not hired to write SQL and Python.
You are hired for your expertise. You are hired for your judgment. You are hired because you know what “good” looks like.
The real value is not just in executing tasks. It is in seeing the bigger picture and shaping the work.
Strong engineers ask better questions:
“Why are we doing it this way?”
“What problem are we actually solving?”
“Is there a simpler, more durable solution?”
And then they help others see a better future. They sell that better future.
You cannot be a force multiplier if you only work with what is in front of you. You have to make things better than you found them.
Writing code is expected. Driving better outcomes is what makes you stand out.
Final Thoughts
If there is one thing I want you to take from today, it’s this:
Mediocre engineers stay busy. Great engineers change things.
They do not just build what they are asked to build. They see what is broken and find a better way.
They have opinions. They have a vision. And they know how to bring people along.
It is not about fighting every decision or arguing for the sake of it. It is about knowing what "good" looks like and having the courage and skill to sell that future to others.
The market has changed. Companies are not looking for order-takers anymore.
They are looking for people who can lead, even without a managerial title.
They are looking for force multipliers.
If you want better opportunities, you need to build real influence. Not next year. Not when somebody gives you permission.
You start shaping it now. You already know the red flags.
Now it is time to work toward becoming the kind of engineer that companies fight over.
You have way more power than you think. Use it!
Until next time,
PS: If you are serious about driving real change as a data engineer and growing your career, check my course out. Don’t miss the bonuses for early access students.
Amazing article and great timing, I found myself leaning into red flag #1 by over engineering a solution that was a smart implementation but really was not streamlined and it would cause problems to share knowledge and make it scalable.
This is just to share that sometimes we also find ourselves in these "traps" trying to deliver something robust but not considering the maintenance vs easiness balance.