How to build a dream team. Technical recruitment process at Pragmatic Coders

Introduction

Wiktor Żołnowski:

Welcome to Pragmatic Talks, a podcast and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. Pragmatic Talks is brought to you by Pragmatic Coders. We believe that modern methods and approaches to software product development should be widely adopted in the market to minimize the wastage of talent. We also believe that everyone should have equal access to knowledge about product development and entrepreneurship. Everyone should have the opportunity to apply it in the pursuit of making our world a better place. Through this series, we aim to create an impact on the future world. For today’s episode, I have invited Marcin. He is a seasoned software engineer, software architect, and currently working as a Service Delivery Manager at Pragmatic Coders, where he is also a board member and shareholder. His role is all about assuring the highest standards of our services for our clients, and that can be achieved mainly through a selection of the best talent from the market and the development of the right processes. The topic of today’s episode has already been mentioned a few times in the entire series. Since a significant part of Pragmatic Coders’ core business is hiring great talent and building effective teams around products we build for our customers, we decided to share our knowledge and experience in recruitment. And now, ladies and gentlemen, please welcome Marcin Byrdziak. Welcome, Marcin, it’s a great pleasure to have you here.

Marcin Byrdziak:

Thanks, Wiktor.

Wiktor Żołnowski:

So, you’re the Service Delivery Manager at Pragmatic Coders. You also recently became a partner at Pragmatic Coders and a board member some time ago. Could you start by telling us a little bit about your story? How you managed to get to where you are right now? Where did you start, when did you start, and what does it look like, briefly?

Marcin Byrdziak:

So, I was programming for nearly all my life, and I was never bored. At some point, I was doing a lot of things. Actually, I started with PHP, went from doing simple applications, and I was eager to just look at other technologies. So, I was that programmer that doesn’t like to code in one specific technology. During my whole career, I was programming in Java, in PHP; I was writing automated tests, I was writing front-end, so actually, I was doing all of the flow that nearly every application needs to have. I think that something that I have never done was a mobile application, yet. So, at some point, I was actually going to be like an architect, and I just started using all of the knowledge from all the technologies and gathered all there is in an application from scratch – not just writing the code in a single stream of stuff. After that, I found that nothing happens in the application, so I was looking for something, and it happens that I had a possibility to scale my experience and just help to manage the company instead of doing single projects. So this is something that I’m trying to do at Pragmatic Coders – to just share my experience and knowledge so the same good work happens in the whole organization, not in a single project.

The greatest challenges in technical recruitment

Wiktor Żołnowski:

Great. So today’s episode will be focused on recruitment because it’s a topic that we already mentioned in a few previous episodes, and every one of our guests said that anything they are talking about – regardless if it’s Scrum, if it’s product management, or building a startup, looking for product-market fit, creating a bank with a small team, and doing a lot of other stuff – each of our guests says that recruitment is something that you need to take care of. If you do the recruitment wrong, then anything else that you are doing will most probably end up as something that you don’t want to end up with. Today we are going to focus on recruitment, especially recruitment for technical roles, for startups, for product companies, for any kind of company. Let’s start with a, let’s say, tough question. What do you think is the greatest challenge when assessing a candidate for a software development role?

Marcin Byrdziak:

It depends on which organization you’re aiming for; we need to specify some conditions.

Wiktor Żołnowski:

Yeah, yeah. So let me start differently. So let’s assume that we have startups, scale-ups, corporate businesses – you know, organizations that are not purely software companies but do have some IT department or software department. What are the differences between these, and in comparison, what are the different challenges that those companies are facing?

Marcin Byrdziak:

So from my experience when working with people across different timelines of the product that they are building, usually the challenge is that they hire candidates for the wrong time period of the project that they should work in. I would say that for every technical role, either a senior developer or CTO or, I don’t know, UX – this will apply for all of the roles – different candidates work better in the area where you start building a new product, new applications. And this is a completely different skill set that is needed if you need to scale the application up or maintain it or write new features and so on. I used to name it as “architects” and “artisans.” I think that it’s something that I found in a book, but I don’t remember the name currently. What is the difference between them? So basically, an architect is the person that looks at the big picture. Earlier, I was saying that I was working with a lot of technologies; I know how the front-end should work, back-end, mobile, and so on. I would say that those people are actually focusing around a lot of technologies, they can see the big picture, they can design the whole system, they can work with the business and talk about all of the streams, not only about the back-end. And artisans are the guys that are usually focused on details, and they are focusing on a single technology. So for example, they are experts on Java applications; they know everything, they know all of the details of the Java runtime environment and so on, and they actually can build any feature that has any complexity.

Wiktor Żołnowski:

So let’s assume we are recruiting for a corporate business. Who is better: artisans or architects?

