Patrik Ruman (CEO, Techband.io): How to Hire Developers

Standing out from larger competitors

Martin Brath: All right, welcome, everyone, to B2B Tech Talks. I'm here with Patrik Ruman, the founder and CEO of TechBand.io, who specializes in providing developers to technology companies.

Patrik Ruman: Thank you for inviting me, Martin.

Martin Brath: You're welcome. We're here because this is quite a hot topic: technology companies and startups are having trouble hiring developers and finding good people for their development teams. Since you've been in this sector for a while, let's start with this question: as a technology company, how can I stand out from my competitors and attract the best possible talent?

Patrik Ruman: The competition for talent is enormous, whether we're talking about our own country or the European market as a whole. We need to recognize that this competition often isn't fair. It's difficult. I'd compare it to David fighting Goliath: small companies with 20, 50, or 100 employees are competing against global corporations with tens of thousands of employees and budgets of millions of euros. On the other hand, as we know from the past, smaller players who are smart can also succeed in the market and become leaders in their fields. So how do you do it? In my experience, there are two or three steps smaller companies can take to stand out and attract the right talent. First, this is a war—a battle for talent. To win that battle, you need to look at the battlefield you're competing on. For example, suppose I'm a company based in Prague. I can decide to look exclusively for people from Prague because I want them to come into my office. But then I'm competing directly against large global players whose hiring budgets are many times bigger than mine. On the other hand, perhaps I don't actually need people to come into the office. Suddenly, I can recruit from the Czech Republic, Slovakia, or neighboring countries, where the language barrier is minimal. Or I might say that I have customers abroad as well—in the US, for example—so I can hire people from all over the world. That makes the talent pool much larger. The first step, then, is to understand which talent pool you're recruiting from. The second step is knowing your vision. Top technology talent wants to work with companies that have a clear vision of where they want to go and how that person can help them get there. In other words, what impact will that person have on the company? The third point is to fight with modern weapons. Nobody wants to fight with bows and arrows when we have drones. Everyone wants to work with the latest technology. Applied to developers, if you're using technology that's 20 years out of date, it will be difficult to attract top technology talent who work with the latest tools, such as AI or the newest versions of Angular, React, and similar technologies. Those are three things companies can do, in my view, to help even smaller players recruit talent that sets them apart in the market.

How much does salary matter?

Martin Brath: All right. We've mentioned that corporations are the biggest threat to startups because they can offer higher salaries. How much of this comes down to pay?

Patrik Ruman: Salary is an important factor. But funded startups that are growing quickly can now also compete with bigger companies on pay. There's also a baseline—a certain level of income that a typical programmer earns. Once someone has passed that basic threshold, earning a few hundred or a few thousand euros more per month at a larger company may become less important. You need to look at what comes next. Once my basic needs are met, I can pay for housing and everyday expenses and support the lifestyle I've chosen, it becomes more about meaning: what impact can my work have on society? Medtech startups, for example, have a big advantage here. Or a greentech startup can appeal to a particular group of people. Startups working with data can attract people who enjoy data and the impact those numbers can have. So, again, it's important to look at what your company is and how you can differentiate yourself in your segment beyond salary. A pay rise motivates you for a few days; a week later, you might already have forgotten about it. What keeps you there is the team and the work you do every day.

Where to look: job boards versus your network

Martin Brath: All right. Once I've decided to hire top talent, where should I look? Where would I start? Should I go to Profesia and look around, or where can I find these people?

