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

I am starting to prepare for system design questions. I would like to know if anyone has thought of grouping/categories when it comes to similarity among those problems?

For example, ecommerce (amazon) and service delivery platform (doordash) based problems has common trait of search, one can easily use the same solution across both the systems (to search for the products on amazon and to search for restaurants in doordash)

Also is there any list of must know system design problems for interviews at senior/staff level?

Lerner et al recently found that "[in resume evaluations] there were some characteristics that recruiters consistently favored: experience at a top-tier tech company..." []

I worked at Amazon as a contractor. In my resume, this is clearly labeled as contract work. In social media bios, title lines, and so on, should I claim Ex-FAANG?

I have 2 other developers working with me on a critical project, plus my mental + physical health is not so good.

I really want to move to a more relaxed workplace, but I feel deadlocked. I'm unable to carve out time from my job.

I have recently not been performing as well as I did last year/early this year due to my mental health and some changes in my personal life, and my manager noticed that too. I got promoted this year only, and if my performance drops, I get compared to my performance last year which led to my promotion. So if I try to avoid work, I'll be noticed further.

Currently, I hold a high senior position (~ L6) within a large tech company. At this point in my career, I often find myself grappling with the decision of whether to focus on advancing as an individual contributor (IC) or transitioning into a management role.

Although I genuinely enjoy mentoring junior engineers and helping them grow in their careers, I have a strong aversion to certain aspects of management, such as the frequent meetings that come with it. Given my introverted nature and my passion for staying closely connected to technology, I don't believe that a management role would be the best fit for me.

Conversely, the idea of progressing as an IC to roles like Principal or Senior Staff can be quite daunting. I grapple with feelings of imposter syndrome, wondering if I can meet the necessary standards and I am concerned that it might negatively impact my work-life balance.

I would greatly appreciate any advice or insights from the community regarding this situation.?

As an E5, I'm switching to more of a tech lead role, and one of the engineers I'm leading has had consistently poor code quality despite being at Meta for a few years now.

I've asked my manager for feedback about this, and they say that we should come up with a plan to improve the situation. I've already invested time in this, and I'm not seeing results. How can I get the code quality feedback to fully land and improve this engineer's code?

Working hard and staying on top of my sprints, I lead a team that focuses on developing tools for customer support to onboard our new features.

Though this work is consistently given priority in team meetings, it is often sidelined or perceived as less critical compared to other product-facing features.

Despite my efforts, I feel I am not acknowledged or seen as impactful and intelligent. I suspect biases at play but cannot substantiate them concretely.

How can I change this perception and ensure that my contributions are recognized and valued within the team?

How can I turn around the situation to be perceived as important and impactful, aligning my hard work with the recognition it deserves?

I just got promoted to senior engineer level (E5) at Google and I just switched into an infra team 2 months ago. In order to succeed as a senior engineer, I know I need to mentor and influence other engineers, specifically helping newer and more junior folks on the team.

How can I do that quickly, acknowledging that I’m not their direct manager?

Hello everyone,

I joined Meta a couple of months ago as an IC5, coming from a predominantly Java background. Recently, I've started working with the PHP codebase, which is somewhat new to me. I've noticed that my diffs tend to undergo several rounds of revisions, which not only delays their integration but also consumes more engineering time than I'd like.

A fellow engineer pointed out that my diffs are often too lengthy, leading to extensive feedback and additional iterations. I'm actively looking for ways to streamline my review process and improve the quality of my submissions.

Here’s what I’m considering to reduce the review cycles and improve my coding approach:

1. Reducing the Size of Diffs
2. Pre-Review Checks: -- Any suggestions here would be great

I would greatly appreciate any advice on:

• Strategies or tools that could help in catching potential issues early.
• Best practices for structuring PHP code and managing larger changes in a PHP environment.
• Any insights on transitioning from Java to PHP, particularly with regard to common pitfalls or key differences I should be aware of.

Thanks in advance for your help! I'm eager to learn from your experiences and improve my contributions to our projects.

I've had some trouble historically getting my ideas pushed through. In some cases, I'm unable to get my idea to land, and another software engineer will get something similar approved later on. What can I do so people are more likely to help me push my vision?

