It's Hard Performing At FAANG - How Software Engineers Struggle At Big Tech

I've been an engineer for a long time sometimes I look back at my work and I feel extremely proud and other times I look back and I cringe at my work or the work of the engineers I've interacted with it turns out that even at a company like Facebook where I work for almost five years as a staff engineer and a manager you can still encounter some pretty awful engineers in this video I want to share three traits of the worst performing software engineers and I also want to share at the end my biggest pet peeve when it comes to technical discussions with other Engineers trait number one is debating technology or semantics that don't actually matter to the delivery of the project a business hires a software engineer for business impact and that's what actually matters what I found for poor performing Engineers is that they will often become a stickler for things that don't really matter things like what linter to use or what version of a library to use these Engineers talk for a long time about different architectures and the pros and cons of different approaches but they don't actually put their hands on the keyboard everything is nice and fun on the Whiteboard but things actually go wrong when you start to implement them Donald knuth one of the most famous computer scientists of all time says it really well beware of bug from the above code I have only proved it correct not tried it it is frankly much easier to stay in the intellectual world of boxes and diagrams and arrows because you can literally do hand waving to address issues problems start to emerge when you implement things and that's where you separate good from bad developers this is the same advice I give to people who are learning to code for the first time the best way to become a developer and the best way to succeed as a developer is to get things done don't stay stuck in the world of theory the second trait of poor performing Engineers is not communicating effectively or not communicating at all the way this will typically manifest is that as an engineer you'll get assign some tasks during a Sprint you'll work two weeks on it and get stuck so you'll come back to the next Sprint planning and only then do you reveal that you didn't get anything done and now you'd publicly admit what happened and that will cause serious reputational damage Engineers think that if they're behind it's better to stay quiet so they have time to somehow magically catch up or they think that no one will notice that they're behind on their work that strategy might work for a couple days or maybe a couple weeks but it almost always ends up firing the amount of delay in the amount of stress that happens in a project almost inevitably will go up it doesn't go down and so it is better to just reveal bad news early it is actually okay to have bad news or blockers but the main thing is that it shouldn't be a surprise and so if you do encounter something that is a problem you should tell the relevant people and then broadcast it as widely as possible to anyone who might be interested one tactic here to make your life easier is to not put yourself in an impossible situation at the time of project planning you should always condition how long you think a project will take you would never hear a competent engineer say this will take me 19 days to finish a good engineer would always condition it and they would say assuming that the API works the way we expect it to I don't get pulled into any firefighting then I think this project will take me between 18 and 20 days to finish software engineering is about working with abstractions which means that you will never have complete information and that means you should always provide some leeway some Gap in your estimate to accommodate for things that might happen unexpectedly by the way if you want to learn how the best Engineers communicate we have literally thousands of high quality questions and answers available at the start of my building Taro joint taro.com and we also have Taro premium sessions where we have directors managers tech leads come in and talk about a particular promotion or project that's a really high quality way to interact with these people who have achieved something great in their career and it's available at jointaro.com I'll leave a link for it in the description the third and final trait of the poorest performing software Engineers is that they make extravagant claims about what they can get done what happens that you come into a company is that you're going to start at what I would call Trust level 50. so you have trust on a scale of zero to 100 100 means I trust you completely zero because I don't trust you at all you're coming in at 50. and the actions you take the behaviors you show me will then dictate whether your trust score in my eyes goes up or down and so there are two things that really hurt your trust score and make you a poor performing engineer the first is that you claim credit for things you didn't actually do if you're at a medium or large tech company any project you work on will almost certainly be a team effort and so you might be a tech lead or a major contributor on a project but my trust alarm starts going off if you start claiming for the whole thing the dangerous thing here is that if people start to suspect that you exaggerate your contributions they won't want to work with you and if you don't have good people to work with then your ability to climb the career ladder and have the impact of the company is severely limited and so you should get into the habit of publicly and privately acknowledging and thinking the people who you work with on any project the second way that your trust score goes from 50 to something a lot lower than that is you talk a big game and you don't deliver you might say something like oh I'll for sure get that project done next week it's actually pretty trivial and that is actually the biggest pet peeve of mine when I talk to Engineers is when an engineer calls something trivial because half the time the thing they're talking about is not trivial and the other half the time saying something is Trivial really hurts the conversation it hurts the ability for people on the team to actually have a productive conversation and ask questions about it I almost never say that something is Trivial just because I feel like that word is quite charged and instead I would always say I think it should be straightforward in general you should under promise and over deliver and when you are giving an estimate for a project you should condition it like we talked about before so you shouldn't say oh I'll for sure get the project done instead you would say oh I can for sure get the project done by next week assuming that the following conditions are true and you can go on and list what you think are the biggest risks of that project this video was about the traits of the worst performing Engineers I've worked with if you want the opposite and you want to hear the traits of the best performing Engineers I'll leave a link for that video somewhere down here if you have any feedback I'd love to hear from you and also tell me what other videos you want to see in the future thanks for watching and I'll see you in the next one

Channel: Rahul Pandey

Views: 45,275

Keywords: development, rahulpandey, rahul, pandey, teach, stanford, techcareergrowth, faang, 3 Traits of the Worst FAANG Software Engineers, bad software engineers, poor performing software engineers, poor performance at work, poor performance, pip, poor pip, communication skills, worst devs, engineer struggle

Id: S2iHnFtrHKQ

Length: 5min 36sec (336 seconds)

Published: Thu Nov 24 2022