Patrik Ruman: Exactly. Companies typically turn to job boards and expect all the best programmers, UX specialists, and testers to be waiting on Profesia. But the best talent often goes undiscovered and isn't on job boards, because those people are usually already doing work they enjoy. So, in my view, the first thing to establish when hiring is who you're actually looking for. Don't simply say, "I want a team of five or six people." Say where you want to take your business, and hire accordingly. For example, if my online store takes 30 seconds to load instead of one or two, that has a major impact on revenue. There are various case studies showing that every extra second of loading time reduces an online store's revenue. So I might say, "I need a senior developer—an expert who can fix this problem in a few days." That person then has an impact on revenue and on the whole company. For small and medium-sized companies with 20 to 100 employees, recruiting reactively through job boards or a LinkedIn post and waiting for a top candidate to apply is quite difficult. In my view, just as location matters in real estate, your network matters in hiring. But, again, that doesn't mean posting on a job board or LinkedIn and waiting for a great senior developer or a top frontend expert to apply. It means taking proactive steps to recruit the best talent. At our company, for example, we use a mental exercise called the Memory Palace. You identify two or three jobs or networks you've been part of over the past five years. For each one, you identify three, four, or five people you really respected in that job. Suddenly, you have a network of 15 to 20 people you can contact and say, "Look, I'm looking for someone for this particular role. I think you'd be a good fit. Can you help? Or do you know someone in your network who could join us?" We've hired around 60 to 70 percent of our people that way.

Applicants versus headhunted candidates

Martin Brath: Okay, so let's compare the quality of those two options. On one hand, I wait for someone to apply; on the other, I actively headhunt people. How would you compare the average quality of applicants who are currently unemployed with people who aren't looking for a job but are good at what they do?

Patrik Ruman: Of course, a top-quality person might get upset about something at work, open a job board, and apply to your company that day. But you can't rely on that. In my view, companies should recruit proactively and seek out top people through their own channels, ideally through their network or otherwise through other sources. In terms of quality, people in tech say that top talent can be up to eight times more effective and productive than an average developer. In practice, you want to work with people who help move your product forward faster.

Assessing candidates: cultural fit and live coding

Martin Brath: How do you tell them apart? There are several things you can do. Of course, the best way to find out whether someone is good is by working with them.

Patrik Ruman: But while you're still hiring, it helps to assess certain things. At our company, we focus on two areas during interviews. The first is cultural fit: is this person easy to get along with? Could I go out with them in the evening and have something to talk about? We want someone who won't disrupt the company's culture. The second is technical ability, which you can assess to some extent during the interview. We use live coding sessions. The candidate shares their screen, and we give them an assignment with three sections: an easy one, a more difficult one, and a third that's the most complex. We look at how the person thinks about both the short-term and long-term impact of their solution to the challenge. We also look at how efficiently they write code. Some people solve a problem in 30 lines; others solve it in two. And they'll explain that they used those two lines for these particular reasons, while also pointing out the potential implications later on. Those are exactly the people I want on the team, because I know they won't need constant hand-holding.

Who assesses candidates and how benchmarking works

Martin Brath: Who assesses candidates at your company? Who leads the interviews and decides? Who takes part?

Patrik Ruman: We see it as "birds of a feather flock together." Over our time in the market, we've identified top people whose abilities we've verified on projects, and they assess the next candidates. We try to benchmark them. If I know that one of our top assessors scores 98 in my assessment, and they say, "Yes, this person is excellent—possibly even better than I am," then I know that this is a very good person I can trust.

Martin Brath: And are there people who'll actually say, "Yes, this person is better than me"?

Patrik Ruman: There are. Humble developers. And people who are confident in their own abilities can also admit, "This is someone I'd like to work with, because I can learn something from them." The really good people recognize that they need to keep learning, and that the best way to learn is from the people they work closely with.

Spotting a weak developer after hiring

Martin Brath: At another company, I saw a developer leave, and the new developer who replaced them said that the previous person's code was very bad. The others didn't disagree. So it raises an interesting question: at what point should the developers—or whoever is responsible—identify a person like that? And how do you do it?

