My team owns a really wide set of features spanning across multiple repos and programming languages (C++, React, Angular). On top of that, each person works on pretty different areas (telemetry/data, UI components, client side api, etc.). We have a v1 of the app being maintained and a v2 currently being developed with some people working on v1 and some working on v2. It's impossible to know all the context behind every pull request.
How can I give quality code reviews? At most I can only provide feedback to simple code logic and really well written PR descriptions. Should I be trying to private message the developer for each PR to understand more, or is this just something that comes with time?
Great questions! I love how you're taking code review so seriously as an earlier-in-career engineer: It's something I feel like a lot of junior engineers should invest in more. I was the top code reviewer in my org at Instagram (i.e. everyone underneath my director) with 700+ reviews per half, so being able to thoroughly review PRs outside of my immediate domain was crucial.
First, I highly recommend this video about writing more meaningful code review comments.
At most I can only provide feedback to simple code logic and really well written PR descriptions.
This might have more value than you think! You also shouldn't hold yourself to that high a bar as you're just starting your SWE career. I left feedback in this domain a lot and it can be very effective assuming your team has a good feedback culture and you are polite about it. Some tactics to try here:
Should I be trying to private message the developer for each PR to understand more...
I can see this getting annoying (you are requesting time, which is the most important resource). For 95% of cases, just lean towards asking great qusetions on the PR. For doing a meeting, I would only do it if:
All that being said, here's the additional advice I have about "breaking into" code reviews that are less within your space: