When I was at Meta, I worked with a new engineer who came in with a ton of experience. Unfortunately, he struggled a lot, eventually got a PIP, and then left the company. He had 14+ years of experience at what I'd describe as a "tier 2" tech company before joining Meta. When I look back at what went wrong, he didn't embrace the struggle that comes with diving into a new codebase. He spent a lot of time writing docs, debating various architectural decisions, and providing opinions to other engineers, but his code output was limited (trait 1). It's ok to struggle with code output, but the main issue was that the rest of the team didn't understand what he was doing (trait 2). If he needed help, he should have made some noise and made that obvious. If he was working on something else, he should have communicated why his priorities were justified.

Performance Anxiety -> Reduced Interaction -> More Anxiety 🙂

This doesn't only applies to engineers but pretty much every typical corporate job I would say. You have to be diplomatic about what you do and the expectations you set, It's not so much about your technical skills but more about how people perceive you to be. You might be a great engineer (If we consider the engineer to be the definition of what an engineer does/builds) but struggle managing your time / output. The reason is that, with such a big company, your estimates and commitments ultimately travel up the management chain. So if there is anything that goes wrong there, ultimately you will be held responsible and you can imagine the amount of stakeholders that will be disappointed when you don't deliver what you promise. Hence you can imagine a "great engineer" typically would set the right expectations by giving safety conditions like "I can do this in X days unless I don't get pulled into A, B, C, D events". In reality, with corporate jobs you get pulled into multiple things and many meetings and its hard to get actual engineer work done the higher your level is. This is the thing I struggled with initially as coming straight out of college. I used to take ownership of everything and ended up under-delivering at times. As time goes by, you realise that senior engineers basically learned how to play this game more accurately.

Thank you! I am 100% gonna use that last bit of advice. I do say things are trivial and now I realize that I am shutting down conversations that need to be had, even if I do think the solution is fairly simplistic. Sometimes there is hidden ambiguity another engineer might raise.

And in all of this, what did the manager do to solve it? An engineer not reaching their full potential is as much a managerial responsibility.

Often times when we are asked about estimates, we try to present ourselves better by giving lower estimates. I used to tell what time it would take without interruptions and if everything goes right, but as time goes by we start understanding value of buffer time. Now we are struggling with another problem that our management already finalises timeline with stakeholders with rough estimates. Then assigns task to individual owner and now they have to keep timeline in mind when designing, developing and it now affects their performance/promotion if not achieved.

Happy thanksgiving Rahul! Appreciate you always talking about points that often gets ignored or don't get talked about. I had some thoughts/ideas that maybe you can think about for your next videos: 1. I am not sure if you have discussed this in any of your videos before.How to make sure to keep on learning new things in the tech world, but also be sure not to have FOMO? meaning there was(or still is) a big hype around Web3/blockchain/Data science/analytics/ML/AI etc. though not a bad thing at all, but I often find myself surrounded by folks who want to learn A tech stack since someone else told them so. How to not get a FOMO but try to focus on building yourself while performing well at your current job? 2. This might be a long shot but I will try. Say a person is working as a front end engineer on a team, but they are interested in becoming a MLE/Backend/Data Engg within the same team or another team. How should one prioritize in attaining that position (given they have acquired those skills using online courses/university courses)?

I agree with most what is said here. Something I’ve noticed is that lots of people have a way to optimistic time estimate when judging new feature development. In general, I feel a lot of engineers fall into the trap of under estimating the time it will take to accomplish things. And I have seen how that hurts the trust of product owners and other stakeholders. Its always better to be more humble and to try and clarify why you estimate that something will take X amount of time. Request to do a spike and investigate rather than just shoot from the hip. In the long term, you will be rewarded for it

Definitely helpful - went from giant tech to small and it is much more apparent how important this is.

What you said is very true. However, one thing I notice with well performing managers who can turn the engineers around is how they would frame the issues. They would never say "here are traits of the worst performing engineers". Often the traits are generated through performance anxiety, and framing it as "traits of worst performing engineers" is ineffective communication as it generates more anxiety, and often resistance depending on the person. An effective manager typically would frame it as "you can improve by focusing more on the business than technology" and "it is a common problem". Frankly what you described are pretty common. Moreover, people who fall prey to these are often the most analytical folks - who have attention to detail, are observant, but are also perfectionists. So it is counterproductive to say "here are the worst performing engineers". While it is true, it is not useful. The framing can be better, and the feedback should be put into more context. Doing so is worth it since these tend to become your best performing engineers over time. Another way to frame it (which also contains sufficient empathy to be effective), is to talk about one's own mistakes in these areas. Lastly, imagine how you would feel if I framed the above in reverse and talk about "traits of the worst performing managers who say the right things but make their engineers worse..."

