Explore Capital One on Taro

Given this industry, switching is always somewhere in my mind. How can I figure out if it makes sense to pursue that or stay? When it comes to staying, how do I know if my current team is conducive to my overall growth and goals going forward?

I think I'm a good generalist with technical breadth and got I ask appropriate questions to learn a new stack. I think I lack in technical depth. Either I haven't had opportunities to develop meaningful technical depth or I haven't known how to leverage those opportunities.

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. 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.

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?

I get a lot of JIRA tickets for bugs where it's not clear what the fix should be. How can I find the problem area and relevant code faster with these issues?

I tend to give everything my all, which is what I did back in school. I overdid it back then, so I needed a long break afterwards. I want to make sure I don't make the same mistake with my career - What can I do to prevent burnout while still achieving lots of impact and growth?

I've heard this advice a lot, and I would like to get more clarity on what that concretely means. In particular, what does a junior engineer being proactive look like? Can someone provide examples?