Over the last few months, approximately a bit over half a year, I’ve been heavily involved in engineering recruiting on the hiring side. From that, I’ve been able to get a good glimpse into the talent market, hiring standards, and the disconnects in between. Looking more into the talent market, for now, I think there is a big problem with how we’re preparing engineers. This is a framework hindrance!
This is a problem worth noting for a lot of reasons, especially with how much society is growingly becoming dependent on the internet and software applications. At this point, it’s safe to say it’s the backbone of society. With that in mind, in this article, we’ll be defining framework hindrance, the problems it creates, and ways to address them going forward.
What Is Framework Hindrance
Framework hindrance, as I like to define it in summary, is the over-reliance on a specific approach to software engineering. This could be a framework of thought, technology, or ideology.
How It’s Created
So much of the industry is geared toward pushing people into two camps: comp sci principled and framework specialist. This creates a huge problem in properly preparing perspective engineers for real-world engineering positions. By and large, only having people meet at the intersection of being heavily specialized and lacking the practical engineering qualities we need!
How It Impacts Hiring
Well, candidates forced into certain ways of thinking can only optimally perform inside those silos. With interviews at any level below the principal level in a particular discipline, organizations need candidates that have a solid understanding of problem-solving and some familiarity with the tools they use. With the two camps outlined above, this leads to 1 of 2 situations. The comp sci principled engineer will likely show problem-solving skills but lack an understanding of frameworks or higher-level architecture of code. The framework literate candidate will show affinity, but when removed from tools they’re accustomed to, we’ll freeze up.
Ways To Reduce It
Focus More On Ecosystem Teaching
This really is lost on most engineers. The things we build are less about performing 100% well independently. The real goal is to build things that work well with other aspects and pieces of code, while still maintaining their own identity and purpose.
Understanding Frameworks Come and Go
No framework is ever here to last, even though things like React have been here for a long time! There will always be something new and shiny that’ll replace what you’re accustomed to. So putting all your efforts into mastering one tool, will always eventually make you look foolish. I mean, think about it. How does the guy that specializes in Backbone or Ember.js feel right now?
Be More Upfront
I think another great thing we can do, but on the hiring side, is to be more upfront about what we’re looking for. It’s crazy to expect an engineer hired to be doing one thing when we bring them on well, while we’re testing them in something completely different. On top of that, what we’re testing them on really doesn’t make sense and would never be allowed in a production environment.