On the hunt for new recruits: What CTOs really look for when they look for new developers

Though Davidson took up his role as CTO at PressPage only nine months ago, he’s already made a lot of changes.With a growing customer base and a recent investment round, he’s substantially expanded his development team. Now that the internal processes match his vision, Davidson has been able to shift his focus to a new major challenge: hiring the best available employees.

What type of people do you look for in your team? Are they easy to find?

‘Good software engineers are hard find. The programming languages and frameworks that we use depend on what best suits the software that we’re writing. What we look for is people who understand problems on an abstract level, that it doesn’t matter which language or framework they have to use. It’s an advantage if you have experience using PHP frameworks such as Laravel, Symfony2 or Silex, but it’s not imperative. I think that if you look at the résumé of good developers, you will most likely see several programming languages. Good developers will choose the right technique to solve a specific problem.'

Your new employees are expected to hit the ground running, so surely they must at least be proficient in PHP?

‘Yes, that’s correct. Programming has to be second nature to you. You should be able to solve problems in a structured manner and know the underlying principles of the programming language. The specific skills gained by mastering a certain framework are also important, but are really secondary to one’s talent to being able to learn them.’

During the application process, how can you tell if someone has such a talent?

‘The first signs of talent usually show up on the résumé. A front-end developer will always have JavaScript on their résumé, and quite often also frameworks like React, Angular, Ember or Backbone. One of these could indicate a specialty, which could make for an interesting candidate, but if there’s more than one, that really shows me that the candidate is able to solve problems in multiple ways. The same principle is applicable to back-end developers.’

What questions do you always ask during a job interview?

‘“What do you do to broaden your knowledge?” When it comes to front-end development, the stable version you’re working with one day could be outdated four weeks later. So for me an important question is: “How do you stay up to date?” A positive sign I encounter on resumes, and I hear other companies talk about this as well when they’re discussing their recruitment practices, is when people study in their own time and specifically read relevant books. I don’t mean just online articles, which are useful, but they often only cover an introduction to a topic. People who really dive into it and read the full book, are always interesting candidates. “Which books are you currently reading and which would you recommend to other engineers?” are two questions I always like to ask. People that can passionately answer these questions will also more likely have passion for their profession.’

How important is that passion in this line of work?

‘Without passion you won’t last long as a developer. You need to enjoy your work. In the Netherlands there are some developers who are only in it for the money. That’s not the kind of people we’re looking for. We need people who want to excel with passion, because that’s exactly what PressPage wants to do. We’re growing at a fast pace and we’re looking for developers that can run with us.’

In your nine months as CTO, what major things have you changed and achieved?

‘When I started here, we had a group of individuals who needed instructions. That’s not how I like to work. I want to work in an environment where people are empowered and have the ability to make decisions. I want them to tell me what we need to do so that I can use their input on a strategic level. The developers that work with the products on a daily basis are the best people to tell me what we should do in the short term. I immediately adopted the Agile and SCRUM methods here at PressPage, so we moved from working on long running project to working in two-week sprints.

Now developers discuss amongst themselves on what they’ll be working on for the coming weeks, and how they will be solving these challenges. If something doesn’t go well, they immediately take it up with each other. This enables us to throw new employees into the mix much more easily. Scaling becomes simpler now as we can split a team into two groups without those groups losing their course. We stopped thinking in terms of projects as well. They always go on for longer than planned and often end up delivering less than what was expected. You have to make sure that your team is stable, and you should bring the work to the team, not the other way around.’

But do these autonomous developers still have a feel for the needs of the end user?

‘Customer requests are first handled by our Customer Success Team and are then reviewed by us. We pick up the vast majority: if it’s possible, we’ll do it. There’s always room for time sensitive issues, but our developers have a pretty full list of priorities for the coming year, so they already know what to do. If a customer has a small request that doesn’t take a lot of time, we’ll take the extra effort to make that customer happy. If it’s a big request, it may not fit into our schedule, but if we see that it adds a significant value to our platform, we’ll make time for it. Our CXO (Chief Experience Officer) is in charge of defining the priorities and I determine whether they’re technically possible and if so, how we should go about it. When these tasks end up with our developers, they know exactly what the client needs’

So, is the end result ever different than what the customer expected?

‘That does happen from time to time, but we try to avoid it by making sure the developers evaluate our plan before they start building. The first thing we do is to ask what specific problem the customer wants to solve with their request. It’s up to the development team to determine with the CXO what needs to be done and how the problem can be solved technically. The CXO ultimately decides if we’re actually going to put in the extra hours. Fortunately we often find that we already have a solution for the problem and that there’s already a module for it, or we can easily generate a custom module using existing functionalities.’