It’s been a while since I last wrote here — work and life have been full, and writing fell off my routine. A lot has changed since then. Over the past three years, I’ve gone from an IC3 engineer to IC5 at Meta.

It’s been fast, chaotic at times, and full of learning curves.

This post isn’t advice — just a few honest notes on what that journey looked like for me.

IC3 — Starting Out

When I joined full-time, I had some context already from a previous internship. That helped a lot — I could ship code from day one and didn’t have to learn Meta’s development stack from scratch.

I joined the Checkout team as a backend engineer. About ten of us worked on backend, with another ten on the sister frontend team and a few PMs across the space. It was a big, fast-moving surface with a lot of cross-team dependencies.

The first few months were intense. I had to learn not just the product logic, but how the whole production system fit together — everything from loggers to metrics pipelines to how code made it into prod.

The “war room” atmosphere built a strange kind of camaraderie; everyone was in it together.

Projects

  • Meta Checkout “War Room” – supporting stabilization and reliability work during heavy launch cycles.
  • Meta Checkout Shopify SDK – owned the Meta-side API design and communication flow between Shopify and Meta (and got my first taste of cross-company collaboration).

IC3 was about execution. Shipping quickly, asking the right questions, and being reliable. Nothing fancy — just doing the work well.

IC3 → IC4 — Building Independence

It took about a year to go from IC3 to IC4.

The biggest shift wasn’t technical — it was how I approached work. At IC4, no one tells you what to do. You’re expected to find things that matter and push them forward yourself.

The moment that made a difference was when I took initiative to refactor a large part of our codebase. It wasn’t assigned — it was just something that had to be done if the team wanted to move faster. That project forced me to understand the system end to end and coordinate across engineers to avoid breaking things.

I was lucky to have strong mentors (IC5+) who taught me how to balance technical idealism with pragmatism. One funny twist: the project I spent the most time on that year never shipped — a strategic decision above my pay grade. But the promotion still happened, because what mattered wasn’t output, it was independence, initiative, and reliability.

IC4 — Broadening Scope

Soon after the promotion, I got reorged into the Orders team. I didn’t choose it — it just happened — but it turned out to be good for growth. I had to re-onboard from scratch and learn a completely new system.

I worked on the Order Management System, the backend that handles everything from payment capture to refunds.

Projects

  • Tax-Inclusive Pricing – a horizontal change that touched every order flow (refunds, fulfillment, capture). A lot of careful coordination.
  • BYOG (“Bring Your Own Gateway”) – building a new order flow to integrate external gateways like PayPal.

It was challenging at first. The new team had different norms, and I missed my old context. But adapting to change ended up being a skill in itself.

Over time, I realized I wanted to work on something more technical and foundational — closer to systems and infrastructure. Product cycles can be exciting, but also repetitive. I wanted to go deeper. That’s what led me to make the switch to AI Data Infrastructure.

Switching to AI Data Infra

Joining AI Data Infra was like starting over again. Different domain, different tools, different way of thinking.

But I was one of the first engineers on the team, which meant more ownership and less guardrail. I had to learn about distributed data systems, LLM training workflows, and what “data quality” means at scale.

Projects

  • GitHub PR Dataset – a research-oriented project to ingest and analyze open-source pull request data.
  • Code Data Sourcing – infrastructure for extracting and structuring code data for training models.

The ambiguity was high, but so was the sense of impact. I was no longer just building product features — I was helping build the data backbone for AI research.

It was easily the steepest learning curve of my career.

IC4 → IC5 — From Execution to Ownership

After about two years at IC4, I was promoted to IC5.

The expectations at this level are different. You’re not just delivering tasks — you’re creating direction.

I started mentoring other engineers, leading designs, and architecting new pipelines from scratch.

The GitHub PR dataset was especially tricky: open-ended, research-driven, and full of uncertainty. Progress depended on aligning people who didn’t technically report to me, finding clarity in fuzzy goals, and building something useful out of it.

At this stage, what mattered most was:

  • Consistency – sustained output over time.
  • Initiative – finding problems before someone assigns them.
  • Leadership in ambiguity – bringing clarity to undefined areas.
  • Time and trust – promotions at senior levels are built over multiple review cycles.
  • Impact (and some luck) – timing and organizational needs always play a role.

It wasn’t about one big launch. It was about building credibility, judgment, and calmness over a long stretch of work.

Looking Back

When I joined as an IC3, I thought growth meant learning new technologies.

Now I think it’s more about learning how to operate in uncertainty — how to keep moving when direction isn’t clear.

If I had to summarize:

  • IC3 taught me how to execute.
  • IC4 taught me how to take ownership.
  • IC5 taught me how to create direction.

Each step forced me to relearn what “being good at my job” means.

I’m grateful for the people and teams I’ve worked with — and for the luck of being in places where I could keep learning.

More reflections (and hopefully more regular writing) to come.