Permalink
Browse files

New dir structure

  • Loading branch information...
rhazdon committed Feb 4, 2019
1 parent 90fe50d commit 99119a39fbbc28ff47d371332366ff06647b2218
@@ -0,0 +1,152 @@
---
title: How to hire Software Engineers effectively
date: 2019-01-31T02:14:57+01:00
draft: false
images:
tags:
---

Die Suche nach Softwareentwicklern, Ingenieuren und DevOps ist eine Herausforderung für jedes Unternehmen. Aber warum ist das so? Und was können Arbeitgeber tun, um die Talente zu finden, die sie für ihre Domäne benötigen?

## Eine vergangene Geschichte

Ende 2017 wurde ich von der [Boxine GmbH](https://tonies.com/) als Head of Cloud & Operations eingestellt. Die Produzenten der [Toniebox](https://tonies.com/toniebox/) sind ein technisches Unternehmen, aber in den ersten Jahren arbeitete das Startup ausschließlich mit Partnern aus dem Technologiebereich zusammen, um das Produkt so schnell wie möglich auf den Markt zu bringen. Zum Zeitpunkt meiner Einstellung hatte das Unternehmen etwa 40 Mitarbeiter, darunter 0 IT-Experten.

Mein Job: Internalisierung der Softwareentwicklung, Migration von Technologien (Cloud und Hardwareproduktion) und Aufbau eines Entwicklerteams und eines IT-Teams. Und das so schnell wie möglich.

Ein Vorhaben, das mitunter Jahre dauern kann. Selbst unsere Technologiepartner haben von dem Projekt abgeraten und auf den unattraktiven Markt für Arbeitgeber hingewiesen. Vor allem IT-Spezialisten sind gefragt. Und gerade von denen gibt es nicht so viele ...

Trotzdem gelang es uns, den Trick zu vollbringen. Mit Hilfe meiner Kollegen, einem guten Produkt und externer Hilfe konnten wir in kurzer Zeit ein starkes Team aufbauen. Innerhalb von sechs Monaten konnten wir von 0 Entwicklern auf 3 Entwickler skalieren. Innerhalb von 12 Monaten waren wir 5 Entwickler, 2 DevOps, 1 System-Operator und 1 PO.


## Die Schlüsselfrage: Warum stellen wir ein?

Zuerst erscheint die Frage sehr banal, da sie das Offensichtliche in Frage stellt. Aber ist es so offensichtlich, warum gerade jetzt ein bestimmter Spezialist eingestellt werden sollte?

> Welches Problem soll der neue Mitarbeiter lösen?
Das erste Ziel ist es, den Personalbedarf qualitativ zu ermitteln. Genau festzustellen, was gesucht wird. Es ist nicht einfach, dies selbst zu entscheiden, weshalb sich der Austausch mit Kollegen, Vorgesetzten und HR durchaus lohnt. Denn als Abteilungsleiter hat man vielleicht ein Problem für sich selbst erkannt, das da heißt: "Ich habe nicht genug Leute". Aber es ist oft so, dass Probleme auf unterschiedliche Weise gelöst werden können, weil Probleme auch unterschiedlich wahrgenommen werden. Ein Austausch mit den Beteiligten soll sicherstellen, dass jeder das gleiche (oder maximal ähnliche) Bild der Situation hat und versteht, warum sich die Frage nach mehr Personal überhaupt stellt.

Die folgenden Fragen sind Beispielfragen, die in einem solchen Austausch gestellt werden können:

- Wie sieht unser aktuelles Team aus?
- Was ist der strategische Plan für die nächsten 12 Monate?
- Wie würden die Kernaufgaben des neuen Mitarbeiters aussehen?
- Würde der neue Mitarbeiter zur Entlastung des Teams beitragen?
- Mit welchen Abteilungen muss der neue Mitarbeiter korrespondieren?
- Sind einige oder alle Aufgaben nur saisonaler Natur?
- Ist eine Vollzeitstelle das richtige Beschäftigungsmodell?
- Welche Alternativen gibt es, um das bestehende Problem zu lösen?
- Wie sieht der Gehaltsraum aus?

Die aus den Diskussionen gewonnenen Erkenntnisse sollen nun einen guten Überblick über den tatsächlichen Bedarf geben. Außerdem gibt es damit bereits detaillierte Anforderungen an den neuen Mitarbeiter. In Prosa zusammengefasst bieten diese Informationen eine perfekte Vorlage für eine Stellenbeschreibung.

Aber die Übung hat noch mehr Absichten.

1. Eine Vakanz sollte nicht nur vor dem Bewerber, sondern auch vor einem selbst kausal vertretbar sein. Die meisten Bewerber merken, ob eine Stellenanzeige nur pro forma geschrieben wurde mit der Absicht, Mitarbeiter zu "parken". Die Bewerber spüren entsprechend auch, ob das Unternehmen eine neue Kraft und Kompetenz zur Lösung konkreter, echter Probleme braucht. Das bedeutet, dass das Unternehmen einen bestimmten Grund haben sollte, warum es die Stelle ausschreiben und sich dessen unbedingt bewusst sein muss. Erweiterung des Teams? Mehr Projekte? Einsatz neuer Technologien? Zu vermeiden ist, dass Talente gesucht und eingestellt werden, ohne ein konkretes Problem in der unternehmerischen Organisation lösen zu können. Die direkte Einstellung um der Einstellung willen ist für das Unternehmen teuer und im Zweifelsfall frustrierend für den neuen Mitarbeiter.

2. Ein zweiter Grund ist, dass IT-Spezialisten sich nicht bei Unternehmen bewerben, sondern eigentlich eher umgekehrt. Eine Tatsache, die man als Arbeitgeber akzeptieren sollte, um auf dem Markt realistisch wettbewerbsfähig zu bleiben.
Aufgrund der guten Marktsituation suchen viele IT-Profis nach Arbeitsplätzen, die entweder sinnvoll sind oder sie technisch fördern und fordern. Im besten Fall beides. Je eher und besser man als Unternehmen weiß, was man sucht und warum, desto besser ist der Auftritt im Vorstellungsgespräch und damit auch der Eindruck auf den Bewerber. Erst damit kann das Unternehmen auch einen Ausblick auf die anstehende Herausforderung geben und und damit Erwartungshaltungen treffen.

3. Last, but not least, wurden so alle Beteiligten von dem Prozess mitgenommen. Jeder im Team weiß jetzt, was los ist und warum neue Kollegen gesucht werden. Auf diese Weise können falsche oder voreilige Ableitungen vermieden werden (z.B. dass der neue Kollege notwendig ist, weil die erbrachte Leistung des Teams nicht ausreichend ist). Ich hatte sogar einen Fall, in dem ein Mitarbeiter dachte, dass der neue Bewerber ihn ersetzen sollte. Solche Fälle müssen um jeden Preis vermieden werden.


## 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](https://medium.com/@MsSapone/why-titles-will-kill-your-startup-58402c5b6954) by Marcela, CEO and Co-Founder of [Hello Alfred](https://www.helloalfred.com/). 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](https://en.wikipedia.org/wiki/Joel_Spolsky), CEO of [Stack Exchange Network](https://stackexchange.com) and co-founder of [Trello](https://trello.com), published his [Joel test](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/) 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/) (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).

1. Can builds, artifacts and deployments be created in one step?
2. Is a build created automatically after each check-in?
3. Are metrics collected about the code regularly and are they evaluated?
4. Is the issue tracker connected to the build and version control systems?
5. Are bugs handled before features are implemented?
6. Is any form of software functionality written down and aligned with stakeholders before implementation?
7. Do the programmers have quiet working conditions?
8. Are the best tools used that can be used or purchased?
9. Are there employees working full-time on testing?
10. Do applicants have to write source code during the application phase?
11. Are usability tests conducted with end users?
12. 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](https://linkedin.com) and in Germany [XING](https://xing.de) 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](https://stackoverflow.com) is mandatory. Hardly any other platform is as specialised in the industry as this one.

Portals like [StepStone](https://stepstone.de) and [Indeed](https://indeed.com) can also be used. If you're looking for established Java developers, this might even be the right place. Otherwise, I would rather do without it and save the money.


## 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:

1. 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.
2. 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?

3. 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.
4. 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.
5. 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.
6. 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.
7. 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.


## Conclusion

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.
@@ -4,6 +4,8 @@ date: 2019-01-31T02:14:57+01:00
draft: false
images:
tags:
- management
- hiring
---

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?

0 comments on commit 99119a3

Please sign in to comment.