After placing engineers across dozens of startups and tech companies, the ones who build the best careers aren’t always the most technically gifted. They’re the most pragmatic.
That’s not a knock on craft. Some of the most impressive engineers I’ve worked with care deeply about how code is written — not just whether it works. But caring about the craft and being effective in a business context are two different things, and the engineers who figure out how to hold both tend to go much further than the ones who only have one.
There Is No Universal “Good Engineer”
When I’m recruiting for a role, one of the first things I try to understand is what kind of engineer the team actually needs — not just the tech stack, but the working philosophy.
Some teams want a TDD evangelist. Someone who starts from the test, works backward to the implementation, won’t ship without meaningful coverage, and will push the team to do the same.
These engineers are disciplined, thorough, and often the person who stops a bad architectural decision before it becomes a two-year problem. If you need someone to build something that has to be right — financial infrastructure, healthcare systems, anything where a bug has real consequences — this profile is invaluable.
Other teams need someone who can move fast and adjust. A RAD developer — rapid application development — is wired differently. They’re not sloppy, but they prioritize getting something in front of users quickly, learning from it, and iterating.
They’re comfortable with imperfection as a tool. In an early-stage startup trying to find product-market fit before the runway runs out, this is often exactly what’s needed.
And then there’s the question of how engineers prefer to work together. Some teams pair program — two engineers on the same problem at the same time, one writing while the other reviews in real time, then switching. It sounds inefficient. In the right culture, it’s one of the fastest ways to spread knowledge and raise the floor of a team’s output. Some companies build their entire engineering culture around it.
If you’re someone who does your best work with headphones on, disappearing into a problem for hours, a pairing-heavy team is going to be a rough fit — regardless of how good your code is. Neither preference is wrong. They just need to match the room.
The Craft Is Real — But So Is the Clock
There’s a version of engineering culture that treats code like fine art. Ten beautiful lines are worth more than a hundred functional ones. Every PR is a statement of values. Every architectural decision is debated until it’s right.
I’ve seen companies operate this way. Some of them build genuinely remarkable software. But it comes with a cost, and that cost is usually time. It’s been said so often it’s become a cliché that IT projects run late — and while the reasons vary, one of the common ones is a team that couldn’t stop refining long enough to ship.
The engineers who build long, successful careers understand this tension. They have standards. They care about the work. But they also understand that a feature nobody can use yet because it isn’t perfect enough to ship isn’t actually serving anyone.
Pragmatism isn’t the opposite of craft. It’s the discipline to know when craft has done its job.
Understanding What a Company Actually Needs
Here’s the part most engineers skip when evaluating a new role: figuring out what the business actually values — not just what it says it values.
A company that tells you they care about code quality might mean they have a rigorous code review process and strong test coverage. Or it might mean one senior engineer has strong opinions and the rest of the team nods along. A company that tells you they move fast might mean a healthy pace of iteration, or it might mean technical debt so deep that new features take three times as long as they should.
The questions worth asking before you join:
- What does your deployment process look like, and how often do you ship?
- How do you handle technical debt — is there dedicated time for it, or does it accumulate?
- What does a typical code review look like? How long does it take, and who’s involved?
- Has the team ever pushed back on a deadline because the code wasn’t ready? What happened?
- What does a bad technical decision look like here, and how did you recover from it?
These aren’t gotcha questions. Most good engineering teams will answer them directly and with some nuance. The ones that can’t, or that give you answers that feel rehearsed, are telling you something.
Fit Is a Career Decision, Not Just a Job Decision
A mismatch between your working style and a company’s engineering culture isn’t something you can usually fix from the inside. You can adapt to some degree, but if you’re a purist joining a team that ships on Fridays and apologizes later, or a pragmatist joining a team that considers SOLID principles a prerequisite for every conversation — you’re going to be grinding against the culture every day.
That wears on people.
The engineers I’ve seen build the best careers are honest with themselves about what kind of environment brings out their best work. They ask the hard questions early. They don’t take roles hoping the culture will shift once they’re inside. And they’re pragmatic enough to know that a technically interesting role in the wrong environment isn’t actually a good opportunity.
Your skills get you in the room. How you work determines whether you stay, grow, and build something worth being proud of.
If you’re trying to figure out whether a role is actually the right fit — or want a recruiter’s read on what a team is really like before you commit — get in touch. That’s exactly the kind of conversation we have.
Also worth reading
