Recruiting developers for software house.
As a developer with 7 years’ worth of corporate experience, I have witnessed many different approaches in recruiting staff for software engineer positions. And these differing approaches apply to both sides of the table - as a candidate and recruiter. Obviously, every recruitment process is different, but I’ve tended to see a standard procedure of starting from only language-related, theoretical questions, to creating working, well designed solutions for assessments and ending with white-board algorithm solving problem sessions.
The candidate side is pretty straightforward; I came to this conclusion after several different meetings with startups, privately-held small business and leading technology giants. I’m pretty sure there are only two tasks for the candidate to concentrate on - presenting yourself in the best possible way and trying to obtain as much information about the company and the position.
Things get trickier on the other side of the table. I’ve always wanted to model how this process looks, but it’s not as straightforward as it sounds. Sure, there has to be plenty of discussion in it, but every interview is different and you can’t always stick to a script. And if you want to make changes to the recruitment procedure, these changes often have to go through an approval process to ensure they’re going to improve the experience. This can take time as it’s down to your employer, not you personally. However, I’m pretty sure that every recruiter (including myself) has thought, at some point, that if they were in charge they would do things differently.
Concentrating on this last sentence, we’re now getting closer to the key point of this article. For the last few months we’ve been running a software house >> and we’ve been searching for new talents for our company. And this search left us pondering the question of: how do we create a good recruitment process which allows us to find the best candidates with the best skills who can start without any delays? The main conundrum was that we wanted to invest as little time as possible without a drop in quality and we wanted to find employees who could easily adapt to the ever changing work environment of a small software house.
Algorithm solving skills.
Personally, I’m a fan of the whiteboard algorithm problem solving approach. Once a candidate passes it you can be pretty sure about their expertise. You can also understand their skills and ability to learn, not just their knowledge in a certain technology stack - which is a huge benefit from the point of view of a small company. An added bonus is that preparing for such a process involves solving a lot of similar tasks, so we can find a person that is not overly-attached to their code, which is another tick in the right box.
The more we thought about whether this was the best way forwards for our recruitment process, the more red flags we uncovered. All the advantages mentioned above certainly remain relevant, but there are other scenarios and questions to consider.
The ideal situation, of course, is to have a project with a starting date which is way off in the future so that you have time to find the right people for it. Projects that are not connected to any specific systems and allow you to use any technologies and tools you want. Green fields at its bests.
Even if the start date for a project is limited, you can still consider it as an achievable and fun project to work on. More often than not, new joiners need to adapt to an existing platform and this requires prior knowledge of the technologies being used. Moreover, the faster the individual is able to integrate and deliver, the more beneficial it is for the software house.
This demand for new starters to hit the ground running means that there’s no argument as to whether they should already be strongly coupled with existing frameworks. From a software house owner’s perspective, I simply can’t afford to recruit coders who may be highly talented, but come with no knowledge of SpringBoot and AWS platform. I’m sure that they could learn these platforms ridiculously quick, but there would still be a period of downtime to achieve this. When talking with potential clients, we like to differentiate ourselves from big companies by demonstrating our pace of delivery as our major selling point. And we can only provide this by recruiting employees with the ability to build production-ready solutions using all the tools and frameworks readily available.
After endless discussions, we came up with the following recruitment process. We decided that the first thing we need to understand is the applicant’s specific technology and language knowledge first. And by this we mean talking about theoretical discussions regarding Java, Spring, AWS and all that they entail. We call it stage one as our expectations here are not very high, a decent knowledge is enough and the candidates answers, at this point, are not going to guarantee them the job.
The next step - stage two - is the most important. It involves us preparing a coding task in a strongly technical domain. What we’re looking for here is for the candidate to solve the task with the best possible algorithm. Naturally, we’re also looking for a conscientious approach to code quality, test coverage, build system, logging etc. The correct usage of certain data structures along with the algorithms implemented are the key factors we look for when deciding if we will make a job offer. As we are also looking at the time factor when it comes to examining the solved task, we ask for the applicant to either provide a test suite that demonstrates the solution’s performance or we hold brief talks with the author about it prior to reviewing the code.
Best recruitment factor?
Finding the perfect balance is the issue we are still struggling with. We have changed our approach several times already and whilst it shows progress, I’m sure the current one will go through many changes yet. My main regret with this recruitment process is the possibility that we may miss out on great coders who simply don’t meet the demands of our specific frameworks.. I am hoping solidstudio.io will grow enough that, in the future, we will be able to give said coders a space to become the programmers we want. On the other hand, the major benefit is that a candidate that passes the process is ready to get started on day one with the tools and frameworks already in use. This allows us to keep pace with competitors – if not outpace them – and deliver a better experience to our clients.
For all algorithm solving questions and whiteboard session enthusiasts, we all need to remember that only delivered ideas matter. And these must be delivered with strong domain, architecture and framework knowledge.