Communication Q&A and Videos

Hi all

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

1. held by my peers, folks I lead and product manager of good business delivery and product timelines. I am respected among both.

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

I’m an E5 at a Big Tech company. My team’s E6 does not communicate or delegate effectively. He dives straight into the weeds without providing proper context, then gets frustrated and explodes when people ask questions or do the "wrong thing" because they are lost. I’ve seen him do this to multiple team members, including my EM and another E5 teammate. He always assumes that everyone has the same context that he has and is unable to tailor his communication to the appropriate audience. How can I best work effectively with someone like this? He would delegate tasks to me without providing acceptance criteria or proper context, then explode when I ask questions or do something other than exactly what he had in his mind (but never communicated properly). Is there a way to fortify my questions so he’s less likely to explode on me? My EM thinks that this E6 has a “my way or the highway” approach because he’s not used to people challenging his ideas. The E6’s feedback for me is to drive discussions more. However, I find it challenging because he leaves out critical information, then explodes and shares it only when we pull teeth about it in team discussions. I tried sharing pre-read meeting docs beforehand, but he still waits until the meeting to explode / share his feedback. Unfortunately he's a domain expert in this area, so there's no one else I can extract the context from.

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?

Hi everyone! I want to understand what are some most effective ways to articulate your person goals and growth areas to your manager. What are some questions to consider? How do I measure success?

I want to maximize 1-1s as much as possible and I think this is a good starting point to laydown the roadmap.

Hey how it's it going

vs

Hey...how's it going

Great job!

vs

Great job...

I have great relationship with my manager. In order to grow within company I feel like increased visibility is required. Any tips on how to do it? We both are remote.

I'm about to be officially promoted to Senior Engineer in a couple of days. At the same time, I've also been been presented with an opportunity to move to a different organization in Amazon that's doing some rather exciting work. This is an opportunity I'm likely to accept.

I deeply value my current manager's support, because he was critical in helping me secure my promotion despite some very tricky circumstances. I'm aware that promotions are just meant to recognize past work, but leaving virtually immediately after a promotion still feels rather unpleasant. Leaving now will also have a bigger impact on my team since we've shrunk quite a bit recently.

What are some tips for structuring and framing the inevitable conversations I will be having with my manager(s)?

Been working for a while as remote, mostly with other remote folks.
Now I'm remote, but rest of the team is in office.

What do you think are some of the most important actions, processes or activities one should take to be effective as remote worker in this specific scenario?

Things to do to build meaningful connections, be productive, build alignment and, from those things, how to know at a given time what are the most important ones.

Thanks!

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

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?

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?

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.

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.

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

A little context: I joined my company back in Jan and have been doing really well. I’ve been consistently pushing code, owning projects, and creating good relationships with my colleagues.

This week I’ve been really sick and it feels like nothing is going right. I have been running an experiment for a couple months and today I found out that one of the arms is bugged because I introduced it a while ago. After a scrambled meeting with my lead and manager, I addressed the bug and pushed a fix but because of freezes my bug fix won’t actually be in til after year end. My manager stated that they wouldn’t have expect an engineer to not notice a bug like this go on for so long.

The business side is actually not even interested in the bugged arm and would like to go with an approach I proposed earlier in the project.

I’ve learned a lot since I pushed the bugged change and my code and communication has improved but my managers comment plus all the news about layoffs and perfs and PIPs has had my anxiety through the roof the past few weeks. Anyone else feeling the same?

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

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

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.