There are many roads; only you can choose the one to take
If you believe the tech hiring process in your company or the industry as a whole is "good enough," this post is for you.
Lewis Carroll wrote in Alice in Wonderland: "if you don’t know where you are going any road can take you there." As an addition to that, if you don't know where you are going, you'll take the road everyone has already been.
There are common patterns of how companies hire these days. Some of those patterns may not bring the result they expect. In this post, I'll talk about the most common problems and solutions to the role advertising of technical hiring processes.
If you don’t know where you are going, any road can take you there, to the same place everyone else has already been.
Cargo Cult Programming is when you add code to a project without really understanding it. An easy way to identify Cargo Cult Programming is when someone has an excessive obsession for frameworks. Frameworks dictate how you should design your software inside a predefined frame. However, it's rare for a project to fit an arbitrary frame. Most of the time, a software project requires a different architecture and a different design to evolve sustainably.
Avoid hiring people with ample experience in frameworks and little experience in software design. If you don't, you'll end up with every project in your company using those frameworks, even if they're not the best fit.
If your intention is to reduce long term costs in the software development process and achieve a great outcome, instead of advertising in job boards for people who know a specific framework or technology like "Angular", ".NET", "React", "Redux" or "front-end", advertise roles to look for fundamental skills like "domain oriented thinking", "software design" or "functional programming".
Developers with fundamental skills are more expensive to hire and take more time to become familiar with the technology stack. A few years ago, Gitlab had a dilemma where they considered hiring non-Ruby developers, only to fall back and hire for skills based on the technology to “err on the side of caution.”
However, one developer with fundamental skills creates more sustainable value over time than multiple framework or technology developers.
Hiring developers with fundamental skills is hard. It's a challenging move. You need the courage to follow the road nobody else has gone before.
Hire people with fundamental skills, not framework or technology skills
There was this company which had 34 employees. That same company also had 34 roles, which means every person in the organization had a different title. The titles ranged from "Express Developer" and "JavaScript Ninja" to "DevOps Engineer" and "API Influencer."
Instead of creating crazy role names and spend hours bikeshedding on which name each role should be, prefer to call everyone a "developer" after they join the company. After all, everyone is responsible for helping developing software, regardless of their previous position or skills.
When advertising a role, though, you might need to specify meaningful titles; otherwise, the right people may never find it through the market chaos. However, when advertising the role, specify in the description the company needs at the moment, not the technical skills you believe the company needs. For example, a candidate with "proficiency in coaching teams" or a candidate with "experience designing systems in the financial domain" over "Front-End developer" or "Java Developer."
An exception to "technology advertising" is when the company need someone urgently to maintain a legacy system. Sometimes the only person who could maintain the system has already left the company, and there's no work around that.
Advertise a role for the technical characteristics you're looking for, not the technical skills.
It's crucial to avoid advertising the technical skills you believe the company needs. A candidate might not be familiar with a given technology, yet they're able to come up with better solutions for the existing problems of the company, or they're able to see problems nobody else can see.
A good example is when a company comes up with the plan to build a mobile version of their web product. The website is a heavy JavaScript-based front-end with business logic written in React and Redux. In this circumstance, it's a widespread thought to advertise roles for iOS/Android developers. That makes sense.
If you want to build an iOS or Android app of some degree of sophistication or complexity, you want to hire someone that has been there before. However, you're already assuming you need someone to write iOS or Android code; what if that's not necessary?
Instead of advertising the role for iOS/Android developers, you can advertise that you need a "developer to build a mobile version of an existing web product." If you do that, you might bring developers who understand the fundamentals behind Jasonette, for example, and don't need to write a single line of Java or Objective C to reuse the front-end business logic in a mobile application. That can be orders of magnitude more cost effective than building it all from scratch.
You probably don't know everything about HTTP protocol design, Evolvable APIs, Jasonette, Functional Programming, Event Sourcing or Event-Driven Design; so stop pretending you know the specific skills the project need.
It's better to have diversity in a project: people who are not like you. If people have a different skill set, different ways of thinking, and different experiences, you’re more likely to achieve a better outcome.
If you only advertise the technologies you know, you'll Trump diversity and end up with developers who are like you, not better.
Hiring in tech is hard and expensive.
Most programmers optimize their skills for technologies and frameworks. Hiring for fundamental skills is the best way to break the cycle and bring more innovation, as long as you're willing to pay some significant upfront cost.
If you hire people for the kind of skills you have, you'll only end up with those who can't add meaningful value to you or the company. Give up on the egocentric thought that you know which practice or technology the company needs. There's someone out there who knows the solution for the problems you don't, and that person won't be like you.
If you don't know the road you're going, and you need help, make sure you communicate that. Advertise the problem, not the technology. Otherwise, you'll choose the road that will take you to where everyone has already been.
Taking that road is the same as moving nowhere.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook, or Github.
Thanks to Cleriston Bernardes and Ian Tinsley for their insightful inputs to this post.
Wanna chat in person? You can find me in the Sydney Software Crafters meetup.
Top comments (0)