Do you think you have what it takes to be a senior?
Somewhere in the Middle
I currently work as a front-end engineer at PayNet. My job grade is roughly equivalent to that of a mid-level engineer.
For someone who’s been in the industry for a modest 3 years, that’s probably a fair and expected position to be—though I certainly wouldn’t complain if the salary were a tad bit higher.
That said, I’m aware that some people within my circle have had a larger share of both luck and success, which helped them climb the career ladder faster within roughly the same period of time. I don’t obsessively compare myself with them, but their progress lingers in the back of my mind just enough to occasionally make me question my own career trajectory.
As it happens, this week was also the deadline for our team-wide annual KPI deliberation and submission. This year’s process felt quite different from previous ones, not least because of a recent change in leadership.
Our department lead-cum-manager asked everyone to gather in the same room to review the agreed-upon KPIs and submit them in the same sitting, which I found mildly amusing. Perhaps it was simply the most efficient way to prevent any last-minute reinterpretation of what had already been agreed upon.
Naturally, different job grades come with different sets of KPIs. What caught my attention, however, was the additional KPI assigned to senior engineers. They are required to mentor at least one junior engineer and conduct a minimum of two knowledge-sharing sessions.
Seeing that KPI made the next step obvious. Like any sane worker out there, the only direction from here is up. The next rung on the ladder naturally is to become a senior engineer.
So far, many of my colleagues have been surprisingly open and generous in acknowledging my contributions to the team—both in terms of hard and soft skills. My former manager once quipped that among all the frontend engineers in the team, I seemed to be the only one who is fastidious even about the smallest details and who cares enough about UI/UX to implement animations and transitions that, unfortunately to some, might seem immaterial or merely a low-hanging fruit.
More recently, I was invited to sit in on a rather high-profile meeting with the CTO. Truth be told, it felt well above my pay grade. I was quite literally the one with the lowest job grade in the room. The collective monthly salary of everyone else there could probably pay for my Mazda 3 in cash.
During the meeting, my manager introduced me as the team coordinator first and frontend engineer second… not exactly how I would have imagined being introduced.
I try not to overanalyse moments like that or give them too much weight, but I can’t help interpreting it as a quiet acknowledgement of the role I’ve gradually come to occupy within the team: acting as a de facto lead in certain situations and helping coordinate the team in what sometimes feels like an unofficial scrum master capacity.
One of my colleagues once asked whether I actually enjoy playing this role. I told him that I don’t relish doing it all the time, but if it helps the team move forward then why the hell not. After all, if the team wins, I win too. Especially if you vibe well with the team itself (shoutout to my MewThree teammates!).
Besides, I’ve always believed that you won’t get very far in life if you only strive to be good at things you already enjoy doing. Growth often means stepping outside your comfort zone while still maintaining competence.
Reputation, like Rome, isn’t built in a day—and this one has been two excruciating years in the making. It was definitely an uphill battle trying to earn the trust of everyone on the team.
And let’s be honest: when you put bold, competitive personalities in the same room, the loudest voices tend to dominate while the quieter ones slowly fade into irrelevancy—not necessarily for lack of skill, but because there are only so many spotlights to go around.
There’s also a stark contrast between my timid, individualistic self in the first year and the more outspoken, team-focused persona I’ve become today. I consider myself a slow burner, one that only burns brightly when given the oxygen to thrive.
Putting aside my personal qualms about my career for a moment, I’m simply glad that I’ve witnessed some genuine character growth in myself over the past two years.
The thing is, I have enough self-esteem and a few years of experience under my belt to believe that I could, maybe, potentially lead a team if the opportunity ever arose. But funnily enough, at the same time I still question whether I truly have what it takes to manage someone directly under me.
I’m not even sure if I possess the necessary instincts or qualifications to interview someone properly. Heck, I can barely manage myself, let alone someone else.
I’ll also admit I felt slightly envious seeing one of the senior frontend engineers on my team with a mentee who reports directly to him. It even made me catch myself daydreaming in the office about what it might be like to have a mentee of my own.
This is not even mentioning my technical skills, which—together with a healthy dose of imposter syndrome—sometimes leave me feeling somewhat deficient compared to the seniors or even juniors on my team.
Sometimes I wonder if my oratory and leadership skills are doing most of the heavy lifting, making me appear more competent than I actually am while quietly masking whatever technical shortcomings might be lurking underneath.
The rise of A.I. has not exactly helped to quiet those doubts either. Tools like Claude Code (which I paid for out of my own pocket) have certainly boosted my productivity, but they’ve also amplified my insecurities in subtle ways.
Perhaps it’s just my ego, but I hate the feeling of being dependent on anyone—or anything.
There was even a moment when this dependence became so painfully obvious. In the middle of a task, I ran out of credits (womp womp) and hit the daily limit for Claude Pro. With no way to continue unless I topped up again (something I shamefully admit I’ve done more than once), I ended up reorganising the Jira board and tidying my tickets while waiting for the limit to refresh.
I sometimes wonder whether the speed at which I’m producing work is truly my own, or merely a reflection of how effectively I can prompt a machine. It reminds me of that scene from the first Avengers, where Captain America questions Iron Man about what’s left of him without all that shining armour:
We all knew how Tony Stark answered. Unlike him, I wasn’t quite sure how I would respond.
In the Terrible Software blog post that I stumbled upon on LinkedIn recently, the author argues that the defining skill of a senior engineer is the ability to reduce ambiguity.
In practice, this shows up in small but meaningful ways: asking questions nobody else thought to ask, separating what actually matters from the surrounding noise, and identifying what needs to be done now versus what can be deferred for later.
In short, a senior is responsible for much of the invisible work upfront, making the problem clear before getting their—and everyone else’s—hands dirty to solve it.
- What problem are we actually trying to solve?
- Who’s the user here and what’s painful for them?
- What are we assuming that might be wrong?
- What happens if we’re wrong and ship this anyway?
Lucky for me and everyone else reading it, the author also outlined a simple litmus test for whether someone is ready to become a senior engineer:
What happens when someone hands you something abstract, fuzzy, or complex?
Do you wait for someone else to clarify it?
Do you start coding immediately and hope for the best?
Or do you spend time up front making it concrete enough that your team can actually execute with confidence?
If I were to honestly introspect, I kind of did all three.
When requirements aren’t clear, I might pass the task to someone more knowledgeable to help clarify it.
The engineer in me sometimes dives straight into coding and builds a quick prototype (with Claude Code handling much of the heavy lifting), not just to get a head start but to make the requirements easier to visualise.
Increasingly, I also find myself stepping into the product owner’s shoes: reorganising convoluted requirements and tidying up Jira tickets. This usually benefits the team by clearing confusion early, but it has occasionally put me in the crosshairs of my own product manager since it can feel like I’m encroaching on their territory.
As I grew more comfortable and confident in my role, I slowly found myself at the crosshairs of more people than I expected. My former manager once told me this is almost a rite of passage for anyone climbing the corporate ladder.
Visibility, as it turns out, is a double-edged sword. The more relevant you become, the more decisions you influence. The more standards you uphold, the more opinions you voice—and inevitably, the more friction you generate.
If I were interviewed for a senior role tomorrow, I’m honestly unsure if I would pass. But I think I’m closer than I give myself credit for.
Not because I’ve mastered the technical depth that I sometimes feel I lack, or because I’ve stopped leaning on Claude Code to get things done faster. But because I’ve begun asking the right questions before picking up the keyboard.
Because I care about the problem behind the ticket, not just the ticket itself.
Because when things are fuzzy, my instinct—even if imperfect—is to make them less confusing for everyone around me.
To me, becoming a senior engineer isn’t just about titles, pay grade, or technical mastery.
It’s about taking ownership of ambiguity, stepping into spaces that need leadership even when it’s uncomfortable, and doing the invisible work that helps the team succeed.
It’s the willingness to lead without being asked, to clarify when things are unclear, and to lift the team even when it would be easier to simply do your own piece.
It’s the quiet confidence, steadying presence, and sense of camaraderie you bring while navigating complexity and guiding others forward—even when the path ahead isn’t fully clear.
To be a great engineer is to go above and beyond titles and positions.
It’s never about pixel perfect UIs or flawless code. Maybe it’s not about getting it right every time, but about not leaving things hanging. You do something with it. You feel accountable for it, and you care enough to see it through to the very end.
The senior KPI that stood out to me initially used to feel like a far-fetched milestone I’d reach once I had proven myself sufficiently. Now I’m starting to think it works the other way around.
You don’t become a senior and then start sharing knowledge.
You start sharing, and somewhere along the way, you slowly become one.
I guess time will tell if I’ll become one—either here or someplace else. In the meantime, I’ll keep sharing and doing my best, one step at a time.