Patrik Ruman: The first step can happen during recruitment, when you look at how someone thinks and what kind of code they write. That's the two-line solution versus the 30-line solution: you can already see how they structure their code and how they think about the overall structure. Then, once they're working with you, ideally you have a CTO or team leader responsible for them. During the first days and weeks, that person should supervise them, gradually assign tasks from the easiest to the hardest, and review their work thoroughly, to find out how advanced they are. That lets you assess quite accurately how reliable they are and whether they can deliver what you need. Another approach is that companies—particularly more established ones—estimate how long a task should take. Then we can compare the estimate with what actually happened. For example, we estimated a feature at 10 hours, and the person completed it in five—or in 50. We can investigate why. Of course, the feature might not have been defined properly. In that case, I'd go to the project manager or product manager who wrote the requirements. But it could also be that the programmer simply isn't efficient. So it's a combination: the initial screening happens during interviews, and the second assessment should ideally happen in the first few weeks. Someone in a leadership role should regularly monitor the person and compare their project performance against the benchmark.

GitHub contributions as a signal

Martin Brath: How do you assess someone's GitHub contributions before hiring them?

Patrik Ruman: It's a useful indicator of how often someone produces code. But we've found that you always need to look at the whole person—not just as a programmer, but as an individual, including how much free time they have outside work. Based on that, you can establish that someone really enjoys programming and has lots of commits in public GitHub repositories. That can be a good predictor that they enjoy programming, want to develop their skills, and are learning new technologies. On the other hand, someone without many public commits can still be a top developer. They might have a family and no free time in the evenings to work on public repositories or public projects. So you need to look more closely. If I don't see anything there, I can ask about it during the interview: why is that? If there's a lot of activity, I can use that as a starting point to understand how the person thinks. I might discover that they go to hackathons, keep learning, and take part in online challenges. That's great, because they're not just saying they're proactive—they're demonstrating it through their code.

Proactivity versus real output

Martin Brath: All right. I assume that being proactive isn't directly proportional to someone's actual output as a programmer. These are activities where an ordinary observer can see that someone is trying and putting in effort. But sometimes the talent or the way of thinking needed for coding isn't there. How do you filter for that?

Patrik Ruman: That's where you need to examine the code in detail. Give them a complicated task and see how they approach it, how they break a complex task into smaller parts, and whether—during live coding or a take-home assignment—they can spot bugs that have a business impact on the application. For example, a hidden bug in the assignment or live coding exercise might make the application take 10 to 20 seconds to load. If the person spots it, they can dramatically reduce that time. That's exactly what we want to see. Some assignments contain hidden bugs with a specific impact. The assignment might look as though it's been completed correctly, but if the person doesn't understand the complexity, they'll miss those things. During the assessment, we might see that the assignment does what the brief asks, but the candidate hasn't done anything beyond that. That's already a good indication that they probably aren't at the senior expert level we need.

Years of experience versus actual quality

Martin Brath: How do you see the relationship between years of experience and a developer's quality?

Patrik Ruman: There are two different worlds. There's the basic recruiter's approach, which you often see in job ads requiring five, 10, or 20 years of experience. Then there's the practical reality, where years of experience don't necessarily correlate with ability at all. A person who's worked on a project for five years might be weaker than someone who's worked on one for a year. The reason is that it depends heavily on the projects they've worked on. Compare someone freelancing on 10 small WordPress sites at once with someone who spends a year working on a complex application in a team of five to seven people, with a proper structure and daily stand-ups. That second person can very quickly outgrow someone with five or 10 years of experience who often works alone, without code quality checks, daily stand-ups, customer communication, and so on. So years of experience can be an initial indicator, but you always need to look at the type of project, how complex it was, and the team structure. That tells me more about the person than the number of years alone. Of course, if I receive a CV showing six months of experience, that gives me an initial way to classify the candidate. But they could be extremely talented. We've also often seen companies return to that question of business impact. For example, on a project, I might know I need more development capacity because we can't keep up. But when I analyze the team's current setup, I discover that my most senior people are doing basic tasks—frontend styling, for example. They don't enjoy it, but they have to do it because there's nobody else to do it. In that situation, a capable student with six months of experience could be exactly what I need. They can take some work off the senior developers' shoulders, freeing them up for more complex things. If that student has ambition and the drive to improve, working alongside those senior developers can help them progress very quickly in six months or a year. So it depends on what the company currently needs. And that should come from the business impact they expect the person to have.

