This is not a comfortable article. Not for hiring managers, not for data analysts, and definitely not for people trying to break into the industry. But that’s exactly why it’s worth writing.
I’ve taken part in many recruitment processes. I’ve seen candidates who made a great first impression and later turned out to be a serious problem for the team. I’ve seen technically strong analysts who delivered very little real value. And I’ve seen people who unknowingly sabotaged themselves during interviews.
This article is about six types of data analysts you should avoid. If you’re hiring, these are your red flags. If you’re applying for data roles, treat this as a checklist of behaviors that can quietly kill your chances or your long-term growth.
This is not about judging people. It’s about patterns of behavior that damage teams, projects, and trust over time.
The “I’m Good at Everything” Analyst
On paper, this sounds perfect. Everyone wants someone who knows Excel, SQL, Python, Power BI, visualization, statistics, storytelling, maybe even machine learning.
The problem is that “I’m good at everything” often means something else entirely: a lack of self-awareness.
Every analyst has strengths and weaknesses. One person excels at visualization but struggles with complex SQL. Another is brilliant at data modeling but hates presenting results. That’s normal.
When a candidate cannot clearly articulate what they are particularly good at and where they are still developing, it becomes risky. Not because it’s impossible to be versatile, but because without self-awareness, it’s very hard to place someone in the right project.
From a team perspective, this is dangerous. You assign someone to a critical task assuming competence, only to discover weeks later that they’ve never actually done this type of work.
From a candidate’s perspective, it’s also a mistake. Saying “my strongest area is X, I’m solid at Y, and Z is something I’m actively improving” is not a weakness. It’s professional maturity.
Entitlement From Day One
This is a sensitive topic, because it’s easy to slide into cheap moralizing. Everyone has needs. Everyone wants fair pay and decent working conditions.
The problem starts when the entire recruitment conversation revolves around demands instead of value.
When someone entering the field opens with:
– full remote only
– a high, fixed salary
– a long list of benefits
they often communicate one thing: “this is owed to me”.
Here’s the crucial part many people miss: entitlement doesn’t stop after recruitment. It’s an attitude toward work and reality. It continues into daily collaboration, task prioritization, and accountability.
If you’re just entering the industry, your main priority is simple: get in and gain experience. Your first job is not a lifelong contract. After a year, your negotiating position is completely different.
From the hiring side, the logic is similar. When an experienced candidate arrives with a detailed wish list before clearly demonstrating what they can deliver, it’s worth thinking twice about how they will function in a team.
There are exceptions. If you’re hiring the Cristiano Ronaldo of data analytics, the rules change. But let’s be honest, most of us aren’t.
Extreme Shyness and Poor Communication
Data analysts are often introverts. That’s not a problem. The problem is when introversion turns into an inability to communicate work.
If during an interview someone:
– struggles to explain what they did
– constantly loses their train of thought
– avoids giving clear answers
that’s a serious warning sign.
Why? Because technical skills are relatively easy to improve. Communication skills are much harder.
In practice, it looks like this: you invest time and money in someone. They build complex queries, models, and reports. And then they cannot clearly explain what they’ve done, when it will be ready, or what they need from stakeholders.
The result is wasted work. Not because it’s technically wrong, but because no one can effectively use it.
This is not about becoming a loud extrovert. It’s about being able to communicate clearly and constructively at a basic professional level.
The Task-Driven Analyst Who Ignores the Business
Another common type is the task-driven analyst. Jira tickets, “Done” columns, closing tasks, moving fast.
Task orientation itself isn’t bad. In many roles, it’s necessary. The issue appears when an analyst has zero interest in why something is being analyzed.
If someone:
– doesn’t understand the business
– never asks about context
– doesn’t care how insights are used
then sooner or later they stop being an analyst and become a tool operator.
At junior level, this might still work. Beyond that, it doesn’t. A data analyst must understand what is being measured, why it matters, and what decisions it supports.
Real value starts after the table or dashboard is finished. It starts when you can say:
– what this means
– what to check next
– what actions are possible
Without that, technical correctness alone is not enough.
“I Am the Documentation”
This type is particularly dangerous because they are often very strong technically.
These are analysts who:
– don’t document code
– don’t explain reports
– don’t share knowledge
– operate in full “solo mode”
Everything is clear in their own head. A 2,000-line script makes perfect sense to them. But companies don’t run on single individuals.
An analyst who doesn’t document their work slows everyone else down. Other analysts, business users, future team members all have to spend extra time understanding what was done.
Individually, such a person may perform very well. As part of a team, they are a bottleneck.
Documentation is not bureaucracy. It’s responsibility.
The Tool-Lover
The last type is the most tempting and the most misleading.
These are analysts in love with a specific tool. Power BI, Python, Excel, Tableau. The tool itself doesn’t matter. The problem begins when the tool becomes more important than the business.
If a company works with one tool and hires a consultant for that exact technology, that’s fine. But most organizations use multiple tools.
Then you get:
– constant pressure to use “my tool”
– complaints about alternative solutions
– polishing advanced features instead of solving real problems
At some point, the tool becomes the goal. Business questions become secondary. The analyst starts serving their own technical ambitions instead of decision-making needs.
Passion is great. Mastery is valuable. But analysts work for the business, not for their ego.
Conclusion
All these types share one thing: imbalance. Between technology and business. Between confidence and humility. Between individual performance and teamwork.
This article is not about labeling people. It’s about spotting problems early, before they become expensive. And about reflecting on whether we ourselves are drifting toward one of these patterns.
If you think this article could help someone, share it on social media. The earlier people recognize these red flags, the fewer teams will have to learn about them the hard way.
The article was written by Kajo Rudziński – analytical data architect, recognized expert in data analysis, creator of KajoData and polish community for analysts KajoDataSpace.
That’s all on this topic. Analyze in peace!
Did you like this article 🙂?
Share it on Social Media 📱
>>> You can share it on LinkedIn and show that you learn something new every day.
>>> You can throw it on Facebook – and perhaps help a friend of yours who is looking for this.
>>> And remember to bookmark this page, you never know if it won’t come handy in in the future.
You prefer to watch 📺 – no problem
>>> Subscribe and watch my English channel on YouTube.
Prefer to read in Polish? No problem.
Other interesting articles:
