Explore Junior Engineer on Taro

I'm pretty good at leetcode (was able to pass some 3 to 5 rounds of interviews), I got good at by practicing and continuous learning. Now I want to be good at software engineering in general like debugging, building components, understanding complex things/systems, etc. I see one of the suggestions is to improve on fundamentals of software engineering, how do I do that? and What action items can I follow consistently? Any concrete suggested steps will be great instead of just some general bullet points. Thank you all.

I work with several senior engineers who split their time between teams. This leads to odd stand up updates such as “I have no updates for this team”. As a result, I feel like I’m not getting value from their updates, and I also don’t know how to structure my updates to make it relevant for them.

Hey all,

I’ve been in my team for over a year now and I’d like to change teams. In my previous companies it took a lot (of luck) to change teams (typically would only happen when orgs restructured). I’ve heard the process in google, and tech in general, is really straight forward and I’d like to get out of my org and try a different team. Would anyone be able to provide tips or guidance on how to change teams?

Thanks!

I'm a junior engineer working with one other person on a pretty isolated part of the codebase. I work closely with this one person, but I don't work for an extended amount of time with anyone else. I am part of a larger team, but the work we do doesn't really interact with them (for example, I don't even take part in their sprint planning, and they generally don't know anything about what we're working on, and us them.)

As a result I only had a couple of peer reviewers in the last review cycle, and my manager said I would need more peer reviews in order to be promoted. What are some things I can do to plan ahead and assemble more reviewers, given I don't naturally get enough reviewers through my core work? I am trying to review some of my team's PRs and be more active on slack in order to increase my interaction with the team, but I'm not sure that's enough to request peer reviews from others.

My team got split up recently, and I got put onto a sub-team I'm less familiar with (I have more context and experience with the other sub-teams formed in this re-org). Any thoughts on how I can make a case to be on one of the teams I feel like is a better fit for me, and if I'm not able to do that, how do I make the most of this new situation?

Sometimes I sit in meetings that I feel aren't really necessary. How can I better identify whether these meetings are necessary and propose a better asynchronous form of communication (slack post, quip doc, etc) if they aren't?

Some of these meetings include status update meetings (besides standup), and meetings where people are there just to absorb knowledge. Is it a general rule of thumb to have meetings primarily to get alignment on decisions? Are there cases where we can get alignment asynchronously as well via commenting on a slack post/quip doc, etc.

Hello,

I am working as an Entry level engineer at mid size product based company. In my end year performance review, I got a feedback that I can work on improving my debugging and technical skills more. As well as, knowledge of other features and overall product as a whole would need to be increased as well.

My Tech lead has offered to mentor me by conducting 1:1 sessions to help me improve at debugging and help identify patterns and teach basic principles. 2 other senior engineers on the team also reached out and offered to conduct sessions regularly with me, for which I am really grateful.

For more context, all my teammates work remotely, so it is not beneficial to go to office. My question is, how can I best utilize these sessions with the senior engineers on team to improve more and skill up? That is, what kind of preparation/ questions should I have ready to make the most of these sessions?

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 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'm currently working as an SRE (Site Reliability Engineer). I was, and am still interested in being a Software Engineer.

I am interested in switching in the future to a normal software engineering role, but want to make the most of my current situation since I recently joined the company (late-stage startup).

What do you think would be some good skills, exposure, things I could learn as an SRE that would be useful to a Software Engineer?

Hello,

As the title says, I’m stuck as an entry level engineer in FAANG for almost 4 years now. I’ve been reflecting on what I’m doing wrong.

My first company I worked for 1 year and didn’t not like it because the lack of mentorship. I joined and my questions never got answered, the tech lead didn’t really care about giving mentorship, just gave me links and bug IDs. I was able to survive for 1 year but I left the company because I felt so lost. My manager mentioned that I was “on track” to getting promoted but I hated the culture.

Then worked for 1.9 years on another company, where I received awards for my projects and contributions. I did receive mentorship here, but I was not able to get promoted. At the end of the timeline my manager mentioned I was moving slower and slower. I was working as a full stack and I believe my error here was not playing my strengths, since every time I had to take another project it would be on a different area, such as server on a language I never used before. I had a few discussions with my tech lead and I felt I lost my team trust because they would give a lot of comments, and just get a lot feedback from other people. This kinda demoralized me and made it hard to keep working so I changed teams. My last team I worked for 8 months before getting laid off. Here I also received recognition for my projects. My first project I missed the deadline because the onboarding had nothing to do with my project. I integrated our tool with an external team, so most of the code base I worked was not even ours (the techlead and team didn’t have much knowledge). Then I was given another project where I was starting to get traction, onboarding and project matched, I had to ramp up again on the new tech stack and my manager was getting frustrated with me, my team was very helpful and I was slowly to become independent. I feel like people trusted me here and code reviews would go smooth this time, at the end I was finally getting positive feedback, but was affected by the layoffs. From reflecting, here is what I did wrong:

• Not communicating well enough my work with my managers. Status updates I was blocked/learning and that would make me look slow.

• Not very good mentorship, I feel like at the beginning I needed lots of 1:1 to be able to learn our teams codebase. Sometimes I got very good mentorship but not complete. So I learned well parts of the code base where the tech stack applied.

• Switching projects too much, went from front end, full stack, server side with several languages. Every time I had to re learn a lot of new of the tech stack.

I did get several recognitions for my contribution with at least helps me think I’m not completely inadequate for the field.

I am looking for a new position, is there anything that could help me perform well as a mid engineer?

Thanks

If you have a new manager joining to manage your team, how can you ramp them up quickly on all the work you have done before them, the impact you have generated, your role in the team.

I joined this new team in October and I'm finding it hard to demonstrate velocity as an entry-level developer. I'm sure this has been discussed before on this thread but what are some sure-shot things to do to increase my commit count?

I know this isn't the healthiest way to approach things but commits and reviews are the best way to demonstrate impact at the L3 level and I'm trying to maximize my impact until the end of this year.

How can I add code quickly? e.g. Add extra unit tests for edge cases, add logging statements, etc.

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?

Currently, I'm on a 10 person team, but we only have 3 senior engineers and the remaining 7 are E4s (5 people) and E3s (me and one other new grad). For our upcoming half, they want E4s leading some of the projects for their development. However, I would like guidance, mentorship, and feedback from an E5 or above ideally since they are more experienced. Also, from one of the Taro videos on feedback, one of the points made was to find a way to get feedback from senior engineers at the end of the half who will bolster your PSC packet versus a mid-level engineer who might not hold as much weight (Correct me if I'm wrong)?

Anyway to navigate this the right way? Should I avoid certain projects that are led by E4s? Does this even matter?

For this upcoming half, I'm working in four different areas: reliability, sourcing, delivery, and datastore table. It just seems like it's too much and I'm not building any depth? Feels like I won't be able to build expertise in anything and be unable to contribute as a good team member if I'm working on everything?

My TL has also informed me they are struggling to scope out work due to a lack of senior engineers. This has resulted in me getting menial tasks such as better engineering work and refactoring in some of these projects (i.e. delivery, sourcing, and reliability). It's great for my diff stats, but I want larger scope and less narrow work to be considered for E4. I'm discussing with EM, but the EM and TL seem like they are on different pages. I'm most interested in sourcing, but seniors are struggling to scope out work.

Any suggestions on what to do here? I feel a bit lost overall and I'm struggling to understand how to get scoped and larger non-menial project work. Should I involve my skip manager here? A couple of questions in this one question but appreciate all the help in advance.

