What I look for in senior engineers in 2026 (after hiring 250+)

I've hired a lot of engineers over the last decade. Across an agency in Tel Aviv, fintech and compliance work in Switzerland, dev shops scaling teams from 50 to 250 people, and now JobCannon and the MIR group. The honest count is somewhere north of 250 hires made or directly approved, plus probably twice that number interviewed.

Almost everything in the first half of that career, I was wrong about. The signals I trusted then — credentials, brand-name companies, articulate interview answers, fast LeetCode — turned out to predict almost nothing about whether someone would ship good software in our environment.

What follows is the much smaller set of signals I trust now in 2026.

Signal 1: They've shipped something complete and they can talk about the trade-offs

Not "contributed to," not "was part of the team that." Shipped. Owned. From spec to live with users.

I open every senior interview by asking them to walk me through a project they shipped end-to-end. The first ten minutes is them telling the story. The next fifteen is me asking why they made specific choices. "Why this database, not that one? Why this auth library? Why didn't you write tests for this part?"

What I'm listening for is not "they made the right call." It's whether they can articulate that there was a call to make. Junior engineers (regardless of years on CV) describe projects as if the architecture fell from the sky. Senior engineers describe projects as a series of choices, each of which had alternatives, each of which had a reason.

Signal 2: They write code in front of me and narrate while they think

I don't do leetcode. I don't care if someone can balance a binary tree on a whiteboard. The interview I run is: here's a small, real-ish problem from our domain. We're going to write code together for forty minutes. You drive, I'll watch and ask questions.

What I'm watching for:

Do they ask clarifying questions before writing anything? (good)
Do they start typing immediately to fill silence? (bad)
When stuck, do they narrate what they're thinking? (good)
Do they read their own code back after writing it? (good)
Do they spot their own bugs before I do? (very good)
If I introduce a constraint mid-flow, do they re-evaluate the design or just patch it? (this is the senior tell)

Signal 3: They can disagree with me without being defensive

I'll deliberately suggest something dumb during the technical conversation — a wrong abstraction, a brittle approach, a "what if we just..." that I know will fail. I'm watching for the response.

"Yeah, we could do that." — fail (compliance, won't push back when it matters)
"Hmm, but..." with a real reason. — pass
"That's wrong because X, here's what I'd do instead." — pass with distinction
"That's a terrible idea." (without elaboration) — fail (rude is not the same as right)

The team I'm building has to be able to tell me, the founder, that I'm wrong. Multiple times a week. Without flinching.

Signal 4: They have a relationship with their tools

Show me your editor. Show me your terminal. Tell me how you debug. Tell me the last thing you got mad at in your stack.

Engineers who have a real relationship with their tools have the kind of compounding daily efficiency that produces ten times the output of someone who hasn't.

Signal 5: They can write a paragraph of clear English about a technical thing

Senior engineering is at least 30% writing. Not code — writing. Design docs, RFCs, ADRs, post-mortems, PR descriptions, Slack threads explaining why a feature is delayed.

If someone can't write a clear paragraph in their working language, the team will collapse around them.

Signal 6: They've been through a real fire and they remember what burned

Outage. Data loss. Bad migration. Compromised account. Wrong charge to thousands of users.

Engineers who've been through a real production crisis — and were close enough to feel responsible — develop intuitions you can't get any other way. They write code differently afterwards. They build observability without being asked.

What I no longer care about

University. Useful as a mild signal at the very top end. Otherwise zero predictive value.
Brand companies. Big tech can produce great engineers and complete tourists.
Years of experience. Above five, the curve flattens. Above ten, it's noise.
Specific framework. If you've shipped good software in two languages, you'll be productive in the third within two weeks.
How fast they solve LeetCode mediums. Useless for product work.

What I now care about more than I used to

Tolerance for ambiguity. Real product work is half-defined specs and shifting priorities.
Self-direction in remote work. Asynchronous discipline is now an entire skill.
Comfort with AI tools. By 2026, the productive engineers are the ones who've integrated GPT-5, Claude, Cursor or similar into their flow with judgement.
Calmness under pressure. Anyone can write code on a calm Tuesday.

The interview process I run now

1. 20-minute intro call. Story of their last project. Features vs decisions.

2. 60-minute paired coding session. Real domain, real keyboard.

3. 30-minute "tell me about a hard time" conversation.

4. One trial week, paid at full rate, on a real ticket. Non-negotiable.

That's it. No take-home assignments (insulting and gameable). No panel interviews (signal-to-noise too low). No pure technical screen by an HR person.

The closing principle

Hiring is the most important thing a founder does, and most founders treat it like a chore. The cost of a bad senior hire is six months and somewhere between $100K and $500K. The cost of running an extra trial week with three candidates is a few thousand dollars and one week of patience. Slow down. Watch them code. Listen to how they tell stories.

Originally published at mktrl.dev/blog.