Junior Engineer Career Development Videos, Forum, and Q&A

I'm learning it's important not just to do good work but also to make your work visible to your team and sometimes wider circle. This is common feedback given to junior engineers at Meta. What are some ways to get more visibility on my work and what are some rules of thumb (e.g. structure of posts, cadence of posts, when to share progress in team meetings)?

I'm an entry-level engineer who recently joined a team working in a new domain for me. Despite my best efforts, I find myself making mistakes in my code, such as forgetting edge cases, missing function calls, or mishandling character escaping (to quote a few recent ones). While these errors should ideally be caught during unit or integration testing, our team lacks a formal review process, leaving me solely responsible for testing my code before it gets merged. Consequently, bugs occasionally slip through, requiring post-deployment fixes. Although we're not a customer-facing team, I am afraid this puts a question on my reliability and erodes trust the team can place on me to write good code, that doesn't require iterations of fixes.

Could anyone offer advice on how I can better anticipate scenarios and prevent bugs from being introduced? I'm also unsure whether my challenges stem from a lack of technical skills or effective communication. How can I ensure I'm asking the right questions and considering all relevant factors before writing code?

Any insights or suggestions would be greatly appreciated.

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?

I'm trying to break into AI as a Machine Learning Engineer. I want to demonstrate expertise in AI/ML topics and capture a "Wow" factor by contributing to a well-known open source AI project.

I'm looking for suggestions spanning CV, NLP, tabular data and collaborative filtering -- not excluding but not limited to the latest GenAI stuff.

Some context: I have an MS in CS, did CV research, and completed Jeremy Howard's ".

The itself is a popular target for a first contribution. See:

2. (if the link doesn't work, it's also discoverable: search "fast.ai"). #fastai-dev is the contributors' channel.

One concern is identifying something that's non-trivial but tractable for a relative newbie. I realize there's tension between this and achieving that "Wow" factor at least in the beginning. I'm not sure a contribution to, say, PyTorch or scikit-learn is achievable from where I stand, but I could be wrong. Perspective on how to spot/scope opportunities would be appreciated too.

Thanks very much!

Potentially relevant questions on Taro:

In this , Alex mentioned that his technical documentation stood out because no one wrote docs in that much detail.

Are tech docs mainly for how you plan to accomplish a project and are they useful for junior engineers? If so, how do you write good technical documentation?

I recently joined Meta, and I'm aware of "up-or-out". However, I would like to more deeply understand how it works and have a better mental map of the entire thing in general.

How long do Meta SWEs overall take to go from E3 to E4 and then E4 to E5?

My manager has given me feedback that I could be more active in meetings, which would help me find my place within the team. However, I find it hard to participate in meetings a lot of the time, because I don't know the technical source material they're talking about. This leads to me learning as I'm in the meeting, and I don't have any remaining mental bandwidth to speak up.

When it comes to meeting types, I'm good with those like retros and brainstorms but those that are more technical like tech reviews and project planning can be hard to a large voice in.

I work on the privacy side, so our core projects are often held up by XFN. This leads to me having to find something to do in the meantime, which often means smaller, ad-hoc efforts. However, I've been told that working on larger projects across a lengthier time horizon is better for promotion. What can I do during these blocked times that also shows good execution signal for promotion?

I didn't interact much with people during my school and college years. Now that I'm stepping into a new phase of my life (my first job), I want to improve myself.

I'll have obvious reasons to interact with my teammates, so I'll try my best to socialize as much as possible (any suggestions are welcome). But how should I go about networking with people outside my team? Should I just randomly approach someone to introduce myself? When should I do it? When they are working they would be busy, so should I catch up with people during lunch (and what can I do if my whole team generally eats lunch together)? Will it be okay to go and sit or talk with a bunch of people having some conversation, or should I try to talk with individuals first?

Also, I'll be the juniormost folk there (other than maybe interns), how fine will it be to approach anyone random (since they can be very senior, which I don't know yet)? Even if I know someone senior to me previously (like the people I met during my internship), I find it hard to start a chat and find the right balance between disturbing them and having a conversation. And in general, I won't have much context to talk about the majority of the topics.

I know I'm really clueless, so any answers or resources would be highly appreciated!

Some additional questions:

1. What do you look for in the team?
2. Do you tell your manager?

What does Alex Chiou read?

How does he think when he writes?

Is there a certain number of drafts?

Does he get someone to read it and give their thoughts etc?

When I read Alex's work, it makes me think better. I learn something new because I think - oh, I could also think this way. Oh, someone else can think this way. Oh, I learned something new.

My goal is to transition into a SWE role, but something I've struggled with is making the building of software projects more digestible. A lot of the time I'll look at some project I have to build, and I just don't know where to start or how to figure out what to do. Any tips on how to make this process less scary?

I have been seeking to develop habits / follow a system to increase code quality, both in terms of readability and number of functional issues. I have come up with a few ideas I have listed below but I am curious what other people have been trying out! Have any of the below worked for you? What specific steps do you take to ensure code quality?

1. More awareness while writing code: it's tempting to write a rough draft version of the code thinking you will polish it later but oftentimes it's easier to spot mistakes while your attention is on the erroneous line of code. Example of this in action: search for where the method you're modifying is used in the code base before making changes to it.
2. Do not submit the code for review immediately after writing the code. Give yourself a short break, come back and review your code with a fresh mind, which will make spotting bugs easier.
3. Write down the possible edge cases in a notebook before submitting the PR for review. For medium to large PRs, the process of writing itself can help you consider more edge cases than simply keeping them in your head.

In July, I received a mid-year evaluation indicating room for improvement, with a rating of 2 out of 5 on the scale. My goal is to achieve an outstanding rating by this time next year. Here are the areas my manager provided feedback on for improvement:

He is a college hire, so he is a very junior developer.  He is an enthusiastic member of the team and seems eager to make contributions. He has struggled to learn the fundamental skills required for the job (programming, database, web development).  He will need to improve upon these skills in order to make contributions to the team with little assistance from his peers.