Why I don’t believe in a “classic” recruitment approach

Over the past 10 years, apart from programming and managing a large team of developers, a big part of my work has revolved around recruiting programmers (in particular PHP). During this period, the world has changed several times — economic growth and crises, an employees’ market then an employers’ one. Regardless of the circumstances, the central question I’ve always had to figure out has stayed the same — out of the many good programmers who apply for jobs, how do I catch the best ones?

For years, I used what I call the classic recruitment model — a telephone conversation, followed by a meeting combined with a skill test in the form of a general problem or a coding task and finally submission of an offer. Each stage was carefully prepared, with detailed questions and tasks allowing me to examine candidates’ technological knowledge and their responses to everyday challenges and relationships between people.

As a rule, prior to submitting the offer, I had a very good candidate profile in each case — but I still often found I’d missed something. Within a matter of weeks or months, either I’d be unhappy with a new employee’s work or they’d be unhappy in their role. There was no match between candidate and company and vice versa.

Every company, whether a startup or a corporation, has its own culture/DNA that defines its everyday work — how its staff communicate, dress, what jokes are acceptable, what tools staff use, etc. It is very hard to work somewhere we don’t fit or feel comfortable. Once I had the opportunity to experience it, when I worked at an interactive agency in which the atmosphere was very formal and the reporting structure was expanded. I stayed just 5 months before I gave up and left, albeit with the new awareness that autonomy and a loose atmosphere are very important to me. I fared much better in my next position, at GoldenLine :)

Now that I’m recruiting at DocPlanner, I don’t like to rely on luck. I want clear answers — does this person fit the team and the team fit them? Some time ago, we realised that the easiest way to check whether there’s a mutual match is to spend time at a desk coding together. This is how the idea of the trial day arose.

This test day is now the most important stage of recruitment for me. It has 2 goals:

• From the company’s perspective: check how the candidate works in combat conditions, that is, in conditions that are as close as possible to those they’ll be dealing with day to day. The laboratory environment of recruitment interviews distorts the picture.
• From the candidate’s perspective: check what the work looks like, how the teams work, what code they’ll be working on and what tools they’ll be using.

In practice, such a day starts around 10 a.m. The candidate gets assigned his buddy (usually one of the tech leaders) who introduces the team and the tasks that need to be done then helps the candidate through any difficulties they encounter during the day. To make sure the tasks resemble everyday challenges, we take them from previous projects. This has the added benefit of making it easy to compare the solution the candidate created on trial day with what we previously coded. During the day, the candidate also participates in all team meetings, joins us for lunch and, at the end, gets very specific feedback from their buddy. And, of course, it’s the perfect opportunity for the candidate to learn about us — our culture, way of communication, code, office structure — to check whether they feel good with us.

In one case, a candidate interviewed very well, but on the trial day, after reviewing the code, decided that it was beyond their level and left after a few hours. This was good because it saved us both a few months.

In conclusion, this is why I see the classic recruitment model as a kind of ‘speed dating’ — we sit at the table with a candidate and quickly check for something sparking, but we can only get to know each other properly on the battlefield, during a whole day spent together over real problems, in the real world. I encourage everyone to find out what work in a new company looks like during a trial day — even if the company you’re applying to doesn’t offer such a possibility, it’s worth asking. The coolest companies will certainly be open to such a test…

And if you’re organising a trial day, keep one important detail in mind:

• Candidates should operate in a real environment (production code), but the solution that arises cannot be used commercially. The trial day serves to check each other out, not to produce new functionalities for free!