Marcin Byrdziak:

I would say that for a startup – and the ideal situation would be that you have both in startups and corporations – but usually in startups, you don’t have money to have artisans. And for the corporations, you need so many people that you cannot just build it with architects. So I will say that you need both people. And you say, what is the challenge? So the challenge is to find a good balance and build them. So basically, in startups, you would look from the beginning – ideally, it would be to just find all of them for architects instead of artisans, because artisans will just leave your organization as you will not be able to give them the really complex, single-technology-focused tasks they are used to implementing. But at some point, you would need to add artisans to your squad if your application will be scaling. And for the corporation, architects will be bored because you will not start applications so often, and the big picture will not be needed. But artisans will be needed because you really want to maintain, scale, debug, and optimize applications. So they will be best to keep with your organization as long as possible.

Wiktor Żołnowski:

You mentioned before that it’s also very important when you’re hiring not only software developers but, for example, a CTO, that the CTO for an early-stage startup is a different person than you may need when you are scaling. And most probably a different person than the person you hire for a CTO role when you have a grown business, a corporate business like, let’s say, you know, Google or Facebook or another company like that. Could you elaborate a bit more on those differences?

Marcin Byrdziak:

So I had a chance, actually, to work with a CTO on a startup where the CTO was from enterprise solutions. So it usually doesn’t work because such a person, when you start, starts by building processes for the organization, something he learned from his previous organization, and it doesn’t work in startups usually. It would be great to just be aware of when you would hire a CTO for the time when you are in an organization. For example, I know that I will be working much better in a chaotic environment and building new applications, the start of the applications. I will be much less performant in situations where they need to scale and optimize the application, building processes to just work at it, how is this solving the better experience. And I’m just important around some time of the project where you’re doing the same stuff and the same stuff, but you need to just make it on a better scale.

Wiktor Żołnowski:

Don’t you think that it might be hard to actually assess candidates for these particular roles at a particular time in the organization? Like, do you see any issues, any challenges here to provide good questions, a good recruitment process for the candidates who are applying, let’s say, for a startup as a CTO or even as a software developer, and the candidates who are applying for a software developer or even C-level or top management level roles in the corporate world or in scale-ups?

Marcin Byrdziak:

For me, the recruitment process is always around a single thing: behavioral questions. Something that I see from recruiters that are not really experienced is they usually ask closed questions and ask something that you can Google. In the organization, it’s really hard to actually check stuff like soft skills or where you belong or what you really like to do. It’s much better to just ask open questions. For example, if you’re a directing programmer and if I would like to see if he can actually build applications, not if he knows Java or any specific technology, I would ask if he can design me any particular application, I don’t know, Facebook, anything. There is no right answer during an architecture design session. Like the big picture, I can just go deeper in any selected area. I’m not interested in a specific one from the beginning, right? Let’s open the dialogue. I see how the guy thinks, how he builds solutions, and if he’s someone that I would like to work with. This also shows me the candidate’s experience – if he worked for startups or organizations, if the candidate is an over-engineer or builds a really good, pragmatic solution for the product. So open questions, behavioral questions are much better than asking closed questions or direct questions where you specify to the candidate what answer you’re looking for.

Wiktor Żołnowski:

It’s mainly like asking the question that the candidates could or even should answer, “It depends,” and then dive deeper with the details, like it depends on the context. That’s correct, or I would say that’s the kind of question where you cannot prepare for them before, before the call. Even if you will know the questions, you have no idea in which direction the dialogue will go. Sounds interesting. So what is the type of people you are looking for when recruiting for Pragmatic Coders?

Marcin Byrdziak:

So we definitely look for the architect-type guys that are really flexible and they don’t focus on a single technology. We’re building from scratch, and this is usually what we are doing, like building applications from scratch or working in small teams, and there is usually not a lot of space for guys that just work in a single technology. And this is from the technical perspective. And usually, something that is much more important for us is soft skills. And it’s from the statistics. So usually, at Pragmatic Coders, if we look at our data from our past years and our rotation, we will see that most people that left Pragmatic Coders, we either just fired them or we couldn’t find a good common language between the company and the candidate, and that was actually soft skills, not the technical ones. And technical skills are much easier to learn, it’s much easier to mentor and to teach people how to do technical stuff, but soft skills are something – I really don’t want to say that it’s impossible or it’s not possible, but it’s something that at least I don’t know if it is easily teachable.

Wiktor Żołnowski:

And yes, and especially in current days when you’re mostly working remotely, so yeah.

Marcin Byrdziak:

So I would say that for me, it’s nearly impossible. So looking at the soft skills is something that we are focusing on at Pragmatic Coders to hire people.

Hiring for attitude and core values

Wiktor Żołnowski:

I know that our recruitment process is based mostly on the concept in the book that is titled *Hiring for Attitude*. And in this book, this concept about the evaluation is that the technical skills are pretty easy to be checked everywhere. That’s from this book that I don’t remember the exact number, but it was something about 80% of people who were mis-recruited – and by mis-recruited, I mean they were fired after the trial period or fired during the first year of cooperation with the company – were fired not because of their technical skills or lack of technical skills, but because of the lack of cultural fit or the soft skills that were required by the employer. Let’s talk a bit more about this cultural fit. So when you are recruiting for Pragmatic Coders, what are the, let’s say, top three to five attributes, skills, or mindsets that you want to have when you’re hiring someone, checking for what attributes and features we are looking for from candidates?

Marcin Byrdziak:

From high performers, we found out something that we call values, and then we just focus on Pragmatic Coders’ values. The main problem is you can just take a person that has been working for a really long time at Pragmatic Coders and just send them to the interview, and that person usually will have a high percentage of hiring a good candidate. But we need to scale. We cannot send the same person to interviews all the time, and not only because of the money, but a single person will not want to just go to them all the time. It doesn’t sound like a great career path. “I was a senior developer, architect, and then I’m a recruiter.” Exactly. So we need to scale it, and this is something that we are looking for: already existing processes and standards that can help us with hiring for attitude. And this is why we started with working with the book that you mentioned. The core values that we found out that our high performers have are: We Deliver Value, We Desire to Grow, We Take Ownership, We Are Team Players, and We Are Pragmatic. Basically, we go focused on those five. We really think that they really incorporate the principles that our employees were using when working with our clients through nine years. Currently, as today we have the birthday of Pragmatic Coders, so this is like nine years, and we haven’t changed them a lot during our time. We changed “We are partners” to “We deliver value” to just make it easier for guys to understand what we want to achieve with this particular value. And our whole soft skill check, which we call a culture check, is focusing on asking questions that tell us if the candidate actually fits our organization. So it’s not like every person will work out. Some people will not go through the recruitment process, and that person can perform really well in other organizations. We’re just looking for specific stuff in the candidate.

Wiktor Żołnowski:

So could you provide some examples of the questions assigned to the particular values and, I know, maybe some examples of the correct answer and the answer that is not the answer that you are looking for? I’m not saying it’s an incorrect answer, but the answer that will not fit the culture of Pragmatic Coders?

Marcin Byrdziak:

So usually, if we ask questions about ownership – I don’t remember the exact questions; that’s something that we change from time to time – but we are looking for the answer that’s around the candidate who, in place, will be challenging the things that are happening in the client’s organizations and in the teams, and looking for the most effective way to just build the product, to take the best decisions, to do additional stuff, to challenge the requirements from the client to do this best. And the people that don’t fit Pragmatic Coders are those that usually tend to work with management and do tasks that someone will give them. So that would be the example. Both people are needed for some stuff. So basically, if you are starting a startup, scale-up, and a bigger organization – usually in a big organization, you don’t want one of the guys that will be challenging every decision from the management, because they will be wasting the time of the management and their actual work with them. And this is exactly what Pragmatic Coders wants, such stuff, because the teams are small, and the decisions that need to be made take money. So as soon as we can just change the process, change the way how we build any features, anything like that, so that would be really something beneficial.

Wiktor Żołnowski:

I also remember from this book, *Hiring for Attitude*, that there is one other aspect, which is coachability. And I know that we are testing it very much during this culture check as well, and our core value “We Desire to Grow” is actually about coachability. Do you have any examples of the questions that we are investigating?

Marcin Byrdziak:

And this is exactly what our HR doesn’t like because such questions just take you from your comfort zone. Yeah. Usually, if you get the questions around, if the recruiter will convince you that he will contact your boss from your previous jobs, then you are just going outside the comfort zone. But that technique can give some truth about how your performance was in your previous organizations and jobs. And basically, this can force you to just give the truth about how your boss was thinking about you, what are your strong features or where you are weaker. And the crucial thing is what you are doing in organizations. So how to check coachability? A crucial part is to get the candidate out of the comfort zone and look for something that will ensure he needs to tell the truth because then there is a chance that you will verify it with his previous boss or manager or whatever.

Wiktor Żołnowski:

Yeah, that’s a good idea to ask those questions. What do you think your previous manager would say if we asked him about your strengths or your weaknesses? Yeah, that is something that I also always like to ask the candidates. It’s pretty easy to discover if someone is telling the truth or if someone is not telling the truth. And especially when the candidate says that they do not know or they do not recall. Of course, there are a few follow-up questions like, did you have regular one-on-one meetings or any other feedback form with your manager or maybe with your surrounding, I mean, 360-degree feedback? And if those people confirm that they did have this kind of feedback and they do not remember anything that was valuable there, that only convinces me of two things. There is some probability that those methods were ineffective, but there is also a great probability that such a person didn’t recognize those feedbacks or didn’t care about the feedback that they received. So the coachability level of such a person is pretty low.