About Company: growing mid-size startup, great tech culture, talented people to work with, pays well

Promoted in recent appraisal cycle (2 levels above entry level, similar to L6 at Amazon) but the increment is not attractive compared to what is normally paid at that level (within company). Performance review was great but manager does not have much say in deciding increment percentage. I do see learning opportunities here in future but demotivated by this bias.

How do I renegotiate salary? How to have this discussion with skip manager?

Context:

• There is little to no documentation
• We are extremely focused on shipping rapidly
• Everyone is occupied to the fullest with their own tasks
• The codebase and architecture is a mess to deal with
• The dev environment is unfriendly to work with

Questions:

• For our success (and survival), we need to keep shipping features and products that bring in business. How do I get onboarded quickly so that I can start shipping too?
• Is there any value in following typical processes and best practices like 1:1s, project planning etc.?

I'm an E5 iOS engineer reporting to an M2 at a Big Tech company. I am the mobile lead for a complex mobile-heavy project spanning 2 other teams. This is a high visibility project that's on the VP Eng's & VP Product's radar. This project had 4 E6s:

• E6 iOS engineer on partner team #1 delivered an onboarding guide with 70+ compilation errors and took a month to fix all the bugs blocking our integration. He did not test his code at all before delivering it to us.
• E6 iOS engineer on partner team #2 delivered a component that did not tokenize SSNs properly, resulting in raw SSNs -- this would have caused an s0 incident, but my team fortunately caught it before it went to production. He also did not test his code at all before delivering it to us. My team's E6 BE engineer spent a month fixing it for that team, resulting in delays to our project's BE.
• My team's E6 BE engineer had a falling out with my M2, so he switched teams, leaving us in a bind since our only other BE engineer (E5) on this project had resigned at the end of last year.
• We got a replacement E6 BE engineer, but he is very slow, requires a lot of handholding, and most of his PRs have serious bugs -- I feel he's performing like an E4. A junior iOS engineer joined our team at the same time as he did but delivered more complex features in the same amount of time.

I switched to BE to de-risk the project after I took care of all the iOS fires. I've already fixed more BE bugs than the replacement E6 BE engineer.

Of the 4 E6s, I feel the one who switched teams was the strongest, but my M2 said that E6 did not exhibit ideal E6 behavior because we're over a month late due to BE delays and we keep discovering more and more BE bugs. The E6 also changed the design 3x when fixing the SSN issue. The M2 told me not to use that E6 as a role model, but the other E6s are even worse!

Hey Everyone, would there be interest in a topic, on how to attract a sponsor who is invested in your growth at least 1/10 as much as we are.

Over the years, I have realized in addition to being sincere and making an impact, we need the right projects to make an impact and the right people to take notice. I feel like I cannot catch a break.

I have been able to uplevel and switch, get an upper level from tier 2 -> FAANG (L5), and stayed there for many years. Thriving. Until my project was canned, and I was laid off.

My current team is at a tier 2 company, and I have already made significant impact, but my manager is hung up on some negative feedback that was given to me early on (3 quarters ago) The current staff even insidiously tried taking away my projects from me. I stood up for myself and got the project back with my managers help.

I have good feedback, on PR, good velocity and mentoring engineers to uplevel. But my manager is still biased.

I strongly believe that actions speak louder than words. Would love to know the series of master classes that can help me with Me and your advice.

Would love to know your thoughts on this when is it time to stay and focus on growth or when is it time to move on and start afresh ?

My eventual goal is L6 at Google / Netflix / Meta - Adjacent

An E6 and I recently joined an existing team and are working with an E6 who has all the historical context on the project's requirements/limitations in his head. The PM is brand new to the team and the company. The EM and designer are also fairly new. The newer E6 often proposes architectural directions that the more tenured E6 shoots down due to this context. Is there a good way to extract all this context from the more tenured E6? I feel like we're often throwing things on the wall and just seeing what doesn't get shot down -- things get shot down more often than not, unfortunately. The more tenured E6 said it'll take too long to document all the context.

What I've learned over the years is that the most important thing to do when I realize a project is late is to:

1. Come up with a revised estimate of the task
2. Notify all relevant parties with #1 (E.M., PM, x-function partners, etc.)
3. Tell the people #2 "I messed up, here's what I will do in planning next time to avoid this planning mishap next time". This step especially builds a lot of trust

What other tips do you have?

Even for the existing money earned and invested, seems like it may face some impact due to the probable hit on US economy due to the same. What can one do best in this situation?

I'm on the earlier side of mid-level with around ~2 years of experience. I just wanted to get some overall thoughts from senior engineers that are more seasoned than me: What are the main things to grow from mid-level to senior?

Since a week I have been investigating a production bug that last occurred on 20th Sept 2023, and earlier in 2021, but unable to reproduce it in test environment. At times there's a transaction that erroneously overrides some database values, and I need to reproduce a similar transaction to see where in the code the database value is getting overridden. I followed the following steps:

1. Got the request URL from logs for the buggy transaction, to see which UI page is responsible for it.
2. Spoke to the user who performed that transaction if he remembers what he changed on that UI page. It was a POST request and only the URL is logged, not the body. He faintly remembers what he changed. The database history tells me what columns were updated exactly for that transaction, but those columns are not visible on the UI. Those were updated indirectly as part of the page save. But I have not figured out still in what scenario those columns will get updated in the database from the given UI page.
3. Tried performing the same steps in test environment, but unable to reproduce. Tried for different scenarios by changing different fields on the UI, since the user doesn't remember what he changed exactly.
4. Will next be debugging the code on my local system to get an understanding of the flow.

I'm worried - what if I'm not able to reproduce it? I often think that others will doubt my capabilities. Can I be put on PIP for this?

At my company, I've experienced receiving a lot slower code reviews than usual. I think this is because I'm on a Platform team but each individual member is very specialized to their focus area. We're encouraged to tag a specific person (and I've been assigned a specific person for my code reviews) as well as the team for broader visibility.

However, I'm often stuck waiting 24-48 hours before receiving anything and always need to ping the person that has been assigned to my reviews. It felt pretty awkward needing to do that all the time so I brought it to my manager. My manager essentially let me know we don't have a good process around code reviews yet and are still figuring it out, and it could be a good opportunity for me to bring a good process to the table. He recommends pinging people in the meantime and to not view it as bothering. I am open to doing that, but still wondering if there is a better way.

I have 2 questions:

1. What could be a good way to propose a code review process to my team, especially given each individual is specialized to their own area within Platform?
2. In the meantime, what would be a good way to get faster code reviews from my assigned person who is intended to be reviewing them?

For my current project, I have 2 broad options for the infra/platform to support the feature:

1. Using a proven technology that has existing use cases within Meta but a somewhat limited API
2. Using a new technology that's not completely done yet and has uncertainty, but should have better APIs and performance

There's also the option of trying to do both, benchmarking them against one another, and then choosing the better one. However, I don't think we'll have the time to do that.

All this being said, any thoughts on which technology to go with?

I am about to start writing a multi year/multi quarter Tech vision doc for my org. To give a bit of background, my org contains 4 teams (1 front end team, 3 backend teams). All 3 backend teams (~20 engineers) work on a big monolithic service containing around 40 different APIs. Of the 3 backend teams, 2 of them work on Product features and the 3rd team (my team) is the Platform team which works on clearing tech debt, architectural enhancements, migrations, etc. For the last few quarters, the entire Platform team has been working mostly on clearing tech debt added by Product teams. The product team engineers have a very tight deadline, so their designs and code are bad or not well thought through.

My vision is basically to split the monolithic service into 3 services with clear separation of concerns and let the product teams be in charge of their own destiny. The reasoning behind this is that I feel like Platform team has been stuck in a perpetual cycle fixing bad work done by Product teams. There is no time for Platform team to enhance the capabilities of the platform. I spoke about this to my manager and he is very excited for me to come up with a vision doc and offered whatever support I would need.

So, given the context, I have the following questions:

