Found 45 lessons for software engineers with this tag.
Even though starting to work for a big company like Meta, Amazon, Google, etc. I believe is a hard to achieve (I haven't work for) somehow it looks pretty straightforward. Learn for interview, get the job, level up. Yes, I am sure it's hard and not many will do it but still you know what should be done (yes, may don't know how). But let me tell you a different story:
I work in a not that famous country in the EU and non of the top tech companies is there. Actually 90+% of the companies are outsourcing companies. As a SE with 10 years of experience in the outsourcing world I can tell you how it works: you work on a legacy code which is so old and so bad (hundreds of people have tried write code there) you can't see good practice at all, no code reviews (sometimes there is bad it is very rare), no unit tests, performance review is only about client's feedback and so on, you got the point. It's about the money only and nobody cares if you are good or not if the client is happy. In very rare cases I have started something from scratch but all of my colleagues were so bad progmmers like myself that we messed up all. It's a deadlock. After 10 years I realized I am a bad programmer and I've seen so many bad practices that I have no passion to do anything anymore. Now to the questions:
The ultimate goal of my career (and maybe in life) is to fill the gap not only in my skills but to create a company (product based or outsourcing) where everyone who join to have a chance to become a great programmer. But before helping others, I need to help myslelf. This is how I found Taro.
For context, I work in a tech lead role where I am often making recommendation to my manager regarding the projects coming down the line. The EM has the final say on this, but they respect my opinion on this matter so I don't want to mess this up.
I also have 1:1s with my teammates whom I am responsible for about their career growth goals. My teammates are all the same eng level, but have different levels of competence and desire to learn.
Additionally, I also know it's important for me to leave some room/ambiguity in project investigation stages to allow folks the space to grow, while it's also important for me to take on some challenging work and help our team deliver more quickly. I guess my question is really 2 parts:
As a Senior software engineer working at a mid-size tech company, I’m still learning how to properly push back when others Sr SWE & managers or Directors from Web or Mobile team tried to get me to do tasks that do not match my own priority. As much as I like to be nice and support others, I agree that I can only do so much. I brought this up with my direct manager and my Director (L7 Senior Manager & L8 Director), and they told me to loop them in when I face overwhelming pressures from other engineers/ cross-functional teams. My direct manager also told me they wants me to be able to focus on big project initiative, and they see that I am on track to be the Tech Lead given my current trending.
While I do appreciate that my boss gives me words of assurance and direction and offered to step in to fend off those pressures during my one-on-one call, I recognize that I would have to be the person who is good on establish priorities and be able to push back on people. I cannot really rely on my boss to do the push-back to fend off the pressure given that with the recent layoff, we are short on staff.
In light of the recent lay off, my boss confirmed that he's busier than before the layoff, and will be less available given the reorganization within the engineering leadership. My boss is not going to available and won’t be able to step in when facing high pressure from the other managers. Since my company uses Slack as main source of communication, I usually just cc and tag my manager on slack thread so that raises visibility and awareness.
Wanted to get some thoughts and suggestions on "How can I push back diplomatically against an overwhelming amount of tasks"?
Over the past year, we've focused on developing our product quickly, which has led to a significant amount of technical debt in our codebase. As a result, we've shipped applications without proper architecture and planning. However, when I suggest refactoring or re-architecting to my team, many of the senior developers and the engineering manager are skeptical. In my opinion, I am not just offering refactoring for just sake of refactoring; it's necessary because our current code base lacks abstraction and separation of concerns and has slow development times.
In those examples, how can I reduce skepticism in my team and bring more productivity, and more good code quality, and best practices to my team?
How does it differ from an entry level engineer to the head of engineering level at each of the levels, given the scope grows as well at each level?
How do each of the levels ensure they are onboarded as quickly as possible to have maximum impact ?
An XFN stakeholder came up with a last minute requirement for a big project I'm working on, which will probably slow down the launch by at least a couple days. I already made promises to other XFN about the launch date.
What's the best way to mitigate the heat on failing to launch on time and zooming out, how do I deal with last minute launch blockers in general?
This quarter, my skip requested/ gave me an opportunity to lead an org wide efficiency initiative as we are at risk of hitting quotas for some internal services (he mentioned potential IC6 scope) and it’s quite urgent to act on it. My role is to start and lead a large team of engineers on this initiative which involves tons of direction to ensure our org isn’t over quota. I would look my role as a hybrid of TL+ TPM with following responsibilities: analyzing data to find opportunities, creating roadmaps for the program, supporting engineers for execution to reduce usage, project management, understanding and enforcing processes, building knowledge on internal services, coaching engineers, setting Eng excellence culture within the org. All that to say, given limited time and a need for someone to lead, I will be focusing on direction and delegate all of the execution work to the squad.
I did read some accounts (anon post on WP) where EM and skip aligning on low code out out but the IC5 still got MM at the end because they had only 10 diffs for a half. I don’t want to be in that position.
Recently my company has split up a core team into two teams. One team is to keep on building the core infrastructure for the product and the other team is supposed to be working in an advisory position with other web applications teams that depend on the core infrastructure. Without dwelling into more details, this core team builds, and maintains datastores, that other web applications consume. A big part of the job is to build google search type infra (on a much smaller scale of course) and data processing pipelines.
Now working with other teams is exciting. But just focusing on one task that is doing tickets/changes/investigations that help them implement some specific features w.r.t to core infra, is kinda troubling me. As it puts me in a passive position and does not clearly define metrics for success. It also puts me on the borderline as I am neither doing core infrastructure-related work nor I am completely part of the other team. The idea is to imitate how Staff engineers work across teams. But I am a Senior engineer (just recently promoted).
Though this is clearly a growth opportunity for me, I am a bit worried about falling behind and not meeting expectations. Any advice on working with cross-functional teams?
What I've learned over the years is that the most important thing to do when I realize a project is late is to:
What other tips do you have?
I don't know how to contribute to our team's monthly planning. How should I come up with ideas for things that the team should work on and contribute to our team's road-mapping meaningfully?
Apologies in advance for a long question. Not sure how to ask this question without providing deeper context.
I’ve been working with my current manager for the last 1.5 years. While they have recently helped me get promoted to Senior, it’s been a constant struggle. I dread our 1:1 almost every single week because it always run overtime and we are often still not on the same page.
I see two major issues that haven’t notably improved in the times I’ve reported to them.
(1) My manager isn’t able to coach me, or any of the SWEs on the team. My manager doesn’t seem confident when we have career discussions - I recently asked them what they thought was the difference between good TL and a great one, and they struggled to coherently answer this. Instead, they said they would know better after the next performance calibration. Additionally, none of my teammate has gotten proper coaching either. For example, a teammate struggled to submit code due to their poor code quality and thus had low CL velocity, so my Manager simply told them to submit more CLs, which only made them more stressed without a legitimate way to improve.
(2) My manager lacks technical understanding of our projects and constantly pushes for speed. My manager was externally hired, and to this day, they don’t really understand the complexity of the work our team does. I understand EMs don’t need to contribute code directly, but my manager almost always underestimate how complicated the projects our team takes on are. As engineers, we frequently have to defend our timelines, which is not only frustrating but also pressures some teammates to favor suboptimal design or hastily done CLs that just causes even more churn.
The weird part is, my manager often seem unaware of their own actions, and when I talk to them about these issues, they are always receptive to feedback and seem willing to improve. However, I simply haven’t seen enough improvement in the last 1.5 years.
I could leave, since this is having an impact on my emotional well-being. But I do have good standing w/ my own team and the overall org, and I want to use this situation to learn as much as I could. I know that I myself have a lot to learn as a tech lead (Thanks for , it’s really helpful), and I know I can probably get a bit ahead of our projects and start estimating/de-risking earlier, so my Manager doesn’t get overly aggressive with timelines. I know I can also take this chance to more closely mentor my teammates and help them succeed, since they aren’t really getting it from our manager.
I want to stay, but is it the wrong decision because I have little career support from my manager? If I do stay, what should I focus on so I can really help my team and at the same time learn something valuable for my career?
Currently, we have tech debt mainly discoverable via a custom annotation in the code.
Some examples are
- break complex features into separate manageable flows
- Split large classes or controllers
- Feature/part refactoring tickets with linked ticket numbers.
The core tech debt is easy to address and manageable via project boards, but the problem is the rest (product related) often gets out of date and never gets resolved, for which there are some reasons like
- The product team has been disbanded.
- Feature no longer a priority for the product.
- The part of the code has not been touched for some time but could come into active development again.
- find better implementation of X
I believe the product-related tech debt should be owned and tracked by the product team but often there are some tech debts left in favor of speed like - breaking complex screens, and classes, and find better approaches etc etc
What's the best way to promote ownership and address such tech debt, so that they are addressed during code reviews and not left in the code as comments indefinitely, nor as a ticket in some project board which never addressed?
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.
I worked on a large org-level, cross-functional project led by a TPM and an EM. Since there were so many engineers on this massive project, we were organized into smaller pods/subteams with pod leads. The TPM had standups 2x/week, and my pod had standups the other days of the week. My pod was loaned out to help a stakeholder team from another org. The TPM only attended his own standups and sometimes missed some. The EM attended most but not all my pod's standups as well as most but not all the TPM's standups. My pod lead attended most but not all of those same standups as well. The POC from the stakeholder team was not invited to any of these standups. Since the TPM's standups had so many engineers, we only gave high-level updates in that meeting.
In such a situation, how do you keep all the stakeholders (TPM, EM, pod lead, stakeholder team's POC) aligned and up-to-date with any challenges such as scope creep, bugs, delays, etc.? There was a slack channel for the overall cross-functional project and a separate one for my pod, but none for working with the stakeholder team's POC (all such communication was via DMs). When the stakeholder team's POC dropped the ball on things, how do you escalate in such an ambiguous situation? The TPM sent weekly "Weather Reports", but those emails were very high-level.
At my startup I was asked to deliver feature after feature + bug fixes by PMs as fast as possible without much time for proper refactoring work or engineering initiatives. Also it was pretty individualistic where you get assigned a task and only work with other engineers during a tech spec review meeting, code review, and syncing with a backend engineer (as an Android dev).
From Alex’s video on getting promoted to tech lead, I saw how you can 1) drive projects as an L5 engineer (vs a PM putting that together with designers) 2) Not have to know how to implement everything yourself for a project, but work with many others and facilitate the team. This sounds 100x more engineering driven and collaborative than at my start up with few developers. Is this common to many people’s experience of the norm in FAANG?
What I liked about Alex's story is also how he had the time and space to do things like document the differences between iOS and Android, as well as go all the way through to making a data analytics plan for monitoring it himself. Seems like a lot of freedom and ownership which I didn't feel I always had the time for personally. Being able to not have to spend 80% of your time coding but rather doing deep work thinking, planing, designing holistically sounds extremely satisfying and rewarding as an engineer. Maybe this also comes with experience at startups as well?
I was curious to learn your take on strategies to push back when the expectations are not realistic. I want to expand my scope and feel that there is lot more scope for me to learn and navigate better. According to me, data and communication plays a major role here.
More specifically in my case, I am wondering how to account for me not being well versed with tech stack and constant context switching between clarifying requirements as they keep changing with each question of mine. How to politely and effectively communicate that although this may seem like a small increase of scope, given that I have to figure tech stuff it will be stretch.
Adding more context: It's trickier as I'm pretty new to the team and tech stack. I feel like I'm discovering a new requirement with every question I ask. I've set up recurring pair programming sessions to increase my velocity, but I'm not sure if that's enough.
Follow-up question: What research should be done before establishing the conclusion that expectations are not realistic?
I recently joined an organization as a senior where I was made tech lead within 3 months of joining. This was somewhat related to recognition of my work among product and my peers.
I advocated for good engineering practices such as automated integration testing and established projects for cross org collaborations to help deliver whats important for the organization.
All of this was quickly realized as a super critical projects by the organization. I created tech specs and prototypes for these projects.
However recently the organization hired a principal engineer.
since he was new I volunteered to help him onboard and asked for his advice on the new super business critical project that was next in our todo team pipeline. He is an ambitious guy so he wants to create his mark in the organization.
But for some reason the way he is approaching it doesn't seem right to me.
He plans to create a new team taking over the business critical project while splitting the newly formed team I lead on the same project that I helped him ramp up on.
I opposed to this asking for rationale for a new team.
there seem to be now two impressions of my work:-
held by my peers, folks I lead and product manager of good business delivery and product timelines. I am respected among both.
the principal Engineer tries to devalue my work in front of senior engg. Leadership saying things like I am overcommitting and under delivering if I do this project with the existing members of my team in public and in front of senior engg leadership.
The automated integration testing project which no one was doing before and we were starting from a basic version to iterate on. This is now communicated to engg management as every team is trying to do their own testing.
My engg management for some reason is siding with him since he has 15-20 years of experience and i have 5. He also is principal and i am 2-3 levels below him.
for some reason I am being micromanaged with no fault of mine.
From engg management perspective I have been just told to lead the project that I am currently leading and just help the team formed by principal engg to start the project.
I have communicated my expectations of being able to continue leading the project. Product is in support of that but engg managment isnt.
I have also tried giving feedback to the principal engineer that his actions are disruptive to the team and becauase of what he is doing he is slowing us down and blocking us from doing critical projects.
My worry is despite doing the hard work the project I have the most context on and I worked on for a while is being given to someone else and second i will not be given credit for the hard work I am doing.
Should I just change teams. I dont want to leave my existing team because I do think they need me but I feel I would rather create more impact where I dont have to swim against the tide. I may also be suffering from sunken cost fallacy here where I knew I led the development of a new critical project
Tia for your help.
When I've been helpful in the past, word quickly spread and a bunch of random engineers started pinging me for help, sometimes aggressively. Sometimes people would delegate grunt work like asking me to test their PRs that do library upgrades instead of testing them themselves. Or asking me to debug their dev environments because they heard I fixed another engineer's dev environment. Sometimes it'll just be asking for expedited code reviews even though I have no domain knowledge on their PRs. We work on the same platform, but are not on the same team or often even the same org. There are only so many hours in the day and I need to get my own work done as well. How do you decide who to help and under what circumstances? Advice on how to push back without damaging the relationship? As far as I can tell, it looks like anyone from E4 through E7 are the ones making these requests.
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?
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?
I'm an E5 iOS engineer at a Big Tech company. I'm struggling to understand what leadership means. A Director told me Leadership means making sure the project is successful no matter what happens. As a result, I often end up doing other people's jobs for them (e.g., when a backend engineer struggles to get their piece working, I often hand-held them and have even created backend PRs to unblock some projects even though I'm an iOS engineer). However, a mentor told me that E6's don't do the work themselves but delegate it to others to scale themselves. If this is true, then what does an E6 do when working with engineers who are either unwilling or unable to complete their deliverables in the expected timeframe and quality? This becomes even more challenging when working cross-functionally with engineers who are not on my team. Also, how do you lead when you're not the DRI (Directly Responsible Individual) / tech lead for a project (e.g., when the tech lead is an E6 on another team, but is not setting up the team for success by refusing to communicate requirements clearly)?
How to best answer this question in quarterly discussion with manager? Things are looking good on personal level. On team level also project plannings are seems to be aligned with team goal. How can I add value to this question?
I have realised over the years that I have gained good amount of technical knowledge but I lack great communication skills (in terms of expressing my thoughts). This was okay till I was working as software engineer as my task involved more of coding work which does not require explaining things to large audience. Now as a Senior Engineer my task revolves around making design choices, explaining pros/cons of selecting an approach etc. I realised that even though I am confident on my technical approach, I sometimes fail to express myself and the approach in the right way during the discussion which led to times when my approach is discarded and others as selected as they express themselves better. I need some suggestions on how to improve on this aspect as this will be crucial part going forward in my career.
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?
I've done various presentations throughout my career, and I always get stressed out doing them. I'll make slides/a script beforehand and pull all-nighters the day before. I'm okay presenting in front of smaller groups, but it's hard in front of larger groups.
How can I get more comfortable with this, especially with higher stakes presentations like those trying to get buy-in from a large group of senior+ engineers and tech leads?
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?
I'm more of an extrovert, while my tech lead is more of an introvert. I feel like our relationship isn't as open and honest as it should be, particularly around sharing feedback. They often times have major feedback for me, but it will come too late, either deep into project execution or as late as performance review.
How can I make this relationship more fluid, so I can get feedback to improve earlier?
I'll be going into Amazon as a senior engineer leading a team of 6-7 engineers. I have some anxiety as I have never worked in a FAANG company before, and I imagine the bar is high. Things are also trickier as I'll be in a different time zone from the rest of the team.
How can I make a stellar first impression after I start?
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 am trying to get promoted to Lead Software Engineer, which relates to an E5 level at Meta, if I am not wrong. I have seen several engineers in my organisation coast at the current level I am.
I wanted to understand if there are some key things I should be doing in order to perform at a Tech Lead level, so that I am promoted to one as well. This would be a bit long question, but please bear with me.
Following are some of the things highlighted in a few discussions:
Another aspect is that my team would be getting changed soon due to organisational requirements. Given that, How do I make sure I am on the right trajectory to getting promoted ? (One thing on top of my mind is that I would be asking for junior engineers whom I can work with and try uplifting, alongside asking for opportunities/projects that would have large visibility and impact.)
Do you have any other advice for me?
In fast-paced organisations that launch a lot of features on a quarterly basis and teams with large sizes, how should a tech lead or team members ensure that everyone knows about everything or is enabled to get to know about it?
Quite often, whenever a new feature comes in, it could be repurposing technology built for other features as well. But, given the pace at which these are developed, it is often hard to know what everyone is working on. Sometimes, each of these features may have idiosyncracies that may be getting missed out by new joiners, especially due to the volume of information, especially for teams that have been in existence since a long time.
I recall once when changes for a new feature done by a developer reverted some conditionals for an older feature, thus causing an outage. How do you prevent this and ensure knowledge of everything is available to all, especially to people new to an organisation ?
Also, are there some general practices to ensure that these are easily discoverable ? Video recordings are time consuming to go through, and wikis though they exist, are sometimes difficult to navigate, when you don't know what you are searching for? I am thinking of something like a mind map could help here, but what are your thoughts ?
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've grown to be more of a "tech lead"-style E5, which leads to a lot of time spent roadmapping and talking to people instead of actually executing on the project and being more hands-on. My team is heavier on the E3/E4 side, so I'm able to delegate a lot of the coding work away. I was wondering if this was normal for Meta and whether this is an okay way to operate as an E5?
The setup on my team is pretty standard: There's an E6 tech lead that has broken up a big project into multiple pieces, and I own one of those pieces (and the rest of the pieces are owned by other E5s). I'm leading a couple engineers (<5), and I think they're E3/E4.
Zooming out, this seems like decent E5 scope, but I'm sure there's some gaps to turn it into E6 scope. The tricky part is that my org is pretty XFN heavy, so it's hard to get things added to the roadmap, and with the hiring freeze, it's hard to get more engineers onto my team to lead.
All that being said, what are some ways I can find staff scope in this situation?
I recently started at my new gig as a remote tech lead. While I am on the West Coast, most of my team is either on the East Coast or in Europe (+11 hrs). Meetings start at around 7 AM PT and go on until 11:30 AM PT!
Here is my challenge: I am a morning person & like to do more deep & undistracted work during the morning hours (Coding / Reading / Writing) . Screen time in the mornings usually drain me out & my productivity dips post multiple zoom / G-meet calls. What are your thoughts on how could I balance my sacred morning hour time between meetings & impactful work?
I'm working on a cross-functional project with a backend DRI (E3) and Android engineer (E4?). I'm iOS, but have a backend background so I could easily code the backend portion if I needed to. The DRI reports to a different EM, who was on vacation for the first few weeks of the project. The DRI was struggling to get the backend piece working, so I spent extra time hand-holding him on how to debug it. I even researched how another feature in the iOS codebase used similar API calls and created a Postman collection for him to troubleshoot his APIs more easily. Is this a good use of my time? What percent of my time should I spend on helping others versus doing my own work? The Android engineer did not help the DRI because he doesn't know backend, so there was no one else to help the DRI.