* The ridiculous nosql fad that led to a tsunami of databases with horribly invalid data because constraints aren't sexy.
* The ridiculous academic fetish that triggered the leetcode phenomenon and led to a tsunami of developers who can code a quicksort in their sleep but still don't have the first clue about structuring code or data properly.
I don't understand this belief. Where does it come from? Junior engineers don't have the first clue about structuring code or data properly, whereas senior engineers do. Google's belief (probably) is that anyone able to quicksort in their sleep is either already good at the other stuff too, or is smart enough to pick it up over time. If they're wrong, companies will outhire and outcompete them eventually.
Exactly. This belief that the two correlate closely enough that you can supplant one kind of test (physically writing code, discussing it and architecting it) with another (leetcode) is massively, horre ndously wrong and damaging. The two do not correlate well. They correlate very badly.
Do you have any evidence? It seems to be working rather well for the companies that follow these practices.
You may speak derisively of "leetcoding" but it does demonstrate persistence, grit, speed of thought, and/or the ability to learn something difficult (algorithms, data structures, competition-style programming). It's not crazy to posit that people who are able to learn one hard thing well will probably also learn other hard things well. In fact, it should be the other way around. Why in the world would someone hardworking and intelligent not be able to pick up new skills?
To me it's absolutely insane that being good at architecture and good at algorithms and data structures are seen as mutually exclusive skills. They're not skiing and barbecuing.
Now I'll concede that Leetcode-style interviews are a terrible and stupid way for smaller companies to hire, because they don't have the candidate pipeline of a Google or FB or Amazon. But it isn't a wrong approach in and of itself. If that's true, someone should be making bank by hiring all the scores of talented devs that the megacorps reject for not being good "Leetcoders".
Plus, surely you're aware that the megacorps also have system-design interviews for all but entry-level candidates? That's where you're asked about architecture, tradeoffs, and high-level design decisions.
And while hacking the programming interview does demonstrate grit and persistence, it doesn't demonstrate actual programming skills. The worst part though is that it generates a mindset that "good programming skills" means "even more advanced leetcode".
I don't begrudge these people. A set of absurd incentives was put in place and they reacted to them accordingly.
It isn't good for Google either. The hires that came after this philosophy have achieved very little of note. The vast majority of post Gmail abject project failures have been built in house while the successes (maps, android) were bought.
Cool, so anecdotes, not actual data.
> it doesn't demonstrate actual programming skills.
It demonstrates ability to learn difficult things. You still haven't answered why junior devs hired this way are somehow incapable of learning good architectural practices. You also didn't address the fact that most of these companies also interview senior hires for system design and architecture.
> The hires that came after this philosophy have achieved very little of note
Photos. Chrome. Brain. Tensorflow. Kubernetes. Even Android didn't take off until 6 years after its acquisition. I don't have the time to research more but you get the idea.
The first thing I learned out of school was the developer's triangle. The triangle has three sides: fast, quality, and cheap. From the outside no matter where you stand you can only see three sides. If you want cheap its not going to be both fast and excellent quality. If you want fast its not going to be both cheap and great quality. Finally, if you want excellent quality its not going to be both fast and cheap.
It takes years for a developer to move from beginning through proficiency towards mastery. If you hire junior developers assume you are sacrificing both speed and quality for cheap. If you fail to develop your juniors your code will not achieve quality and your people will not become faster. Frameworks, or any layers of unnecessary abstraction, are not a replacement for training and experience. While this is mostly true for all platforms/technologies it is especially true for web technologies where everything is defined against the same set of standards that work the same cross browser and cross OS.
If your leadership were interested in product quality first then developers would be allowed to fail internally so that they could learn. You learn a lot from failure. It is part of growing, innovation, and making better product decisions. You separate the product from that learning through test automation, continuous integration, performance metrics, and automated complexity analysis.
No argument there. You know not everyone gets to work under a 10x leader. Probably the median leader in any sector is -x, because the skillset required to raise money is not necessarily the skillset required to lead.
> The triangle has three sides: fast, quality, and cheap
I think that should not be a universal rule. You can leverage open-source solutions to cheat more than one of those sides, with a little bit of expertise, or by stumbling on the right framework by accident.
Dependency management, or the lack of, is one of those "be careful what you wish for" type scenarios. At my current team we perform a lot of manual copy/pasting of directories they many contain hundreds of not managed dependencies. I really think it would be substantially faster to burn it all down and do it right with few, or no, dependencies and an emphasis on automation at every level. That perceived speed increase takes into account the costs and lost time for reinventing many wheels.
I think that's a reaction against how it's also fashionable to worship whatever Google does. And just cargo culting google practices can be damaging, at least from a selfish perspective. I lose developer hours because our entire 13-person company's (with 2.5-ish developers but 7 years worth of code) is hosted in a monorepo. I've now worked at two out of two companies that have gotten stuck because they built with an Angular stack and management refuses to switch to a stack that I can reliably hire or train juniors out of a bootcamp for, etc.