One hire: motivated junior or experienced parent?

Martin Brath: All right. Suppose you can hire only one person. On one side, you have a talented young person who hasn't worked for years and has limited programming experience, but is very motivated, tries hard, and has ambitions. On the other, you have someone with substantial experience who has a family, wants to leave at five to spend more time with their children, and no longer has such a strong drive to move forward. Which would you choose?

Patrik Ruman: It depends on what I need. If my server costs are €10,000 a month and I need to cut them by 50 percent, I'd expect the person with years of experience to deliver what my business needs in two or three days so that those costs don't kill the business. On the other hand, if I'm a startup that wants to iterate and doesn't know whether tomorrow's feature will be blue or green, and we need to work in the evenings because we're presenting the company at a trade fair the next day, or pitching to an investor and need a new mock-up, then it probably makes sense to hire that capable, talented junior who has the enthusiasm and drive to work evenings and has no other commitments, because that person can help me meet my goals.

Martin Brath: All right, thank you for the conversation, Patrik. See you next time. [Closing phrase unclear in the source.]

The ideal interview process, revisited

Martin Brath: All right, when you're hiring a developer, it's very important to have a distinction between a very good developer and a mediocre developer. How would the interview process ideally look like to find out within the interview process who you're dealing with, whether this is a very good programmer or a mediocre one?

Patrik Ruman: In my experience, the best way to find out how good a developer is on your team is by working together. But you can reduce the hiring risk by focusing on the right elements during the interview. Over the last four years, we've interviewed a lot of people for our teams. I'd say the structure we use works very well. First, we look at the person's interpersonal skills. It's about cultural fit: I want people on my team whom I can trust. The second area is technical skills. To assess technical skills, we use a live coding session where the developer shares their screen. We work through some code and give them three challenges in a 30- to 60-minute session, ranging from the simplest to the most complex. I always look at how the person thinks about solving the coding challenge and how efficient the code they write is. For example, one developer might solve something in 30 lines, while another solves it in two. You can see how efficient the person is in their thinking and their coding. So that gives you a good indication of who might be the right fit when you combine interpersonal and technical skills. Of course, there are other things you can check: their GitHub repositories, the projects they're working on, perhaps side projects, and what they do in their free time. What challenges are they working on? Are they learning new technologies? Do they publish articles for other developers or take part in meetups? These are all activities we consider when building a profile of the ideal developer.

Martin Brath: Which would matter most to you if you had to choose just one? When you read a CV and see a list of activities, what would be the most important?

Patrik Ruman: On a CV?

Martin Brath: On a CV. For example, if someone has a side project where they're coding an application, [wording unclear in the source] or organizing meetups.

Patrik Ruman: In my view, there are two things. The first is whether their experience fits the project we're working on. Let's say I have a [type of platform unclear in the source] that handles tickets, and I know this person spent the previous year working on a similar project, perhaps a bigger one. That's the first thing. The second is proactivity: whether the person uploads new code to GitHub, and other activities that demonstrate initiative.

Martin Brath: Do people get nervous in these live coding sessions, when they're coding in front of you and have to think?

Patrik Ruman: Yes, definitely. It creates stress because you don't know what to expect or what type of challenge you'll get. Sometimes it isn't just about coding, but also critical and mathematical thinking, involving algorithms. They need to work out a solution in the real world and then put it into code. [The precise wording of this explanation is unclear in the source.]

Martin Brath: So do you give them a few minutes?

Patrik Ruman: We show them the outcome we want, and then it's up to them. They can use Google, think it through, use their phones, or even call someone. [Brief response about calling someone unclear in the source.] Even if someone uses ChatGPT, you want to see how that person thinks, because when they're working at your company… [Sentence trails off into repeated, garbled wording in the source.] [Several closing lines about interview stress and helping candidates are too garbled in the source transcript to translate reliably.]

Martin Brath: Thank you, Patrik. All the best.