Lately I’ve been recruiting people for our Front-End team at Up2 Technology. I am quite satisfied with the process so I decided to share it with you.
This is a non-extensive list with the guidelines I’m trying to follow in order to have an interviewing process satisfying for both me and the people applying.
A rule of thumb I follow is to never organize the process in a way that I’d not feel good if I had to go through it as a recruit myself.
Job security is less of a thing than what it used to be, so it would not be a surprise if in a few years (or months) you’re the person being on the other side.
People learn mostly from their own experiences so we have to do our best in such situations. These people will inevitably become senior developers or team leads at a point and will start recruiting themselves. Make sure you show them the best of you!
Skip the whiteboard
Something I’m very proud of myself is that I’ve never conducted a whiteboard coding session.
What to do instead?
A superior way to see someone’s skills is to give them a realistic task – something that you often receive as a task yourself or that is common for you to assign to your team.
I usually provide an API that returns a JSON and the task is for the person to visualize the returned data however they decide. I do provide some context on what the end-user cares for, but only as high-level details. This is actually what most of our assignments look like.
Additional ideas on how to approach the task for home
- Give extra time for the people to work on your task (at least 7 days, to include a weekend) – You’re probably not the only company these people are applying for. They might also be still working full-time. Be respectful and give them the time needed so they can be calm while doing your task
- Limit the time for actual development, which will force an incomplete solution – this will show you what the candidate thinks is most important and what do they feel most comfortable at.
- Use the task to test their git skills too – ask them to use git as they would in their day-to-day job. (Not using git? Got the idea – ask them to use your system to see if they’d need extra training)
- Hide a common error you to see how do they handle it – they might figure it out, or they might ask. Whatever they do, I think it is okay – the most important is to notice the error. I intentionally give a CORS error, since this is the most common I got.
Don’t waste their time
Make sure you don’t fool them and you avoid doing harm as much as possible – like asking people to quit before you’re sure that you will be able to hire them (I’ve heard of such super-lame cases).
Once you’ve decided that a person is not your candidate – let them know immediately. Give them the reason you’ve not picked them and move on. They will feel bad, but they’d feel even worse if you’d wasted more of their time.
Avoid Relying on the Trial Period
Most of the positions have some kind of trial period (at least in Bulgaria) where you’re legally allowed to cancel the contract of a person immediately. (They could do that too).
Please, try to avoid that and apply it only in a very edge case. This is causing greater harm to the employee (since most of the time they cannot go back to their old job) than harm to the company – after another set of interviews, you will find the right people for your team.
Maybe Unexpected: Apply for a job in a company you admire (and people like their recruitment process)
Go wild. Apply for the company you’ve always wanted to work for. Check the feedback at glassdoor how their interviewing is.
In the end, they could hire you or not. Either way, you’d witness their recruitment process from within and learn from both the good parts and the bad ones.
Cheers, and go find the people you’d enjoy working with.