In July 2021, I joined BYJU'S as an Associate Software Engineer. Less than five years later, I'm an SDE-2 at Expedia Group. Here's what I learned about career growth — the technical parts, the non-technical parts, and the things I wish someone had told me earlier.
The Timeline
- July 2021: Associate Software Engineer at BYJU'S
- January 2022: Performer of the Quarter (6 months in)
- March 2022: Promoted to Module Lead (8 months in)
- April 2023: Software Engineer at Tekion Corp
- June 2024: SDE-2 at Expedia Group
This wasn't a straight line. Each transition taught me different things.
What Actually Gets You Promoted
It's Not Just Code Quality
Good code is table stakes. What separates engineers who grow quickly:
Ownership: Don't wait to be assigned work. See a problem? Propose a solution. At BYJU'S, I noticed our payment validation had edge cases that caused silent failures. I mapped them all out, proposed fixes, and implemented them. That's what led to the Performer of the Quarter recognition.
Impact Awareness: Connect your work to business outcomes. "I refactored the payment module" is less compelling than "I refactored the payment module, reducing validation errors by 40% and saving approximately $50K/month in failed transaction costs."
Communication: The ability to explain technical decisions to non-technical stakeholders is a multiplier. When I presented the Vue-to-React migration plan at Expedia, it wasn't about frameworks — it was about developer velocity, hiring pipeline, and time-to-market.
Technical Skills That Matter at Each Level
Junior (0-1 years)
- Core JavaScript: closures, promises, event loop, prototypes
- One framework deeply (React, Vue, Svelte)
- CSS layout (Flexbox, Grid)
- Basic Git workflow
- Writing readable code
Mid-Level (1-3 years)
- TypeScript beyond basics (generics, utility types, type guards)
- Testing (unit, integration, E2E)
- Performance awareness (bundle size, render optimization)
- System design basics (state management, data flow)
- Code review skills
Senior (3-5+ years)
- Architecture decisions and trade-offs
- Cross-team technical influence
- Mentoring and knowledge sharing
- Production debugging and incident response
- Understanding of backend concerns (APIs, caching, databases)
Non-Technical Skills Nobody Talks About
Learn to Write
Clear writing is a superpower. I write:
- PR descriptions that explain the "why" so reviewers have context
- Technical documents for architecture decisions
- Incident postmortems that help the team learn
- Blog posts that solidify my own understanding
Every senior engineer I respect is a clear writer.
Learn to Disagree
Early in my career, I'd agree with senior engineers even when I saw problems. That's not helpful. Learn to disagree respectfully with data:
"I see the appeal of approach A, but I'm concerned about X. Here's a prototype of approach B that addresses that — what do you think?"
This is different from "I think we should do B instead." One opens a discussion; the other creates conflict.
Learn to Estimate (Poorly, but Honestly)
Estimation is a skill you develop through being wrong. The key is being honest:
- "I've never done this before, so my estimate has high uncertainty — 3 to 8 days"
- "I've done similar work, I'm fairly confident: 2 days"
- "This depends on the API team's timeline, so I can't estimate the full scope yet"
Managers respect honesty over optimism.
Mistakes I Made
Mistake 1: Chasing Breadth Over Depth
In my first year, I tried to learn React, Vue, Angular, Svelte, Node, Deno, and GraphQL all at once. I had shallow knowledge of everything and deep knowledge of nothing.
What worked instead: Going deep on React + TypeScript for two years, then expanding.
Mistake 2: Not Asking Questions Early Enough
I'd spend 3 hours stuck on something, then ask a question and get unblocked in 5 minutes. The fear of looking incompetent cost me real productivity.
Rule of thumb: If you're stuck for 30 minutes with no progress, ask for help. Prepare your question well (what you tried, what you expected, what happened) — that shows competence, not the opposite.
Mistake 3: Ignoring Soft Skills
I focused entirely on technical skills for my first two years. When I started investing in communication, writing, and presentation skills at Tekion, my career growth accelerated noticeably.
How to Transition Between Companies
When to Move
Move when you've stopped learning and your growth has plateaued, not because of a small salary bump. Each of my transitions had a clear reason:
- BYJU'S to Tekion: I wanted exposure to a global product, accessibility, and internationalization
- Tekion to Expedia: I wanted to work at enterprise scale with more complex frontend architecture
Interview Preparation
For mid-to-senior frontend roles:
-
JavaScript fundamentals: Event loop, closures,
this, prototypes — they still ask these - System design: Design a component library, design a real-time dashboard, design a form builder
- React deep dive: Reconciliation, hooks rules, performance optimization, Server Components
- Behavioral: Use the STAR method. Prepare 5-6 stories that cover leadership, conflict, failure, and impact
- Take-home or live coding: Practice building small apps with time constraints
Advice for Each Stage
If You're Junior
Focus on one technology stack and go deep. Build projects. Read source code of libraries you use. Write about what you learn — it forces clarity.
If You're Mid-Level
Start thinking about architecture, not just features. Review others' code proactively. Understand the business context of your work. Begin mentoring juniors — teaching is the fastest way to learn.
If You're Approaching Senior
Develop your technical writing. Lead a project end-to-end. Build relationships across teams. Have opinions about technical direction and back them with evidence.
Key Takeaways
- Career growth is more about impact and communication than code quality alone
- Go deep before going broad — specialize first, then expand
- Writing clearly is a career multiplier at every level
- Each company transition should serve a specific learning goal
- Soft skills aren't secondary — they're the difference between "good engineer" and "great engineer"
- Ask for help early, estimate honestly, and own your mistakes
Originally published at umesh-malik.com
Top comments (0)