In my earlier experience as an intern, I haven't had much previous experience where I had significant influence over the projects I get to be allocated into; it was typically out of my control as to the sort of projects I got to work on. I've had opportunities to work on incredible projects where I grew a lot and also projects where it didn't quite align with what I wanted to do and also had limited opportunity to grow (e.g. working on some proprietary language or a lower impact project designed to be assigned to interns).

As I start my job as a junior engineer, I'd like to play more of an active role (wherever possible) to influence the direction as to the sort of project I work on and my growth direction.

In my experience and from my understanding, I think there are several factors when evaluating a project:

1. Your own personal technical background and experience (Zone of Proximal Development)
2. Your own personal career goals and skills you're trying to develop
3. Growth & business impact potential (if your goal is promotion)

Do these factors make sense when evaluating a project, and are there any others I'm missing? Also, how can I figure out #3 more in-depth for any project?

My goal is to join a team that would allow me to have the opportunities to work on projects that have the potential to produce higher business impact & learning opportunities to grow and reach promotion in the shortest possible time. Early in my career, I don't think I would mind working longer hours or being stressed as long as it is for good reason (such as the opportunity to be promoted) and within my capacity to handle it and also as long as it is not something that is long-term and chronic stress forever.

This is why I want to understand more about oncall. I know that oncall can be very stressful, and this applies to Atlassian too. Can being oncall be good for learning, even for a junior SWE, or does it always just give you chronic stress for no good reason?

I transitioned into a backend engineering role 1 year ago after working as a data analyst for 3 years. The jump was definitely big to me, as I had to learn a lot of new concepts (OOP, clean code, architecture, devops etc). The transition was done through internal hiring where they did a live coding interview (2 easy leetcodes), a live system design interview, and motivational interview. I passed all of those and ended up in a high-paced team.

The team was severely understaffed. The manager was managing 3 teams that decreased from 20+ people to <10 people and there was hiring freeze. There was no proper onboarding and all the seniors were too busy with tasks to help me properly. I did my best to read the documentations and set up 1-1s with more senior engineers from other teams that could help me. I finished several projects although carried over some to the next half.

My 1st performance review was "meet expectations". However, before my 2nd performance review, there was a manager change and this manager gave me "partially meet expectations" and then said that I would be put on PIP program. When I asked the manager what the program would be like and how many people completed this successfully, he/she couldn't give a definitive answer and said that HR would be in touch me.

I decided to quit and spend time to learn more fundamental concepts and take up a freelance project. It's been 2 months since then. Right now I feel like I'm learning a lot in these 2 months compared to my 1 year in that company, but I can't help but feeling very anxious with all these layoffs and the incoming tech winter. I don't have any self-confidence within myself that I would get any decent job, especially after getting an incoming a PIP, I'm just worried that when I'm interviewing at my next job, the career gap in my resume and the past potential PIP would deter me from getting any jobs. I'm also at loss on how to avoid potential PIPs in the future. Any advice to help me? Thank you very much.

Edit: For more context, I didn't come from a CS background (I studied Mathematics). My team was not a revenue generator. The company was especially hit really hard during covid and had 2 big layoffs. When I left, there are many products that are being shut down and a couple of senior-level product managers left as well without being replaced due to hiring freeze. During the talk of my PIP, the manager brought up his/her expectations on me that was 1 level (mid-level) above my current level (junior-level).

