Recruiting Backend Engineers at ottonova

To do our part and share with the Community, as well as provide a bit more transparency into ottonova and how we are building state-of-the-art software that powers Germany’s first digital health insurance, here are some words about how the Backend Team goes about finding new team members. 

We’re going to cover what we are doing in the Backend Team, what we value, and how we ensure we hire people that share our values.

The Backend Team

Our team is responsible for many of the services that power our health insurance solutions at ottonova. This includes our own unique functionality, like documents management, appointments timeline, guided signup, as well as interconnecting industry-specific specialized applications.

Under the hood, we manage a collection of independent microservices. Most of them written in PHP and delivering REST APIs through Symfony, but a couple leveraging Node.js or Go. Of course, everything we use is cutting-edge technology, and we periodically upgrade.

As a fairly young company, we spend most of our time adding new functionality to our software, all in cooperation with product owners, but at the same time we invest fair effort into continuously improving the technical quality of our services.


Technical excellence  is one of our team’s core values. To this end, we are practitioners of Domain-driven design (DDD). Our services are built around clearly defined domains and follow strict separation boundaries. 

Because we created an architecture that allows it, and we have the internal support to focus on quality, we invest a lot into keeping the bar high and whenever needed we refactor and make sure the Domain Layer stays up to date with the business needs, or that the Infrastructure Layer is performant enough and can scale.

Although most of our work is done using PHP, we strongly believe in using the right tool for the job. Modern PHP 7+ happens to be a pretty good tool for describing a rich Domain, but we like to be pragmatic and where it is not good enough, maybe in terms of performance, we are free to choose something more appropriate.

Expectations from a new team member

From someone joining our team we, first of all, expect the right mindset for working in a company that values quality. We are looking for colleagues that are capable and eager to learn as well as happy to share their existing knowledge with the team. 

A certain set of skills is needed as well, or the right foundation for developing those skills. We are particularly interested in a good mastery of  programming and PHP fundamentals, Web Development, REST, OOP, and Clean Code.

As actual coding is central to our work, we require and test the ability to both write code on the spot, and to come up with clean design.

These expectations can be grouped into four main pillars that a candidate will be evaluated on:

  1. Mindset – able and willing to both acquire and transfer knowledge inside a team
  2. Knowledge – possesses the core knowledge needed for using the languages and tools we use
  3. Clean Design – able to employ industry standards to come up with simple solutions that can be understood by others
  4. Coding Fluency – can easily transfer requirements into code and coding is a natural process

The Recruiting Process

To get to work with us, a candidate goes through a process designed to validate our main pillars. All this while giving them plenty of time to get to know us and have all their questions answered.

It starts with a short call with HR, followed by a simple home coding assignment. Next there is a quick technical screening call. If all is successful so far, we finish it up with an in-person meeting where we take 1-2 hours to get to know each other better.

The Coding Assignment

Counting mostly for the Clean Design pillar, we start our process with a coding assignment that we send to applicants. This is meant to allow them to show how they would solve normally a problem in their day-to-day work. It can be done at home with little time pressure, as it is estimated to take a couple of hours, and it can be delivered within the next 10 days.

The solution to this would potentially fit into a few lines of code. But since the requirement is to treat it as a realistic assignment, we are expecting something a bit more elaborate. We are particularly interested in how well the design reflects the requirements and the usage of clean OOP and language features, the correctness of the result (including edge cases), and tests.

We value everyone’s time and we don’t want unnecessary effort invested into this. We definitely do not care about features that were not asked for, overly engineered user interfaces or formatting, or usage of design patterns just for the sake of showcasing their knowledge.

It will ideally be complex enough to reflect the requirements in code, but simple enough that anyone can understand the implementation without explanations.

The Tech Screening

To test the Knowledge pillar we continue with a Skype or a regular phone call. This step was designed for efficiency. By timeboxing to 30 minutes we make sure everyone has time for it, even on short notice. We don’t want to lose the interest of good candidates getting lost in a scheduling maze.

Even if it’s short, this call ensures for us a considerably higher match rate for the in-person interview. In time we found that there really are just a handful of fundamental concepts that we expect a new colleague to already know. Many of the other can quickly be learned by any competent programmer.

All topics covered in this screening are objectively answerable. So at the end of a successful round we can make the invitation for the next step.

In-Person Interview

This is when we really get to know each other. This is ideally done at our office in central Munich – easier for people already close by, but equally doable for those coming from afar.

In this meeting we start by introducing ourselves to each other and sharing some information about the team and the company in general.

Next we ask about the candidate’s previous work experience. With this and the overall way our dialog progresses we want to check the Mindset pillar and ensure that the potential new colleague fits well into our team.

After that we will go into a new round of “questioning” to deeper test the Knowledge pillar. Similar to the Tech Screening, but this time open-ended. Informed opinions are expected and valued. We definitely want to talk about REST, microservices, web security, design patterns and OOP in general, or even agile processes.

Then comes the fun part. We get to write some code. Well… mostly the candidate writes it, but we can also help. We go through a few mostly straight forward coding problems that can be solved on the spot. We are not looking for obscure PHP function knowledge, bullet-proof code, or anything ready to be released. We just want to see how a new problem is tackled and make sure that writing code comes as something natural to the candidate. With this we cover the Coding Fluency pillar.

