| I strongly disagree with the premise here. Anyone who hires based on this mentality will be compromising significantly on their team's performance. Within a specific part of the stack, there is a vast quantity of micro-skills that a developer needs to know. The language syntax, the language built-ins, the language ecosystem, best practices, canonical designs, the debugging tools, other development tools, etc. Many things are Google-able, but searching for answers to problems is like making a network call. It's WAY faster if you can pull from cache. My specific context is frontend development. I would never hire a frontend developer who cannot clearly demonstrate their skills in the domain. There are ~140 HTML tags, each with different attributes and behaviors. There are ~200 CSS attributes with 2-10 meaningfully different values each. JavaScript as a language is moderately challenging for some developers and there are many hundreds of built-in methods, behaviors and functions to know. I've seen time and time again the differences between a talented frontend engineer and a senior non-frontend engineer trying to solve the same problems. Given a description of a problem, an experienced FE dev can quickly identify the problem using dev tools and make the necessary changes to solve the problem. It might take them 20 minutes. The "senior" non-FE engineer might spend a full day searching, debugging, experimenting and learning. By the end of the day they might be proficient at Flexbox layouts and able to solve the same problem in 2 hours next time. But depending on your business, can you afford to hire an engineer who takes 10x longer to do things, with the hope that after 6-12 months they might only be taking 2x longer to do things? And don't get me started on architecture and design sense. How can you expect a senior to make wise decisions in a domain they know little about? Nearly every time I've seen mostly-BE engineers build FE projects, they create bloated, complex and over-engineered designs that are hard to develop and maintain. There's a thousand little details that you learn over the years when working in a specific domain. For me, I hire based on demonstrated expertise in specific domains. When I do that, my teams move fast and effectively. It can be hard to hire the specific skills you need, but I've found it to be far more important than anything else. |