“So, what kind of engineer are you?”
“I’m a Python engineer.”
Every time I hear this, I cringe a little. Not because Python isn’t amazing—it absolutely is. But because somewhere along the way, we’ve started defining ourselves by our tools instead of our craft.
I’m sure you’ve heard it too: “I am an AWS engineer,” “I am a React developer,” as if the tool has become their entire professional identity.
The Tool Identity Trap
Here’s what I mean by “tool engineers”—people who’ve wrapped their professional identity so tightly around a specific platform or language that they can’t see beyond it.
Now, before you roll your eyes and click away, let me be crystal clear: I’m not talking about smart people who strategically brand themselves as “Kubernetes experts” or “React specialists” to land better gigs. That’s just good marketing.
I’m talking about something deeper—engineers who genuinely believe they ARE their tools, not people who USE tools to solve problems.
Here’s the Thing About Tools
Let me drop some truth on you: AWS is just a tool. A phenomenal, mind-blowingly powerful tool, but still just a tool. Same goes for Python, Rust, Kubernetes—they’re all beautiful, elegant solutions to specific problems.
But here’s what real engineering looks like: understanding problems, wrestling with constraints, and making trade-offs that keep you awake at night. The tool? That comes after you’ve figured out what you’re actually trying to solve.
Yet somehow, we’ve flipped this script entirely.
Why does this happen?
Look, I totally get it. Hiring is broken, and everyone knows it.
Employers are drowning in resumes, so they throw keywords at the wall: “We need a GCP engineer!” “Find me a React developer!” It’s the path of least resistance—way easier than figuring out if someone can actually debug a gnarly production issue at 2 AM.
And honestly? How do you even test for that kind of problem-solving magic in a 45-minute interview?
So here we are: employers hunting for buzzwords, candidates stuffing their resumes with acronyms, and everyone playing this weird game where the actual craft of engineering gets lost in translation.
When I Wasn’t Just a “Python Guy”
Story time. I once landed a contract to build a data pipeline. Python-heavy work, so naturally, they hired me as their “Python engineer.”
But then something interesting happened.
A few weeks in, the team discovered I could do more than just wrangle pandas DataFrames. I started setting up CI/CD pipelines, spinning up Kubernetes clusters, orchestrating deployments across AWS and GCP. Their faces? Priceless.
“Wait, you can do ops too?”
Here’s the kicker—they were genuinely surprised. Their mental model was: Python engineer = person who writes Python. Period.
But because I approached it as an engineer (not just a Python-wielding code monkey), I could see the whole system. When things broke, I could trace issues from the database all the way up to the UI. Infrastructure problem? Code bug? It didn’t matter, I could hunt it down.
The Right Way to Think About This
Don’t get me wrong—deep tool knowledge is absolutely powerful. Maybe you know Rust better than I ever will. Maybe your Kubernetes fu is legendary. That’s awesome, and I respect the hell out of it.
But here’s the secret sauce: put the problem first.
The flow should be: Problem → Constraints → Solution Design → Tool Selection.
Not: “I know React, so let’s build a React app.”
How to survive the keyword economy without losing your soul:
Speak two languages.
Language #1: Recruiter-speak Spam those keywords. AWS, GCP, Python, Terraform, React—whatever gets you past the ATS robots.
Language #2: Engineer-speak For every project, tell the real story: “Reduced customer churn by 23% by building a real-time recommendation system that processes 50M events/day. Built with Python and Kafka, deployed on AWS.”
See the difference? Problem first, impact second, tools last.
In interviews, be that person who asks: “What are we optimizing for here?” and “What problem are we actually solving?” While everyone else is debating framework choices, you’re cutting to the heart of the matter.
The Bottom Line
Employers will keep playing the keyword game, it’s just easier for them.
But you? Don’t let their broken hiring process define who you are as an engineer.
Be the person who walks into any codebase, asks the right questions, and designs solutions that actually work. Be the one who sees systems, not just syntax.
Here’s how I think about it: You rent the tools, but you own your judgment.
Your judgment starts with understanding problems and ends with shipping solutions that matter.
So please, don’t be a tool engineer.
Watch the Video
I also shared this perspective in video format. You can watch it here: