im sharing this purely from my journey of going from a software engineer intern in jan 2025 to swe 2 in sept 2025, which is not a regular curve for most of the engineers, but what actually mattered was the principles and practices that i followed. im not setting the expectations, this won’t work for everyone, but these principles compounded fast for me and can give you a real jumpstart early in your career.

the principles below are shaped by the seniors i worked closely with and learned from over time — through feedback, reviews, and day-to-day collaboration, combined with the mistakes i made while working both in silos and in teams. over time, these experiences helped me internalize and curate what actually mattered.

1. be curious #

read a lot, stay relevant to the industry, especially in the domain you are currently contributing to in your company, this gives you an advantage — you get access to rooms and conversations where decisions and ideas are shaped.

ive been consistent about sharing my learnings, and reading articles, blogs, and even research papers in AI around how intelligent search systems are built for data catalogs and ecommerce. one thing that helped a lot was exploring and experimenting with ideas that had no immediate real world impact or direct relevance to my company’s roadmap. i always kept a parallel learning thread that didn’t depend on my sprint board, which helped me stay curious and current.

2. prioritize impact over speed #

in the era of AI, speed matters. but speed without direction compounds noise, not value.

avoid prioritizing work that isn’t aligned with your company’s goals — especially work that doesn’t translate to real business impact. you can build impressive features and experiments, but in the long run, what matters is the impact your work creates.

3. taking ownership #

its easy for interns or early-career engineers to say yes to everything that comes their way. but people are counting on you to finish what you start. partial ownership blocks others downstream.

i became very conscious of what i took on. it wasnt easy — i often handed off tasks after completing 80% of them. over time, i realised my team kept asking me for updates because i was the owner, i was responsible, i was accountable. from that point on, i stopped taking up tasks unless i was willing to own them until completion. i took help — but i owned the outcome.

4. dont wait to be asked #

act like the outcome depends on you - because often, it does. don’t wait for permission or assignment. if something’s blocking the customer and no one’s moving, move.

5. stay open even when you’re certain #

when you’re good at what you do, it’s easy to stop listening. you may skip validating your approach at a broader level. even when you feel certain, stay open. listen to other perspectives. strong engineers hold opinions loosely and invite better ones — that’s how better systems get built.

6. shorten the feedback loop #

talk to your customers, understand their pain points, because they are the ones who are using your product. the feedback gets carried away from customer -> product owner -> engg manager -> engg lead -> you. by the time it reaches you, it will feel more technical rather than the business outcome that customer is looking for, understanding the original context changed how i wrote code — i started optimizing for outcomes, not tickets.

7. be confident #

early in my journey, i was hesitant to talk to people because of their titles and experience. someone at my org told me: never care about titles — but always respect them.

be confident. ask questions, even if they feel stupid. share your thoughts and ideas. a fresh perspective often brings value. confidence doesn’t mean being right; it means being willing to be wrong in public and learn faster. be confident in the code you write, the architecture you design, the decisions you make, and the problems you solve.

8. be a team player #

i wasn’t a team player at the start. i worked solo on the -1 to 0 implementation of AI search, and i was good at it. but as the team grew, i realised i could do far more with others involved. they brought experience, perspective, and depth that i didn’t have alone.

you may feel slower initially due to dependencies, but individual brilliance hits a ceiling. teams remove it.

9. giving back (very personal) #

ive always been very connected to open source community, as i was a maintainer at autogen (now ag2), we at our org use a lot of oss tools, frameworks internally to build world class products to our customers. so whenever i get sometime, i try to give back to the community by contributing to these open source projects we use internally, or i go as a speaker at conferences to share our learnings and experiences which can help others in the community.

teaching and contributing exposed gaps in my own understanding and helped me grow faster.

always think problem first, writing code is the easiest part now with AI.

what compounds fastest early in your career isn’t intelligence or tools, it’s curiosity, ownership, and clarity of impact.

i’ve been fortunate to work in a healthy team environment. these principles may need adaptation in toxic or misaligned org cultures.

thanks for reading!