As the problems become harder, you can’t just Google for solutions. Really great engineers often build things that nobody has ever built before — or at least not documented how they built it publicly. If you don’t have fluency in the fundamentals, you won’t be able to piece together the parts that you need to build novel systems.
Second, part of hiring junior engineers is evaluating their growth prospects — e.g. new grads are often completely unproductive for up to a year, and firms make large investments when hiring them (maybe up to $200,000 in mentorship and wages). People with the attitude “I don’t need to learn/understand things, I can just Google them” are unlikely (IMO) to reach that level of seniority.
In my experience, it's very rare that you're in a job that requires you to come up with a solution to a problem no one has ever dealt with before. Custom solutions are often a sign the engineers in question didn't do the appropriate research to find the standard solution for the problem.
I've been a software developer for 10 years, and I've never worked on a problem that someone else hadn't come up with a solution for somewhere. And if they haven't, alarm bells go off as to why I'm the first to do this, and where down the pipeline did I deviate so horrifically from the norm.
I strongly agree with this. I worked on low level algorithms in bioinformatics circa 2010. Writing mapping algorithms and variant detection in C/C++. Most/all of what we did was adapt known compression and database algorithms. The "best" aligner is still BWA (Burrows-Wheeler Aligner), which uses the Burrows-Wheeler Transform, popular in a lot of compression utilities.
Could you please give a firsthand account of an instance when a great engineer built a novel solution? I feel NIH syndrome is way more common cause for building things from the ground up
I've seen it at least ~10ish times in my pretty short career. I think you're maybe imagining someone building, like, "Linux from scratch". Novel solutions don't have to be that big; they just have to be novel.
Someone I worked with once went off on their own and implemented a test framework that solved a lot of the problems we've been having. They could have just written tests the normal way; they did it a different way; it was great. Someone else made a debugging tool that hooked into Python's introspection abilities and made flame graphs of the stack traces. Not exactly groundbreaking science but it was entirely "innovative" in the sense that no one expected or wanted that tool, yet it solved a real issue. Someone else made a JS library that abstracted out the problem of organizing these dynamic workflows on an internal-facing took. Small, but novel, and it organized the ideas in a way that made it possible to build on the abstractions later. For my part we had this chunk of business logic that was a pain to debug and I had the thought to factor it out into a standalone library that was completely testable at the interface. Not groundbreaking, but no one had thought to do it and it obsoleted the issues from before immediately. Etc.
If your job is anything more complicated than "feature implementation", there are chances for innovation left and right, and good engineers see and pursue them.
I’ve come up with some of the core solutions in my org to solve massive big data problems and had to depend on intuition and theory instead of the web. I still failed a merge sort whiteboard challenge in an interview. Some people just can’t deal with these inane questions in an artificial environment.
Second, part of hiring junior engineers is evaluating their growth prospects — e.g. new grads are often completely unproductive for up to a year, and firms make large investments when hiring them (maybe up to $200,000 in mentorship and wages). People with the attitude “I don’t need to learn/understand things, I can just Google them” are unlikely (IMO) to reach that level of seniority.