I've always been the one to dive into problems and solve them without thinking about how difficult they are but recently I've been running into this failure mode where many of the problems I work on involve using old tools that are cumbersome to work with. The result is that it takes much longer to deliver my work compared to those that work on packages with newer tools (I'm talking about native AWS lambda, s3, dynamo, etc) and sometimes I wonder if I'm doing what's best for my career.

Some cumbersome tool examples include

• One package uses an old technology that doesn't allow us to test our changes in our dev desktop before we can submit a PR
• Another package doesn't map correctly our dev desktop to the prod environment so it's sometimes difficult to reproduce the issue
• Some non aws tools do not really provide much information to help the user debug their problems compared to the native aws tools

My company has at least acknowledged the issues with the above first two bullets and has slowly started deprecating those tools. Oftentimes the senior and mid-level engineers work with newer tools and therefore aren't as familiar with the older ones, which is fine. I could just avoid working with these packages altogether and only work on the packages that involve the shiny new aws tools but I'm not sure if that mentality is what's best for my career.

I’ve been at meta for about 6 months now as a new graduate and my team recently got re-orged. The project of the new team is very uninteresting to me and honestly I realized that I’ve chosen an “easy” work team.

I recently got advice that I need to do more meaningful work such that my skills develop and I can create credibility. I don’t think the work on my current team or the new team makes me excited or even happy in anyway.

I would love to explore the metaverse org as I was heavily involved in VR/AR development work in college.however, I’d have to wait until July to start this process+ this would mean I moved 3 teams in 1 year implying I spent more time ramping up than doing meaningful work.

I’m also considering switching companies. I am able to secure interviews from a few companies that seem interesting to me.

Does anyone have any suggestions ?

I'm still navigating a career switch to SWE, and I tend to get pretty overwhelmed when looking at code. I already ask a lot of questions, and I want to be more self-sufficient because my full-stack team members are pretty busy. (They are all kind and would all be willing to to take some time out of their day.)

How can I get faster at reading code on my own while balancing a team transition? I'm at the point where I understand the high-level purpose of parts of our codebase but little as to how the moving pieces all fit together.

While I understand that there is likely no magic threshold to determine the point at one needs to ask for codebase navigation guidance, a good rule of thumb would be helpful when possible.

I started my career in a mid-level startup that was on the verge of IPO. I contributed a lot. Learnt a lot in terms of how to deliver big scale features relatively quickly, work within sharp deadlines, owning features and products. I was a high performer.

After 2 years of working in that company, I decided to switch to Big Tech for better compensation. While Snap is not exactly a Big Tech company, this is what I had in mind when switching.

I immediately started adding value in terms of delivering features and owning products. However, since I come from a mid-level startup, my soft skills are very weak. I am an excellent programmer, but I struggle writing Technical Design Docs. I deliver features quickly, but I don't know how to contribute to the spec sheets and writing launch emails, holding engineering sessions, efficiently using 1:1s. It feels like in my previous company, delivering features on time, writing quality code was enough to be a high performer, but seems like Big Tech requires a lot more. My manager's ex-Amazon, so he values tech docs a lot, and I feel like I am missing a huge opportunity here by not being good at them.

How do I adapt better to this work environment ?

I am mentoring juniors for the last few weeks. In the past, I've been mentoring people with some professional experience but this colleague doesn't have any. Now, after these few weeks I am wondering:

1. How much time should I spend helping them? Currently, I have to spend 2-3 hours for person per day otherwise they will be blocked for days. Even though I am trying to explain that they can ask other colleagues as well, they are not asking anyone else.
2. How can I be sure what are they suppose to know and what's not? For me, I have my own understanding of what they should know but I know for others may differ. In my country the juniors must be part of an academy before applying for a job. I know what they learn there, so I know what hthey should know and what not. Now, after these few weeks I realize they have gaps which they shouln't have. On the other hand, the academy is typically more than an year and it makes sense many things to be forgetten with the time.
3. How can I measure properly their performance since they are just starting? What is a normal performance?
4. How deep should I go in explanation of his questions? I believe this is where the high quality questions will help them, but I believe they have a lot of gaps to make a quality question and give the proper context.
5. How can I help them to improve their questions instead of having to explain for hours one topic and then another, etc?
6. When should I say I give up on him? I really want to try everything before giving up.
7. How to stay less emotional when explaining the same things for hours to the same person?
8. How can I help them to understand me better? Sometimes, no matter how am I explaining specific case/topic and no matter what examples, nothing helps.

I think the colleagues are really motivated and this is one of the reasons I want to help them. I want to be sure I did everything I can.

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?

In the class , we talked about how easily people get defensive when receiving feedback that they don’t 100% agree with.

I’m wondering, other than intentionally suppressing this instinct, are there any other tips, tricks, or mindsets that would help?

My starter project was to migrate a web service to a new API which offers similar functionality. This was intended to be a pretty straightforward migration, mostly renaming + replacing some strings. However, this project took much longer than my manager or I anticipated. How could I have predicted and prevented this?

Amazon is well-known for its design doc reviews, which appear to be small-scale system design reviews. However, I'm having trouble understanding them, let alone recommending modifications.

I'm aware of Alex Xu's Byte by Byte go course, but I'm skeptical using it as it's specifically for interview preparation. I want to learn for the workplace. I can definitely look at blog posts and current design documentation, but I'd prefer something more structured. How can a novice learn system design and grow to the advanced/intermediate level? What books or resources would you suggest?

I feel like it's more joyful to positively impact the life of others vs. only getting a really high title/pay. The latter also has high stress, and I don’t want work to be everything. I believe that teaching is a way to improve communication skills and software engineering skills overall, and I would like to mentor more junior engineers than myself at work. Another option I'm considering is going back to my bootcamp App Academy bootcamp to teach others how to code.

Some of my work involves coding in an old AngularJS codebase that has a lot of issues. Most files are 5-6k lines long, many of the functions are on v3() while v1 and v2 are left in there creating technical debt. We've already moved on to a rewrite of the application in React, leaving the AngularJS code a mess that no-one cares about.

How should I approach work that is assigned to me in this codebase? Get it done as fast as possible so I can get back to my "real meaningful work" in the React codebase, probably adding on more technical debt in the process? Take my time and try to make the most even if the code is worse and I might be learning anti-patterns? The AngularJS codebase will be deprecated and migrated away from in a year anyways so developers don't really care about refactoring or improving the code quality. I've been trying my best to essentially avoid work in the AngularJS codebase, but unfortunately I can't ignore it since 200 million+ users rely on it and oftentimes on-call issues crop up in it.

Hello,

I am an Entry Level Engineer at a mid sized company. The thing is, my team has a very strict deadline which we have to meet at all costs. For more context, I have been with this team for around a year now. I had done some menial tasks of building small easy features and styling the components in React. I have a task now where I am supposed to write unit tests for a particular component from scratch in jest. ( I think this is a learning opportunity in disguise but concerned if I might not able to finish the task, as I already got a call out in team standup that my area is lagging behind )

The thing is I have not done this kind of task before. I am super overwhelmed with this kind of situation and everyone in the team is expecting me to deliver it asap as we have a strict deadline.

I tried to convey that this is something of a new task I am trying to a senior engineer to understand how they solve these kind of problems, but was mocked in return and was told I should already know (I agree to some extent ).

The approach I am trying right now is to understand the functionality of that part of component, trying to understand the code written for that and start making my own tests cases. I am also looking at the other unit tests written for other components but feeling super overwhelmed as I am clueless what to do. Could someone please advise me how to approach this problem ?

I was recently persued by a big tech startup on LinkedIn for a full-stack JavaScript role. In the phone screening they asked if I would be open for their new grad program. As I have been working at my current company for 4.5 years (3 years part-time during university) it simply didn't feel right. They ended up going with someone else after the phone screening which could've been for multiple reasons, but was it wrong of me to not consider the new grad position? Should I consider new grad positions at big tech companies if it is my goal to work in big tech, even though I have some previous my experience?

Our VP keeps office hours every week (even more so recently because of the layoffs announcement). However, I see (and he often complains) that people do not utilise those, perhaps because people do not know what to ask.

I see this as a wonderful opportunity to learn from the senior management (as well as build some visibility). However, I myself am not sure how to utilise them so that it is not a waste of their time.

I have utilised them once and it helped me understand what the work expectations look like from our VP's perspective as well as his insights on growing fast. But, I am not sure if I did it right, and any perspective on this would help.

I'm currently in bootcamp and deciding between back-end and iOS/Android. I'm pretty neutral about these stacks, but I do have a slight preference for back-end as it seems similar to topics I learned in school.

Are there any differences in growth potential in any of these focus areas?

1. How do pull requests and pull request comments look like with an increasing level of seniority?
2. Are pull requests for senior engineers not expected to have any comments for improvements? If yes, then what kind of comments should be there?
3. Also, have seen some principal engineers not sharing their pull requests as they are quite high in seniority and merging it directly. Do you recommend that? If not, who should review PRs for very senior engineers if the team does not have engineers at that level?

One thing I have noticed about competent engineers is that they have a very strong understanding of upstream and downstream dependencies in terms of what are the typical parameters being passed into our API's and what we return and what are the things we pass into our dependencies API's and what they return,

How can I learn the context behind what data is typically being passed quickly? I understand that one of the best ways to learn is to start tinkering, and call the API's myself and see what they return. I was wondering if there is any faster way because surely a staff/principal/TL doesn't have the time to tinker with all of the different dependency services and understand what they take in and return. Is it just a matter of reading documentation and asking around?

I have 2.5 years of experience and working as an L3 engineer at Snap. To give you a bit more context about the structure of my team, We have 2 L3s, 2 L4s and 1 L5 in the team.

We just had our half yearly performance review. The review I got from my manager for the half yearly performance reviews was “exceeds expectations”. Clearly, I am a high performer, and in any other case, having 2.5 years of experience, I would be looking at a promotion in the next 6months-1year. However, the other L3 in the team got “redefines expectations” in his performance review.

We have same years of experience. He is a better engineer than me. He manages projects better than me, his output delivery is faster than me, he’s really good at writing technical docs as well as communicating stuff to the important stakeholders. There is no debate as to who is the better software engineer in team.

My question is, how much having him in the team affects the speed of growth from my career ? I am completing 3 years of experience soon and want to get promoted to L4. However I don’t see any situation where I am promoted before him, and I worry that this means delay of my promotion considering he'd be promoted before me and we already have many L4s in the team.

Am I overthinking this? I just want to know if switching companies or teams would be more beneficial for me than waiting in this team. Should I discuss about this with my manager ? While he is very focussed on making sure that the teams does well, I don't get the feeling from him that he cares too much about my professional growth.

My manager told me in my 1:1 that he would like to see me working more independently. He had few points for me like utilize other engineers to unblock and have more discussions on team channel. I feel like I already work quite independently. I drive discussions on my own and involve stakeholders as needed. I speak out whenever I see any issue or I've something to contribute.

I'm trying to understand what can I do more here and show my manager I'm already doing what he's suggesting.

I'm in process for L5 promotion and I feel this feedback can negatively impact my chances.

TIA.

After this past half (I joined mid-August), my manager is saying I'm working at a meets all (MA) level. Granted, I only joined in the middle of the half, but when I ask him how can I take the next level to be promoted or have an EE or above rating, I get very vague answers with not much detailed support (he's also a new manager and this will be his first PSC).

This past half, we had an expectations doc where it listed each project and the impact it should have. I hit all those expectations, but with his vague advice, I'm not able to create actionable steps for myself for this half to get the promo or higher ratings.

From Taro, I'm learning code quality, velocity, and impact are the most important at my level - which from my feedback, I'm doing well in. What are some ways to take it to the next level? Finish my projects earlier and take on more projects in the half? Feeling a little bit lost so any advice is greatly appreciated!

I’m a junior/mid with 1.5 YOE who has learnt to touch type recently with a speed of around 65 wpm.