Marcin Byrdziak:

That question can really quickly end the recruitment process. We have had it happen that some of our candidates didn’t want to talk about previous jobs. They didn’t want to just give any contacts or just clearly said that they don’t want us to actually talk about them with anyone that they were working with. This was usually something that we didn’t want to work with such a person, actually. There is no any extra comment on that. If there is no reason for that, because of course, I can understand that someone could have been working in some, you know, pathological organization that he doesn’t want to even recall, but it’s also about the transparency and saying that, “I don’t want you to contact them because I don’t have a rational relationship with them” or “I didn’t end up the cooperation in a good way.” And that’s still okay if the fault was somewhere else, not in the employee itself.

The recruitment process at Pragmatic Coders

Wiktor Żołnowski:

Okay, is there any difference between recruitment for the technical roles, I mean the software developers in this case, and recruitment for roles such as UX designer, product manager, or any other role that is not strictly related to programming in terms of the process, in terms of the questions, or in terms of what you are looking for?

Marcin Byrdziak:

The process is the same, especially the cultural check. What we are doing, even outside of the technical roles – so we are using the cultural check for any back-office roles as well. What’s changed, of course, are the technical questions for the competencies and skills. And from my perspective, that’s enough. We don’t need another process; we can just focus on doing better stuff like the culture check that we mentioned, that is most important to hire the best candidate.

Wiktor Żołnowski:

So if you are talking about the process itself, could you walk us through the typical recruitment process, step by step, at Pragmatic Coders? How does it look like?

Marcin Byrdziak:

So when you will send a CV to us, you will have contact from the recruitment team, some technical call that’s just around 15 minutes long or something. And basically, our recruitment team just checks if there is a basic fit between you and Pragmatic Coders and just asks if you want to go through the next step, which is actually a technical interview that is mainly focused on checking the skills. And the final step is the stuff that we call the cultural check. And usually, we just try to divide it as much as possible, so the technical stuff and the culture check don’t focus on the same stuff between those two things. And also, different people do such stuff. And after the culture check is something, that’s everything that we need to just find the best people. This is like going for the decision that we are trying to just do as fast as possible.

Wiktor Żołnowski:

How do you make a decision? Like what is it based on? What is the impact of the culture check on the decision? What’s the importance of the technical part? How does it look like?

Marcin Byrdziak:

A lot of things happen here. Currently, we are on the way that the cultural check is standardized, and we have a score from it, so it’s pretty easy how we can learn from them, which is history and statistics from our people that we hired and what the score was from the culture check. So we can clearly say how the candidate will be performing at Pragmatic Coders based on our previous experience, and we can just lower or hire them according to the market status. So you can just have our expectations. If the talent pool is pretty low, then we can just lower them but still have control over it. And we are working on doing the same with the technical interviews as well. Currently, we are at the moment that our best people are doing technical interviews, but we need to delegate that at some point, so it’s a great moment to just look at the standardization of the technical interviews and do pretty similar stuff as the cultural check. So we started with the culture check as it is the most important for us, but it’s time for the technical as well. So we’ll have that score and statistics at some point as well. Right now, it’s like the trust that we have in our team in the organization.

Wiktor Żołnowski:

So what would you do in a situation when, for example, you have a candidate who went through the technical check very well, like 9 out of 10, and then went through the culture check, let’s say, 4 out of 10? So would you hire such a person or not?

Marcin Byrdziak:

This depends on what we would need from them. If we need a person for a single-time assignment or a really short job on a fixed-term contract and so on, then maybe I would just try to think about if we can do it. But if that will be a person that should stay with Pragmatic Coders as long as possible, completely no.

Wiktor Żołnowski:

There is no perfect recruitment process. Like, I know that you and your team are still improving it, etc. But maybe you can share with us some spectacular failures or some mistakes that you made when designing a recruiting process in the past, and so also share with our listeners what type of mistakes they should avoid?

Marcin Byrdziak:

Transparency from the start to the end with candidates and with employees causes most of the errors during the hiring process. And it’s not specific to our failures, but it’s something that demotivates people at some point – a lack of transparency that we are doing in the recruitment process. And just to give some examples: Apparently, a candidate understood that he will have an evaluation after three months and will get a raise with them, but that’s definitely not the case. So this information, lack of transparency, and that person was really demotivated after the three months of working with us. And at some point, that person left the organization. The trust from the beginning was crushed, and we couldn’t just find a good solution on how to work with it. And this is something that can be really easily fixed from the beginning. Other stuff, again from the transparency bucket, is that apparently, we guaranteed a project from the beginning, and this was not the case. So usually, if we are working for a company that has a lot of clients, you cannot guarantee clients at that point. You can just talk about things that you are working on at the moment. If the company said that a project will be available, then again, it’s okay. But usually, you cannot guarantee stuff at the company, and that level of transparency is really important from the beginning. And I would say that transparency is something that organizations should look at in the process, especially because organizations usually send people that aren’t aware of all of the things. If there is a bigger organization, then usually some team member is going, but probably that person will not be hired for that team, and that person has no information around all of the specifics and cannot guarantee any sales stuff. So transparency is really important, and that’s like the recruitment team’s job or asset, that transparency is really high across all of the steps.

Onboarding and the impact of remote work

Wiktor Żołnowski:

We already mentioned onboarding, actually, like what happens after we hire people. So could you also describe how this process looks like? So okay, we already hired someone, and that’s not it, it’s just the beginning. So what happens after we sign a contract, the person shows up on the first day in the office or remotely? So how does the onboarding process look like?

Marcin Byrdziak:

Following the crucial case is actually to just see them at the office remotely, visiting our office and working at least one or more days with the team to onboard into the project as much as he can and just ideally integrate with the team, go for a beer – that would be ideal, but we cannot force people to go for a beer on their first day. But we can just enforce that the people will meet with each other face to face. Of course, we have a lot of different stuff: HR, recruitment, delivery, finance, and so on. I would say that the most crucial step is to just meet the people that are responsible for it so the guy can know which person will be best to address any questions that he’ll have at some point. So that would be onboarding, but we can just go further. So we have this period, usually three months – and this is a standout in IT – to just assess some people if they are working correctly during the three months, and we are doing the same. We just divide this three-month period into two parts to just share the feedback with the candidate and the team to have the time to actually see if something is going wrong or if there is everything okay. And after three months, we just decide if this is okay from both sides. Of course, it’s not like only Pragmatic Coders decides, but we are looking for an agreement that we can work with each other for across these three months. But still, I would say that onboarding ends after three months.

Wiktor Żołnowski:

Yeah, in one of the previous episodes, we discussed with Jakub Dobosz how our training works, how our onboarding looks like for the first year, and so on, how the growth of our employees looks like later on. You already mentioned remote work. So in your opinion, how did the entire market change – I mean the employee-employer market – and how did recruitment change during the COVID-19 pandemic and afterward?

Marcin Byrdziak:

The first change is that we cannot only recruit in the offices. It’s something that is past us and we will not be doing this any further. I would say that remote work adds a really big challenge for the IT market, and you’re surely aware that it’s really hard to find a job as a junior developer or any other role. So basically, it’s not possible because we don’t know how to mentor, how to educate juniors when they are working.

Wiktor Żołnowski:

Right, we, and the entire market, are observing this exactly. It’s not only Pragmatic Coders; we see this across all of the market, all of IT, and it doesn’t help. It doesn’t help the new people as well, and it doesn’t help companies because they usually just cannot grow with someone that has fewer competencies. And not every organization can hire only seniors, and we are not at the moment that we can just hire as many seniors as possible because they are not available on the market.

Marcin Byrdziak:

So I would say that this is like the first biggest thing that was affected by remote work: that we don’t know how to teach, how to mentor those people. The second thing is, I would say that it’s like my understanding, but I have a few proofs about it, that our programming skill was really much worse than it was before remote working. So.

Wiktor Żołnowski:

I also noticed, it was like the end of 2022 when I noticed that when we analyzed all of the CVs that were sent to us by candidates, there were candidates who had at least two years of experience and more, and candidates who didn’t have any experience at all. So there were no candidates with one year or one and a half years of experience. That was the period when the COVID pandemic started, when homework started, when the lockdown started. And I believe that that confirms what you said, that because of remote work, there is a huge gap in terms of new people on the market, new people starting their career in IT. Of course, there are some exceptions, there are some people who still managed to find their job, and there are companies who are trying to fill that gap, but it’s still not enough. Like most of the companies, the majority on the market, do not hire junior developers because they do not know how to teach those people how to do their job in an efficient way. They are even willing to pay more for experts instead of hiring more junior people to teach them, even for less money. And also, it’s much harder to have company people who are working remotely spend their time teaching others who are also working remotely.

Marcin Byrdziak:

