Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a soli

Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a solid simpler designs. Always on projects I was ether fully or partly coding. I would try to get agreement on the people it would effect and nearly always rejected. Then everything I pointed out would go wrong but: "This was completely unexpected" "really interesting problem..." At one point our ($100 million USD) security monitor product was down for a month until a customer noticed on our behalf and flipped out. Due to a several problems I had repeatedly pointed out (and fixing any one of them would of prevent it). If I full sailed ahead then I would get alot of grudges. Culminating in "I found this bug and its your fault" (which was nearly always end up being because that very persons regression) or some other baseless attacks during meetings. It was tiring. My managers always liked me however. shrug In turns out almost every time my peers and betters actually never understood our discussions (but of course it would look bad if they actually asked questions). As my career went on I would start forcefully asking questions to confirm their understanding. And indeed this was nearly always the case. So I started making really nice layouts and explanations. And this got me a bit further. But if someone is missing years of required background you can't teach them in a realistic amount of time. I am careful about who I work with now. I establish during interviews that your future team (or teammate) has the needed technical capacity for the problem set they have relative to their position. I think about the problem set the day before and discuss with them how they are solving it and it has saved me many a time. People are often critical of domain specific problems when given in an interview but I always start there and work my way down to the applicable fundamentals. The higher up they can answer the more senior. It also avoids the problem of asking out of scope questions/coding problems. The structure (who is doing what, seniority, and how both are established) should always be crystal clear and changeable. Something to be aware of are non-formal structure in an org. Like a junior dev. on random team x has the CEO's ear. These are much harder to find and deal with. The worst problems an org can have IMO.