I’ve read a lot of the q&as on productivity and code velocity and have even watched Rahul’s YT vid on working efficiently in Android (IDE shortcuts etc.)

Will I be able to perform at the velocity needed for an E4 at say meta with only a 65 wpm typing speed?

What do people feel is acceptable for a top-tier tech company?

I joined about 6 months ago and my manager is absolutely great. I don’t have anything where I think they can be better at at this stage. At the current stage, I feel like I have a lot of self improvement to do before expecting anything more from them. What do I say in the critical feedback section for my manager?

I have attached my resume for review:

I am a new grad Software Engineer who has completed 6 months ago. There's a lot of internal tech stack and plenty of codelabs. Lately, I have realised that I am not prioritising learning about the stack my team uses (but I do not currently use directly).

I understand it would be helpful in one-off occasions when I have to interact with a new part of the codebase or during on-call, which I am expected to begin soon. However, I always end up prioritising my current work that I have in hand. (It is also because of the fact that I find the codelabs pretty slow and boring)

How should I prioritise learning new things? I remember Rachel's video where she said she spends 20% of her time learning new things and that seemed like a good strategy to me.

Let’s say 2 companies give you different levels, but the compensation is the same. Is it better to have the lower level to have lower expectations? Zooming out, how should I think about level and its overall importance across my career.

Crux is when you’re learning and digging deeper technically. How do you approach taking ownership and growing your impact on not just the project but across the team and larger axis?

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?

Hi all, recently during Q1 roadmapping I chose to move on to a new workstream from a growth/independence point of view as part of working my way up to E4. (My earlier effort was a 1->100, this one is 0->1 and was decided by me, my TL and EM together), and I had a couple of questions about this move.

1. I have spent the past 6 months gaining context on a set of technologies and tools (internal to Meta) that perhaps only 2 other engineers on the team have context on.
   1. Should I do a knowledge transfer session or write up a doc to ensure all the context I have doesn't get lost?
   2. Should I allocate some time to supporting the team until I'm here on areas I gained context on?
2. There is some possibility of scope thrash since I'm also long-term supporting one of the projects part of the earlier workstream (I delivered the v0 and have been making iterative but small changes since then). Should I talk to my manager about this?
3. This is a very n00bish question: from a growth perspective, is it better to go 110% on the new workstream and all its nuances/open problems or go 80 and 20? As far as allocations go, I'm slated to be 100% on the new workstream as part of the roadmap.
4. Bonus question: should I do a year-in-review/look-back post in tandem with my self review? (This is a very Meta-specific question in a way, but would love to hear other views too!)

How often does everyone pair program here? And how do you regard them?

I am at a startup and since I have started, first as a junior, my pairing frequency is about 1-2x per week. I do not consider myself a junior anymore (at least not at the company, but maybe on Leetcode >_<) and find these sessions more valuable as volleying ideas flow more. I was wondering what it’s like for others and if it is a day in the life thing at big(ger) tech; is it kind of seldom or frowned upon or do some of you use it as a measure of skill, etc.

Hope everyone is having a good start to the week!

My sub-team was 3 people (an L5 tech lead, an L4 engineer, and me), but now it’s just me since the others left. My manager is hiring other people in the coming months.

How can I best onboard the new people and set myself up to lead the team?

My goal is to get to this level someday, so I would love to understand more. In particular, how does this dynamic play out at Big Tech/larger tech companies?

I recently got moved to a new manager, and I've been having some trouble building back up the more fluid and quite positive relationship I had with my prior manager. In particular, I'm trying to get more signal into my feedback and how I can improve. When I go over this kind of content with my new manager, they'll say something more quick and high-level like "That makes sense", but they won't give me something more specific and concrete. How can I go deeper with these kinds of conversations while keeping our relationship healthy? I want to make sure I respect their boundaries.

Whether that be a formal mentor within the company or you have found a mentor outside the company.

e.g. I want to level up as an engineer, have sought out a mentor(s) to help me do so, what are some of the things I should make sure happen that I get the most benefit out of the relationship.

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 have been working at my current company for about a year. I am a junior engineer on a team with mostly senior engineers. My team trusts me to execute independently and I'm pretty confident in my ability to get things done. I want more ownership and I would like to bring value to the team outside of assigned tasks/projects. How would you approach identifying opportunities here?

I'm currently moving a bit slower than other engineers on my team. Here are some of the problems I'm facing:

• I talked to the manager and he said that if you get stuck after 30 minutes, just ask for help. I will often spend many hours to an entire day working on a problem before asking for help.
• I feel unmotivated to do work until I actually start it. I need to get into the zone, and it takes a while to overcome the initial hurdle.
• How do I feel more uncomfortable in the unknown? The uncertainty is discomforting for me.

I appreciate the value of side projects mentioned on Taro, and I'd like give one a shot. Whenever I've looked before, I got caught up in not finding ones relevant to my work. I work on the backend side, working in the machine learning infrastructure/ops space. That's literally the example used in the side projects video of one where it's hard to do on your own... so is it still worth doing a side project? Maybe one in a similar language (C++), even if it's not related?

I feel like I'm just not being creative enough here, but I'd rather not do a side project that's super unrelated to my area (e.g. learning a ton of frontend to build an app that has a small machine learning component) unless it's still valuable. Maybe to make this more general, how did those of you working on the backend get started with side projects?

I work on a product that runs on a variety of architectures, with code split across many GitHub repositories. We have a complicated build process. When making changes, I often struggle to find a way to run those changes efficiently (i.e. outside of the CI process). This is made worse when I need to make changes that also change the build process or need to run debugging tools like GDB.

When I onboarded, I was told that everyone has their own setup by people who've been on the team since its inception. It seems like people newer than myself have figured it out, even with how messy and changing everything is. However, I've been here for over a year and the team tends to work quite independently. Occasionally, folks will be quite helpful for a point or two, but generally everyone's stretched a bit thin and tends to focus on their tickets. My manager has also rebuffed any requests for collaboration or mentorship since I started, saying that I'm expected to be independent to show I'm ready for the next level. He did say I could that I could try to change the team's culture to be more collaborative if I wanted to take initiative, but that's not what's expected of a software engineer, especially if I want to do well and get promoted.

This question may be more about how to correctly get answers answered when you're no longer new, but I also feel that building (CMake, Docker, environment setup, package management, etc.) is slowing me down. Are there good processes for getting more efficient at building components/systems and unblocking yourself faster?

I've been on my current team for around a half, working primarily on the back-end. Unfortunately, I discovered after I joined the team that Android work is very interesting to me, so in order to pursue this, I would need to switch teams. There is actually a team fairly close to mine in my org where there's compelling Android work.

Right now, I'm heads down on a big project, so my immediate instinct is to wait until that's done to bring up this conversation with my manager, who I have a very good relationship with. Is this the right thing to do or should I have this conversation sooner rather than later?

I'm considering a team switch, but I'm wary of the effect that it will have on my E3 -> E4 promotion timeline, which I know we have to do within 2 years. I've been at Meta for around a half - Does the timing for a switch work out here and what other factors should I consider?

I joined Meta very recently, so I'm in bootcamp. However, the company just announced a mass hiring freeze, so teams aren't taking in bootcampers at all effectively (there are very few exceptions). It's not clear when this freeze will end. Teams are still giving bootcampers tasks as they understand that we're pretty much "free" labor.

This is such a weird situation, and I feel like I'm spinning my wheels. I like Meta as a company a lot, but I'm unsure how to make the best of this situation. Any advice?

Some additional questions:

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

I'm relatively new to software so would love to understand more here. In particular, what does it look like at Big Tech compared to other companies? My goal is to eventually transition into a Big Tech company - Do you always need to work 60+ hours a week to do well there?

