How I Went From Getting Rejected to Leading a Platform Team (It Wasn't My Code)

Let me tell you about someone I knew back when I was still in investment banking. A developer on our tech team (let's call him Marcus) could code circles around everyone. He'd built half the trading tools we relied on. Seven years of experience. A GitHub profile that looked like a green forest. And he got passed over for senior developer twice.

I remember thinking, "How is that possible?"

Years later, after making my own career pivot into data engineering and eventually leading a platform team, I finally understand. Honestly? What signals you're ready for a senior developer role has almost nothing to do with what most developers obsess over.

I've learned something from both sides of the hiring table: developers who get promoted to senior aren't necessarily the smartest coders in the room. They're the ones who've quietly developed a set of behavioral patterns that most people completely overlook.

Some of what follows will challenge things you've probably been told. But if you're trying to figure out when you're actually ready for a senior developer promotion, you need to hear it.

Why "5 Years of Experience" Means Absolutely Nothing

Job postings lie to you. Or at least, they oversimplify.

When a company posts "5+ years experience required," they're not actually counting years on a calendar. What they're really asking is: "Have you accumulated enough reps at solving ambiguous problems that we can trust your judgment?"

I've interviewed candidates with 10 years of experience who repeated year one ten times. Same patterns. Same scope. Same safe choices. And I've seen engineers with three years who operated at a senior level because they'd been thrown into chaos and figured it out.

Comparing junior vs. senior developer skills isn't about time served. It's about pattern density.

Companies actually track certain things, whether they realize it or not:

• How many times have you been the one responsible when something broke in production?
• How many systems have you seen evolve, not just get built?
• How often have you had to convince someone your technical approach was right?
• How many codebases have you inherited from someone else?

"How long does it take to become a senior developer?" Wrong question. Ask instead: how quickly can you accumulate the patterns that matter?

Signs #1–2: You've Stopped Asking "How" and Started Asking "Should We"

Sign #1: Your First Instinct Is "Why?" Not "How?"

A moment I see play out constantly goes like this. A product manager drops a feature request. A junior developer asks: "How should we build this?" A mid-level developer asks: "How can we build this efficiently?"

And the person ready for a senior role? They ask: "Should we build this at all?"

Being difficult isn't the point. Recognizing that your job isn't just implementing tickets is. You're protecting the team from wasted effort and the codebase from unnecessary complexity.

After I transitioned from investment banking to tech, I brought a habit that frustrated some engineers at first. I kept asking, "What problem does this actually solve for the business?" Turns out, that question is worth more than a thousand hours of clean code.

Sign #2: You Can Articulate Trade-offs Without Being Asked

Junior developers present solutions. Senior developers present options with trade-offs.

"We could use approach A, which ships faster but creates technical debt here. Or approach B, which takes longer but sets us up for the feature we're building next quarter."

Few things signal a good senior developer more clearly than this. They've internalized that every decision has a cost, and they surface those costs before anyone has to ask.

Already doing this naturally? That's a signal. Not doing it yet? Start practicing tomorrow.

Signs #3–4: Junior Developers Seek You Out (And You Don't Resent It)

Sign #3: You've Become an Unofficial Mentor

One of the most reliable signals I look for when evaluating what companies want in senior developers: do junior developers seek you out for help?

Not because you were assigned as their buddy. Not because you sit near them. Because they've learned that you'll actually help them understand, not just give them the answer.

Something like this happened to me when I was still pretty new to engineering. A junior developer on another team started Slacking me questions about data pipelines. At first, I thought, "Why me? I barely know what I'm doing." But her questions forced me to organize my own thinking. Teaching her made me better.

Nobody tells you this: mentorship items on a senior developer skills checklist aren't about being generous with your time. They're about multiplying your impact. One senior developer who can level up three juniors is worth more than one brilliant developer who hoards knowledge.

Sign #4: You Don't Resent the Interruptions (Much)

Look, nobody loves getting pinged during deep focus time. But consider your reaction to a junior developer's question. Consistent irritation rather than temporary inconvenience? That's a red flag about your readiness.

I've seen technically excellent engineers fail at senior roles because they couldn't shift from individual contributor mode to team multiplier mode. They resented every minute spent helping others as time stolen from "real work."

Senior developers understand that making others more productive IS the real work.

Signs #5–6: You See the Codebase as a Product, Not a Project

Sign #5: You Think About Code That Will Be Written Six Months from Now

A specific moment happens in the timeline from mid-level to senior engineer. Something shifts in how you see architecture. You stop thinking about today's feature and start thinking about tomorrow's features.

Junior developer: "This code works." Mid-level developer: "This code works and is clean." Senior developer: "This code works, is clean, and leaves room for the payment integration we're probably building next year."

Ownership mentality shows up in small choices. Naming conventions that make sense to future developers. Documentation you write even though nobody asked. Refactoring that isn't strictly necessary but prevents problems you can see coming.

Sign #6: You Feel Personally Responsible for Technical Debt

My first legacy data pipeline was a mess. My initial reaction was, "Who wrote this garbage?" Classic move.

But as I learned more about what makes someone ready for senior positions, I realized something crucial: senior developers don't just complain about technical debt. They own it, even if they didn't create it.

Because once you're senior, the codebase is your product. It reflects on you. Ready for a senior developer role? You'll catch yourself making improvements that nobody asked for because you simply can't stand leaving a mess behind.

Companies increasingly prioritize this in 2024: demonstrated ownership beyond your assigned scope.

Sign #7: You've Failed Publicly and Led the Recovery

Nobody wants to talk about this one. And it's the most telling sign of readiness I know.

Have you ever shipped something that broke production? Been the one who had to get on a call with stakeholders and explain what went wrong? Led the postmortem and owned the outcome?

No? You might not be ready.

I say this knowing how harsh it sounds. But senior developers make senior-sized mistakes. And companies need to know you can handle that.

Evaluating my own interview readiness, I realized that my most valuable experiences weren't the successes. They were the failures I'd recovered from gracefully.

Any developer who's never failed publicly has either:

1. Never been trusted with anything important enough to fail
2. Been extremely lucky
3. Been hiding behind other people's accountability

None of those prepare you for senior-level ownership.

Companies assessing candidates for the mid-level to senior transition are looking for resilience signals. Can you stay calm when things go sideways? Communicate clearly? Drive toward a solution?

Faking this in an interview won't work. But you can absolutely build it through intentional experience.

A Brutally Honest Self-Assessment Checklist

Below is a 15-question diagnostic I've developed based on what actually correlates with success in senior roles. Score yourself honestly. Nobody's watching.

Technical Decision-Making (0–5 each)

1. Given a feature request, do you immediately consider whether it should be built at all?
2. Can you explain why your team chose your current architecture to a non-technical stakeholder?
3. Name the last time you successfully argued against a technical approach.
4. Do you regularly identify risks before they become problems?
5. Can you estimate accurately within 20% most of the time?

Team Multiplication (0–5 each) 6. How often do junior developers come to you voluntarily for guidance? 7. Name the last time you wrote documentation nobody asked for. 8. Do you actively share knowledge in team channels or meetings? 9. Have you helped someone else get promoted or significantly level up? 10. Can you give constructive code review feedback without being dismissive?

Ownership & Resilience (0–5 each) 11. Have you led the recovery from a significant production incident? 12. Do you take responsibility for problems in your codebase that you didn't create? 13. Name the last time you refactored code purely because it was the right thing to do. 14. How comfortable are you saying "I don't know" in meetings? 15. Something fails. Is your first instinct to fix or to blame?

Scoring:

• 60–75: You're ready. Start advocating for yourself.
• 45–59: You're close. Identify your two weakest areas and focus there.
• 30–44: You've got real growth ahead. That's okay. Now you know where to invest.
• Below 30: You're probably early in your journey. Keep building patterns.

So where does this leave you?

Scored high on the assessment? Your next 90 days should focus on visibility. Start documenting your senior-level contributions. Have explicit conversations with your manager about promotion readiness. Prepare for the interview questions that will come up in any formal evaluation.

Got gaps to fill? Try my suggested 90-day approach:

Days 1–30: Observation Mode

• Track every decision you make this month. How many were "how" decisions vs. "should we" decisions?
• Notice who seeks you out for help and who doesn't.
• Identify one piece of technical debt you've been ignoring.

Days 31–60: Intentional Practice

• Volunteer for one ambiguous problem nobody wants to own.
• Schedule 30 minutes weekly with a junior developer, even informally.
• Write one piece of documentation that doesn't exist yet.

Days 61–90: Stretch Assignment

• Raise your hand for something slightly outside your comfort zone.
• Lead one technical discussion or postmortem.
• Start tracking your contributions in a format ready for promotion conversations.

Signs you're ready for a senior developer role aren't mystical. They're behavioral patterns you can observe, measure, and develop. Developers who get promoted aren't waiting for permission. They're already acting like senior developers before they have the title.

Which sign are you going to work on first?