Welcome to another episode of “Code & Chatter” discussion panel. Today, we’ll discuss recruiting a senior software engineer. We’ll tell you how this process looks at Code & Pepper. For this conversation, I’ve invited three people who regularly participate in such recruitments.
Introduction to the Panel
Ewa Dusza: Agnieszka, let’s start the introduction with you. You represent the project management department at Code & Pepper, so you check what requirements a candidate must meet from the project and client’s perspective. Hi, Aga!
Agnieszka Kopiczko: Hi.
Ewa Dusza: Aleksandra (Ola), our recruiter, the front line, the first contact with the candidate, but also the person overseeing the entire recruitment process in our company. Hey, Ola!
Aleksandra Pluta: Hi.
Ewa Dusza: Piotr, our representative of senior developers at Code & Pepper. A warm welcome to you.
Piotr Ujazdowski: Hi, nice to meet you.
The Recruitment Market for Senior Software Engineers
Ewa Dusza: Aleksandra, I’d like to start this discussion with you, as you’ll not only introduce your role in this recruitment but also give us a general view of the market, how it looks today for senior positions.
Aleksandra Pluta: Yes, regarding the current market, we’ve noticed several significant fluctuations in recent years. The situation has indeed changed, directly affecting seniors’ positions in the market. Last year, especially, we saw many layoffs. This situation was global, not just in our country. According to Layoffs, a global tracker monitoring IT industry layoffs, in August 2023 alone, there were 225,000 layoffs. That’s the same number we reached for the entire year of 2022, so it’s quite significant. And we still have several months left in the year. Unfortunately, I couldn’t find specific data for Poland, but we know that some companies underwent restructuring, and layoffs occurred in both software houses and product companies. However, according to a report from Just Join IT, a leading Polish job board, the number of job offers in Poland hasn’t really decreased. The Polish job market only saw a two percent drop in offers and professional proposals from IT companies. So, theoretically, the situation for programmers in Poland hasn’t changed. However, employers’ requirements regarding seniority have changed. Seniors have seen a 9% increase in interest from IT companies this year.
Seniors have seen a 9% increase in interest from IT companies this year.
In contrast, juniors experienced a 30% drop in interest, and regular developers saw a 5% decrease in offers. Employers’ requirements for candidates have also changed. Many companies are now looking for top talents, well-suited for their organization. People who can join a project, be ready to act, and quickly adapt to the organization’s needs. So, recruitment requirements have somewhat increased. Both at Code & Pepper and in the market, we see more candidates, including seniors. We recently recruited Node.js developers and Angular developers and were literally flooded with CVs. Programmers must realize that their market situation has changed and they need to engage wmore in recruitment. They have to demonstrate their skills more than in previous years.
Ewa Dusza: Do they also need to lower their financial expectations?
Aleksandra Pluta: You know, I think the financial bubble hasn’t burst yet. Maybe the salary ranges have slowed down a bit. They’re not soaring as high, but we’ve maintained last year’s salary level.
Ewa Dusza: That’s good news.
Aleksandra Pluta: Yes. Regarding how the market perceives a senior, it’s hard to speak of a clear-cut definition. Each company has different requirements and needs. Also, we at Code & Pepper have our definition of software engineer talent in general but also in specific technologies (Node.js engineering talent, React.js engineering talent, Ruby Engineering talent, React Native talent, Angular engineering talent). Analyzing various discussions and job offers, it’s evident that many companies still strongly focus on work experience. The market views a senior as someone with at least 3 to 5 years of commercial experience. It’s hard to disagree that years of experience and tenure are a kind of promise that the candidate has encountered various situations, both technologically and business-wise. But we must remember that this can be misleading. There are people who might spend 5 years on one project on a very simple web application, with limited opportunities for growth.
Looking at other requirements, of course, we can’t escape from technical competencies. Piotr will talk more about this shortly. But from a recruiter’s perspective, we expect seniors to have a broader understanding of technologies. Until recently, a back-end developer only dealt with back-end. Now, we expect them to have basic cloud skills and even some DevOps areas are coming into play. So, continuous learning and skill improvement are essential. You can’t rest on your laurels. Important aspects are high-quality code, code optimization, and security issues. All these requirements are now appearing in the market, so keeping up with technological trends is very important.
Over the past few years, we’ve seen an increased interest in soft skills. Gone are the days of people locked in their proverbial basement, writing their code, uninterested in communication or teamwork. Now, it’s clear that programming is a team effort. Communication skills, the ability to conduct technical discussions, and the ability to talk to people outside the tech world, like business people, are very important. We’ll focus on self-presentation, finding common ground with people from different areas, and encouraging everyone to participate and express their opinions.
Gone are the days of people locked in their proverbial basement, writing their code, uninterested in communication or teamwork.
We also expect seniors to have some business skills, to look at the product not just from a technological standpoint but also in terms of future development. They need to be a kind of consultant for the client, helping them make more informed decisions that will impact the finances and development opportunities of the entire company. So, seniors must make decisions that may not always fulfill their personal ambitions but must align more with business needs.
Leadership skills also come into play. At the senior level, people with rich experience must share their knowledge with less experienced colleagues, exchange information, and look at the project as a whole, not just their tasks. They need to manage their work time and that of their less experienced colleagues efficiently, notice potential problems in the project, and react actively. So, it’s a very proactive attitude.
When we talk about a senior’s competencies, we can consider it through the lens of the letter T. There’s a concept that says the letter T represents our skills. The vertical line, the base of the T, is all the technical skills, expert knowledge. The horizontal line, the top of the T, is all the skills that support and enhance these technical competencies, like soft skills, business skills, and various analytical abilities.
Ewa Dusza: Let me interrupt you for a moment and let you catch your breath. In terms of theory – when screening candidates, do you consider courses, certifications, education? Does it matter, or is it solely based on experience, this assessment of a senior?
Aleksandra Pluta: It’s hard to answer that question. Each company has its own approach. I think education is worth having, especially since foreign clients often look at whether a candidate has higher education or not. There’s a lot of talk about the quality of various bootcamps and that those candidates aren’t necessarily prepared to work as programmers. But from experience, I know that in programming, determination and individual predisposition for development are very important. Even if you graduate from university and do nothing more with your professional development, that formal education won’t help you much.
Even if you graduate from university and do nothing more with your professional development, that formal education won’t help you much.
Ewa Dusza: OK, thanks.
The Recruitment Process at Code & Pepper
Aleksandra Pluta: Generally, as you mentioned, I’m on the front line, responsible for what’s known as screening. After the initial selection of candidates from the submitted CVs, I meet with those who best fit the profile of the candidate we’re looking for. This screening is a very preliminary stage of recruitment, a stage where not only do I assess the candidate, but the candidate also evaluates us as a company. We exchange information. I, of course, provide information about how we function as a company, our work culture, and verify with the candidate if this is the place they are currently looking for.
During such screening, recruiters usually ask very basic questions about experience. We try to check to what extent the candidate has worked with the required technologies, what challenges they faced in their recent professional projects. We also gather basic information related to availability and financial requirements. And we check soft skills, mainly related to communication and self-presentation. For Code & Pepper, this is very important because we’re not just looking for people for one project, but for people who will stay with us for years, who will cooperate with us in the long term. So, there’s a high probability that, for example, after a year, a programmer will undergo an internal recruitment, and we need to ask ourselves whether this person also has a chance to work on other projects.
This screening is also a moment for the candidate to ask all sorts of questions related to further recruitment or the organization of work in the company. So, it’s a two-way stage of recruitment, you could say. Regardless of whether it’s screening or further stages of recruitment, it’s very important to maintain a structure, an order, which will allow the candidate to find their bearings in this situation better. It’s still an assessment process, so it causes stress in everyone. Therefore, just be human during recruitment and try to relax our candidates with a short chat. At the beginning of each meeting, it’s worth introducing yourself, talking a bit about your role in the company, and also asking the candidate about their needs, how their day is going. So that they feel comfortable and cared for.
Candidates should view interviews as a two-way street, assessing the company just as much as they are being assessed.
It’s definitely necessary to inform the candidate about how the recruitment process will proceed, the given meeting, and when they will be able to ask questions of interest. When we move on to verifying the candidate’s skills, don’t start with heavy-caliber questions, but initially give more general questions, so that the candidate can comfortably enter the process and open up. Because if we ask a too difficult question right at the start, it’s guaranteed that the candidate will start to tense up and won’t feel comfortable in the conversation and won’t have a chance to present themselves properly. So, I think that’s the most important thing.
Of course, regardless of whether we are the first contact person, i.e., the recruiter, or a technical person, it’s worth informing the candidate about when they can expect further information and who will be in contact with them next, so they are not left without any information.
As for how to assess candidates, before I give some tips on how to do this, I just want to emphasize that we must primarily take care of our comfort. We can’t take on too many interviews in one day and also need to respect our time, project meetings. It’s mainly about the fact that our mood can greatly affect how we assess individual candidates. And here, before entering recruitment, it would be good for technical people, like Piotr, or Agnieszka, as our hiring manager, PM, who will also ultimately make the decision, to define their availability to the recruiter. How many meetings can we also set up during the week? This will greatly simplify the process and probably translate into the quality of the recruitment itself.
There are some iron rules to follow in the recruitment process. When we decide to conduct more general interviews with the candidate, we must strive to make it a standardized interview, i.e., we must ask the same set of questions to each candidate, so they are assessed according to the same principles, the same indicators. Therefore, it’s very important not to succumb to subjective assessments, but to very objective factors. Definitely don’t ask closed questions, because they won’t contribute much to the assessment of the candidate. We will strive to ask open questions, i.e., those that will force the candidate to speak more broadly. These questions start with “How”, “What”, “What do you think about”, “Tell us about your experience”. It’s also worth using probing questions whenever we start to feel that there is some misunderstanding of the message the candidate has conveyed to us or when we start to feel uncomfortable. It’s worth verifying on the spot whether our initial judgments are true. So, don’t be afraid to ask and also don’t be misled by very general answers. For example, during screening, when I ask candidates what they expect from their new employer, I often hear that they expect a nice atmosphere. But what does a nice atmosphere mean? For everyone, it will be something completely different. Always use paraphrases and confirmations, so the candidate can also hear and verify whether the message they sent was correctly read and understood by us. When we verbalize their statements, they have a chance to hear themselves, to determine if that’s really what they meant.
In recruitment, I also use various techniques for asking questions. I really like retro-behavioral questions, i.e., questions that refer to the candidate’s previous experiences, which bring out the scale of challenges they faced in a given project. For example, I ask them why they decided to use a particular technology, why it was that library and not another, and what their conclusions are after the project is completed. We also have different models for asking questions, such as the STAR model. It’s based on guiding the conversation and asking questions so that the candidate first tells us about their project situation, outlines the problem they faced. Then we will ask them about the tasks they performed. Then we ask questions about the actions they took to achieve a specific goal. And finally, we ask them about the result and their conclusions related to that experience. We also have the KAR model, which involves asking candidates about the challenges they faced, the challenges that occurred in the projects. We also ask candidates about the actions that took place in the project and the result, i.e., some general summary of the completed project. There’s also the funnel technique, i.e., asking more general questions to more specific ones, sometimes ending with closed questions. And I think if it comes to recruitment techniques, these are the most well-known methods used by recruiters and that can also be used at every level of recruitment, including during technical meetings, of course, translating them into more complex and technological issues.
In recruitment, we also encounter various errors, and it’s hard to escape them, regardless of the experience and length of service. The most common recruitment errors include, first and foremost, excessive reliance on one’s intuition, i.e., succumbing to one’s own feelings. This is something that often warns us and can be helpful, but it should always be verified on the spot. For example, there often appears in us the belief that “I feel that he/she will not be suitable”, or “I feel that this client will not feel chemistry with this candidate”. It’s worth asking yourself why this is so and in such a situation, it’s worth going to the other people involved in the recruitment and asking if they also have such feelings. It’s worth confronting and also looking at the job profile to see if our feelings are justified.
The most common recruitment errors include, first and foremost, excessive reliance on one’s intuition, i.e., succumbing to one’s own feelings.
One of the recruitment errors is also notes. I know it takes practice to note, talk, and assess – many activities at once, but I notice that many notes contain very subjective assessments. Here, above all, we should note even quotes from candidates, so that after the meeting we can refer to what the candidate said. Was it our subjective feeling, or did it really come from his mouth? And here, these notes should also be created right after the meeting, but not necessarily shared further, because after conversations with candidates, we are often very emotional and here the subjective factor of assessment still creeps in. So, it’s worth writing everything down, but give yourself at least a few hours to come back to it later and coolly assess whether what was written there is consistent with the objective factors that actually fit the profile of the candidate we are looking for.
There are also cognitive errors, i.e., simplifications and shortcuts of our brain. These are feelings that we have acquired and evolved over time. And although theoretically they should help us, they often disturb our objective assessment. And in recruitment, there are hundreds or even thousands of these cognitive errors. The most common cognitive errors encountered in recruitment interviews include, first and foremost, the halo effect. It occurs in the first moments of contact with the candidate, up to 20 seconds. Here we acquire various beliefs about the people we meet. The halo effect is associated with the fact that we will assess candidates too positively. For example, a candidate who is smiling, well-dressed, may be assessed by us as more competent than a person who came to the meeting dressed sloppily.
Another effect is the Golem effect. It’s the opposite of the halo. It also operates on quick associations. We notice one negative feature of the candidate and during the meeting, we will construct questions to confirm our thesis about the incompetence of the person. For example, if we notice many typos in the CV, we may acquire the belief that the candidate is inaccurate and may make many mistakes, which may not necessarily be consistent with reality.
There’s also the contrast effect. The contrast effect will be based on the fact that we will compare candidates with each other, and we will not compare the candidate with the requirements we set in the recruitment advertisement and the job profile. This is wrong because it’s very easy to make a subjective assessment. For example, if we have recruitment, 5-10 meetings, and at the very beginning there appears a sensational candidate who has very good technical competencies and soft skills, and right after him appears a very good candidate, but simply does not have such a personality and cannot fully sell himself, he will be defined as mediocre, although he does not deserve it. Conversely, at the beginning of recruitment, we meet with weak candidates, and then we meet with an average candidate. We will assess him as a very good candidate, which will not be entirely fair either.
The contrast effect will be based on the fact that we will compare candidates with each other, and we will not compare the candidate with the requirements we set in the recruitment advertisement and the job profile.
There’s also the similarity effect, when we favor people because they are similar to us or to people we know. And here we will also tend to assess these candidates better. There’s also the beauty effect, regardless of how much we deny that we don’t pay attention to external appearance, we are humans and the first impression is very important. And unfortunately or fortunately, people who are beautiful are usually assessed more positively than people who are not physically attractive. But to console you, I can add that people who are attractive and dress too nicely for a meeting can evoke negative emotions in us, and that’s already inadequate for the situation. That’s just human, simply.
Agnieszka Kopiczko: That would be suspiciously too nice. But I have a comment when you talk about these mistakes. It’s tempting to ask whether a computer should replace us in recruitment, as it would be devoid of human feelings. How often in the recruitment process do we rely on intuition – “Because I think”, “Because I know the client”, “Because I know what their preferences are”, “Because I similarly feel that someone might fit”, etc. Of course, this can be a mistake. I remember from recruitment, just to interject, that I focused on providing as many facts to the client as possible and, God forbid, not a single sentence or expression of my personal opinion, so as not to influence the client. Let them judge and draw conclusions themselves, but here a sort of avatar/robot seems to be called for.
Aleksandra Pluta: Well, you know, artificial intelligence is increasingly entering the area of recruitment, so I’m scared about what will happen to my future :-).
Ewa Dusza: Our previous episode was about AI in software creation. And we concluded that the human factor cannot be completely replaced and it won’t be found, so Ola, you can feel safe.
Agnieszka Kopiczko: Yes, I think so too.
Aleksandra Pluta: Well, I’m glad. I still have two cognitive errors, so I’ll allow myself to finish this topic because they seem quite important to me. Often in the course of recruitment, we have candidates who bombard us with a lot of information, and it’s hard to sift through the most valuable. And when a stream of all this information falls on us, we also lose the ability to make a rational judgment and then make decisions based on factors that don’t necessarily indicate that this will be the best choice from the project’s point of view.
There’s also the blind spot effect, which is about ignoring or trivializing certain candidate behaviors because, for example, they came to us from a very reputable company, and that’s already a bit of a guarantee that they have cool experience because they worked in such and such an organization. This can be very misleading, so it’s not worth succumbing to it.
And unfortunately, there’s no cure for cognitive errors. That’s the worst part, so maybe artificial intelligence would be useful here. We can only neutralize them, so self-awareness, asking ourselves questions, self-control in contact with another person is the only way not to make these cognitive errors. And the key will also be those notes I mentioned and a structured interview that will allow us to assess candidates according to specific criteria, not necessarily our feelings. So yes, that’s what recruitment errors look like. It’s worth not making them.
Ewa Dusza: This job is incredibly difficult, after everything you’ve said, but hugely important. Is that everything you wanted to tell us?
Aleksandra Pluta: Yes.
Technical Assessment and Criteria
Ewa Dusza: Okay, so incredibly difficult, but also incredibly important, because Ola decides who from her first screening goes further, and if they go further, it’s the next step and often it’s a technical task. And here we turn to our seniors. And today to Piotr, for you to tell us about your requirements or standards when you assess such tasks, and then in a technical conversation with the candidate.
Piotr Ujazdowski: Sure, thanks. Generally, Ola has covered the topic very broadly and also deeply in technical matters, so I agree with everything that has been said. Especially about those issues related to a broader view of things. Because from a senior, we expect not only to know one solution but to know that there are also other solutions, to know what the trade-offs are, etc. So absolutely, from the perspective of a technical interview, that’s 100% agreement on my part.
Because from a senior, we expect not only to know one solution but to know that there are also other solutions, to know what the trade-offs are, etc.
I’ll just briefly add about how the process looks from my perspective. There are really two stages: the task and the technical conversation. The task is, of course, an asynchronous process. The candidate gets a little task, has to write code and send it to us. Here comes the question of how much time is there? Generally, we don’t give a specific value. But it would be nice if, for example, the candidate defined it and then kept their word. Because if it drags on, then we might have some doubts about whether the candidate is very interested in this job or not. Because they probably have other processes open, most likely. So here the time is not very strictly defined. But it’s nice when we keep our word and respect each other. That’s the first, most important thing.
And yes, if we already get this task, there are a few things we pay attention to. First of all, it would be nice if the requirements that were specified were met. These are never complex problems to solve. Usually, it’s just some simple API to write, which has to implement some simple logic. So here, well, it would be nice if these requirements were met. And if, for example, the candidate doesn’t have time, because often it is so, that someone is already working and is in recruitment, so if they don’t manage to do everything, then it would be nice if they added some notes, that for example, this and that is still missing, or this can be done differently. So it’s nice if they are proactive, not just coding, but also somehow embellishing it, maybe with some context, comment.
So one thing is compliance with requirements. The second is the tools, libraries used. Here too, it’s not that we expect specific things, that it has to be this framework, because something else. Unless, for example, there is a specific recruitment for a specific client and it is particularly listed in the requirements. But if not, then it’s just a hint for us that the candidate uses tools that are currently standard in the market. So this is something that may be subject to evaluation. Another thing is best practices, the architecture of this code. Here again, I repeat, these are not complicated tasks, so if you insist, you could probably write it all in one file. However, we expect that the candidate realizes that this is just a certain synthetic sample of this code, these skills. So we expect that there will be some architectural issues despite the fact that the task is simple. Because this is a signal for us that someone understands what good practices are.
We expect that there will be some architectural issues despite the fact that the task is simple. Because this is a signal for us that someone understands what good practices are.
Sometimes people have doubts about whether they should write automated tests in such a task. Absolutely. If someone undertakes it in such a task, it is definitely a plus. Of course, we don’t expect 100% coverage, but we expect someone to show their approach, that they understand that there are different levels of testing, how to approach it at all, how to structure these tests. It’s not about a bulletproof solution, but about showing your way of thinking and some practices you use.
And here I’ve already mentioned comments, and maybe I’ll repeat it to emphasize it. Often there is not much time for the task, some things just can’t be done in two hours. If someone devotes that much time to it, because that’s about how much is usually spent on such tasks. So here, if someone adds a comment, for example, that this is done in a simple way, but it can be done differently and it depends on this and that. So these are very helpful hints for us, that such a senior simply understands the context, that he realizes that this solution works, is correct. However, in another context, it may not be the best. So here it is definitely a plus.
And yes, if the task is okay and all these issues I mentioned do not raise any objections, then we move on to the next stage. And then there is this conversation, where we start with technical issues. And here it varies. Sometimes the same person evaluated the task and conducts interviews, but it’s not always like that. So here, these notes are also useful, which we exchange so that recruitment smoothly transitions in the organization. And now, already having this task, we have some view of the candidate. What practices they use and so on. And generally, this conversation is a bit of a deepening of all this.
So here I personally usually introduce two stages to this conversation. First, it’s a conversation about the candidate’s experiences, for him to actively talk about what projects he had, what technologies he used, what challenges, problems, how he solved them. So this is also an element of self-presentation. Here it has already appeared in the screening. However, I am also interested in it from the perspective of a technical person, because we expect from a senior that he will be able to clearly talk about technical issues also with technical people. So this is important for us, not just to ask from a table, some issues, but that this conversation is deep, that he shows that he can talk about it somewhere.
And this second stage is a return to this task. And both these elements serve me to deepen these issues, which already come out at the stage of the task, such as a discussion about architecture, we can touch on that here, in this task, such architecture was used, what other approaches the candidate knows and what costs are associated with them, etc. Similarly, when we talk about experiences, it can reveal, for example, what patterns the candidate has used, what problems they encountered with them, and how things could be done differently. This applies to every aspect, really. We can also discuss testing based on the task, as well as the candidate’s experiences, tools, and libraries, and their level of expertise. So all these elements that were assessed in the task can also be delved into during the interview, using the two pillars of our knowledge about the candidate: the task and their experiences.
As we’ve mentioned before, but I’ll repeat because it’s super important to me personally and I think in the process in general, a senior should not only be able to solve a problem, i.e., not only be able to deliver, but also understand the different paths to a solution. Because not every context calls for the same solution. Sometimes a project is in an early stage of development and needs quick delivery because we’re validating a business model. Later, for example, the organization might be in a more stable phase because it wants to scale, so then we need to approach these problems and solutions differently. What I want to emphasize today is that a candidate understands this broad context and can talk about it, because later they need to convey this context to the client, argue their case, and communicate with the team. Sometimes there are also developers, technical people at the client’s side, and you need to communicate with them, exchange experiences, and argue why a solution is good in a particular context.
Returning to the technical interview during recruitment. Personally, in such a technical interview, I’m also interested in how the candidate approaches less experienced team members, as a senior. Not everyone has the skills to teach well, and not everyone feels very comfortable in that role. Some people have natural predispositions, and not every senior has to be a super teacher or mentor. But there is an expectation that such a person will be able to help the less experienced, to guide them, to teach them something. So we don’t expect everyone to be a super mentor, but we do expect them to be open to it. It can’t be someone who is super technical but closed off in themselves with all of that. So this is definitely an important element of a candidate’s competence for me.
We often also ask about how the candidate expands their knowledge. This is a bit of a bonus question, but it’s important that the candidate is willing to develop and not limit themselves to just one source. For example, some people only watch things on YouTube, but for a senior, it would be nice if they read a book once in a while. Books often contain knowledge not available anywhere else, in the sense of free sources. This is often more high-level, in-depth knowledge. Personally, I think a senior should read a good technical book from time to time.
For a senior, it would be nice if they read a book once in a while. Books often contain knowledge not available anywhere else, in the sense of free sources.
And basically, that’s all from me. At this stage, I usually know quite a lot, so we move on to the next stages.
The Role of Project Management Representative in Recruitment
Ewa Dusza: OK. Speaking of the next stage, let’s move on to Agnieszka. Agnieszka, you are kind of the middle-to-final link. You know the needs of the project, the needs of the client, and what is your role in this recruitment process?
Agnieszka Kopiczko: Everything is correct. So, of course, during such an interview with a project manager, there is always a developer present who supports us in the technical part. Starting with organizational matters at the beginning, we always present to the candidate how the conversation will proceed. It is usually divided into three parts. This way, the candidate knows exactly what to expect during the hour we meet.
The conversation then proceeds in such a way that it is divided into a technical part at the beginning, where I always think that this is the moment of greatest fascination for developers, because they can exchange experiences, talk in Polish, talk about their different problems and tasks, and everything that Piotr mentioned. Only in the second part do we switch to speaking in English. Here, of course, the conversation is not at such a technical level. It concerns very general topics related to communication, teamwork. And this is just the final step to gather all the information about the candidate, to then verify whether we will send them further to the client for an interview.
But what happens during such a conversation? We try to conduct it as naturally as possible, because the candidate will later work in a similar atmosphere with the client. There will be questions related to technology, experience, everything they will encounter daily. However, the level of English required from a senior is quite high. Unfortunately, there is no room for struggling or explaining things in writing. Usually, the people who come to us speak very good English. I always emphasize – it’s not about the accent, people not born or raised abroad won’t have that accent, but the client doesn’t require it. It’s about someone feeling really comfortable in English, being able to talk about the weather, but also about the superiority of one database over another, about choosing technologies. Everything they will encounter with the client, the product, the business, and they will be able to freely express all their knowledge. Because even if they are super technical, very experienced, but unfortunately have a low level of English, they won’t have a chance to show their skills to the client and engage in team work.
But the questions we ask in English are more about – cooperation with the team so far, any problems they encountered, their approach to these problems, how they solved them, what they meant, what they wanted to propose, or maybe something didn’t work at a certain moment and why? Generally, whether they have worked directly with a foreign client before? Because sometimes it happens that people have only worked in a developer team, and someone else was responsible for direct communication with the business client.
And also during this conversation, we ask questions in a way that is somewhat similar to how the client will ask them when they go for the final interview with the client. Of course, during the final interview, a lot depends on the client, on what their needs and requirements are in a given project. Of course, the technical requirements are always known in advance, and the candidate can check for themselves whether their experience is included in this list of requirements. But the interview with the client varies. Sometimes it’s a very casual conversation, and the client focuses on getting to know the candidate as much as possible. Whether the candidate will fit in their team and whether the candidate will feel good in that team. The so-called character fit, the so-called culture fit. There are no specific questions for this. It cannot be checked through standard questions. It comes out during a dynamic conversation, really, both these soft skills and the way of communication, it comes out of the candidate during this conversation. They tell a story about themselves, about the company, about the projects, what they like, what they don’t like, what they have encountered, and what they want to achieve in the future – their whole way of communication, body language, it comes out of them.
So we will also know if they will feel comfortable enough when they go for an interview with the client, that they will be able to present themselves well. It should be emphasized that candidates usually have the final interview with the client on their own. We usually try to do only an introduction at the beginning and leave the client alone with the candidate, so they also have such a space, freedom to get to know each other, to ask questions. I don’t remember historically that the client was “cruel” during such an interview. They really do everything to make the conversation as pleasant as possible. They ask very casual questions at the beginning to warm up and then simply often ask about similar things that we also ask earlier in the team interview. And based on that, they make some decision, send us their conclusions.
Sometimes there is a separate conversation about only fitting into the team. When the client in the first phase says yes, this is a candidate we want to go further with, there is still one more play-off, as I call it, a purely technical conversation. Then they designate another engineer from the team to meet with the candidate, and it’s a really strictly technical conversation. But also not in the form of a stiff list of questions, but simply what did you do, how did you do it, and why this way and not another. Everything that Piotr talked about, only at this stage the client asks these questions.
Ewa Dusza: I think that the “business card” you mentioned, that attractive self-presentation, is very important to prepare. I always talk about this before meeting with the client in English. Because the client doesn’t ask specific questions, their first question is usually “tell me something about yourself from a professional point of view.” Not everyone is prepared to deliver a short monologue about themselves, their career, what they like most, and to present some achievements. It’s worth preparing this in English to shine at the first meeting with the client. Tell me, do you also match candidates to the project and client needs in terms of personality? Because we know that not every project can have only seniors who like to make decisions and be leaders.
The Role of Personality in Team Dynamics
Agnieszka Kopiczko: Here, unfortunately, I have to admit that I probably make the mistake that Ola mentioned. That is, based on people who are already on our side, our employees, I assess the candidate comparatively in such a conversation, i.e., whether they have experience working in a team, whether they have worked in the SCRUM method, whether they are accustomed to meetings? More from a comparative side than just my personal character preferences.
Even if a candidate seems to be quite a strong introvert, I sometimes warn the client about this, that they may seem closed off, but they open up upon closer acquaintance. Clients have never rejected a candidate just because they were shy. That would be an anomaly if it happened. However, I mainly look at technical experience. I rely heavily on the developer’s opinion who conducted the technical stage of the recruitment, in terms of whether they can technically handle it, whether their experience so far will simply work in the project. Because those soft, communicative, character traits are important, but maybe not the most important.
And sometimes it is so that the client does not require the person to – metaphorically speaking – shine in the team, to be a lion in the team. Sometimes the client will explicitly say that it doesn’t matter, they will open up over time, as they feel safer in the team, and so on. So it’s important, but it won’t be the most important. It happens that you don’t need to have only “alpha” people in the team, it doesn’t work in every condition, because the team needs both people who step forward and those who are a bit more withdrawn, a mix of people sometimes is the best, a mixture of different opinions. Then we have a chance that someone will question an opinion at some point, and not everyone will blindly follow an opinion that may turn out to be wrong. Because someone will have the courage to say “wait a minute”. And there is a discussion. So the more diversity, the better.
A team needs a mix of personalities – not just leaders, but also those who can support and complement each other.
Aleksandra Pluta: I think it’s very important that the team shares the same values, has the same approach to work culture, but that it is indeed very diverse. Because if we create an army of clones, it’s really hard to innovate, to have discussions about solutions.
Final Thoughts and Advice for Candidates
Ewa Dusza: And finally, I wanted to convey a message to potential candidates, because Ola gave a lot of advice for recruiters, and I will refer to the candidate’s perspective. At the beginning of the interviews, I always repeat to candidates that this is a conversation not only for us, which allows us to verify and get to know you, but it’s also a conversation for you. You’re getting to know us, you’re verifying us as a company, and checking if the fit is mutual, whether this is the company and project where you will develop, whether this is really what you want to do in life. And there’s always time for such questions during interviews.
Preparing for an interview is not just about answering questions, but also about asking the right ones.
But very often, candidates don’t have these questions. I think that’s because they’re more focused on answering than asking. And it’s good to prepare such a list of questions for that last quarter of an hour, which is always intended for the candidate’s questions. And also, if during these interviews, especially the technical ones, if someone doesn’t know the answer to a question, or doesn’t fully understand a topic, they should delve into it and use the conversation for their development. Because often it happens that a candidate doesn’t pass the recruitment, but leaves it enriched with some knowledge. It has happened like that sometimes. It’s worth taking advantage of the fact that these are conversations with seniors, with very experienced people.
We often received feedback that the conversation was nice in this respect, or that if it worked out, they would want to work with that particular senior, because they would want to continue learning from them. So I also encourage you to prepare for questions, not just answers before the conversation. Thank you very much for this conversation. I think there are a lot of tips here for both candidates and recruiters, and you will be able to prepare for these conversations from both sides. Thank you for participating, and thank you to the listeners for listening. See you.