Hi Rahul! I'd love to hear these topics from you : 1. Must have habits for engineers at faang 2. How to maintain a second brain as an engineer at faang 3. What are some easy to measure performance metrics to present impact 4. How to measure impact in an area where monitoring is very hard To the rest of the viewers, please feel free answer any of these questions from your perspective and I'd sincerely appreciate that. Thank you! 🙏

Similar things happens in accounting and auditing world. Can u make a video about how engineers in corporate world interact with non engineers ( hr , accounting , admin etc ) . That would be fun

been struggling to perform since my last reorg thanks for this

The video every engineer needs to watch. The earlier, the better🙏🙏

As usual, spot on correct. I think there's a flipside to the first point though as some folks think certains tasks must absolutely be performed in a certain framework/library, though there are means of getting the task done. I have a leader right now who's general competence in a framework isn't good so he tells us we can't use it at all, despite it being designed for scale and flexibility. We inevitably and consistently run into issues where the leader doesn't understand why our product is so inflexible and requires rebuild for every potential use case. The poor trait is also overestimating your knowledge while underestimating other team members, especially when they have a great track record and are invested in a project outcome. My rule of thumb is if you order food at a 5 star restaurant, don't go into the kitchen and tell the chef how to make it.

Hi, it's me, the imcompetent engineer. I spent 5 weeks on a project that probably should have taken me 2, and the entire process was miserable, I'm losing face with my team and manager, and I've cried almost every moment the past couple days following a negative performance review. I feel like your video is close but you're quite far removed from us strugglers, and I don't think it's particularly helpful. I'm adding some feedback and always down to chat more. 1. I'm not sure why your first point is about tech debates. I would say this is more of a pet peeve / flaw perhaps than a trait of poor performers. There's a couple highly effective colleagues of mine who have this flaw, and they are staff level / knock out tasks easily. I did not relate to this one at all. 2. Second trait is pretty accurate, but I'd have gone into the process of asking for help, how it needs to be ongoing, how it's often difficult to identify blockers, or that you may think you're not blocked and progressing but you're actually spinning in circles. Also I didn't like the estimation portion of this section mainly because it discounts how hard estimation is, especially at junior/mid level, and the example I think wasn't ideal. Adding extra days to your estimation is fine if your estimation is wrong by a day or two, but what if it's wrong by a month? I think there's a deeper conversation around deadlines here. 3. I think there's a lot of accuracy to the trust issues thing, my main problem with it is it entirely removes responsibility from the team. It doesn't seem you have a thesis except 'increase your trust level', in other words, 'be one of the good ones'. Well, as one of the bad ones, I'm trying, maybe it would be easier if you could meet me halfway? Because I'm fucking miserable, no one on my team likes me, no one trusts me, what do you fucking expect me to do? Overall, I think your points are valid but they expose deeper problems in SWE culture, and people at the top should think more about improving it.

I completely agree with these

Happy thanksgiving Rahul! Thanks as always for sharing your personal experience with the rest of us. It’s of immense value! I also wanted to know if you could do a video on tactical usage of design patterns at FAANGs? How familiar are senior devs with design patterns and is it used in communication documents etc?

I liked this video. Although with the trivial piece, that sounds a little bit like getting into semantics 😄. I use trivial when I think it actually really does apply to something that should be straightforward and very quick to get done. Often to relay to product members though when they are concerned an ask will delay or add too much time to other pieces on the roadmap.

Great advice as always Rahul.

Thanks Rahul. I'd be curious where you come down on the idea of bad code or the flip side "best practices". It feels like these are used sometimes as passive aggressive cudgels by programmers discussing theory (where the discussion didn't go their way)--but I'm curious if there's a line where they are quantifiably useful and if you consider them a differentiator for a good/bad developer. Appreciate your channel, thank you as always. Happy Thanksgiving.

we need more contens like these.

