The software industry has been growing significantly for the last few decades, and this trend seems to only be accelerating.
Due to this fast growth, there has been an ever-increasing demand for software engineers and, since there are not enough developers to meet the demand, many companies often fail to cover their open positions. But, is it also possible that we are looking at the wrong skills when hiring?
Most job descriptions simply list a set of technologies as the necessary “profile” for the open position. However… Aren’t there other skills that could have a higher impact on developer’s success?
Are we looking at the right skills?
Beyond languages and frameworks
So, despite the shortage of software engineers, we keep seeing, with dismay, that many companies keep restricting their opening positions to people with experience in very specific sets of technologies. Often stating that “X years of experience in <new framework Y>” is a key requirement.
Have you thought that it’s very likely that you will not be using <new framework Y> in two years? When that happens, which would be the skills your team will need to keep being productive?
It’s great to keep an eye on new technologies, of course, as they might bring relevant innovations to our businesses; but focusing mostly on trendy frameworks or on our current tech stack, when hiring, has negative impacts in the long-run and, as a general practice, is very harmful to our industry. We need to move forward. This focus on languages and frameworks hints there is a fundamental misunderstanding in what makes a great software developer.
The software industry is evolving constantly
Granted, if you need an urgent short-term solution for a framework-specific problem, you may want to find someone that knows it deeply. However, more often than not, those short-term needs hide long-term problems in a company.
Developing software is often about making processes more eficient and providing solutions to existing challenges. Also, we now know that due to the fast pace at which both technology and our needs evolve, software development is a continuous process. In most cases software products don’t have an end. We add new features, teams change, companies pivot in their strategy, new technologies bring new opportunities for enhancements, consumer demands change… And we just keep evolving our digital products.
This constant innovation brings constant changes, both in business and in technology. Our products change, as well as the languages, frameworks, tools and devices we use.
Fortunately, key skills are evergreen
Isn’t there “evergreen” technical knowledge that can be portable across frameworks? Aren’t “soft” skills vital? How about code readability, learning-ability and communication skills? Wouldn’t those skills be more valuable than framework-specific knowledge in this ever-evolving world?
It’s not just about technology
There are skills that often have a higher impact on success than technical knowledge. The so-called “soft” skills (or core skills) are crucial for any software developer: being able to communicate properly (via email, chat or face-to-face), sharing knowledge with coworkers, engaging in constructive discussions…
Every day more relevant voices in the industry are raising concerns about this. Sam Altman recently shared his hiring priorities: values first, aptitude second, specific skills third. Buffer is also a very innovative company in this area, with a culture-fit-based hiring process, where “soft” skills play a key role.
But there is also technical evergreen knowledge
Despite the constant change of technology, the technical principles and best practices that also make a software engineer great, are portable across frameworks.
This is a heated discussion. It is indeed difficult to name “fundamentals” or even to draw a line separating technologies that are evergreen from those that are just temporary, as can be seen in the dicussion between Zach Leatherman and Laurie Voss.
However, when I refer to “evergreen” technical knowledge, I mean principles, such as OOP and SOLID; data structures, SCM, Clean Code guidelines or DevOps practices.
The repository of “evergreen” knowledge to the rescue
So, since 1) nowadays most opennings still focus only on technologies and 2) coming up with the “evergreen” knowledge that we could use for hiring interviews is not trivial, I have gone ahead and created this GitHub repository, which goal is to serve as a pool of ideas to condut a fair assessment of skilled software developers / engineers.
As stated in the repository, the purpose of this work is to serve as an alternative resource for conducting hiring interviews of software developers / engineers. It focuses on software development best practices, cross-framework principles and other portable skills; instead of the usual focus on specific languages, frameworks and trends, which tend to quickly become outdated and often don’t reflect the real value software developers / engineers bring to the organization.
It is also worth mentioning that it is a work in progress, so important knowledge might be missing, existing bullets can probably be improved and better grouping strategies could be found. For those reasons, any contributions (i.e. PRs) are welcome. Please feel free to propose changes following the contributing guideline.
Be the change you want to see in the world
We all have a role in moving our industry forward. As a manager, think twice when designing the description for your new open position and look for ideas beyond a list of technologies; as an individual contributor, when you are asked about the skills your next coworker should have, ask for principles and best-practices; as a candidate, highlight your “evergreen” knowledge and its importance. We owe it to the profession we love.
I have created the evergreen skills repository as my two cents’ contribution to this discussion. As I wrote before, it is a work in progress, which means there is a lot of room for improvement. I have added contributing guidelines and all constructive PRs are welcome… So I look forward to you contributions!
2018, Dec 30: Major rewrites to the article. First “public” version.
2018, Dec 29: Original draft published.