Christian Brennecke-Räther
6 min readFeb 28, 2023

When setting out to build a great team, your approach to hiring is one of the most important ingredients. Only with a good hiring process can you ensure that you’re quick enough to get new teammates in the first place while ensuring you get the best-fitting people possible. For 2022 at EVANA, we’ve been able to hire more developers with less time spent interviewing than we did throughout a whole year before, with way less fluctuation and every single one meeting, or even exceeding expectations.

This is the first of two articles on the hiring topic, focusing on general improvements we introduced to become more effective and efficient, while the second one will be more about what we’re looking for in candidates, how we evaluate them, and how we factor in retention at this stage.

I experienced times at EVANA but even more so in my previous companies, where it would take up to two months from the first interview to an offer. If the candidate didn’t already withdraw in the meantime that is.

From the time we implemented these changes, we’ve been able to consistently keep this time below two weeks, I even remember a few candidates where it’s only been 3–5 days. Of course, this also depends on external factors like the candidates’ availability, but let’s not worry too much about things we can’t influence anyway.

How did we achieve this?

#1 Prioritize It

Raise awareness for the importance of being quick. All of us have some pain in our daily work we hope to get solved or alleviated by the new recruit, so each of us should have an interest in finding the right person quickly. Always keeping in mind how critical swiftness is for achieving this, helps to prioritize interviews against other seemingly important appointments. Make sure everyone involved understands that rescheduling some internal meetings might be called for once in a while, rather than letting the candidate wait.

And let’s be honest: Don’t most of us have enough meetings cramping our calendars, which provide way less value than getting that awesome candidate would? Maybe a conflicting interview slot can be the excuse you need to drop one of those ;)

#2 Tooling

Our Recruiter, let’s call him David, brought us a lot of great improvements, one of them has been the introduction of a proper tool for managing the hiring process - an ATS (Applicant Tracking System), namely Greenhouse.

I haven’t worked with other full-fledged ATS yet, so I can’t compare, but it’s definitely a way smoother experience than using some generic tool like Asana.

This greatly increased efficiency as well as transparency, because it’s really quick and easy to find any relevant information about the candidate across all interview stages, including previous feedback by other interviewers, the description of the job she/he applied to, and open questions which came up during previous interviews or mail correspondence.

For teammates who don’t do these things on a regular basis, it’s also really helpful to have the provided interview kits with standard questions for the respective role all in one place.

#3 Avoid Bottlenecks

A great swiftness-killer is of course any kind of bottleneck. Individual people absolutely being required for some steps in the process, e.g. I as the Head of the department having to be present in the first interview or make the final call in the end. A different kind of bottleneck would be the capabilities needed for some interview steps residing with only one or two people, or not everyone understanding the purpose of the individual steps.

One Having to be Present

Of course, the examples given above weren’t coincidental, those were exactly the two cases we had.

One of the first things I discussed with our recruiter was that while ideally, I’d like to be in every first-stage interview, we shouldn’t risk losing great candidates because of me being off sick or on vacation. Instead, I asked for another Lead Developer to be added to those interviews in my stead, with me participating at a later stage.

One Having to Make the Call

This one is easy. In most cases when I’ve been off the day the final interview took place, I had been in the first interview already. I’ve met the candidate, found her/him to be a great fit, and asked our recruiter to move forward.

So why would I change this opinion after further interviews I haven’t even been part of myself? I can’t see a reason, thus I made clear that when the ones who have been part of an interview agree the candidate is great, the hiring process should proceed, including the final stage leading to an offer. For planned time off I named one of the Leads to make the call in case the participants are not able to decide.

Missing Capabilities/Knowledge

In the beginning, I often heard “Dev X said he cannot do the technical challenge, he doesn’t know how it works and where to find the material”.

This did sound like the kind of problem that’s easy to solve.

We documented the challenges in Confluence, including how much time should be allocated for briefing, challenge, and debriefing, as well as how to approach each of those steps. We added a standard briefing text to use, as well as instructions about what to look for, and what kind of questions to ask.

The only thing left was to let people know and ever since we’ve had more different developers conducting these challenges with candidates. The briefings as well as the criteria for evaluating the candidates got a bit more fleshed out and consistent as a nice little side-effect.

Missing Understanding of Interview Purpose

The one other part that needed to be addressed was the big-picture understanding. How does the interview I am doing fit into the overall hiring experience and the candidate’s evaluation?

For this, we extended the Technical Challenge documentation to Hiring Process documentation, adding the same kind of information for the other steps, with lots of exemplary questions to ask, and explanations of what we’re looking for in the candidates. Both in general, and which of those traits to evaluate in each individual step.

#4 Become More Flexible Ourselves

The number of promising candidates almost skyrocketed after two crucial changes in our requirements.

The Obvious One: Remote Option

In the past we already switched from “developers should work in Saarbrücken, but if they’re really good we could also live with them working from the Frankfurt office” to “they can work from any of our offices, and if they are super amazing we rather get them as remote colleagues than not at all”. This already made a little difference, but what really changed things was openly offering the option to work 100% remotely, hybrid, or completely on-site at any of our offices.

Photo by Avi Richards on Unsplash

Don’t Require German Language Skills

From my time in Frankfurt and Munich, I knew how many great people hang around in our country not being fluent in German, so even with locations being restricted to Germany, requiring fluency in German was still a limiting factor.

For me personally, the world of Software Development has always been an English one anyway. Almost all the resources one commonly taps into to learn new tech, improve, or find solutions to one's engineering problems, are in English. I haven’t seen German class or variable names yet either. Since the company wanted to internationalize anyway, that move made even more sense.

After speaking to the teams about the prospect of having to speak mainly in English in the future, I received green light from most. The very few ones who felt insecure about it, at the same time signaled they’d be up for the challenge.

Fun fact 1: Of the last 5 great engineers we hired, only one is able to really converse in German.

Fun fact 2: The ones who felt insecure about speaking English, in the beginning, all improved greatly by now, and they happily noticed themselves.

Conclusion

Most of our new colleagues named our quickness as one, if not the deciding factor. For one, we simply sent them an offer way ahead of others. But also because it gave them the impression that we’re agile and getting shit done, which suits the kind of environment they want to work in.

To sum up how we got there:

  1. We gave the candidates top priority relative to internal dealings
  2. We introduced proper tooling for managing the candidate journey (ATS)
  3. We removed and mitigated bottlenecks on our end as much as possible
  4. We simply became more flexible with our requirements and policies

All this mainly impacted efficiency and success rate within the hiring process. Another, even more important part though, is how good you are at keeping those recruits. In the next part, I’ll go more into the things that impacted retention.

Christian Brennecke-Räther

Passionate engineering leader and team builder, also Director Cloud Development at Sematell GmbH. Happy to connect over at LinkedIn: linkedin.com/in/christianbr