Last Friday we took on what is starting to become a regular event here at MetaBroadcast Towers: a candidate day. No, it’s not local election time, we were instead having a potential cat in for the day. We differ from a number of places out there in that we tend to invite people to spend the entire day with us.
a day in the life of metabroadcast
Each of our candidates spends a day doing tasks that they might typically do when working here, assisted by various members of the team. We get to see how they work on a (nearly) normal working day, and see how they are technically and also how they interact with people. We also try and get them using some of our software (engineers will find themselves using Atlas, for example), so they get to see what we do. At the end of it all, we retire to the pub for some well-earned beverages and a casual chat.
The sort of work we get each candidate to do depends upon what role they’re applying for. Devops magicians might find themselves building servers or streamlining deployment, whereas engineers are more likely to have built some form of app during their time with us. As I’m an engineer, I’m going to talk a little about the engineering test, given it’s my area of expertise. No sneaky details, mind!
the language barrier
You may have noticed by now that we’re mostly a Java shop here. We do little bits and pieces in other languages, and we’re not dead set against anything else, but we know it well, and it does many things very well. As a result, we have our potential engineer cats code up a small app in Java. That’s worked pretty well in the past, but with our latest candidate, we faced a conundrum—the chap was a wizard in NodeJS, and super enthusiastic, but lacked knowledge of Java. Now, you may be thinking ‘how can you use a Node coder in a Java-based company?’. This comes down to what we look for in a candidate. While technical skill is great, if someone is bright, and really quick at picking up new skills, that can often be as good, or better. We’re flexible, see? So, the trick is to give the candidate a task that they can actually perform, but that pushes them into somewhat unfamiliar territory.
This meant a new test, one written in Node. Fortunately, we’ve got some pretty awesome people here, some of whom are quite handy with Node. Between them they managed to whip up a decent test in no time. That left one final puzzle—what about the assessing engineers who didn’t know Node?
I’m afraid to say I fall into this category. However, it’s not quite the hindrance you might think. I know basic JS, and would like to think I’m reasonably savvy when it comes to assessing code. To be on the safe side, I spent 30 mins or so reading up on the basics of Node, but it turned out to not be an issue. I found that I could understand our candidate’s code just fine, and was still able to help out when they hit the odd tricky spot.
Essentially, the moral of the story is—don’t judge a book by its cover. Just because a candidate doesn’t know / isn’t super proficient in your language of choice, don’t immediately throw their CV in the bin. Enthusiasm and ability to pick up new skills is often more important than established technical skill. Obviously, you might require a little more initial training if you do decide to take them on, which shouldn’t be ignored, but dismissing an able candidate because of lack of knowledge shouldn’t be done lightly. As long as you can still assess them accurately, and come to a reasoned decision, then programming languages soon become water under the bridge. Oh, and what of our candidate? Let’s just say we may have news on that front soon…