Does it get worse as you progress from L3 -> L4 -> L5 -> L6 -> etc? Intuitively that seems like what would happen as your scope grows across promotions: Is there more overtime associated with the more senior levels?

There is a mentorship program at Booking, but I am not currently enrolled. This is because I’m not entirely sure what sort of mentorship I should seek out. How can I figure out the optimal mentor to have?

In terms of what a potential mentor can help me with, I'm currently spending a lot of cycle on a Perl -> Java migration effort across the company's legacy codebase.

I recently joined a startup (just finished my third week about to start my fourth) and I set up a one-on-one last week with my manager to hopefully create a mentor-mentee relationship. That went well and now I’m looking to create a growth plan and a way to measure my performance. We’ll be checking in on a weekly basis so I can get a sense of my performance and how I am growing as a engineer.

Given that it is a Series B startup with ~25 people, our goals will be shifting a lot which makes long-term growth plans hard to create. For context, since I joined, my 60 day and 90 day projects have shifted somewhat. So how do I create a growth plan that is flexible and what should it include (Concrete goals vs. more behavior orientated goals)?? Should the growth plan be used separately from judging my performance or would it be the measuring stick for performance?

Would really appreciate some insight on this.

Context: I work as a Entry Level SWE at Series B Startup with 25 people; the SWE team is 7 people total. I am the only person currently under my manager & my coworkers are fairly clear about what I am building & why. Also, the SWE team morale is strong and productivity seems to be at a sustainable rate.

In general, I think my manager & mentor is an incredible engineer & empathetic person open to feedback/trying new things. He’s personable, highly knowledgable, is available to answer my questions, & answers all my noobie questions. While I love these aspects, I do feel he is a bit reactive as a manager. When I asked him if he wanted to be my mentor, he agreed but I think he interprets it as being available to answering more of my questions. I don't think he is used to being a mentor or a manager and would like to see a more proactive effort from his side to help me level up as a engineer (right now I am mostly bringing up the ideas for 1:1 meetings, and creating a growth plan, etc).

So how do I help him?

During my first 1 on 1 with a manager, I asked him if he could help me find a mentor and he said he would find one within our overall organization. He also said he could find me a manager within overall Amazon if I want. This would for overall mentorship in Amazon vs being limited to the scope of just my organization.

What are some advantages/disadvantages of having 2+ mentors? Also are there any qualities I should be(or probably more likely asking him to be) on the lookout for those 2 mentors?

I'm a React developer and for the most part am able to accomplish tickets assigned to me; however, what I struggle with is when I have a particular ticket that is heavily logic focused.

For example, recently I had to implement a multi date picker for a booking engine and between the many different cases for user interactions and date comparisons, I feel it took me way longer than it should have.

In order to optimize improvement in this area, would it be worth it to grind leet code style questions? or maybe codewars?

I am a junior engineer at a series A startup. I was interning for the past 8 months and got converted full time, now working as full time junior engineer for the past 3 months. I had been getting "Exceeds Expectation" from my tech lead/manager.

But from the past 3 1:1s from the tech lead. He mentioned that

1. My code is not up to the mark to directly merge without taking a much deeper look into. Basically mentioning that my code is not levelling as a senior engineer. There are no senior engineers in my team, I directly report to tech lead. So I really cannot learn how to write better code as he mentioned. Where can I learn this?

2. I have been just crunching tasks or helping someone without understanding the root cause. He mentioned I lack "Product Thinking". I am really not sure what he means by this. I thought helping others would help me grow in my career. By helping others I mean if there is a small task that is required by some other team, I just go and do it without understanding entirely what they want.

3. The founders keep mentioning that there is a lot of growth potential in our company

I really work hard every day from 8 AM and late 11 till night but the work I do is not helping me to grow and I want to grow and become a senior engineer. There are not even tests in our codebase, and a lot of problems I see in the way we do things which I don't know I can help solve . How can i grow? how can I tell them that I can be that senior engineer to solve the problems? How can I learn to make good decisions as to what needs to be prioritised in terms of which task needs to be done? If I don't know let's say how to write tests, how can I learn that and cultivate that in the team?

I graduated with a master's in CS 1.5 years ago and since then I have been working at a no-name brand company as a full-stack engineer. I would love to join Spotify but I lack prestigious grades and side projects. The tech stack I work in is somewhat old (Angular 2, .NET, no cloud, in-house solution for CI/CD, etc). The company is nevertheless alright and my colleagues are all very friendly, including my boss and manager.

If I would want to join Spotify, should I double down at my current job and try to get those side projects started, or should I consider another position in-between my current position and Spotify in order to increase my chances to join Spotify? The reason why I’m not a big fan of this idea is that I don’t like to join a company with the intent to leave within 1-2 years. The reason why I'm considering changing company is because I worry that my current growth could potentially be a lot higher than what it currently is.

Will my lack of experience in newer frameworks/tools be a large disadvantage to me when I’m looking for a junior/midlevel role at a tech company where being efficient in languages/tools is a must? Is it better to stay since I can make more of an impact now since I’m familiar with my company’s tech stack compared to having to go through an onboarding process at a new company which may result in decreased impact for that period? I would prefer to join big tech in 1 year as a junior engineer, rather than in 10 years as a mid-level engineer.

I work at a relatively small private company, and we spend pretty much all of our time churning out features as customers request them. I'm wondering if it makes sense to also spend some time digging into data to better understand user behavior. I'm trying to find ways to add value to the company besides just feature work.

Starting my first day and I was assigned an onboarding buddy. I was wondering what are some of the main questions I should ask.

Some questions I have asked:

1. Wiki on how to set up dev environment
2. Info about all meetings that I was invited to
3. More info about what our team does?

I'm wondering if there are any other main ones I should be asking or is it just ask as they come along?

Sometimes I find people with a backround similar to mine who have gone to places I would love to go. Naturally, I would love to learn from them as they have done what I wish I could do. Their time is of course quite valuable and I understand that it might be naive to think that they would want to talk to a random person whose incentive might be mostly for career growth. Is there any way I could approach this in a genuine way? Or should I try to avoid connecting with people because of this reason?

I never got the full experience of working from an office due to the pandemic. I am currently working from home and making the decision to move out of state to be at my companys HQ. I hope this will help boost my career by being near my co-workers, asking questions, participating in "water cooler" conversations and even helping out with non-technical tasks like filming a commercial (example of something I heard happen at the office).

Is there any tips you would recommend for someone to make the most out of their time in an office? I am planning on being there for at least a year and I was told I can have the empty seat right next to my manager.

How do I make sure to continuously improve at a company which does not really give much feedback? We have a meeting once a year where we talk salary and the work that I've done. I have only had one meeting, but they just said they were happy with me and my work. It's a rather small company so we don't have many of the feedback loops that larger companies have (code reviews etc). Since we are a quite small company, every senior have their own view of what good code should look like and I'm not sure which one to listen to.

Hi I wanted to ask how valuable a bootcamp can be and can I do that instead of a four year degree? The reason for this is because of how expensive college tuition is and I'm really worried about the return on investment. I feel like there's a lot of information that I'm learning right now that I feel like I won't really need and instead, I can use that time at a bootcamp to work on projects and learn valuable skills I can use in the work field. Would I be at a huge disadvantage by not completing my 4 year degree and are there valuable concepts that I would be really missing out on by not completing my four year degree?

I see engineers like Alex and Rahul, and they have had many accomplishments with pretty fast trajectories leveling up. I'm wondering if there's a primary common theme among software engineers like that - What are they doing that others aren't?

