Senior software engineers aren't defined by coding speed but by judgment under ambiguity. A CTO's lessons on hiring, mentoring, technical vision, and code review.
The first time I rejected a candidate who could out-code me, I realized my mental model of "senior" was broken. He solved the algorithm problem in half the time I'd budgeted, wrote Dart cleaner than mine, and knew Flutter internals I'd only half-read about in the source. And I still said no. It took me the rest of that week to articulate why, and the answer has shaped how I hire, mentor, and promote ever since.
Six years of shipping production apps, and a few years leading engineering at a startup in Dubai, later, I've stopped confusing fluency with a framework for seniority as an engineer. They are not the same axis. They're barely even correlated past a certain point. Here's what I actually look for now, the mistakes I made getting here, and the things nobody warns you about when you cross the line from writing code to being responsible for the people who do.
Before the stories, let me put the definition on the table so everything else has something to hang on: seniority is judgment under ambiguity, not fluency with a tool. A senior engineer is the person who makes good decisions when the requirements are half-written, the deadline is real, the data is incomplete, and being wrong costs money. Every trait I describe below — how they interview, how they handle a code review, how they behave during an incident — is downstream of that one capability.
This matters more now than it did when I started, because the "fluency" half of the job is being commoditized in real time. Agentic coding tools and LLMs increasingly write the boilerplate that used to signal competence. Syntax recall, framework trivia, the ability to bang out a clean CRUD method — machines are eating all of it. What they don't do is decide which problem is worth solving, at what cost, with what blast radius. That judgment is the scarce thing, and it's the entire game now.
Let me finish the story, because it's the whole thesis in one anecdote.
The problem wasn't his code. His code was excellent. The problem showed up in the follow-up. I asked, "Say this feature ships and a week later support is drowning in tickets about it. Walk me through what you do." He talked about adding more tests. Good instinct, wrong altitude. He never asked what the tickets said, never wondered whether the bug was even in his code or in a bad product assumption, never mentioned looking at logs, metrics, or a single actual user. He treated the system as a closed set of functions, not a living thing with users, money, and blast radius attached.
That's the tell. He was a phenomenal coder and a junior engineer. Coding is the part where you translate a well-specified problem into correct instructions. Engineering is everything around that: deciding which problem is worth solving, at what cost, with what tradeoffs, and what happens when you're wrong. The keyboard part gets cheaper every year — agentic tools now write the boilerplate he wrote so beautifully. The judgment part does not get cheaper. If anything it's the only part left that's scarce.
So seniority, to me, is judgment under ambiguity. Everything below is a consequence of that one definition.
The dirty secret of most technical interviews is that they measure how well someone performs under an artificial 45-minute spotlight, not how they behave on a Tuesday afternoon three sprints into a messy migration with half the requirements missing. I've hired people who nailed the whiteboard and then froze the moment a spec got fuzzy — which, in a startup, is always.
So I changed what I probe for. Instead of "reverse this tree," I hand candidates a small piece of real, anonymized code from our codebase and ask them to critique it. Something like this:
Future<User> getUser(String id) async { final doc = await FirebaseFirestore.instance .collection('users') .doc(id) .get(); return User.fromJson(doc.data()!);}The junior engineer tells me it works. The mid-level engineer spots the ! and asks what happens when the document doesn't exist. The senior engineer asks a cascade of questions: Who calls this? Is it on a hot path where we're paying for the same read hundreds of times? Should this be cached or streamed instead of a one-shot get? What's the offline behavior — does Firestore serve stale cache or throw? And is getUser throwing even the right contract, or should the UI layer get a typed result it can render as an empty state?
Same twelve lines. Wildly different altitude. The senior version of the answer usually rewrites the contract, not the code:
sealed class UserResult {}class UserFound extends UserResult { final User user; UserFound(this.user); }class UserMissing extends UserResult {}class UserError extends UserResult { final Object error; UserError(this.error); }Future<UserResult> getUser(String id) async { try { final doc = await FirebaseFirestore.instance .collection('users').doc(id).get(); final data = doc.data(); if (data == null) return UserMissing(); return UserFound(User.fromJson(data)); } catch (e) { return UserError(e); }}Notice what happened. Nobody asked them to make the failure states explicit. The senior engineer did it because they were already thinking about the caller — the widget that has to show something whether the user exists, is missing, or the network died. Seniority is mostly about the questions you ask before you touch the keyboard, and the people you're solving for who aren't in the room.
The other thing I screen hard for: can they disagree with me and then change their mind? I'll deliberately defend a slightly wrong technical position mid-interview — something plausible, like "we should just denormalize everything into one document, reads are cheaper than joins." People who fold instantly worry me; I've just learned they'll ship my bad idea without friction. People who die on the hill worry me more. The ones I want push back with reasoning, hear the constraint I add ("this document is written by three services concurrently"), and update on the spot. That single loop — hold a position, absorb new data, revise — is the most senior behavior you can watch happen live.
If you're building an interview loop, I'd bias the whole thing toward that loop. A code-critique prompt, a deliberately-flawed design you defend, and one open-ended "the feature is live and on fire, what now?" question will tell you more about seniority than any number of algorithm rounds. The algorithm rounds mostly measure who practiced LeetCode recently, which correlates with almost nothing you actually care about on the job.
As a CTO you live in permanent tension between the architecture you want and the features the business needs this quarter. Early on I over-indexed on vision — beautiful abstractions, clean layering, a state-management setup that could scale to a team of fifty. We were a team of four. We shipped slowly, and I felt smart doing it. That is a bad trade, and it took a missed launch window for me to feel it in my stomach rather than just know it in my head.
What I believe now, scarred into me:
// TODO: this breaks at scale that no one tracks is just a lie you tell your future self. If a shortcut isn't a ticket with an owner and a trigger condition, it doesn't exist and it will hurt you.The practical version of this is being ruthless about the feedback loop. If a Flutter build-and-deploy to internal testers takes twenty minutes of manual steps, engineers quietly avoid shipping, and avoidance is exactly where quality goes to die — the untested edge case never gets seen because nobody wants to run the gauntlet to see it. I would rather spend a day killing that friction than let it compound:
# .github/workflows/internal-release.ymlon: push: branches: [develop]jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: subosito/flutter-action@v2 - run: flutter test - run: flutter build appbundle --flavor internal - name: Distribute to testers run: fastlane firebase_distribute
The vision is served by the boring pipeline, not despite it. Every hour of manual toil you delete is an hour your team spends thinking about the actual problem instead of babysitting a release. And the engineer who builds that pipeline unprompted, because they noticed everyone flinching before deploys, is showing you more seniority than the one who wrote the fanciest widget that sprint. That instinct — to attack the friction the whole team feels instead of the ticket assigned to you — is one of the clearest seniority signals I know, and it never shows up on a résumé.
Here's a distinction I wish someone had drawn for me earlier. A shortcut is a tradeoff you make consciously, with the cost written down. A mistake is a cost you pay without ever having chosen to. Senior engineers take shortcuts constantly — they're some of the fastest-shipping people I know — but they almost never make mistakes in this sense, because the ledger is always open. When they hardcode a value or skip a layer, they can tell you precisely what it'll cost and when the bill comes due. Juniors experience those same decisions as things that "just happened" to the codebase.
The practical habit that separates the two is writing the cost down at the moment you incur it. Not "we'll remember" — a tracked ticket with a trigger: "single-region deploy; revisit when we onboard a customer outside this timezone." That one sentence converts an invisible liability into a decision the team made on purpose. Technical debt isn't dangerous because it exists; it's dangerous when it's unaccounted for.
The biggest mindset shift going from senior engineer to CTO is that your output is now other people's output. A line of code I personally write is a rounding error against the team's total. A junior I turn into someone who can own a whole feature is a multiplier that compounds for years. Once that clicked, hoarding the interesting work started to feel like what it actually is: stealing from the team's future to feed my own ego today.
A few things that genuinely move the needle:
The engineers who grow fastest under this share one trait: they treat feedback as data about the work, not a verdict on their worth. You can watch the two reactions in a code review. One person reads "this'll be slow at scale" and hears "you're not good enough." The other reads the same sentence and immediately asks "at what scale does it break, and what's the cheapest fix?" The second person is going to be senior in eighteen months regardless of their current title. The first will stall no matter how many years accrue, because they've made every review a threat to survive rather than information to use.
Part of my job is making feedback safe enough that people default to the second reaction. That means criticizing the code with surgical specificity and the person with genuine warmth, and never, ever confusing the two in the same sentence. "This function is doing three things and the third one surprised me" is about the code. "You always overcomplicate things" is about the person, and it teaches nothing except to stop showing you real work. The distinction sounds small; it's the difference between a team that grows and one that quietly learns to hide.
Strip away the titles and the years, and here is what I've found actually correlates with seniority — the signals I now weight more than any line on a résumé:
One warning, because I fell into it. It's tempting to hunt for the mythical 10x engineer who out-produces everyone. In practice, the person who makes the rest of the team 20% better is worth far more than the lone genius who's 300% faster and leaves a wake of code only they understand. I've hired for raw individual brilliance and quietly regretted it when that brilliance came bundled with a bus factor of one and a documentation habit of zero. The multiplier that matters most points outward. A senior engineer's real output isn't their commits — it's the ceiling they raise for everyone standing near them.
There's a version of this that gets worse with seniority, not better: the engineer who's genuinely brilliant but treats knowledge as leverage, hoarding context so they stay indispensable. That's not a senior engineer, that's a single point of failure with good PR. Real seniority is measured by what keeps working when you go on vacation. If the system falls over the moment one person is unreachable, that person made the team fragile, however fast they type.
Compressed into one sentence: seniority is judgment under ambiguity, not fluency with a tool. The candidate who out-coded me taught me that in a single follow-up question. Hire for the questions people ask before they touch the keyboard, not the syntax they can recite — the syntax is the part machines are busy commoditizing. Let delivery earn you the right to your vision, and keep an honest ledger of every shortcut you take. Mentor by handing over context and getting out of the way, and make feedback safe enough to be useful. And measure your best engineers by how much uncertainty they remove from the room and how much they raise the people around them — because that, far more than raw personal output, is what lets a small team in a Dubai office ship things that punch well above their weight.