How do you choose an opportunity for technical depth?

Great question - I really appreciate all the added context! 😊

I'll split response into 2 parts: First I'll cover the pieces specific to your current situation, and then I'll share my thoughts on finding greater technical depth in general across the industry.

A perceived limitation is I tend to associate these opportunities only with refactoring, which needs buy-in from business, but maybe there's more I don't see.

I think your introspection is correct - There's far more to technical depth than just refactoring. In fact, I'm actually not a huge believer in massive refactors - The impact is hard to measure and they often times make things worse. If you are going to go down this refactoring path though, here's some great resources around strategies for measuring the impact and getting buy-in:

• "How can I demonstrate the impact of migration projects in a platform team?"
• "How do you measure the impact of refactoring your codebase to use a new pattern?"
• "How to get more engineering focused work on the roadmap?"

My experience has been business only wants to spend the type of work that applies to covering 80% of the needs and the rest tend to be edge cases that don't get much review during initial design & implementation.

This is unfortunately a pretty common operating pattern - So many companies and their execs just want to do the absolute bare minimum to get working software into customers' hands. Something to think is whether this is a default operating mode or something explicitly mandated by the company. Let's say you push to cover those 20% of the more "edge" cases to really ship a robust, stable, and scalable product that works in all scenarios - Will you get pushback or do you think there's a chance it'll be accepted?

When I joined Instagram Ads, the coding culture was decent, but it wasn't the best. I got a lot of credit for leaning the org towards being more quality-oriented by revamping the oncall process to fix bugs faster, making code review culture much healthier and thorough, and just doing a ton of cleanup work in general (and making all my mentees do it too, hehe). It was big part of my promotion to senior and finding staff scope; maybe you can do the same too. This is definitely to talk to your manager about.

An idea I've considered is deliberately practicing DSA interview questions with the intent to identify concepts that may carry over to other implementations. How feasible does this seem?

In a nutshell, not very. It's definitely possible, but it's pretty rare to find a real-life engineering problem that requires a "DSA-esque" solution. And even if there's a DSA component involved, a lot of it is abstracted away by core libraries anyways.

And now, here's my thoughts around finding technical depth in general. At a high-level, my thought is to move away from the product layer and more towards infra. So what exactly does that mean?

• First, let's define "product" and "infra".
  • Product is stuff that's very close to the user. For the front-end, it's the pixels on screen and for back-end, it's the API endpoints that feed the front-end.
  • Infra is anything that's >1 layer away from the user. The further away it is from the user, the more "infra-ey" it is. An example of front-end infra is making optimizations to load video in Android apps more reliably in low-bandwidth environments (3G or less), which was a huge source of scope at Meta. An example of back-end infra is creating a library to provide simple APIs to query the database in a non-blocking way.
• The reason infra is generally more technically complex than product is because of the philosophy of "dumb client, smart server". Since the client (website or mobile app) is right in front of the user, you want it to be lean and fast. This means it's best for everyone for the infra layers to be as "smart" as possible and abstract almost all of the work away from the client.
• This is why more technical engineers will often times switch from product teams into infra teams: It's much harder to find technical depth when working on the product side. It can be tough getting senior scope in that environment, and for most engineers, it's near impossible finding staff scope as a product engineer.

Lastly, this isn't directly related to technical depth, but I highly recommend this discussion (also from a mid-level engineer) around how to come up with innovative, impactful projects: "How do I come up with innovative, impactful ideas and bring them to my team?"

Alex's comment about moving away from product matches my experience. I moved from a product team to a research team.

I still feel like a generalist, but the research team offers an opportunity to dive into technical problems on a months-long scale.

The sub-team I'm on within the research team functions as an engineering team embedded in a team of scientists. I like being exposed to the domain of the scientists (biology, stats) while being able to offer engineering experience.

If you work at Capital One, I'd guess there's a fraud detection team. Maybe there's a team that builds infrastructure to run the anti-fraud models at scale. A team like that intersecting two domains could have interesting technical problems.

How novel can you be relative to your peers while solving problems? In my latest job, I'm wanting to revamp everything after ~1800 hrs of study and I'm largely in charge of a number of large-scale initiatives whereas some teammates might only be in charge of epics. That being said, get a sense of how often your coworkers defer to your knowledge in a meeting and then tip that in your favor by focusing in on areas of interest. I do high-end AI/ML, software development, DevOps, and business C-exec level stuff and that's all I'm good at, very little more if you count personal hobbies and trust me it shows in personal life. Build more knowledge in whatever interests you and build out your 10,000 hrs of learning. Remember only your own effort limits you from becoming as good as you want. Just didn't change or do lateral moves too much because you kill forward progress. Hope this helps!