I'm pretty early in my career (~1 YOE), so I'm still trying to figure a lot of things out. A lot of the advice on Taro is around finding your strengths and investing more in those, but I'm unsure on exactly how to do that. I feel like I'm just going from ticket to ticket and am quite busy in general, so I don't know how to think about all this. Any tips?

Alex and Rahul and the other senior people on Taro have consistently emphasized how important good software engineering fundamentals are to long-term career success as a software engineer. This is in contrast to learning the latest popular framework or area of development. Can people define what those fundamentals are and how one should go about acquiring/improving them?

Thanks!

I've heard Alex, Rahul, and other engineers within Taro talk about handholding when joining a new company for all engineers and for newer engineers in general.

What does it mean that an engineer doesn't require handholding anymore? Does this mean the frequency of the questions gets diminished or is it more about needing as much initial help to start tasks or something else entirely?

As a junior engineer, I ask questions and ask for help a lot in general. However, I want to make sure I'm not annoying my teammates and being too big a burden. How can I do that? Is there something I can do to return the favor for those who helped me?

I've been working for around a year now, and I feel like there's a big gap between where I am now and where I should be in terms of skill level. I'm getting good feedback at work, but there's just such a huge gap between the senior engineers on my team and me - It all feels really daunting. How do I know if I'm good enough, and what can I do to feel better here?

We are working on a technical product solution which provides APIs in a B2B fashion. We do not have any interface apart from these APIs. There are some internal tools which replicate this functionality (web dashboard) for us to view the data and some smaller B2B Companies to use, but is outside the scope of our Product / Team as it's just parity that is maintained.

Our PM is not a technical person and sometimes it gets very hard to explain the reasons why something cannot be done. Or their suggestions completely miss the point / question I was asking.

They view it from a visual perspective and suggest things that require a lot of back and forth to explain why it isn't feasible.

I've tried in the beginning to help them get setup with basic Postman collections of our API to see the flow. Our EM is also doing their best to prioritise tech vs product.

I feel some of this is reactive and not proactively helping as I feel a bit frustrated to what seem quite obvious which isn't helpful at all.

What do you suggest one can do to better improve communication or even how to view things from their perspective.

The one con is as a PM their calendar is always full

I'm positioning myself to go through the process of transitioning to a SWE position, and I've been told that junior developers would be given tasks that are small in scope, well-defined, and with low ambiguity.

That said, I would love to know if there are concrete examples of such tasks. For instance, would updating a Makefile before an internal release be within such a scope? Other examples would be helpful in order to get a better understanding. I assume that it would likely be different from company to company as well. Thank you for your time!

As I'm starting to join a team soon(and knowing this answer varies by team, level, and company), I'm wondering how long does onboarding take and what does it mean to be fully onboarded within your team

Hey all, as you know there’s high probability of cost cutting and lay offs by increasing bar at meta. I joined the company 2 months ago and plan to travel to another country(12 hour time difference) and work remotely for about 20 days! (Whole month of December)

In lieu of new information, should I be trying to stay in the same time zone and be seen around meetings(my team is fully remote)? It will probably also help my productivity.

I’ve already booked tickets and I’m not sure what to do.

I’m nervous about joining since my past internships were very relaxed and I didn’t actually do much coding. The probation period makes me think that it may be more “sink or swim” when I join. How can I ensure I get enough support and survive the probation period?

