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 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. Some of those engineers were brilliant individually and disastrous on a team. Others were the opposite.

What follows is the much smaller set of signals I trust now in 2026. The list is short because if I'm being honest, most of the things people interview for don't matter once the work starts.

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. They'll often tell you the choice they regret. They'll usually know why.

If someone has fifteen years of CV and walks me through a project as a list of features rather than a list of decisions, they're not a senior engineer. They're a long-tenured mid-level engineer. Different role.

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 go silent and panic? (bad — but recoverable; check whether they ask for help)
• 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)

The output of the session matters less than how they got there. I've hired people who didn't finish the problem and rejected people who did. The unfinished one usually had the better thinking process.

Signal 3: They can disagree with me without being defensive

This one's load-bearing for the team I want.

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, will not 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. If they can't do it in an interview when there's nothing on the line, they won't do it later when something is on the line.

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.

This sounds petty. It's not. Engineers who have a real relationship with their tools — who've customised, who can answer "what do you do when this errors" — have the kind of compounding daily efficiency that produces ten times the output of someone who hasn't.

It's also a proxy for curiosity. Someone who's never opened the source of a library they use heavily, never read the changelog, never looked at the bytecode of their own runtime once for fun — they tend to be the same engineers who file bug reports rather than fix them. Both are valuable. But for a small team, you need the second kind.

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. Their tickets will be ambiguous. Their PRs will be unreviewable. Their hand-offs will be lossy.

I always ask for a sample. A blog post they wrote, a PR they're proud of, an internal doc with names redacted. If they don't have one — they're not senior enough yet, regardless of CV.

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. Pick your favourite.

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 know what a 3am incident actually feels like. They write code differently afterwards. They build observability without being asked. They write rollback plans without being asked.

If someone has only worked in environments where production is somebody else's problem, they're not a senior engineer in the sense I mean. They're a senior implementer. Both have value. The first one is much rarer.

What I no longer care about

• University. Useful as a mild signal at the very top end (Cambridge, MIT, Technion). Otherwise zero predictive value. Some of the best engineers I've hired didn't finish their degree.
• Brand companies. Big tech can produce great engineers and complete tourists. The ones who survived a 2,000-person codebase with discipline are gold. The ones who rode a hype cycle with three people doing the actual work are not.
• Years of experience. Above five, the curve flattens. Above ten, it's noise. I've hired four-year engineers who were stronger than fifteen-year ones.
• Specific framework. If you've shipped good software in two languages, you'll be productive in the third within two weeks. The framework someone happens to have used last is the worst possible filter.
• How fast they solve LeetCode mediums. Useless for our work. We don't write balanced trees. We integrate APIs and ship features.

What I now care about more than I used to

• Tolerance for ambiguity. Real product work is half-defined specs and shifting priorities. People who need clear tickets are great in stable environments and miserable in startups.
• Self-direction in remote work. Asynchronous discipline is now an entire skill — writing things down, choosing async by default, managing your own day. Some excellent engineers can't do this and burn out.
• 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. They're not vibe-coding blindly; they're using AI for the rote layer and applying brain to the rest. Engineers who refuse to use AI tools are increasingly the ones who can't keep up. This is a real, controversial signal in 2026.
• Calmness under pressure. Anyone can write code on a calm Tuesday. The differentiator is who you are when production is broken at 23:00 on a Friday.

The interview process I run now

1. 20-minute intro call. I want to hear them talk about their last project. If the story is told as features, not decisions, we don't continue.
2. 60-minute paired coding session. Real domain, real problem, real keyboard. Watch the thinking, not the output.
3. 30-minute "tell me about a hard time" conversation. Production incident, team conflict, a project they killed. I'm checking how they tell stories about hard moments.
4. One trial week, paid at full rate, on a real ticket. Non-negotiable. The interview lies. The trial doesn't.

That's the entire process. No take-home assignments (insulting and gameable). No panel interviews (signal-to-noise too low). No pure technical screen by an HR person (waste of everyone's time). One call, one technical session, one behavioural conversation, one trial week.

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 in salary, opportunity cost, and morale damage. 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. Disagree with them once and see what happens. Hire on signal, not on resume. The CVs that look the most polished are usually polished for a reason.