Why Are Engineering Managers Getting Coding Challenges? (And Why It Matters More Than You Think)
The rising need to test coding skills EM+ candidates is back again.
Let’s talk about something that’s been bothering me—and probably you too.
You're applying for an Engineering Manager or Senior Engineering Manager role. You’ve got the leadership experience. You’ve coached teams. You’ve handled performance reviews, product roadmaps, outages at 2 a.m., and stakeholder drama.
And then, out of nowhere, the recruiter says:
“We just need you to complete this coding challenge first.”
Wait, what?
You pause. Maybe laugh nervously. Maybe feel insulted.
But here's the kicker: this is not an exception anymore. It’s becoming the norm.
And I get it. It's frustrating.
Because as someone who’s been in this game for a while—and as someone who now coaches other tech professionals through these hiring loops—I’ve got a strong opinion:
Coding challenges for leadership roles are often the wrong tool for the job.
But hang on.
Today, I’m not here to rant. I’m here to zoom out.
To take a deeper look at why this is happening in the first place.
And maybe… just maybe… there’s a logic behind it.
So in this first part of the series, I’ll walk you through the why. Not why I think it’s fair—but why it’s happening.
Part 2 will break down what companies are really testing when they throw a coding challenge at leadership candidates.
Let’s dive in.
The Ground Is Shifting: What’s Really Going On?
1. The IC vs. EM Line Is Blurring
Remember when Engineering Managers were mostly people leaders?
Yeah. That’s fading.
More and more, companies expect EMs to stay close to the codebase—not to ship features, but to be able to discuss, understand, and unblock.
And not just at a high level.
They want managers who can:
Review code with confidence.
Jump into debugging if needed.
Make architecture decisions without stalling.
It's not that you're expected to code full-time—but the line between technical contributor and leader is thinner than ever.
In fact, in many startups and scaleups, EMs are still the most senior engineer in the room.
So what’s the fastest way to validate if someone still has their technical chops?
Yup. You guessed it.
A coding challenge.
2. The AI Effect
Here’s the plot twist no one talks about:
AI made coding easier, but it also raised the bar.
With tools like GitHub Copilot, anyone can write a “working” solution.
But that means the bar moved. Now it’s less about can you code and more about can you think technically and guide your team through AI-assisted development?
A manager today is expected to:
Know when AI-generated code is wrong.
Understand how to integrate AI into workflows.
Help their team become faster and smarter, not just more robotic.
Companies are using coding challenges to test this indirectly:
Can you turn vague requirements into sound logic?
Do you know when not to trust it?
Do you rely too much on Copilot?
This is less about syntax. It’s about technical fluency in a new world.
3. The Role of the “New” Middle Manager
Let’s be real.
Middle management is under pressure.
The days of sitting between execs and engineers and “coordinating” are gone.
Middle managers today are expected to:
Own delivery.
Unblock tech.
Represent the team technically in cross-functional discussions.
They’re no longer supervisors.
They’re enablers. And enablers need to understand the terrain.
This shift is pushing hiring teams to verify if you can actually keep up.
So what do they do?
They hand you a scenario.
“Build this.”
“Debug that.”
And they’re not always looking for the best code. They’re watching how you approach, decide, and communicate.
4. Decentralized Decision-Making = More Pressure on EMs
In many modern teams, especially in remote or async-first companies, decisions can’t always go through a long chain.
Engineering Managers are expected to:
Make fast, solid calls about architecture.
Solve blockers.
Choose tools.
Without always running to Staff or Principal ICs.
That’s a good thing—it means more autonomy.
But autonomy brings responsibility. And that’s making companies nervous.
They want EMs who can handle both strategic and technical discussions without skipping a beat.
A coding challenge? It’s one way—flawed, yes—to see if you’ve still got that edge.
5. Leadership Is No Longer Just People Skills
There’s a saying: “People leave managers, not companies.”
That’s still true.
But in tech today?
People stay for managers who also understand the work.
Let’s flip the script.
Imagine you’re an engineer. Your manager shows up to a planning meeting and doesn’t get half of what you’re building.
Worse, they ask you for daily updates because they can’t read the Git logs.
You’d lose respect, right?
Now imagine the same manager says:
“I saw your PR. I think the memory handling might be off. Can we pair for a bit?”
That’s a different vibe.
That’s someone who gets it.
And that’s what many teams—and by extension, companies—are looking for.
Not micromanagers.
Technical mentors.
So they test for it. Again, through code.
Why This Still Feels Off (And You're Not Wrong)
Now, here’s the thing.
I’ve been in your shoes.
I’ve had years of experience leading large teams, scaling products, managing layoffs, and hiring senior talent—only to be told to “do this coding challenge before we continue.”
It can feel like a slap in the face.
And let’s be honest: it’s not always fair.
Some coding challenges are poorly designed.
Some don’t account for years of strategic experience.
Some are time-wasters, completely unrelated to the job.
So yes, your gut reaction is valid.
There are better ways to assess leadership.
But here’s the uncomfortable truth:
We’re not in 2015 anymore.
The industry changed.
And while I believe strongly that EMs shouldn’t be filtered out based on a code test alone—ignoring this trend won’t help either.
So What Do You Do?
Here’s how I coach my clients through this:
Detach the ego. You're not your title. You’re a learner. Treat the challenge like a puzzle—not a verdict.
Don’t overengineer. They’re not looking for the next Twitter clone. Think clarity over cleverness.
Think out loud. If it’s live, explain your thought process. Show how you’d guide someone through it.
Ask the right questions. Before you accept a challenge, ask:
Decide your boundaries. Some companies will die on the “code or get out” hill. You get to decide whether to walk away—or play the game.
In Part 2...
Next week, I’ll walk you through what these coding challenges are really testing.
I’ll share:
Common patterns in EM/SEM coding tests.
What interviewers are actually looking for.
How to stand out without losing your mind.
When to push back—and how to do it without burning bridges.
This isn’t about “just doing the challenge.”
It’s about playing smart in a shifting game.
Final Thoughts
If you feel frustrated right now, you’re not alone.
The hiring bar is changing.
But that doesn’t mean you’re not qualified.
It just means you need to adapt how you show your value.
Not by dumbing it down.
But by connecting the dots between your leadership and your technical roots.
The best EMs I’ve worked with weren’t the fastest coders.
They were the clearest thinkers.
They could translate business problems into engineering solutions. And they earned trust because they knew enough to be helpful, without trying to out-code the team.
That’s the sweet spot.
Let’s aim for that.
Until next week—keep your head up.
—Raphael
P.S. If this helped you, share it with someone who’s struggling with the same thing. Or hit reply and tell me your experience—I read every message.