I'm going to be joining Amazon soon and the team I'm on is going from 4/5 people a month ago to I believe 9/10 people (counting me). Our team is going to be comprised of SDE 2's and 1's (I'm an SDE 1).

I'm wondering what's the best way to have the best onboarding experience during this time.

While it will be nice that I will have a decent amount of people who will be in the same boat as me in terms of onboarding, I'm also worried that my manager and more senior teammates won't have as much time for things like 1 on 1s, answering questions, helping me onboard, etc. if they're also helping other people on our team in addition to their own work.

I am joining Amazon soon as SDE 2. At my previous job, I was a higher end SDE1. I have owned small internal services at my previous job. I would like to know what are some of the things that can be expected from me as SDE 2 @ Amazon ? I am expecting more ownership, but is that the only thing? I did ask the same question to my manager but he seemed very chill about it and said that he cannot say anything at the moment, maybe in our 1:1s we can discuss more clearly. Also, if you can let me know how the expectations vary across levels for Junior and Mid level and what can I do to hit the ground running and create a good impression from the very start, that'd be great. I am sure that you must have seen various E3 / E4s at Meta. If you can relate to what exactly was the difference that you saw, that'll be super helpful.

I'm looking to get promoted to E4 in the next cycle, but I'm worried as my impact contribution isn't very clear. I've done a lot of work, but due to churn within my org (which includes a recent re-org), a good amount of my code isn't truly in production yet. I've documented my work in Quips and tasks to show that I did it, but I'm wondering if a lack of shipped impact will hold back my PSC.

I'm pushing for the E4 promotion in the next PSC cycle, and I've gotten some feedback that I could shore up my people axis contribution. Given that, I was wondering how important people is for this promo and how I can get points on this axis as a growing E3. People axis contribution seems harder given the hiring freezes (e.g. it's harder to be a bootcamp mentor) and the fact that the main intern season is over.

Apologies for the long post.

Before Snap, I was working as an Entry Level Software Engineer in a company that had just IPO'd. The growth opportunity was amazing, and I was learning a lot, but I wanted to work for Big Tech for better compensation.

I worked in that company for 2 years after my graduation. And then I switched to Snap Inc as an L3 engineer. At my previous company, I was up for promotion in a few months, and I probably made the bad (in hindsight) decision to switch at that time instead of waiting for a few months, getting promoted and then trying for L4 at Snap (I don't know if Snap would still have offered L4)

Now I am almost completing 6 months at Snap (so total 2.5 years of experience) and I talked about promo with my manager. And he told me that he isnt putting me up for promotion in the next cycle (in 6 months) as I need more than >1 year experience (around 1.5 years) in the company for promotion. So this means the realistic cycle for which he would consider me would be a year from now (at that point I'd be 3.5 years work experience). Which to me feels way too late. For some context, I am a high performer with "exceeds expectations" feedback from my manager, so the only thing stopping me from getting promoted is my tenure in the company (acc to my manager)

My question is, should I wait for another year or should I start looking outward and considering I am 2.5 years right now (and 3 years by the time I get an offer) I should be able to get L4 in a Big Tech (I think?) I am not super certain about the future of the company as well so I will most probably be switching even after promotion.

All my college friends are L4's and SDE2's so I feel like I am behind in my career.

My future manager asked me to read “Effective Java” as preparation for starting. However, it’s really not making sense to me. I have a fear that they’ll ask me how much I understood from the book. How should I answer the question without making myself look bad?

Hello!

I was assigned my first JIRA ticket at my first official dev job, which I started about two weeks ago. Given my situation, I want to know how long my manager expects me to work on the ticket, so I don't end up underperforming or not meeting expectations.

Some background: before this job, I worked at a very early-stage startup (one other person and myself for about a year), so I don't consider myself a complete junior. Additionally, I don't know my official title since I came in as a contractor and the contractor title does not match the FTE title, so I'm not sure what is expected of me.

Some of my thoughts: I've considered asking my manager directly how long he expects me to work on this JIRA ticket, but I wasn't sure if the question was too noob-like or too forward. I've also considered that so long as I'm making progress (which I am), I should be okay (until it's not).

So, all this to ask, should I ask my manager how long he expects me to work on my first JIRA ticket?

When I started in bootcamp, my bootcamp mentor assigned me a couple tasks to do. How important are these tasks? Do I need to get them done with a certain speed and quality? Are you judged on them in any way?

I'm a new E3, and I know that there's the up-or-out promotion timeline to E4. I was wondering how much of a challenge this level-up generally is and what are the main things to keep in mind with this promo?

For people who work on side projects: I was wondering what is your system when it comes to coding at work and then coding after work? How do you divide your time effectively between the two?

What can I do to get on the radar of senior engineers within the company and build respect for me overall? My company is also relatively small, so I'm fairly close with the CTO as well.

Question: "For being promoted from SWE I to SWE II, how do I take the behaviors my company has associated with each role (below) and make that more concrete for a growth plan, taking into account the changing & flexible timelines startups have?"

For context, I already have weekly one-on-ones with my manager (who is new at being a manager & is also my mentor), and a growth plan (that I created with him) that roughly outlines (meets most expectations, meets expectations and exceeds expectations for my role). Additionally, keep in mind I work at a startup w/ <30 people so highly specific concrete goals set on a particular date can change in 2-3 weeks as priorities change. Also, my company has defined a series of behaviors as to what each SWE level should be able to accomplish. Here it is.

Software Engineer I (<1 year - 2 years)

• Technical Skill
  • Broad knowledge of CS concepts
  • Focus on growing as an engineer, learning existing tools, resources, and processes
• Getting Stuff Done
  • Develops their productivity skills by learning source control, editors, the build system and other tools as well as testing best practices.
  • Capable of taking well-defined sub-tasks and completing these tasks
• Impact
  • Developing knowledge of a single component of our architecture
• Communication & Leadership
  • Effective in communicating status to the team
  • Exhibits company’s core values, focuses on understanding and living these values
  • Accepts feedback graciously and learns from everything they do

Software Engineer II (2-6Years+)

• Technical Skill
  • Writes correct and clean code with guidance; consistently fellows stated best practices
  • Participates in technical design of features with guidance
  • Rarely makes the same mistake twice, begins to focus on attaining expertise in one or more areas(eg. embedded , testing, algorithm, support code, commlink).
  • Learns quickly and makes steady progress without the need for constant significant feedback from more senior engineers.
• Getting Stuff Done
  • Makes steady progress on tasks; knows when to ask for help in order to get themselves unblocked.
  • Able to own small-to-medium features from technical design through completion.
  • Capable of prioritizing tasks; avoids getting caught up in unimportant details and endless “bikeshedding”.
• Impact
  • Self-sufficient in at least one large area of the codebase with a high-level understanding of other components
  • Capable of providing on-call support for their area including systems that they are not familiar with.
• Communication & Leadership
  • Gives timely, helpful feedback to peers and managers
  • Communicates assumptions and gets clarification on tasks up front to minimize the need for rework.
  • Solicits feedback from others and is eager to find ways to improve
  • Understands how their work fits into the larger project and identifies problems with requirements.

I'm looking to get promoted as fast as possible, so I really want to understand how very senior engineers think. Here's some additional questions to add more depth:

1. If you were to backtrack and retrospectively analyze the careers of the engineers who reach staff level at Big Tech, what's the common thread with all the projects they've worked on?
2. How were they able to land themselves on those projects?
3. What allowed them to put themselves in a position to contribute to such high impact projects?

Hi everyone! I will join Palantir as a Forward Deployed Software Engineer(FDSE). I need advice on tackling the first 2-3 months at the company to gain team respect and trust. I am excited about this opportunity and want to grow but do it efficiently, if that is even a thing😅. Jokes aside, All I want is to have a great career at Palantir.

YOE: over 2.5years(including just over 1year of internship).

Stack Experience: Ruby on Rails, Python, some Java

Current Work: Backend Engineer. Building and maintaining APIs

As I figure out which team to join, oncall comes to mind. I've heard that oncall can be pretty intense and stressful here, especially on infra teams. The company has said that they're making efforts to fix this problem, but I'm unsure what to expect there.

How can I figure out whether a team has a healthy oncall rotation? I don't want join a team just to be burned out by a crazy oncall.

Back when I was an intern, I worked incredibly hard, often times with late hours. Aside from the personal downside of burning yourself out, is there any other way this can hurt you career? Can it skew the team's perspective of you in a bad way?

They recently rolled out the Booking Career Framework, creating itemized lists on the expectations for each level, so I know what it takes to get promoted. I'm 70% - 80% that I'll get it in the next performance review cycle, but I have some concerns.

My main concern is that Booking doesn't have a lot of space to grow, evident by the fact that I spend ~50% of my time on the company's migration effort to move from Perl to Java. The effort for this started in 2014 and is around 30% done. It's not a super high company priority according to my manager, but my team spends a lot of time on it, which worries my prospects about finding scope with better business impact.

On the flip side, I had Java experience coming into Booking, so I am well-equipped for this migration work. For example, I was able to solve a deep image loading issue recently that required a strong understanding of default Perl behavior.

Right now, I'm on the test side in my company, writing some automated tests but doing a lot of manual tests as well. I would like to transition to software engineering, but I'm not entirely clear on my path there. There has been precedent of making that transition within my company, but I don't have any hard commitments there on allowing me to do the same. Any advice on how I can plan out this switch?

With a recent, completely unexpected reorg, the product my team owns has effectively been cancelled and will be sunsetted. The company is trying to figure out new scope for my team, but in the meantime, I don't really have stuff to work on. Here are my questions:

1. Is having 1-2 months of downtime like this okay for my job and career?
2. What can I do in the meantime to be productive? I've mainly just been doing auxiliary things like reading documentation.

I'm a native Android developer, and I really enjoy doing the work. However, I want to make sure that I'm well setup across my career overall - Does Android have good prospects in tech going forward? On a related note, how does it correlate to future opportunities and growth within Amazon?

I want to be able to plan my work better for sprints, so that I can avoid spillovers or call out anything that might lead to that as soon as possible.

Context: I work as a Entry Level SWE at Series B Startup with 25 people; the SWE team is 7 people total. I am the only person currently under my manager & my coworkers are fairly clear about what I am building & why. Also, the SWE team morale is strong and productivity seems to be at a sustainable rate.

During our mentor-mentee meeting last week, my manager & I agreed to give each other specific feedback each week (and also agreed for our 1:1 meetings to be used for awkward, personal stuff as Alex & Rahul recommended). In general, I think he is an incredible manager; he’s personable, highly knowledgable, is available to answer my questions, & answers all my noobie questions but I do think there are some shortcomings as he is not used to being a mentor or a manager.

I don’t want to just say “Great job!“ as that is an easy default to fall into week-after-week.

So how do I evaluate my manager? Is there a set of questions somewhere? A framework of some kind?

Sometimes I feel like I didn't get 40 hours "worth" of productivity after a week, and it didn't make sense to physically spend 40 hours working that week. Is it possible to succeed as a software engineer working less than the traditional 40 hours? I imagine it requires being able to get the work done faster - What are some techniques to do that?

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?

Part 1: Before Joining an organisation

1. How can one identify the best kind of organisation to join at different point in one's career? I understand that the advice to this question may not be a prescription for all, but how can one identify places that would help them to maximize their learning and growth. For several other people, different parameters may be important for them as well such as work-life balance. Personally, I feel that WLB is dependent on a person more than that on the organisation. Thoughts?
2. Quite often we feel that growth may be fast paced at startups, but there can be startups that do and don't promote the growth of a person. Given that there is no list out there to check, how can one make the best suited decisions for their career, not landing at a place they should not be at? What kind of research can a person do before joining an organisation?

Part 2: After joining an organisation

1. Given that a person has joined an organisation, what are the kind of signals that they can identify to see whether the organisation is supportive of their career growth and is indeed the right place to be, for them?
2. On several anonymous portals, there are people from the organisation that will talk poorly about an organisation when things are not going good for them. Managers can quite often paint a really rosy picture about the place. How do you identify the honest signal from the noise all around?
3. If you find an organisation not good for you after you join there, how quick is it too quick to leave? How much time should you spend there before you can make a judgement about the same?

I feel like engineers on my team are all just doing their own thing. I work on the front-end, and when I go into front-end meetings, it seems like nobody has an opinion on how we can improve.

I like working with the people here: Everyone is nice and the overall work/life balance and vibe are relaxed as a result, but nobody is pushing me to get better and I'm not even sure what better looks like. It seems like my manager is fairly removed from the code at this point, so they don't have concrete feedback for me.

I get some meaningful feedback in code review, but not a lot. A lot of the comments are more surface level.

Given all this, what can I do to grow more?

How can we identify what are the core in-demand "Legos", especially in the context of what we do commonly on our day to day job?

As software engineers, we are tackled with new things to build regularly, so I was wondering how I could focus on the components (i.e. "Legos") that are built more regularly and learn to build them with high-quality.

I don't have a concrete need for this right now, but I want to be more efficient at work and keep this in mind for when I do get into a new technology. As a web dev, a core in-demand Lego will be like responsive design or something like that right?

Would you recommend software engineers try a rotation as an SDM (software development manager)? What benefits or drawbacks would you say would come from making that switch to SDM?

Some additional questions:

1. Does it vary between big companies and small companies?
2. Do you need to work a lot to be a high performer?

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.

I was told that exceeding expectations doesn't necessarily mean that you're operating at the next level, so I would like to get more clarity here. What does it mean to exceed expectations in a way that's building up towards promotions vs. not?

My main goal right now is to level up, and that next level for me is making the jump from junior to mid-level, hopefully within 2-3 years. To better understand the evolutions I need to make, what are the main differences between junior and mid-level when it comes to SWE?

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?

At a huge company at Google, there's resources on everything imaginable, including other trades like product management and sales (which I'm interested in). Does it make sense at this stage in my career to spend a lot of time looking into those and learning?

I just joined a new company (7 months of industry experience) and I want to make sure I can come in quickly and make an impact. More specifically, I want to become a quality contributor to the team as soon as I can.

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

Fear/stomach-turning when I think about asking people for help (especially in public channels) has been a major blocker for me as a junior engineer.

One of the tips for processing feedback is “to convert it into action items”.

What should you do if you don’t really know what to do with the high-level feedback you get?

Example: I got the feedback that other engineers don’t think that I understand the framework/library we’re working with deeply, not understanding the patterns and whys behind things that we do in our project, not knowing how to use different/“better” patterns.

Unfortunately, they didn’t give me a specific example, so I’m unsure on how to convert this into an action item.

We don't have mentors, so there isn't anybody who can "teach" me, except learning from code reviews, asking to do more pair programming, etc.

My idea would be to study up on “design patterns”/best practices for the framework we’re using, but I’m unclear on if that would really solve the issue.

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'm really new as a Google FTE (still doing some logistical onboarding like getting my laptop fully set up), but I want to hit the ground running and start growing at Google as fast as possible. However, I don't know what I don't know - There's a lot to take in, and I'm unsure where is best to focus and allocate my time.

When I was hired, the hiring manager said they were debating between mid-level and entry-level for me, but decided to go with the more conservative approach since I don’t know the tech stack here. How can I quickly show my technical skills despite not knowing the stack?

I'm an earlier-in-career software engineer, and I work in an extremely busy startup on a small team (<10 engineers). I do a lot of things, including:

1. Manual QA - I test every build and find a lot of crazy bugs.
2. Release/deployment - I make sure the apps go out well and am looking into CI/CD.
3. Development - I work wherever I can to fill in the gaps and am happy to pick up any ticket.

However, at the end of the day, tickets need to get done and I've had some trouble with that. How can I get better at this? Do I just need to "put in the reps" when it comes to coding?

Freedom and autonomy are often mentioned as great perks of working in tech, but I feel like there can be too much freedom, especially for earlier-in-career ICs. As someone who's relatively new to my field, I feel like having more supervision could be good. Is that true?

I've heard it's always good to try and understand your manager's perspective, their expectations, and what they need from you.

I assume most junior engineers wouldn't have prior management experience, so it would be useful/insightful for junior engineers gain some perspectives on the priorities and challenges a manager faces whilst running a team, so they can better help the team.

I work at a small company with only 10 engineers. Since it’s so small, there’s no real feedback culture - We don't have a formal performance review system.

Everything I’m hearing is always positive - Everyone just tells me I’m always surpassing expectations and doing well. However, I know that there's a lot I can improve as I'm an earlier-in-career engineer. I want real feedback so I can get better and understanding the path from junior -> mid-level -> senior: What can I do to start getting this feedback?

I know that it's in the company's best interest to lowball you: Is there a way to get around this without burning bridges? I'm wary of doing something like getting a counteroffer, since that feels very aggressive.

Adding on to this: Even though we're a startup, we do have a fairly defined career matrix. We have levels (junior, intermediate, senior, etc) and a performance review every 6 months where levels are reassessed and promotions/raise are given where appropriate. So that's a path that can be taken.

I've heard that situations at Atlassian and other companies in general can be very competitive to the point where engineers are competing against each other for survival with systems like stack rank and team quotas. I'm wondering what's the best way to navigate through systems like these.

I pretty much interact with everyone else through text-based means, which is all really pronounced in this remote covid era. However, I like to learn from other people directly, talking with them. For example, I'm currently working with a senior full-stack engineer doing things like pair programming and that has been helpful.

What can I do to get more of this deeper learning instead of trying to learn almost entirely through text?

I took part in a company-wide hackathon and won! I hacked on a backend API that allowed for a more intuitive UI around hotel policy changes. This feature is now on the roadmap for the company and I’ve been talking to the relevant eng manager on the team to talk about the work in one of their teams. How can I continue the momentum of this hackathon?

My work is in C (which I do not have much experience in), so if I don’t understand some error that emerges (after ofc trying Google & Stack overflow & my own tests), are you sure it would be appropriate to ask a question around that??

It seems to me that after asking a few questions, my team members may feel that I should be able unstuck myself or that getting myself unstuck is simply a natural part of the process of growing as an engineer.

I'm following the guide in around asking for help after being stuck for 15-20 min, but I worry this might be too frequent.

Security teams are typically infrastructure teams rather than product teams. Security teams make changes to existing products to make them more secure, which are usually trivial changes, not intellectually stimulating.

The interesting part is the planning happening before. For the first few months at Google, I did routine security fixes, which was boring but impactful. Then I found a project that allowed me to develop a more complex system for about 2 months, but that project has shipped to production and has concluded.

I am working actively with my manager to find projects that would allow me to write more complex software that will also help me grow technically. So the question is: how do I find these projects?

What I am doing now: stay up-to-date on new threats and what other security teams are doing at Google to see if I can draw some inspiration from them.

I see a lot of engineers get excited by new frameworks, and I can’t emulate that same enthusiasm. There are some exceptions (e.g. when I learned about Storybook.js, I was excited to pick it up as it was applicable to my work), but for the most part, I'm just not as excited as other software engineers about picking up the latest and greatest tech. If I’m not going to get my hands dirty with a new framework or use it at work, I just don’t really care for it. What can I do to be better about this kind of learning?

Here are the 2 main options I’m thinking about:

• Build scope here at Booking, particularly with this Perl -> Java migration where I am well-equipped. I've only been here 6 months, but I have a decent amount of good-will here with a supportive team and manager.
• Go to a more prestigious Big Tech company like Meta/Google