Episode 2: The Employer

_If you're looking for part one, you can read it _here

CVs Screened. Test invitations sent! Best start preparing that test then eh!

The technical test can be daunting for the candidate, however people often forget the host / employer in these situations. You're having to scrutinise someone's work, and potentially say no to them. Equally, you could be saying yes. What should you be testing? How do I word my questions? Hopefully, this can help you a little.

Note: I'm writing this having interviewed around 50 candidates for a range of roles from Apprentices, right up to Senior / Lead developer. The questions will be skewed towards PHP, however you can translate this over to your technology / industry just as easily.

When I'm preparing for a tech test, as the employer, I like to ensure that I'm meeting 5 key criteria, so here they are!

Keep it relevant

Is this person going to be maintaining services? Improving them? Building new ones?

Don't ask questions that are never going to be used in the candidates role. This is one of the most infuriating things to experience as a candidate, and is embarrassing for you as the Employer if the candidate calls you up on it.

It makes sense to keep the test relevant to the responsibilities of the role being offered. There's no point giving a test to the candidate on core PHP, if they're mainly going to be working on GitHub Issues and fixing front end issues.

Let your candidates show off

Candidates often have hidden talents. Allow your tests to show these

Prepare your tests as though your candidates are going to smash it.

One such test I was recently given was to build a URL shortener. The employer only asked me to provide the code. However, I was able to host the solution, and have it working on a production website within the time frame. This pushed me to the top of the candidate pile.

Ensure that your tests are not a simple check list of right or wrong answers. Allow your candidates to show their full potential and go beyond the brief.

Naturally, if a candidate does attempt to go above, and misses the core brief - it should be noted. Going above a brief should only be undertaken once the core requirements are met.

Some people are going to choke, or fail

It's part of life. The pressure get's to us, or we just have a bad day. Sometimes, you'll have to help this candidate out a little. Have some questions in there to boost confidence. Something that anyone who applied to the role should be able to answer. The last thing a candidate needs on top of the pressure of a test - is a test that they're failing massively. Sometimes a little boost is all they need to get going.

For PHP, I have an A4 sheet of questions, ranging from basic, to more advanced. I'll randomly throw these out to gauge a candidates ability, then choose a test based on their answers. I find this helps with keeping a candidate engaged.

I've got two equal candidates!?

You've got 2 candidates. They're both awesome. How do we decide which to hire? No, you can't make them fight, or have a hack-off.

Personally I will go with the candidate which was the most passionate about the role, and the code they were writing.

When attempting your tests, did one candidate have a nasty habit that could cause issues? A minor issue on one question that they brushed over?

If they're still both equal, look at the code, and see which you would rather inherit and work with, your answer lies there.

Engage in conversation

Learn more about your candidates through open questions

Keep your questions open if you can. The idea of interviews is to create conversation around the role, allowing the candidate and employer to get to know each other - as well as add confidence to the employer that the candidate is capable.

For example, one such question could be, What are the SOLID principles?. We used to ask this of candidates, however recently changed it up. We added a simple sentence to the end, that allows for discussion, What are the SOLID principles, and how do they benefit Software Development.

From this slight change, we have noticed that some candidates may not know the specific definitions of SOLID, however they will know of it, and know better how to apply it.

Remember, keep it relevant to the role though. Opening up questions could lead to tangents, and time wasted talking about something completely different to where you started.

Use your colleagues!

You've most likely got colleagues that already sit in this role, or similar style roles. Give them your test, and use their feedback.

Often some things will go unnoticed if you write the tests yourself. It's always great to get a second, or more, opinion(s).

If you can get a group of you together for 15 minutes, to put together a test and question set - that's even better.

You should always try and have a second person with you in the interview as well, so that if you forget something, or need help with asking a question - they can step in for you.