In particular, I'm having trouble figuring out really complex bugs. For example, on my current project, we're auditing a lot of the existing feature set to see what issues they have so we can fix them as we revamp them. I'm happy to find lots of issues, but I have no idea how to fix them, even after finding a code pointer.
I talked with a senior engineer on my team for help, and they were able to get more color on the situation. However, they mainly were able to do this as they have been in the org for a while and knew who to go to for what: I can't replicate that deep knowledge they have as I'm fairly new to the company. How can I create a systemic process I can follow to figure out these situations?
Do you have any tips on how to debug through these massive backend codebases? As a new engineer, it has been a steep learning curve needing to figure out the file structure of packages and where in log files to look for the right error to point me to where the bug is at in the code. Also, being new with Java, I have been struggling to figure out what to do after finding the error, not all error statements in Java are as.. robust as I would maybe like (cough cough Rust cough cough 😂)
The main difference between back-end and front-end when it comes to debugging is that you can't see pixels on screen. You can still add print statements, step through with the debugger, etc, and I recommend you try to do all those things.
When it comes to logging, I highly recommend figuring out how to get all logs to print to a console that you can then grep through. Quality of life when debugging is really low without it - I worked with both back-end and front-end at Meta, and we had this for both.
After finding the error, the goal is to understand how it is thrown. Is some piece of data missing when it shouldn't be? Are you going down some completely unexpected control flow? Use a mix of debugger and print statements to "detective" your way through this.
All that being said, a lot of the things like navigating the file structure and identifying the correct log files seem like pretty specific, extremely tactical things that I really think are best learned through talking to people. These are the kinds of issues where you can easily spend hours on it just trying to figure it out yourself even though this isn't really a part of coding fundamentals - It's just tribal knowledge specific to your setup.
I can't replicate that deep knowledge they have as I'm fairly new to the company.
Update your mindset. Believe in "I need to replicate that deep knowledge and I could achieve it." Then the right question to ask is "how can I achieve it efficiently?"
You should proactively get help to unblock yourself. The most important thing is to focus on "learning how to fish" instead of "getting the fish" in the process. It's part of the journey you are expected to take during your stay at Meta.
When I was a Bootcamp mentor and then later a Bootcamp mentor coach I kept telling people that it's critical for a Bootcamper to learn how to get the information they need. It's what the Bootcamp tasks should drive the Bootcampers to learn: ask POC to provide the context; ask POC to answer questions; ask POC who else to get the information if the POC doesn't know; follow the lead and jump through multiple hops to get the information; (when you are more senior) make decisions based on incomplete information.
Usually, it takes you one to two years to get enough institutional knowledge in a large company like Meta. The senior engineers in your team know where to find the right people and ask the right question. Ask them to show you how they do it. Ask them to walk you through each step in their process. Isolate the ones you can pick up quickly and accept the ones that take time to accumulate.
If they tell you "I just know this person on top of my head. So you should go ask them." That's something you need to accumulate over a long time. You just wouldn't know such things on top of your head.
If they tell you "I look up the manager and the tech lead in the org chart. I reach out to and ask them whether they are the best people to talk to about this question. It turns out the manager is technically hands-off and the tech lead is new to the team. They recommend I talk to another senior engineer in the team for my question." This process is the "fishing skill" you can observe and mimic quickly. Ask them to show you "how to use the org chart in Workplace", "how do you identify the tech lead in a team", "how to write a message to reach out to strangers in another team", or even "how to not feel bad if those strangers say no to me or just ignore me". Focus on learning in this way by keep asking people to demonstrate how they would do stuff that you can't do independently, yet.
I think others already made a lots of good points. I will just add one.
Let us be clear, you are
replicating that deep knowledge as we speak. A big part ramping up is asking for help to unblock yourself. Leverage the fact that you are new and earlier in your career to ask pertinent questions. Senior engineers expect you to ask questions especially during onboarding.
You should also do two things while asking those questions