## Challenging projects

One of the most challenging projects I worked on was leading the backend development for app called "fan app" at Warner Music Group. We had only six months to deliver an MVP to internal artists and fans, and the environment was tough — most of the team were contractors unfamiliar with working together, infrastructure was minimal (mostly basic Lambda functions), and there was little documentation or support from leadership, as my manager was focused on longer-term strategy.

As the tech lead, I had to bring structure quickly. I initiated daily team meetings, even holding them at 5 a.m. to accommodate the London-based contractors, to sync up and track progress. I created a shared backend repository with a proper setup — including linters, unit testing, and factory patterns — and introduced scripts to enforce coding standards.

To unblock the team from infra bottlenecks, I also set up a temporary CI/CD pipeline on GitHub using basic cloud distribution so we could deploy and test independently before later migrating back to the company’s infrastructure.

On the feature side, I took on more complex tasks like implementing real-time comment pulling and handling audio/video processing pipelines with ffmpeg, which were areas the contractors weren’t familiar with.

Thanks to these efforts, we were able to launch the MVP on time. Even today, parts of the structure I set up, like the testing frameworks and audio/video processing, are still being used, which I’m proud of. It was a project that really tested both my technical skills and leadership ability under pressure.

## Tell me about feedback you got

One piece of meaningful feedback I received was during my time at Meta, where I was working on a project called Channel Value Rules.

The project environment was pretty challenging — there were frequent top-down changes about what we were allowed to launch, and how Channel Value should apply alongside other audience targeting data.
Because of that, I ended up writing a lot of code early on that later had to be thrown away or heavily reworked as the design shifted.

After one of these cycles, my manager gave me some really valuable feedback.
They said that technically, I was doing a strong job — I could adapt quickly, get the work done — but I should try to take leadership earlier in areas I wasn't fully comfortable with, like design ownership.
Specifically, rather than just adapting to changes, I should try to get ahead of them: understand why the design was shifting, where uncertainty was coming from, and proactively influence how we moved forward.

After that conversation, I made it a point to change my approach.

I wrote up a few key internal documents that clearly outlined:

 - What parts of the system were stable

 - What parts were still fluid

 - What options we had moving forward

I presented three main options to the team:

Build an alpha version fully aligned with the latest spec — but accept that it might be thrown away later.

Use the partially completed alpha work I had already built, even though it wasn't a perfect match with leadership's latest direction.

Integrate Channel Value into Audience Value logic for now, treating Channel as a subcomponent of Audience, and later evolve it into a separate view when needed.

We had a few discussions around the trade-offs, and ultimately agreed to go with Option 3 — it gave us a clear path to deliver something real without wasting a lot of effort, and kept the system flexible enough for future changes.

As a result, we were able to successfully launch the feature without more major throwaway work, and I felt much more confident leading design discussions and influencing the team's technical direction after that.

## Discuss a time when you had a failure, what did you learn from it.

One example that stands out is when I tried to introduce Bazel as a build system at Warner Music Group.

Coming from Google, I really believed in Bazel's strengths — having reproducible builds, better dependency management, and avoiding "works on my machine" problems.
At WMG, we were building a new backend system, and I thought if we set up Bazel early, it would save a lot of trouble later.
So even while working on main feature work, I spent about 20% of my time — and even weekends — trying to set it up and make it easy for the team.

The problem was, most of our engineers weren't used to build systems for scripting languages like Python and JavaScript.
For them, adding extra build definitions for simple scripts felt like unnecessary friction.
Even though I created codelabs, gave internal talks with a principal engineer, and tried to teach people how Bazel worked, productivity didn’t improve.
In fact, for many, it slowed things down because they had to wrestle with build rules instead of focusing on delivering features.

Eventually, a new senior staff engineer joined and raised a good question:
Why were we investing so much in something that wasn't an urgent problem?
Our codebase was small, our team was small, and unlike Google, we weren’t going to have 1000+ engineers working on the same monorepo.
Versioning by hand was manageable for us at this stage.

After a lot of discussions, we decided to stop pushing Bazel adoption and presented the situation to higher leadership.
We also convinced the principal engineer that, for our team's size and stage, the tradeoff wasn’t worth it yet.

What I learned from this experience was that technical correctness isn't always the most important thing — timing, team context, and scale matter just as much.
I learned to balance idealism with practicality: sometimes it’s better to solve today’s problems and leave future problems for when they’re re