Recently, Netguru has once again broken new records when it comes to the developer horsepower packed under our hood. The time has come to get our hands dirty with some new hires, not for the first and (definitely) not for the last time. I want to share with you my thoughts about how it is to participate in the recruitment process as a recruiting developer. It’s not as easy at it may seem at first glance.
As I said, recruiting isn't an easy thing to do – we're not the type of software house that brings in temporary workers on a needs-must basis for a one-off project. We want them to stay with us for much longer than that. We want them to be more than mere code monkeys – we encourage our developers to get used to and become involved in our workflows, improve our technology stack. In a word, we would like them to have an active and positive impact on our work company-wide.
It’s not all about code wizards
Technical wizardry aside, we also need soft skills. We need people who are assertive and able to respond directly and swiftly to our clients whenever necessary. They need to be able to reassure people that all those little niggling doubts hanging over a product under development have been resolved, in order to avoid some unfortunate misunderstandings.
It's not easy to find people with just the right skill set, or even with a clear potential to reach these standards. Good developers today are few and far between, which leaves us, and every other company in a similar position, in the throes of a fundamental paradox:
- We need really good developers
- There are never many good developers available
And there's no place for compromise either – lowering standards in the long-term would do nobody any good. It's actually better not to hire someone at all than risk that they and the company become unhappy soon after.
So how does it feel when you're given the task of scrutinising potential employees, not so long after having gone through the same recruitment process in the same company?
My recruitment experience
The first time I was given the job of checking a recruitment task solution for a front-end developer position, it wasn't so bad. It was just a one-off, low-risk endeavour. You see if it works, you see how it looks, you try to read the code. If it's readable, sensible and clear – that’s a green light for a technical interview.
And this is the part that can get surreal. Even with predefined questions, even with tried-and-tested pieces of code designed to evaluate someone's skills, even with many similar interviews already under the belt – there will always be cases when you just can't be sure what to do. You end up with different voices in your head, and it's a huge challenge to pick the most objective one that would deliver the best resolution of the dilemma. So many questions suddenly arise when you have less than an hour to, perhaps significantly, alter someone's career path. Your words suddenly mean a lot to someone and carry a lot of power, and with this comes great responsibility.
Is that it? No, it gets even funnier. Let's bar the usual, common recruiter dilemmas with borderline cases – the ones where one single, random element can tip the scales. And there’s not much that can be done about them.
Very recently, during one particular phase of full-blast recruitment, a position for a junior front-end developer opened up. The number of applications exceeded anyone's expectations, and suddenly myself, and my fellow workers, had to assess a large number of potential hires. Doing that en masse you can't help but feel at times like a cruel meat-grinder, who only looks at potential co-workers as “just another person to get through”. It's a real challenge to stay involved and truly objective, without letting any preconceived notions influence your decisions.
And even before the real interviews started, we knew that we were in a rare situation, where the number of developers meeting our standards would exceed the number that we could actually accommodate. We wanted them in, but each junior developer needs time along with a dedicated mentor to become a truly adjusted and self-directed programmer. And it’s just impossible not to sacrifice quality for quantity if we strive to do it on a bigger scale. So what happens?
Suddenly you have to decide between two good candidates both of whom you'd normally happily accept. You have to say “nope...” when usually you'd say “YES!”. You have to make heart-breaking decisions, knowing all the time that there's no guarantee that they’re actually the right ones. And you have to do it all more than once or twice, for a while you're almost used to it.
There isn't one. Hiring is a funny and unpredictable business, from both sides. It’s a numbers game, where no matter what we do, we can always make mistakes and have to assume that the results will never be 100% under our control.
As a potential hire, prepare for rejections even if you're really good – that's the name of the game. Be glad that software developers are in demand, keep improving and you’ll find the job of your dreams sooner rather than later.
As a hiring person, prepare for surreal experiences, hard decisions, the lure of power trips, and metaphysical questions bugging you at night.
It’s worth it though. You were once in the very same situation before, can feel the solidarity and remember all corresponding feelings. Whether it’s just having a nice, interesting conversation about technology with a potential hire, or hearing thankful words after giving meaningful, helpful feedback to someone who’s not-there-just-yet (but may be quite soon!), or perhaps meeting someone you directly vouched for, in person, already working with you in the same company (and doing great!) – they are all positive, priceless moments that you’re bound to experience sooner or later.