How the perfect technical interview should look like?

Today I’ll give myself a small break from the CodeMate project and share my insight about how I imagine the perfect technical interview that is valuable for the employer and painless for the candidate.

Idea for this post

Recently Gutek wrote about striving for perfection in terms of approaching interviews [PL].  To give you a quick summary what it was about: the more experienced programmer you are, the more stressful the interview may be. “Will I answer this elementary question >What the class is?<” you may think. Or “What keyword calls IDisposable.Dispose()?”. This kind of questions is either so basic that you surely know the answer but you can’t simply elaborate it or they are built in such sophisticated way that you will never hit on what the author may have wanted to achieve here. Even if you know the correct answer. The last option is that you simply don’t know the answer, but – you’ll probably never need it.

The key here is to be self-confident about your own abilities, experience, and skills. When you’ll make yourself aware of how much actually you know, you’ll pass the vast majority of fairly build recruitment processes.

Fairly build recruitment process?

I’m thinking about something that validates not only your hard skills (e.g. your knowledge) because there are plenty of different things that count. Some of these are candidates’ solution oriented attitude, ability to work in the team (being friendly), usage of techniques listed as favorite ones in candidate’s CV… and more.

How shouldn’t it look like?

I’ll start with anti-pattern here – the best I know is the one mentioned in the post above. Although candidate was a perfect match for the position, he didn’t pass, because the answers haven’t covered the ones prepared by the examinator (they were just better!). The truth is that recruiter can always beat you. He is the one who prepares the questions. He is in the winning position since the very beginning, and he can tell you you’re wrong even when you’re right. And that’s I guess what we stress about when approaching interviews – the tricky questions which will knock us out.

Would you be nervous about the interview driven by your friend? I bet no. So verifying your knowledge is not a problem itself here.

In fact, you’re afraid of being unfairly treated. About missing your job because of question prepared by a cocky recruiter.

What are we trying to achieve?

I assume we want to hire a software developer. Who is the software developer? Is that this funny guy who only writes the code?

No.

The guy you want to employ is the guy who needs to be able to solve problems. Who needs to fit the team and efficiently communicate with them. Who sometimes even will talk to the customer. And will be using tools he had never used before thus he needs to be able to learn relatively quickly.

Do tricky questions find for such guy? I’ll not only say ‘no’ here – I guess it even makes our results counterproductive.

How should the interview look like?

Just give the candidate a piece of work he’ll be doing when he joins you! Simple as that!

I’ll describe you the recruitment process I had in my current job because I consider this really good one.

Step 0

Quick small talk call to check my English skills and agree to interview due date with my potential manager.

Step 1 – the talk

60 mins call with the manager to introduce the company to myself – and myself to the company 🙂 I had a chance to say something about my experience. There were quite a few questions – but none was examining myself in any sense. It was rather determining my areas of expertise, my willingness to develop in this or that, or even ‘trolling’ ones to make us laugh and break the tension.

At the end, I was told I’ll get the task to solve so he could see how I write the code.

Step 2 – the task

I got a task desription and one week to deliver the solution. At first sight, it was an easy one: create a web page which lets you upload a file. The website displays a list of files with word counts of the content. Seems effortless, doesn’t it?

It was not extremely tough, but I wouldn’t call that straightforward as well. There were few architectural notes to consider – like the ease of adding other file extensions, manageability,  testability etc.

I not only had to write the code in that case but also design the architecture, ask some questions, make some decisions, push the code to Git… Generally speaking – solve the problem.

There’s a simple path simulation here: customer has a problem. You are the one who solves it. Just show if you can!

Step 3 – the review

The last step was to discuss the solution with an architect who pointed out areas that could have been improved and the parts he was pleased to see. He also asked what else I could potentially cover yet in future. That was valuable session as well and I guess determining if I was the one who actually wrote the code hadn’t been the most important goal of our conversation.

Then I’ve been hired 🙂

Summary

General advice for a perfect interview is giving the candidate the kind of task he will be asked to resolve after being hired. Especially for software developers: what can you conclude from examining some niche syntactic sugar or asking for code compilation on the whiteboard? Nothing.

What’s on the other side? When you’ll do the better way, you can find out if the person you evaluate is pragmatic. If asks good questions, is oriented on delivering solution instead of finding problems. If he/she can use the tools you want him/her to know (i.e. Git). The outcome of such approach is incomparably greater than (sadly) standard one. And what’s more important – it is not stressful for the candidate. So in the end: you’ll be sure that he/she is doing his/her best for you.