The Software Engineers No One Wants to Work With
When people talk about becoming a better software engineer, the conversation usually revolves around technical skills.
Learn System Design. Master AI. Grind LeetCode. Understand distributed systems.
All of these matter.
But there’s one skill that has a much bigger impact on your career than most people realize.
Can people enjoy working with you?
I’ve worked with engineers who were incredibly smart. They could solve problems faster than anyone else on the team.
But if a new project came up, people would quietly hope they weren’t assigned to work with them.
Why?
Because software engineering isn’t an individual sport.
You spend more time discussing ideas, reviewing code, debugging together, and helping teammates than actually writing code.
Your technical skills might help you land the job. Your behavior decides whether people want to work with you again.
Learn System Design the Right Way (Educative.io)
I used to watch random System Design videos and memorize architectures. It helped... until I got a new interview question.
What actually worked was learning a repeatable framework.
That’s why I like Educative’s Grokking the Modern System Design Interview course. One thing I found especially useful is that every problem starts with clarifying requirements before jumping into architecture, exactly how strong candidates approach real interviews.
Here are five behaviors I’ve seen hurt otherwise talented engineers.
1. The Know-It-All
What they do
They always have an answer. Every discussion becomes a debate.
Instead of trying to understand another perspective, they’re busy proving why they’re right.
After a while, people stop sharing ideas. Meetings become quieter, and good suggestions never get voiced because everyone already knows how the conversation will end.
What to do instead
Remember that being the smartest person in the room isn’t the goal. Getting to the best solution is.
Ask questions before giving opinions.
Be willing to say, “I hadn’t thought about it that way.” People respect confidence, but they trust humility.
If you work with one
Don’t turn it into an argument. Share your opinion with data and examples.
If someone else hasn’t spoken, invite them into the discussion. Sometimes the best thing you can do is create space for other voices.
2. The Blame-Shifter
What they do
When something breaks, they immediately start looking for someone to blame.
“It wasn’t my code.”
“QA should have caught it.”
“The requirements weren’t clear.”
The problem is that blame rarely fixes production issues. It only makes people afraid to admit mistakes.
What to do instead
Own your mistakes. Everyone ships bugs and everyone misses edge cases.
What matters is how quickly you acknowledge it, fix it, and learn from it.
People don’t lose trust because you made a mistake. They lose trust when you refuse to own it.
If you work with one
Keep bringing the conversation back to solutions.
Ask, “What can we do differently next time?”
That simple question shifts the focus from blame to learning.
3. The Lone Wolf
What they do
They prefer doing everything themselves. They rarely ask for help.
They don’t document their work. They keep important knowledge in their own head.
It might make them feel productive, but it usually makes the entire team slower.
If one person becomes the only expert, everyone else has to wait for them.
What to do instead
Share what you know.
Write documentation. Review code. Help teammates when you can.
A strong engineer doesn’t create dependencies. They remove them.
If you work with one
Look for opportunities to involve them in design discussions, pair programming, or knowledge-sharing sessions.
Sometimes people don’t realize the value of collaboration until they experience it.