It’s pretty hard to share knowledge remotely. When I am speaking with people that work remotely, they usually tend to say that they are much, much more effective during working remotely, and it’s hard to disagree with it because the performance of a single person usually can be higher, but it’s coming at some cost. So what is the person doing? That person optimizes their time in remote work, and that person doesn’t waste time to work with a junior – “waste” in quotes, exactly. It doesn’t work with even juniors, doesn’t mentor anyone, just skips meetings that don’t deliver any value for that particular person. And yes, that person can do more tasks, but we are not doing projects with a single person. If you will be doing single-person projects, then usually I would actually agree that remote work can be much better for projects with a very single person, but we are not at that moment. So the major reason why it’s not working is because those people don’t work on team player responsibilities, don’t teach people, and this is why we are struggling as IT with incorporating juniors throughout our organizations. It’s a really big problem that we as IT will be handling for, I don’t know, the next two years or something, and we don’t have any solution for it. I don’t see it currently.

Wiktor Żołnowski:

Yeah, maybe the way we are already doing it, that we are, say, forcing people to show up in the office more often, like twice a month, for new people twice a week. That is something that I see, I already see the results of that. I already see that this knowledge sharing, the velocity of the team is increasing, etc., on the team level, maybe not on a personal level. Of course, some of those people complain that, “No, we are wasting time in the office, I’m spending most of the time in the kitchen drinking coffee, speaking with people.” But when asked, “What are you speaking about?” “Oh, about the product that we are working on, about our job.” Maybe that’s knowledge sharing here.

Marcin Byrdziak:

It sounds like a thing that we forgot about. But still, short-term, we are at a moment where the talent pool on the market is really high. Yeah, and we can try to look for candidates that will be visiting the office, but that will end at some point. Next year, probably, will be after that, and we need to learn how to do it in a remote environment, or something else will change.

Wiktor Żołnowski:

Okay, comparing the recruitment three years ago, when most of the recruitment happened on-site – people came to the office – with the remote reality that, even when we rented this office, we decided to launch two conference rooms, small conference rooms that will be designed especially for recruitment. And then the pandemic started, then we were doing remote recruitment from these rooms that we didn’t need. But do you feel that there is any impact of the pandemic on the way companies or we started recruiting people because the equipment became remote instead of the on-site recruitment?

Marcin Byrdziak:

From the beginning, we didn’t change anything, and we made a lot more mistakes during hiring. For me, at least, it’s much harder to perform a cultural check remotely versus face-to-face, where you don’t see all of the body language from the candidate, like normal people stuff that you can just do when you’re talking face-to-face. And yes, we made more mistakes for it. How we reacted to it: we added some more standardization during the process, and this is also why we are looking for standardization of technical interviews, to just make it easier for people to do it. So it’s much harder for the recruiters to do such conversations. And yes, we need to learn how to do it as long as we’ll be doing it more. Maybe not this year, but next year, probably. And if it will be possible that we can just invite the person to the office, then surely we’ll be doing it because this will be much easier, and statistics show that we have a better success ratio for hiring.

Wiktor Żołnowski:

And you’re mentioning about the standardization of the technical interview because we have the data about the culture check that now we can analyze after a few years of running this culture check and having this standardization, having the scoring system there. We can easily, as you mentioned, go through all the data and see where we made the mistakes, why we had a mis-hire. And our area that when you showed me this data and showed me all the candidates, like maybe not all of them, but in many cases, the data showed us that that person will have already quit or been fired because they didn’t fit the culture 100%, but you know, there were some yellow warning lights that we saw in the data. But still, we made a decision that wasn’t the best. But also, as you mentioned, some of these candidates were assessed remotely, so also the scoring wasn’t as good as for the people that we assessed on-site.

Marcin Byrdziak:

I would say that I would consider hiring that person if that person were working from the office. That’s the scope when you can try to work with the soft skills and the writing problem. Or ideally, I would accept a lower score, at least not from the growth category, because that’s something that if that person is not coachable, then we will not do anything at the office as well that can help us to grow with that person. And I really like to date with junior candidates because they usually don’t have any bad habits – at least bad habits for Pragmatic Coders, because they can have good habits for different organizations. And we can work with that person to just try to do as much as possible. But as we are saying, if that person is working remotely, then it is usually a matter of time. As I will say, this is mostly like a decision about money that we can earn or something like that, but usually it is like a short thing because a person that leaves Pragmatic Coders is always demotivating the team. Yeah, unless they are fired because of some misculture or mis-hiring problems that everyone has from time to time. Fortunately, we do not have it very often, so it’s not so bad. Okay.

Candidate experience, growth, and retention

Wiktor Żołnowski:

Let’s switch a topic to candidate experience. So how do you ensure a positive experience for candidates who are going through the process of Pragmatic Coders? You mentioned transparency is very important, but maybe there is something else?

Marcin Byrdziak:

