Communication Q&A and Videos

I joined a company 6 months back and from start I am noticing that some of the engineers in the team are constantly underperforming and I can hardly see them working on any task. This puts additional pressure on other teammates to perform as we set team sprint goals considering availability of all engineers and we find the team always lag behind the deadlines.

I am wondering what should be the right way to discuss this with my manager during 1:1’s. I don’t want to sound like I am pointing fingers on others.

I just found out that I was rejected from one of my dream FAANG companies :(

The recruiter told me:

Thanks so much for taking the time to interview with our team - they really enjoyed meeting with you. Unfortunately at this time, we will not be moving forward with an offer. The team really enjoyed your positive demeanor, thought you had great communication skills, and a well thought out process throughout the technical interviews. I am not able to share specific feedback as per company policy, but I am of course happy to jump on a call if you have any questions.

What can/should I ask her in this call to maximize my learning to be a better candidate?

I work as an E4/L4 equivalent Software Engineer at a fairly big tech company (5k+ employees).
My org's Senior Director is interested in helping engineers in his team develop good soft skills which align with one's career aspirations.

I have my 1st recurring 1:1 with him soon where we'll be brainstorming over which skills I can work on one by one. I want to go in this meeting with some ideas.

Personally, at this stage of my career, I haven't thought about whether I would like to stay in IC role or get into management some years down the line. So for now, I want to work on the soft skills which would generically provide best returns in future in the tech industry.

The ones which come to my mind are -
- Presentation Skills
- Leadership Skills
- Conducting meetings well with a large audience
- Decision Making

Can you please share the right skills to work on from your side ?
Also any pointers on action items I can take for each skill you recommend (or for above mentioned skills) will be of great help too. Thanks.

My question is when should I reach out to help someone. If someone new joins, and if it is clear that task might be difficult for person, or there is some context needed etc, and they fail to ask, should you help them? Reaching out early and helping might be hampering their own learning, also at risk of hurting someone's ego. But If I am in other person's shoes, I would appreciate all help so what is right balance here?

Also, should you helping be more visible or private? If it is public, other people can add extra context as they like, but maybe in private conversations, person can ask more follow up question, assuming they are afraid to ask dumb questions. To be more specifically, by public I mean team channel in slack and private would one-one chat.

Background:

Being pressured to deliver at high speed all the time, my team doesn't seem to value wiki type documentation a lot.

When starting a project/feature, we often have a high level design doc & design meeting to talk about high level infrastructure, and we make key trade-off decisions together as a team. If we are lucky, we get another low level design doc & meeting focused on sequencing of actions & interaction between class level objects.

We rarely seem to go back to our initial design doc after initial design phase of a project to update them and explain the actual final product we built and maybe some additional design decisions we made during implementation.

As a result, documentations are kind of dead after facilitating the initial design review. For legacy projects, high quality docs are extremely hard to come by and most just rely on reading large amount of code to understand how things work (nothing wrong with this but I think high quality documentation can save lots of time here).

I understand we don't want to boil the ocean and write everything in painstaking details, but we should at least have enough to help people understand responsibility of services and contract between them.

Questions:

• Could you share your view on this topic and how you find your balance?
• Do you believe it's always worth it to go back to documenting after finishing a project/feature and update it as if you are explaining it to someone new to the team/project?
• Could you share any resources we might already have on this topic as well?

My org VP holds office hours every week. Also he sometimes does AMA sessions. I'm usually not sure what to ask so I don't avail those sessions as I don't want to ask any stupid questions.

I am working on a component with eta 2 weeks. This is to write just the application logic and doesn't include any infra setup or APIs. I am not blocked with any major issues. I am new to this team. My update is like I am working on xx component and continue working on it today. Can I get ideas on various ways to update?

I'm an E5 at a big tech company. I've been on multiple projects where stakeholders waited until the very end of the projects to say, "That's not what I wanted." What can I do to prevent this from happening? I got feedback that I "need to navigate ambiguity". Does "navigating ambiguity" mean somehow predicting that stakeholders want something besides what they sign off on? If so, how do I develop this skill?

This seems to only happen on projects led by E6+ engineers or an M2. I have not had this experience when working with other E5's or more junior engineers.

Examples:

• Misaligned OKRs: At the beginning of the quarter, my M2 told me that it was okay to have a multi-quarter effort, so I planned to do an analysis and roadmap in the first quarter, then execute on improving metrics in subsequent quarters. My M2 signed off on my OKRs for the first quarter. When I provided my deliverables at the end of the quarter, the M2 said, "That's not what I wanted." Then he told me that he wanted metrics moved, even though my OKRs clearly said it was just an analysis & roadmap. I asked 2 mentors (a Director & an M2 - both not in my management chain) for a 3rd party opinion and they both agreed that there was no way to read my OKRs as moving any metrics. I'm confused why the M2 signed off on it and didn't say anything about it in our team's weekly OKR review meetings if that's not what he wanted. He gave me feedback that I need to "navigate ambiguity." When I asked him for concrete, actionable steps to navigate ambiguity, he said, "If you need to ask that, then clearly you don't know how to navigate ambiguity." I'm so confused! Please help!
• Low-level design missing on a cross-functional project: The DRI (an E6 backend engineer on a different team) kept talking in circles & refused to answer questions whenever the other mobile engineer and I asked about the low-level design for our project. The other mobile engineer tried escalating to our EM, but our EM did not help us. As a last resort, the other mobile engineer and I aligned on the mobile implementations and built that. During end-to-end testing, the DRI said, "That's not what I wanted." He did the same thing to the data scientist. The project was initially scoped for 6 weeks, but ended up taking 2.5 quarters due to all the churn around "late findings". My EM gave me feedback that I need to have a low-level design before starting implementation.
• Wrong requirements on a cross-functional project: The DRI (E8 web on a different team) provided a requirements doc that was confusing, meandering/disorganized, and hard to follow/understand. An E7 mobile engineer flagged that the doc is not a proper requirements doc at a TSG (Tech Steering Group), but the DRI ignored him and forced me to implement it. I asked for requirements clarification, acceptance criteria, and end-to-end test cases, but he refused to provide any of them. He told me that the requirements doc was all I needed. I escalated this to 3 EMs (my EM, the project's EM, and the DRI's EM) due to my bad experience from the previous project, but none of them helped me. When I asked my EM point-blank how to avoid building the wrong thing, he told me to just make sure I get sign-off on the low-level design in my mobile RFC. I made sure to get sign-off from the DRI before implementation. I also provided TestFlights every 2 weeks for the duration of the project. On the final day that I was allocated to the project, the DRI asked what happens in an error scenario. I said, "Exactly what was documented and signed off in the low-level design of the mobile RFC. Why would it be any different?" Sure enough, he said, "Oh, that's not what I wanted." When I asked why he signed off on the low-level design, he said he missed the flowchart that described the error handling. This happened even though I explicitly tagged him on that flowchart in the Google Doc. So the overall mobile design was about 80% wrong. Turns out his requirements doc said the opposite of what he wanted and that's why the wrong thing got built. The TestFlights had the wrong behavior starting with the initial build, but he missed this as well. His feedback for me: "needs to make sure we build the right thing". How do I avoid this in the future? My EM was unable to provide any advice on how to avoid this in the future. All 3 EMs resigned towards the end of the project.

I have joined this new company for little less than a year. I had interviewed for a different role but due to certain hiring constraints joined in a different team and role. The team I am in is not very technical, there's a lot of process and grind work that's part of the role. It is rather different from what I have been doing which was essentially automation of manual processes and deployment pipelines using tools and coding.

I had one review till now where I got an average rating, to me it seemed sub optimal given I put in a lot of effort to add value to the team. Some of the comments I received included that I should come up with my own ideas (this was with respect to a manual process that I automated which was lying in the backlog for over two years) and also related to some of the choices I made (manager asked if I want project A or B and I said I'm definitely interested in A).

To be honest, I feel my manager is nit picking and he also trivialized my work by making comments like anyone can code, ideas are important, etc even when no one from the team actively owned to execute the ideas.

I feel my manager doesn't particularly like me due to the above behaviors. In this situation how do I set myself up for a good performance review the next time. I would have considered quitting but I like the vibe of the company and some of the other teams are doing phenomenal work. It was hard for me to get in so even if I quit I don't want to quit without trying first.

In most of my previously held roles I became a go to person pretty quickly and got good visibility. How do I do this here?

Say you want to research on a topic for resolving an issue and want to share with the team by creating a Google Doc. How does one master the skill of creating an high quality Doc?

My Senior team member, top performer, is super solid at creating Google Docs and churns out one great doc almost every week. He said he just focuses on just dumping out the thoughts in the first go and fixes them later on. But I feel his velocity in getting that doc out or completely the research on it is very fast. So clearly there is something that I am not understanding.

So I am looking for opinions from experts on Taro :)

I recently had a conversation with my manager regarding my work commits every week. It seems like he always downplay me in every one to meet showing me in bad picture. As compared to other folks , I have shown more progress with respect to code commits and tasks completion. He ignore other developers mistakes or issues softly.

How to deal with this scenario?

At times, we face tight deadlines which I believe are challenging to meet. Despite my reservations about the feasibility of such timelines, my fellow engineer peers often express confidence in meeting them, though history has shown they're frequently mistaken. When I voice my concerns, the project managers claim that delivery is non-negotiable, and everyone in the room goes silent. I've suggested prioritizing essential features for the immediate deadline and planning for a subsequent delivery for the rest, but my ideas are usually ignored. Despite not being in a lead role, it's disheartening to later hear about our inconsistent delivery timelines from my manager when I receive performance feedback. How should I navigate these situations? It's frustrating to be the only one on my team who ever expresses these thoughts as I always appear as the "pessimistic" engineer. I just try to voice concerns to make more reliable deliveries. What should I do in these situations?

We are 3 people in my team. I've been at the company for 2 years roughly and my team mates for 15+ years. I'm in a situation where my coworkers do stuff, but stuff that's often completely unrelated to our backlog. One of them struggles with being motivated by the job. Occasionally, a 16-hour job takes a month to complete. Maybe 2. And you never know why or when it will be done. This causes a lot of tension with the product lead. The other teammate (focused on the front end) rarely makes any PRs. I'm not sure if it's due to the fact that they have mostly done HTML/CSS and are unsure of how to navigate the frameworks we use or what it is. Our manager tends to cover for us, but obviously he's not loving this situation. It's been like this for 1–2 years. Now it has started affecting my pay raise, and I'm starting to feel tired of always playing dumb or referring to the other great work that they're doing when asked what my teammates are up to. Both seem to be struggling somewhat with stress and anxiety, so I've tried to be compassionate with them. But what do I do? I want to take ownership of the team's performance, but it's difficult to know what to do. They have the senior roles, and they have most of the ownership of the project, so I also feel weird telling them "what to do," if that makes any sense. The company size is roughly 20 engineers, FYI.

Any advice on how to handle this situation nicely, i.e. making sure we're still friends afterward, would be highly appreciated.

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.

I'm an E5 at a Big Tech company. My team's working on a very ambiguous project. 3 opinionated, vocal engineers (2 E6, 1 E5) tend to sidetrack our brainstorming discussions by playing devil's advocate to shoot down ideas. How do I drive these meetings forward with this dynamic? We often rehash the same discussions over and over. When we're close to reaching a decision, oftentimes someone would throw a wrench into things. Moreover, some engineers require upfront planning and want to finalize all the details before committing, while others prefer to defer the details to future milestones. Both my manager and team are getting frustrated, but are unsure how to fix this.

I'm an E5 at a Big Tech company. There are several loud, opinionated, dominant personalities on my team. Some of them are E6. They often talk over each other as well as the rest of the team, so the rest of the team rarely contribute to discussions anymore. When a teammate (E5) presented his RFC to our team today, the dominant personalities started questioning his design decisions and talked over him when he tried to defend them. My teammate looked so discouraged and beaten down at the end of that meeting. When I brought this up to my EM in a 1:1, he said it's a people problem -- people are not being respectful. I asked my EM if he could coach those people, but he said he prefers to invest in people like me who are interested in learning & growing.

• Is this a lost cause?
• Are there techniques to handle these dominant personalities skillfully? Or do my teammates & I just need to develop "thick skin"?

I am currently involved in the interview process for a Senior Software Engineer (SWE) position at a bank. As I prepare for the upcoming behavioral interview, I've reviewed common questions provided by Alex's blog and completed the behavioral interview track on AlgoExpert, which has equipped me with a set of comprehensive responses. Despite these preparations, I am seeking further advice to optimize my readiness. Given that my background as a Software Engineer has been primarily within a small company, moving into a banking environment presents a new and unique challenge. Are there any specific tips or guidance you could provide to help me navigate this process more effectively?

I have five years of engineering experience. I joined a product-based company last year as an SDE - I, after six months of working in the organization. I felt that I qualify as an SDE - 2.

I cracked an engineering manager round, which is the final technical round in a different product-based company. On paper, it has more scale and value.
I need help navigating the compensation, which I have to discuss tomorrow.

I have an interview coming up that isn't DSA / System design focused, but rather a project deep dive or work experience deep dive.

If the interview is 45-60min long, how should I best describe my work experience in that given time. Also, if using STAR method to answer work experience / project related questions how many situations per bullet point on resume should be discussed?

I'm mid level, new to the company.

I got assigned a chunk of a bigger project owned by a staff level engineer, let's call him X, who has worked on the product for a long time and has a lot of context.

Things that were new to me: the language, the tool chain, product context. The codebase is several years old.

My skip level manager (1 level above my direct manager) once encouraged that I should aim to finish my work in less than 2x the amount of time it would take X to do it (but besides this I received no pressure, or reminder to push for this target from managers).

This was overly ambitious. I worked longer hours and harder than anyone around, including weekends but still could not finish it in 3x the amount of time initially estimated.

The staff engineer overestimated what I can do too. He's very willing to explain but I had a hard time mapping his high level explanation to what happens at the code level.

I could not tell if the standard here is high or the task is too hard. So I leaned towards putting in more effort rather than voicing my concern.

I also did not have a good sense of "are these unknown parts of the code base grok-able with a little bit of time or do they require a lot of time?" to estimate time spent up front.

In the end I got some barebone thing out and he took over. Still took him a couple more weeks to get the thing finished. Along the way he solved some problems I'm sure I have no chance of solving in that timespan.

With this evidence I was sure the task was legitimately too hard for me and was comfortable letting my manager know my opinion.

Back up a little bit, when I started working on the project, my manager knew I could not stick to the original timeline set by the engineer and encouraged me to take my time to learn the codebase. What is puzzling is my manager did not tell the engineer about this unrealistic estimate. The engineer reports to a different manager and has been around way longer than my manager.

Maybe there is some politics going on that I'm not aware of.

Anyway this has been a very stressful experience.

What could I do better? What should I do to mitigate any harm done through this experience?