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

For context, I mainly work on the web-side, building customer-facing surfaces. I don't want side projects to be something like DSA where it's good for interviews and that's it. The concept of side projects makes me think of Flappy Bird when it came out. It seems like it started off as a side project, so this is all interesting to me and would love to learn more about the benefits.

In Alex's case, he met Rahul at Meta and now they're cofounders. How can I build up such deep relationships with other people at Google or any future company I work at?

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?

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)?

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

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 "Practical Deep Learning with fastai and PyTorch". The fastai library itself is a popular target for a first contribution. See: How to Make Open Source Contributions to fastai (Hamel Husain) - Pull requests made easy - Contributing to fastai fast.ai Discord server (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: Side projects vs open source How to start contributing to open source Determining whether something is a major PR for Big Tech open source Getting users for your open source projects Promoting your open source projects

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.

In this Taro Premium session about onboarding at Robinhood, 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?

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.

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?

Some additional questions: What do you look for in the team? Do you tell your manager?

I would like some info on how hiring decisions are made. I understand DSA and System Design are important but HMs know these aren't good predictors of performance so I see a disconnect there. I'd like to understand what goes through the mind of the HM and/or committee before a decision is made. I know it's a broad and complicated question that has different answers depending on the company, but any info is helpful.

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!