Mid-Level Software Engineer [Senior Associate] at Capital One

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?

How do I know when it's time to leave a team/company?

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?

How do you choose an opportunity for technical depth?

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?

Entry-Level Software Engineer [Associate] at Capital One

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?

What does being proactive look like in practice?

Capital One Financial Corporation is an American bank holding company specializing in credit cards, auto loans, banking, and savings accounts, headquartered in McLean, Virginia with operations primarily in the United States.

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? For additional context, I'm working more on the back-end side with data pipeline.

Capital One

Mid-Level Software Engineer [Senior Associate]

- My tactic for quickly root causing: start by grepping the codebase for anything relevant to the problem (do this by searching for the relevant string, module name), and then blame the code. 
- If the regression just happened recently, look at recent code or config changes and try to see if that fixes the issue. This strategy lets you quickly fix issues even if you don't know what's going on :)
- It's important to clarify if the gap here is around the desired behavior or identifying the cause/fix. If it's the latter, I'd push back aggressively on the person/team who filed the bug and ask for more info, or send the task to the PM to get input on the desired behavior. It's also fine for you (as the engineer) to have input on the correct fix, but it should be documented and clarified what is a bug, feature, or desired behavior. (you'll be surprised how often there is ambiguity around that)

Meta, Pinterest, Kosei

Rahul Pandey

Here's my process for debugging:
1. Figure out the overall flow (i.e. series of steps) for whatever your issue is
2. Go through each of the steps and use log statements/debugger to figure out if it's working
3. After finding the broken step, narrow it down to the relevant module/class that is broken.
4. Step through the code carefully to find the broken method and finally, the broken line of code.
5. If you're struggling with #3 or #4, blame the code (or use your org knowledge of component ownership) to find the proper person to ping for help. If the person can't help you, get someone else who could and traverse the "help chain".

The step I see junior and mid-level engineers struggle with the most is #1, followed by not having the confidence to do #5. The failure mode with #1 is they just try to take in everything all at once and don't have this structure to step through the issue pragmatically. So with data pipeline, here's a really scuffed example from me.

Bug: Client event triggered by user behavior (e.g. clicking on a button) isn't properly being logged into the SQL table.

The steps could be something like:
1. User behavior happens - Maybe the event just doesn't fire?
2. Event is sent to some back-end endpoint - Maybe the endpoint doesn't receive anything and the sending protocol is broken.
3. Endpoint parses the payload into some local data model - If this breaks, maybe the sent payload is malformed?
4. Back-end logic inserts model into table - If this fails, the issue could be a database connection issue, malformed local data model, or maybe the entire table is just broken and missing a column or something.

Another thing I recommend while debugging is to write everything down as you're stepping through the issue and learning bits and pieces along the way, similar to what a detective would put together investigating a crime scene. The paper trail helps you zoom out and remember theories you have already considered and debunked, and it helps you claim full credit for fixing the bug at the end as you can show how complex the journey was.

For a detailed case study of how to find bugs and get proper recognition on fixing them, check out [this video](https://link.jointaro.com/2f9yjSU3B3BRdNwr6) where I break down how I fixed a multi-million $$$ bug in Instagram.

Related resources:
- ["How can I become more independent and better at unblocking myself with tricky technical issues?"](https://link.jointaro.com/xE8oMpCaDYjuMhCg7)
- ["I'm trying to fix a P1 bug, but some relevant code is owned by another team. Unsure about ownership and how to proceed."](https://link.jointaro.com/d6aBjYcf85i1E4AE8)

Robinhood, Meta, Course Hero, PayPal

Alex Chiou

Mid-level engineers have very strong technical proficiency, able to execute on small to medium-sized projects with minimal hand-holding, leveling up from junior engineers.

How can I root cause bugs faster?

Capital One

Discussion

Capital One