I work at Mailchimp (we’re hiring 😉) and I get the “code monkey” thing from developer friends at bigger companies. Always lighthearted, never malicious, but it sticks in a weird way. Like… I know you’re joking, but also, sending a billion plus emails a day ain’t exactly simple.

I have implemented breadth-first search and depth-first search so many times for LeetCode that I could probably write them on a whiteboard blindfolded. And yet, in my actual day job… where I work on automation infrastructure that runs DAG-based workflows (graphs! finally!)… I have written a graph traversal from scratch exactly once. It became a helper function. We haven’t touched it since.

So what fills the rest of the week? Figuring out why unrelated tests are failing. Helping a newer engineer think through a design they’re stuck on. Negotiating scope with product when the ask doesn’t match the timeline. Explaining why “just add a toggle” touches more surfaces than anyone expects. None of that shows up on a whiteboard. Most of it doesn’t even show up in Jira.

A coworker recently shipped a feature that worked perfectly in isolation and then knocked over a downstream service because he’d never talked to the team that owned it. Didn’t check the contract, didn’t ask about rate limits, didn’t read the runbook. The fix took a week. The conversation that would’ve prevented it would’ve taken twenty minutes. His code was fine, for the record. It did exactly what he wrote it to do. Nothing that went wrong was a coding problem.

That gap… between “can solve the problem” and “can figure out which problem to solve, who else it affects, and whether it should even exist”… is where most of the actual work lives. It’s also the part nobody interviews you on. Should this job exist? Who owns it when it fails? What happens if we run it twice? Which undocumented table is it quietly depending on? Your LeetCode score has no opinion on any of this.

Interviews test whether you can solve a puzzle under time pressure with a stranger watching. The job tests whether you can sit in a room with a product manager, a designer, and a skeptical director and explain… in human words… why the thing they want will take longer than they think, why the shortcut will bite us in three months, and no, we can’t “just cache it.” Those are different skills. The Venn diagram overlap is not huge.

Which is why I think the “code monkey” jab has it backwards. The engineers I’ve had the hardest time working with could code just fine. What they couldn’t do was explain a tradeoff without retreating into jargon, or push back on a bad requirement without making it personal. The industry has a soft spot for the “difficult but brilliant” 10x engineer, and in my experience that person writes code nobody else can touch, makes junior engineers afraid to ask questions, and slows down everyone around them. That’s not 10x.

The best engineers I work with, at Mailchimp and before, are rarely the ones who solve a hard problem fastest. They figure out which problem matters, explain why without putting everyone to sleep, and then write code boring enough that the next person can maintain it without a Rosetta Stone. If that’s a code monkey, fine. Hand me a banana. We’re just interviewing for the wrong half of the job.