So we mentioned already that we have standardized the process, and it usually happens that we are getting really good feedback around it because we are not sending unprepared recruiters for all of this stuff. I think that’s enough. You don’t need a building a really complex recruitment process; it just needs a few nice things in it, like transparency, a good offer, a good interview process, and so on. That’s really something that’s working really well for us. Something that also is really good is that we just share the feedback with the candidate at the end as well. So we’re just not leaving the candidate without any response for it. But still, it’s transparency, right?

Wiktor Żołnowski:

Perfect. Let’s talk about the things that also happen after recruitment again. Let’s assume that we recruited top talents. How will Pragmatic Coders ensure they grow and their retention? How do you care about people so they will not leave the company?

Marcin Byrdziak:

Something that probably is out of the discussion is that the offer needs to be good. If we look at the statistics, they will all show us that the offer, the money, is most important. The second thing is doing good projects. This is something that probably should be defined because this will be something else for anyone. We have limited things that we can do about it. So the money basically depends on the market, on stuff that we add in our condition and so on. Good projects, probably as well. But we can learn how to do better marketing, what is the UVP (Unique Value Proposition) of the company that we have. It’s the knowledge sharing that we can do. Usually, the most valuable thing that we can give our employees is the knowledge and the time for them to just get it. And we are focusing mostly on doing this knowledge sharing as fast as possible so our guys can quickly become better developers.

Wiktor Żołnowski:

I also recently posted on LinkedIn that some of our employees or former employees became a CTO or CEO of their own startups, or they were hired as technical leaders, CTOs, etc. And this is something that I also think is something that we managed to do pretty well at Pragmatic Coders. Since our people are leaving the company or starting their own company, that’s part of growth and knowledge gaining, knowledge sharing, that is something that assures the retention of Pragmatic Coders as well, even though some of them are leaving the company and they are starting their own. “Retention” may not sound very good, but from my opinion, it’s something that is actually good and is positive retention as well.

Marcin Byrdziak:

I really would like that every person leaving PC would be like that. Personally, for me, it’s positive retention, especially that we usually maintain relationships longer. Sometimes such people just go back to us. Usually, this is because something doesn’t work well for them in a different organization or different companies and so on, but still, we keep relationships. And sometimes we are even just handling this relationship, but now the relatives we are doing business with. We have at least two cases from the recent year that our former employees became our clients. So if such people leave us, join some other company or start their own company, and then hire us to work with them because they know the value that we can provide.

Tips, the future, and final advice

Wiktor Żołnowski:

Okay, so let’s try to figure out a few tips and tricks for startups and other companies that are just thinking about starting to do recruitment right. I’m not saying that they’re just starting, but they see that they can improve. Maybe after listening to what we had to say here, they realized that they could do some things better. What are the top startups with top advice for startups and other companies that you still recommend them to do, to start with when designing their recruitment process, when starting their recruitment process?

Marcin Byrdziak:

Imagine this question was that if I will be not technical, how I would build an IT department in a company. And I believe that the only way that has a high possibility of success is to just share equity with someone really experienced and just delegate such stuff to that person. Why so? Because if you think about it, can you just hire senior developers for an organization that doesn’t have an IT department? Probably not. We are not at the moment that we can compete with other organizations. We probably cannot compete with money, we cannot compete with knowledge sharing. The product is usually not at the moment that it can be something that will help them to make the decision. So I think that I would like to have a person that will do it for me, and most likely that person will need to start from hiring juniors or regulars and mentor those people, who will be really good developers at some point. Other stuff, like if I will be a startup – and if I would select a startup, I understand it as a concept where we just check if our product will be performing well – then I will just get a company that’s doing product development. Let’s say, what is the statistic? Nine out of ten startups are failing, right? So usually, I would have a really big chance that my startup will collapse. So why should I just hire people for several months and fire them after that? Yeah, so maybe it’s just better to just work with a company that can do it and just has experience and so on. And when my product will be a success, then just think about my own IT department.

Wiktor Żołnowski:

And this is something that I would like to also talk about. You said that hiring the product development, namely a software house or software development company such as Pragmatic Coders. In our history, we also like to offer our clients something more than just product development because we offer them the possibility to transfer some of our employees into their organization, the Build-Operate-Transfer model. Could you tell us a little bit more about it? How does it work? What are the success stories? From your perspective, is it still positive retention, or do you consider it as something that wasn’t very good for Pragmatic Coders?

Marcin Byrdziak:

It was an agreement between them that they wanted to work for the client because the product was good, because the work that they are doing was great, and they could get a better offer and get higher expectations from what we’ll be doing in there. So you will not do a CTO from a PC member; you would like to have that person on your board. So I have only positive memories from such transfers. But still, yes, it’s challenging for Pragmatic Coders to lose such people, but we were talking about it. This is like positive retention for the people going out and using their skills in a much broader way.

Wiktor Żołnowski:

So let’s talk about the future. What do you think, what do you see in the future in terms of recruitment for digital product teams, digital product companies? What will change in the next, let’s say, five years?

