Looking for software developers, engineers and DevOps is a challenge for every company. But why is that? And what can employers do to find the talent they need for their domain?
A past history
At the end of 2017, I was hired by Boxine GmbH as Head of Cloud & Operations. The producers of the Toniebox are a technical company, but in the first years, the startup worked exclusively with partners from the tech sector to bring the product to market as quickly as possible. At the time of my recruitment, the company had about 40 employees, including 0 IT professionals.
My job: Internalize software development, migrate technologies (cloud and hardware production) and build a developer team and IT team. And as quickly as possible.
An undertaking that can take years for a company to complete. Even our technology partners advised against the project and pointed out the lousy market for employers. IT specialists, in particular, are in high demand. But there are not that much on the market. Nevertheless, I succeeded in doing the trick. With the help of my colleagues, a few tips and tricks and outside advice, we were able to set up a strong team in a concise time. Within six months I could scale from 0 developers to 3 developers. Within 12 months we were five developers, 2 DevOps, 1 System Operator and 1 PO.
I want to tell you what we did and how.
The key question: Why do we hire?
At first, the question seems very banal, as it questions the obvious. But is it so obvious why a specific specialist should be hired right now?
What problem should the new employee solve?
The first objective is to determine the need for staff qualitatively. The aim is to determine what is being sought. It is not easy to decide on this on your own, which is why the exchange with colleagues, superiors and HR is entirely worthwhile. Because as a department manager you may have recognised a problem for yourself, which means: “I don’t have enough people”. But it is often the case that problems can be solved in different ways because problems are also perceived differently. An exchange with the involved people should ensure that everyone has the same (or at most similar) picture of the situation and understands why the question of more staff arises at all.
The following questions are sample questions that can be asked in such an exchange (I like to use them):
- What does our current team look like? - What is the strategic plan for the next 12 months? - What would the core tasks of the new employee look like? - Would the new employee contributions to the relief of the team? - Which departments will the new employee have to correspond with? - Are some or all of the tasks only seasonal in nature? - Is a full-time position the right employment model? - What alternatives are there to solve the existing problem? - What does the payroll area look like?
The knowledge gained from the discussions should now provide an excellent overview of the actual demand. Also, there are already detailed requirements for the new employee. Summarised in prose, this information offers a perfect template for a job description.
But the exercise has even more intentions.
A vacancy should be causally justifiable not only in front of the applicant but also in front of yourself. Most applicants notice whether a job advertisement was written out only pro forma, to “park” staff. Applicants also feel whether the company needs a new force and expertise to solve concrete problems. This means that the company should have a specific reason why it needs to advertise the position and be aware of it. Enlargement of the team? More projects? Use of new technology? What should be avoided is that talents are searched for and hired without being able to solve a concrete problem in the entrepreneurial organisation. Directly hiring for the sake of hiring is expensive for the company and in case of doubt frustrating for the new employee.
A second reason is that IT specialists do not only apply to companies, but companies instead apply to IT specialists. The fact that one should accept as an employer to become realistically competitive on the market. Because the market situation is so good, many IT professionals are looking for jobs that either make sense or that support and challenge them technically. A clear statement, which tells the applicant why the company is looking for specialists in this area, also gives an outlook on the upcoming challenge and raises a certain expectation.
Last, but not least, everybody was picked up by the process. Everyone on the team now knows what is going on and why new colleagues are being sought. In this way wrong suggestions can be avoided (e.g. the produced output is not enough). I even had a case where an employee thought the new applicant would replace him. Cases like this must be avoided at all costs.
The right title
Since the requirements for the new employee are now clear, it is time to think about a title.
Of course, it also depends on how the company is positioned. Startups, medium-sized companies and corporate groups have to be evaluated differently. Especially with startups, it’s a good idea not to rate titles too highly. But there is a great article by Marcela, CEO and Co-Founder of Hello Alfred. A generic model, which can be assigned to several people at first, often avoids many problems.
Generic titles like “Software Engineer” or “Software Developer” are of course okay. A more specific presentation, however, increases the likelihood of being found by technical experts and is more recommended for companies with larger development teams and more specific roles. So if you are looking for a backend developer, the title can be “Backend Developer”. If even the core technology is known, the title may also be “Python Backend Developer” for example. When searching and researching applications, the probability of being found is now higher. Often, IT professionals search for keywords in the title, which they use to decide whether or not to click on the advertisement.
Avoid terms like “guru” or “hacker”. Some time ago I even received a letter from a recruiter looking for a “Lucky ‘Django’ Luck”, one that “develops faster than its shadow”. That’s not professional and doesn’t attract IT professionals.
The right job advertisement
Each industry has its own Dos and Dont’s that describe what a job advertisement should look like. The same goes for IT.
A job advertisement should explain as succinctly as possible what the job is about. Short and concise and without gimmicks. Some companies like to point out that they can also celebrate well or organise a football championship every week. That’s great but ultimately irrelevant.
For the technical part, we have already created a template. ;)
A list, which calls the hard requirements to the applicant, is well-known and a reasonable means. It helps the applicant to evaluate how well the applicant fits the job. A list of technologies, for example, helps with orientation. How concretely these are called is a very individual matter.
The Joel test
Joel Spolsky, CEO of Stack Exchange Network and co-founder of Trello, published his Joel test in August 2000. The goal was to have a simple way to measure the quality of software teams. The Joel test, consisting of 12 simple questions answered with “Yes” or “No”, has become very popular and still has great relevance today. With StackOverflow, for example, you can fill out the Joel test directly while describing your job advertisement. It’s a fixed component.
In 2012 Sven updated and modernised the 12 questions of the Joel test in his Blog svenpet.com (https://svenpet.com/2012/01/09/neue-joel-test-12-schritte-besseren-code/). I think the update makes a lot of sense, which is why I like to refer to it. These are as follows (I changed the questions a little bit and took out the direct address).
- Can builds, artifacts and deployments be created in one step?
- Is a build created automatically after each check-in?
- Are metrics collected about the code regularly and are they evaluated?
- Is the issue tracker connected to the build and version control systems?
- Are bugs handled before features are implemented?
- Is any form of software functionality written down and aligned with stakeholders before implementation?
- Do the programmers have quiet working conditions?
- Are the best tools used that can be used or purchased?
- Are there employees working full-time on testing?
- Do applicants have to write source code during the application phase?
- Are usability tests conducted with end users?
- Is each line of code changed and reprogrammed reviewed?
I consider it optional to answer the questions and attach them to the job posting. However, it is a sign of great self-reflection and a certain amount of know-how to deal with these questions. Besides, it offers the applicant the opportunity to protect himself from nasty surprises.
At this point, I must also mention that it is not bad if not all questions are answered with “Yes”. By a truthful statement, no false expectations are aroused.
Where to post the ad
The best place to be is there where potential talents are.
You should always be able to find the ads on your website (if you have one).
Also, the two business social networks LinkedIn and in Germany XING are right places to publish the ads. LinkedIn and XING both offer the same corresponding features, preselecting and displaying suitable job ads for both headhunters and talents who are looking for them.
In my opinion StackOverflow is mandatory. Hardly any other platform is as specialised in the industry as this one.
The application process
Short but crisp.
IT specialists are currently being overrun with offers. This also means that the application processes in the industry have to change a little.
Unless you’re called GitLab or GitHub and only hire elites from all over the world, you should choose the process that causes a reasonable amount of effort. The applicant would like to get to know the company and its working environment. At the same time, you want to determine whether the candidate meets the requirements and fits into the team.
Of course, there are several strategies for this. Mine looks like this:
- the applicant submits his documents. I look at the papers and ask a colleague from the relevant department to check them, too. In the good case, the applicant will be invited to the first interview.
The first interview. It takes place with me and (as a rule) the CTO. We introduce the applicant to the company and ourselves, ask them about their career, tell them what we do, and so on. It should be a pleasant and honest meeting in which both sides gain a good impression of the other. During the interview I evaluate the following points:
- Are the applicant’s details correct?
- Would the applicant fit into the team?
- Does the applicant meet the requirements? And if not, is the applicant ready to learn the necessary skills?
- Are the contractual conditions in order?
- Salary expectations?
- What questions does the applicant ask? What is important to him?
- In which direction would the applicant like to develop professionally?
After the interview, we then determine what we think about the applicant. In the good case, we found the applicant just as good as he saw us and we arrange a second appointment.
The applicant gets a task that he has to work on. The jobs usually consists of a logical and a practical part, for which the applicant may spend a maximum of 8 hours. The goal is to see, how the applicant is thinking and what tools he is using to solve problems. The task itself does not need to be finished in any way.
The second appointment. This takes place with all (or as many as possible) team members. At the meeting, the applicant presents his code. Before that, the candidate must indicate how long he has worked on it. When the code is shown, the team checks and questions it critically. It can be determined very quickly whether the applicant has answered true or not by indicating his time investment. In addition, it is now also possible to check how the applicant behaves in the event of a critical review, how much code he may have copied and how strong his specialist knowledge is. Afterwards there will be a relaxed chat in which everyone can get to know each other a little better.
the applicant is invited out later. We then discuss the assessment together and debate. Everyone can now cast their vote on whether they would like to work with the applicant. Just one “No” vote disqualifies the applicant.
After the advice the team leaves the room and the applicant comes back in. He now gets a direct answer and the corresponding feedback. In the good case now still the salary negotiation follows. An offer follows then already usually one or two days later by post.
The process is therefore structured in such a way that we can make a decision as efficiently and well-founded as possible in as short a time as possible as to whether the applicant fits. And also the other way around. Finally, even the applicant has only limited time and cannot take itself if necessary not five times vacation (or does not want it also simply), to come by for an interview.
What about support?
The support of an internal HR department is, of course, worth its weight in gold if it knows what to look out for in applicants.
The use of headhunters is recommended if there is a good relationship of trust. If a headhunter doesn’t come by to get to know us as a company and as people, he won’t get an assignment. Headhunters should be as efficient and accurate as possible. To do this, however, they also need to know the spirit of the company they are looking for. Once you have found a good headhunter, he can work wonders.
The search for talent in the IT segment differs somewhat from that in other industries. The art is to be aware of what you need and what you need and want to invest. Sovereignty and authenticity are highly valued. The same goes for the prospect of working on projects that advance you as an IT professional.