This is usually not a consideration and has not really been there for decades. What many forget is that people who are speciallists in the area thay are recruiting for are not necessarily the best candidates for the actually position.

Sometimes (many times) if you can get someone who is more of a generalist and is capable of diving in to gain the necessary skills is far more valuable. They are quite often the first to be discarded from the interview process.

Many of the psoitions I have participated in required handling new tasks that were not within the broad scope of what the position was expected to handle. Yet, having the attitude of "let us see what is needed", meant that I was bale to be functionally more effective in that position, including being the "go to" person for those who needed problems to be solved that their normal IT groups would not handle.

I have found too many "code guru's" to not be capable of thinking outside of the box whaen it is necessary. You don't have to be a "brilliant coder" but more of a person who can develop an understanding of the "problem space" of those having the problems that require solutions.

This is what we've resigned ourselves to, but it's very expensive. We're building crud apps, not doing cutting edge research, so I assumed we would be able to find someone that is already up to speed on the language and frameworks. You also have to factor in the cost of senior developer time spent coaching, the lost productivity, and the code quality suffering in the meantime.

You might be shooting yourself in the foot by having not picking an ecosystem that better supports your business case. No one I know who's good at React+Redux would pick a CRUD app as the domain they'd like to exercise those skills in.

The app in question is used by retail employees at hundreds of locations to manage inventory. It runs on a tablet, has to work offline, and has a very dynamic UI that has to keep thousands of complex relational entities in local state, and perform aggregate functions on them in real time. It's still a CRUD app, but it's very much the use case for a SPA.

> We're building crud apps

Perhaps you shouldn't be using complicated faddish framework then?

Was just thinking that too. Many folks like to complain about the quality of "the help," but don't look in the mirror.