A B
C D
E F
If you ask me a question like this, I'm going to judge your company pretty harshly.
(disclaimer: all of this is notwithstanding the fact that some people's brains shut down specifically during interviews/places where they feel under pressure, which I have nothing but sympathy for. Afaik that's an unsolved problem with coding interviews. I would always try to lower their stress but it is not a sure thing.)
Having said this, I'd never hire a person that's not able to reason about this. Actually writing the implementation is really secondary
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.
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.
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.
What percentage of engineers are working on truly hard technical problems?
I can only speak from experience but the vast majority of us are doing the same shit with a different name signing the checks.
The world doesn't need millions of brilliant engineers. It needs construction workers that can assemble materials.
I am fatigued by every tech bro in the industry that thinks they need to find the next genius with their ridiculous hiring process.
I code, sure, but I will never come up with a custom solution for any non trivial problem. I know where to find appropriate solutions (the best ones) because I’m aware of what I don’t know (I read a lot of tech books). You cannot test this in the classic tech interview (because I would googling 75% of the time).
The final result is: you want good code or not? How I come up with it should be secondary.