Marcin Byrdziak:

We’ll really use AI for a lot of stuff. So, we’re talking that we will need to do remote interviews and solve data they can imagine can happen. We can have software that will be analyzing body language and the risk process from the candidate and assist the culture check, that it fits the organization that we are hiring for. I will just go, if we are talking about the future, five years, and the speed of artificial intelligence growth, I would expect that this is something that you can do. I wouldn’t expect that it will be completely automatic if this is five years long, but I wouldn’t like to work for the company that has automatic interviews. But that company can just incorporate tools that will help us assess the candidate and just make a better fit for the organization.

Wiktor Żołnowski:

Are there any resources or tools that you would recommend for companies or people in companies who are building their recruitment process?

Marcin Byrdziak:

If you have a few people in the organization, then you probably don’t need a lot of things. You have trusted people, and you can just perform interviews really well. But when we are scaling, then I would say that standardization is something that we need to go for, and mostly standardize the hiring attitudes, the behavioral stuff, at the beginning, because most likely you don’t have any problems with assessing technical skills, but you have problems with the soft skills of your guys. And it’s a common problem that many organizations have.

Wiktor Żołnowski:

What do you think is the most common misconception about recruitment that you would like to debug? Or like, what do you think are the common mistakes that companies and people do when recruiting people for software projects?

Marcin Byrdziak:

The biggest one is that you cannot check soft skills during the recruitment process. A lot of people think that there is this famous three-month period that is something where you need to check it. And no, you can do it in the interviews. It’s hard, it’s not something easy, and it requires all organizations to learn and just make a good culture check for this to happen. I would say that the biggest misconception is that you cannot do it from the beginning.

Wiktor Żołnowski:

So last but not least, if you could give one piece of advice to candidates who would like to apply for product development companies, what should they focus on? It may be an example of Pragmatic Coders, but it might be any product company, not necessarily a software house.

Marcin Byrdziak:

Let’s focus on the interviews that are covered with behavioral questions that you cannot prepare for because it’s not possible. So how do you prepare for that interview? I was reading some article recently when I was working at the standardization of technical interviews. I don’t remember the name, but there was a quote from a CEO from some company, and actually about the concept that you need to prepare three stories for any interview that you can go to. And three stories are about the project that you are working on. And this is like one is a passionate project, the second is a group project, and the last one is a success project.

Wiktor Żołnowski:

That preparation will give you a possibility to answer any question. That sounds really great for the candidates, not so great for the interviewer, yes, but if you consider that there is no right answer for the questions, but the recruiter is looking for things that really matter to the organization, then why not? Yeah, exactly.

Marcin Byrdziak:

And if you will be honest when you are preparing this story and then telling the story, then you can save a lot of time that you’d invest into a company that maybe also is a mis-hire for you, like you won’t fit their culture, and then you will just waste the time and energy, and they were wasting their time, money, and energy. We have limited time in the world, and we have limited time that we can spend on working. So choosing the right company to work with is as much important as choosing the candidates to hire, or even more important because it’s more personal for you. I had a lot of interviews where the candidates really struggled to give some examples from their personal experience. So I would even be more happy that they will prepare and know what we will be looking for and so on because the dialogue is much more open at some point. So yeah, that will be my advice for people. But from my experience, a lot of companies just ask closed questions that you can usually Google. Then yes, you can prepare for them and so on, but usually, that process is not really good. It doesn’t tell you as a candidate anything about the company, and the recruiter cannot just check anything about the candidate as well. So this is usually something that you can use to assess the technical perspective, not the mindset, not the cultural fit, and so on.

Wiktor Żołnowski:

So no worries. Even if the job market right now is not as good as it used to be like two years ago, it’s still very easy to find a job, but you can find any job. The question is if this is the job that you would like to have. So to all the candidates, no worries, especially if you are not a junior person who already has a hard time finding a job, then the market is still good for you. Okay. But thank you very much for this conversation. It was a great pleasure for me. I hope that everyone who watched it, who listened to it, will also feel that they spent their time in a good way. And to anyone, if you would like to work with us, regardless as a product company who is looking for people to hire or as a candidate who would like to join us, please do not hesitate to contact us. And of course, subscribe to Pragmatic Talks and watch our next and previous episodes. Thank you very much.

Marcin Byrdziak:

Thank you, Wiktor, for the invitation.

Wiktor Żołnowski:

Always welcome.

This episode of Pragmatic Talks is delivered to you by Pragmatic Coders, the first software development partner for startup founders. Be sure to catch all new episodes. Subscribe to our YouTube, Spotify, or Apple Podcast channels. And if you are thinking about building your own startup or struggling with product development, contact us and find out what we can do together.