Great video with great insights. Thank you . Every part teaches us something. Went though the entire video without skipping any part.

Engineering is a social activity. So for example claiming credit for something you didn't do will not earn you rewards within the community. That said, the true breakthrough efforts are often done by individuals working alone, that's why you have a chief architect. I hobby code but have helped engineers in my professional capacity when working at Silicon Valley (I retired in my 40s, and yes, there's life after retirement doing no work, lol, but that's maybe just me).

these animations are fire 🔥🔥

I have found that the most frustrating experience I had was with an engineer who simply refused to dive into anything and had a negative sense of ownership, always trying to get somebody else to take responsibility for stuff that clearly fell under his team's area of responsibility. I feel like I'm the complete opposite, where I've often spent time diving deep into code that I'm not anywhere near an owner of just to solve that issue for that common customer. I don't expect people to be like this and just look at everything regardless of their current scope, but the worst engineers in my opinion are those who actively try to work their way out of tasks that are clearly well within their scope. FAANG^

Interesting how you gauge people by their responses .. Thanks for those examples ..

I agree with most of them. But people constantly suggest other technical options also adds lots of value to the product. No doubt on the importance of making business impact, but I don't enjoy the attitude of rushing the timeline by compromising the quality, and growing tech debts. Like patching code here and there, made code base hard to maintain with the excuse of making business impact first. Nice way to put it, we look for win-win solution. Reality is, the developer needs to make tradeoffs. You are making trade offs from one perspective, should not judge other people making trade off from a different perspective as a poor-performing employee.

Really helpful!

True

@Rahul Pandey Regarding conditional timelines, I've also heard that this lowers your trust level in the eyes of people, if your estimates are conditional. They seem non-confident and make it harder for others to believe in what you say and your ability to deliver regardless of the situation. (Not that i believe in it, but this is what I have heard regarding conditional timelines which i gave)

Hi Rahul, excellent video and good, real information. However, I want you to explore and talk about any experience that you have with engineers who have developed a new mid or late career disability such as Parkinson’s disorder. What would you suggest should a star performance engineer suddenly finds oneself in a unexpected situation where the disability reduces the quality of the performance. I can discuss more with you if you are interested

Hey Rahul, some thoughts have been haunting my mind lately, ever since my last appraisal cycle. I had significantly helped my colleague to complete a research project, also because I am strongly inclined to problems. But my contribution in this project was overseen by my manager, also because colleague didn't share the credits to the management i deserved. So I was just accounted for my regular tasks in financial year, not properly for my knowledge and competency, rather discouraged that for my age i am earning good enough. I also sometimes feel that my manager has a soft corner for my colleague, and he brings him forward for tasks we do in team, when others have major contributions. So I feel discouraged to give my team more good projects as I feel credits won't be shared in a fair manner. How should I approach this in my organization, should i just get a new fair manager, or try to discuss this in growth talk, but i don't want to sound selfish and much vulnerable.

Hi Rahul, is jointaro available in India too ?

Good points, except conditioning estimates. Those sound like you are setting up yourself for failure and are looking for something to put the blame on even before starting. As a staff engineer you should make sure that the story is deliverable as it own. And if you have concerns that the API not being ready can cause problems, just focused on getting the API ready first. Conditioning estimates should get minus points on your trust level bar.

Omg the number of developers arguing about why need to migrate an entire codebase to another JS framework instead of the one currently used just because they read an article or saw a video. Grow up! They're basically the same.

good talk ! but what is point of adding stock videos ?

Why become a SDE when you can do MBA & become the boss.

Hi Rahul, I was going to ask at Facebook and the other companies you’ve been at, have you ever had to use Data Structures on the actual job itself?

Makes me realise I had all the qualities of the worst performing engineer at certain point in my career.

Rahul really blue balled by making us join taro for other half of this video so not gonna like the video ever again assuming it will be in same lowly format😉

Do MBA

Imagine if you worked with Rahul at meta and you have three traits 😅

Im no engineer, but 'conditioning' just sounds like 'covering your ass'. Not delivering.

Agile sucks in general, don't use sprints

Typical meta way of doing things; code first, design later; that's why it is a failed company.

I thought most of the engineers at FAAMG were poor or mediocre, not just some of them

disliked for the amount of times you used the title "engineer" to describe nitwits who know syntax of a programming language

*꧁ 🌈‼️ ꧂*