Afterwards it’s the interviewee’s turn. We take our time to answer any questions they may have. They get a chance to meet someone from another team and get a tour of the office.

What’s next?

The interviewers consult and if there is a unanimous “hire” decision, we send an offer. In any case, as soon as possible (usually a few days) we inform the candidate of the outcome.

Interested in working with us? To get started,  apply here:

Analogies between physics and IT project management

Could physics be helpful in solving the problems of IT project management?

Naturally! Physics is after all the science that describes how the world around us works. Actually, any domain – IT project management included – that belongs to our universe must exhibit regularities which implies there will exist certain laws that allow describing it, therefore also be to some extent under the scope of physics.

“Okay, but why would anybody want to spend their time seeking analogies between project management and physics?” one could ask.

The answer is, that tools which could be helpful in solving problems that seem too difficult in the project management (PM) world, might be available and well known for physicists. In short – rummaging in the physicists toolbox might produce tools usable in IT PMs daily life.

This is why we would like to dedicate this article to show some of the analogies between the two worlds and – using some of them – to stress the importance of quality assurance in the world of IT.

Einstein supposedly said: “everything should be (made) as simple as possible, but not simpler”, let us therefore try to simplify the view of an IT project by making an analogue in the world of classical physics: namely, driving a car. Not to oversimplify things and not to draw false conclusions, we will have to keep alert for when the analogy becomes too far fetched and holds no more.

Before we enter the car, when wanting to go from a point A to point B, we would possibly have a look at the map, check the traffic to make sure we can make our travel in the expected time, take into account the terrain on our way, prepare the money for the gas and other expenditures, make sure if the car is in technically good driving condition and whether what the route demands of our vehicle meets what the car can deliver, then ‘simply’ go into the car and drive from A to B.

‘Nothing more to it’.

How should we translate this picture into the IT-world? What is the car? Who’s the driver? What is the road?
Let us start with the project and what it means to complete the project – since it involves the entire team cooperating on achieving a set goal – it would equate to having the car, its passengers and luggage reach a desired destination.
The PM – steering the project from point A to point B, at the same time trying to assure that the plan of making it on time and within given budget – seems to be an obvious choice for the driver.
The developer team’s analogue is the car’s engine – for those actually move the project/car and induce the changes in the surroundings/project state (what could also be called “the state” of the car) at the cost of burning fuel/budget.

This time, let us try to make one step further and ask some (rather rhetorical and sometimes absurdly sounding) questions:

  • when driving the car, would you consider having your eyes open?
  • what is the largest distance that you would dare to drive a car with constantly closed eyes (or, how long would you dare close your eyes when blinking them)?
  • how powerful a car would you dare to drive if your eye-blinking speed was restricted when driving it?
  • would you dare to drive if you were to only look through the side window?
  • how often would you consider stopping to verify all the car’s surroundings and its technical state?
  • would you risk driving your vehicle without doing required inspections and maintenance?
  • would you risk driving your vehicle using the incorrect gear and on too high engine-RPM?

‘Okay, well, that really sounds rather absurd to ask … any of the questions actually. What’s the point?’.

As it will soon turn out, even those ‘absurd’ questions can provide insight into project management. If that will prove to be so, this will also mean that some difficult-to-solve problems from one ‘world’ might be actually fairly simple in the other ‘world’.
Let us then see, how the ‘absurd’ questions translate into the IT-project-management world…

  • when doing an IT project, would you consider verifying how the software operates and evolves?
  • how many software releases would you dare to make without knowing the how the product works (or how much new functionality would you dare to release without ever checking it)?
  • how big a developer team would you dare to have if you had only very scarce quality-assurance resources?
  • would you dare to continue a project if the quality-assurance was focusing not on the most important features?
  • how often would you require your quality assurance team to test all possible product features?
  • would you risk running your project without checking the technology stack and ever adjusting it?
  • would you risk running your project requiring the developers not to use available languages, but having them develop everything from scratch?

Answers to those questions form some of the basic truths that should be known to experienced PMs:

  • Testing is necessary in order to know where the project is – what the software actually does.
  • There is a certain proportion between the amount of developers and testers that should be on a team.
  • Testing should focus on the most important features.
  • It does not make sense to test everything all the time.
  • Not doing thorough testing at reasonable time intervals introduces unnecessary risks.

One of the differences between the IT world and the classical physics example posted above is that actually looking at the road costs us seemingly no time at all. The information flows in in a steady stream. That is not so in the IT world.

Not only performing tests requires a given amount of time (and effort), the same applies for moving the car. Namely – developers need to commit code changes, those usually do not happen with every single character of code changed – as only specific units of code actually make any sense at all for the computer.

We can already see, that two things change in discrete amounts – the information and the time required to change that information. Discrete amounts are known in the physics world under the name of quanta.
Entering this realm – the quantum physics domain – will be the topic of another episode.

Every 2nd friday – IT Breakfast is on

Every 2nd friday we’re celebrating. Us tech-guys! By having an official IT Breakfast.

The boss is cooking tasty scrambled eggs with crackling bacon. Then typical german breakfast ingredients like breadrolls, cheese, salami and butter are served. On top of that there is always fresh fruit, juices and coffee from our excellent ECM Technika espresso machine.
The outcome: Well fed, invigorated team members, full of energy and in a splendid mood!