Mid-level Engineer Career Development Videos, Forum, and Q&A

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'd love to ask about is effective pressure management. Coming from small cos to a big company like Meta; despite startups having a reputation for chaos, I personally find there's a larger number of failure modes at big companies - a review taking too long, lack of good logging, misalignment, which can lead to either a project being derailed or just flat out failing. I've personally gotten better myself at pressure management (trial by fire); but would love to have thoughts from folks on how they work on this skill!

I have recently joined a team which works in Go (no frameworks). My team handles multiple backend services ( exposed through REST APIs ) which are like a platform for various other services.

I have picked up the language grammar and have enough understanding to write working code. However, I feel I don't "get" it. I don't understand how to organise the code into a well-defined folder structure and interfaces.

I would like to understand what are some of the good ways to learn a new language. It's been 2 months since I started learning it and feel like I am working with incomplete knowledge. Maybe at 50% level. I know there's no point in understanding all the features of a language but I would like to understand design patterns, best practices and how to write high-quality code.

I really need to be able to ramp up in another month's time.

Majorly need advice on

1. Learning to write high-quality Go code
2. Writing with Dependency Injection in mind
3. Design patterns and low-level system design

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

So, a new situation has come up at work. My lead let me know today that he/she is going on a parental leave around October last week. I did ask them to let me know if I need to step up and need to prepare anything before they leave.

Question is How do I handle this situation and work with my directors to get prepared for it. I don't feel prepared to replace them for the next 3 -4 months nor I think I'm expected to do that but the question here is how can I proactively reach out, prepare and help the team in this situation.

I recently accepted an offer as a full-stack developer for Atlassian (P4). I have about 2 years of experience.

My first company was about 12 people (all engineers, no teams) and my current company is about 400 people (about 20 engineers, with my team size being 5 people). The team I'm moving to at Atlassian has about 100 engineers in total, and the team I will be on should have around 10 engineers I have been told. The hiring manager said that the teams are made up mostly of mid-level and senior engineers.

What can I do to make sure I get up to speed in ample time and be able to make an impact? I would like to become very career focused starting with this job and focus on advancement. My main concern is that maybe my experience in only smaller teams at smaller companies will cause friction for me as it will be a big adjustment.

I've been debating this though for a while. Is it worth it to go for a principal role (61 -> 62 -> 63 -> 64) or just go and build something your own

Came across on CSCQ where the original poster asks about what these missing essential skills. One reply had me wondering, how I can actually learn these points:

• How to write things in a way that other people really understand what you're saying.
• How to structure code so that you can come back to it in 2 years and understand it.
• How to show off the work you've done.
• How much testing is the right amount, and not too much or too little.

I get a lot of JIRA tickets for bugs where it's not clear what the fix should be. How can I find the problem area and relevant code faster with these issues?

Given this industry, switching is always somewhere in my mind. How can I figure out if it makes sense to pursue that or stay? When it comes to staying, how do I know if my current team is conducive to my overall growth and goals going forward?

I was working with a team during bootcamp, and they mentioned that they intentionally have very low test coverage (both unit and integration). This team is more on the back-end side. Is this a bad sign or is there something specific about Meta's culture that I'm missing here?

More specifically:

1. How can I tell if I'm building projects properly?
2. How do I make sure I'm teaching the right things? - I'm mentoring a couple other engineers right now, and I want to share the proper methods and ideas with them.

I've gotten feedback that I could be more of an expert and provide insights more smoothly on past projects I've delivered. However, I've been at the company for many years, so there's a lot of stuff attributed to me. How can I be an expert on all these things without being overwhelmed?

I feel like the projects I get are more generic and straightforward. I want to start making progress towards senior, but the more complex, larger scope projects are going to the engineers on my team that are more senior. What can I do to start getting those projects?

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 work overtime a lot, and it's pretty stressful. I'm also worried that amidst all this effort working for Meta, I'll lose track of who I am overall and what I can do for other companies. What can I do to strike a better balance here?

There's a lot said about asking great questions, but I'm wondering what guidelines apply to the other side: Providing great answers. How can it be done in a way where the answer resonates the most with the asker and the relationship is built up?

I know that moving companies is very powerful in terms of compensation and learning new things. However, I'm wondering if it's still effective in the context of trying to get to the highest engineering execution levels like director or VP?

Something I want to get more efficient at is promotion trajectory, and team selection is a big part of that. If I were to switch teams, how can I find one that's important for the business and has a good amount of L5 scope? My goal is to move up to L5 soon and have scope to start making progress to L6 as well afterwards.

Recently, I have found myself just working on the tasks and investigating the bugs that my manager tells me to. However, from a performance perspective this would be considered "meeting expectations" at best. How do I develop a nose for impact and introduce new, innovative ideas to my team that really improve our product or development workflow?

At Microsoft, basic criteria for promotion is to deliver at next level consistently. Example: At L62, i need to work and deliver at L63s work level standards.

At my last job, I was working on machine learning infrastructure and moving towards becoming a machine learning engineer. I switched jobs because I was miserable for other reasons besides the work, but I'm now at my new job working on a completely new domain in distributed systems. I'm not sure if I like this domain compared to what I was working on before. I'm going to give it a year, but if I figure that I don't like it, how difficult would it be to move back to my previous work?

Every quarter, manager asks few question like what are things that went well for team? what are things that didn't went well? what are your top priorities as a team member? What is best way to answer these questions (as someone who's been in company for less than a year)?