• What does a good tech vision doc look like? What sections should it have? Currently, I have the following sections: Motivation, Future Architecture (Splitting the Service), Deploying in the new world, Automated end - end tests in the new world (we don't have end - end tests currently)
• How do I "sell" this vision to my management chain (my manager is onboard with the general high level idea), Principal Engineers, Product engineers in my org? I know the Product engineers are not gonna like the monolithic service to be split and will push back. How can I convince them?
• What pitfalls should I be aware of while doing this work?
• What upfront legwork can I do before I present this doc to everyone?

Appreciate your help in advance!!

I've been a Data Engineer for most of my career and my observation is that scope as a Data Engineer can plateau and therefore I see a lot more L4/5 DE's than L6+. I think it is because you don't impact the bottom line directly and regularly.

At FAANG's I've worked at so far, finding new scope can be difficult even when you are working with stakeholders: it is "easier" to scope/build a product (i.e. SWE work) and show metrics of success to add value vs building a data pipeline which may be limited to them having a reporting need for example which often isn't the case especially in a more established firm.

I moved into a partner facing DE role to help more with scope/stakeholder exposure. The highest impact project I worked on so far is influencing an internal team to change the way we measure a particular metric. This involved mostly stakeholder management and nothing more complex than SQL queries from a technical standpoint. While it was fulfilling, this is also something I 'stumbled' upon and is rare due to challenges like partner scope/vision is limited/slow (their leadership can change and therefore you projects/ideas can), technical challenges of automating things because of larger concerns (e.g. privacy, lack of infra on their side which you have no control over) and so on (you generally have even less control than an internal DE).

In my current role, I am generally able to derive projects, but (in my opinion) they are limited in scope/value: i.e. build a pipeline, deliver an analysis. Therefore, even though the projects 'ticks the boxes' for an L5, it is not really driving a 'transformation' as an L6+ would. I also directly asked my manager what are some of the hardest problems we have, and have been told we have a lot, yet, I'm not hearing or seeing them.

Given the situation, would you:

1. Move to a SWE role internally at FAANG for a more established path 'up' (not sure this resolves the scope problem especially at FAANG as I think SWE-DE's can almost be even harder to get to L6+ on because they generally lack stakeholder visibility and focus on more top down work?).
2. Seek roles outside of FAANG where the scope of the work is already scoped to L6+ e.g. Airbnb so the 'heavy lifting' has been done in terms of scope.
3. Refine your scoping strategy within you own team, and if so, how?

Note: my motivation is to thrive at work, this isn't for a promo, just incase the post comes across as promo-focused. :)

Hi all,

Due to recent changes in the company (Big Tech), my current manager is moving to a new org and a new manager is brought to manage the team. I really respect my manager and they were amazing at supporting me (helped me grow from E3 to E5 in 2 years).

They mentioned the new team has an opening and mentioned that I'd be welcome to join if I wanted to. The new team is our company's top priority and based on initial understanding, their work sounds very interesting to me. Here are some pros and cons I could think of:

Not Changing Team:

• Pro- I have great relationships with IC6s on the team and also junior engineers.
• Pro- I know the codebase well and scope is well defined.
• Con- Been working in this space for 2+ years and feel slightly bored sometimes. Skillset also becomes stagnant.
• Con- Manager mentioned hard to find IC6 scope in the org moving forward.

Changing Team:

• Pro- Will continue the same manager, who I have a great relationship with.
• Pro- Exciting new space and top company priority.
• Pro- Manager considers me as high IC5 and mentioned potential IC6 growth opportunities-(although since manager hasn't joined the new team yet- so I should take this with a grain of salt).
• Con- Having to ramp up to a new team as an IC5 (seems a little risky considering layoffs).
• Con- Unknowns like work life balance, team friendliness, team success etc.

Considering these, I am planning to talk to the senior manager in the new org to evaluate their team and vision. Since this is a unique situation, how should I approach choosing between the two? What kind of questions should I ask? Thanks a lot!

My team will often collaborate with other teams, often times working with them extensively to provide the proper help. However, when those teams achieve their big wins with our support, I sometimes feel like we aren't getting enough credit for our contribution, getting just a sentence or two instead of deeper attribution.

I like these other teams, so I don't think it's bad intent on their part. However, my team goes the extra mile thanking others, and it would be nice to see that same behavior in all our partners. What can we do to better facilitate this?