A technical interview is an interview to assess whether a candidate is technically strong enough to join your team. A good technical interview should also give you a good impression of whether you could work with the person on a personal level.
Technical interviews are f**king difficult to get right.
As a candidate they can be stressful, bewildering affairs, involving whiteboards, theoretical questions, hands on coding and sometimes even trivia questions. There is very little standardisation and many companies do a bad job.
As an assessor it can be difficult to feel confident that you have properly assessed the candidate and ensured that they meet the technical bar.
Perhaps equally frustrating is a candidate making it all the way to a face to face interview, only for the assessor to discover that they can’t code their way through a basic FizzBuzz challenge. To avoid being a horrible person this results in having to sit through a painful half and hour to an hour of the candidate fumbling even the most basic tasks before an awkward ‘you’ll hear from us…’.
While looking for jobs I have been subject to a dazzling array of different technical interviews, the most heinous of which is the non existent technical interview.
NEVER work for a company as a software developer if they don’t make any attempt to properly assess you technically before you join.
If they are happy to hire you off the back of an enthusiastic buzz-word laden conversation, then they will do the same for others.
That means it is a total crap shoot as to whether you will be working with talented, passionate developers, or brainless monkeys who read some blogs about ‘Agile’. Do not take that risk.
What does a good technical interview look like?
My favourite interviews as a candidate have involved writing and analysing code, in an editor, on a computer.
My most successful interviews as an assessor have involved writing and analysing code, in an editor, on a computer.
See a theme?
So my completely biased answer is that a good technical interview involves a candidate writing and analysing code, in an editor, on a computer (you know, like they would do if they worked for you for instance…)
More specifically, for a mid to senior weight, hands on Angular developer, I have found the following interview pipeline/format invaluable.
1) Screen CVs. Exclude any without links to work they have done, either live websites, or GitHub projects. This is the number one indicator of whether someone is worth talking to. Then remove poorly formatted CVs or ones with obvious grammatical errors. Our discipline requires a lot of attention to detail, and a sloppy CV is a clear demonstration that this quality is lacking. Also exclude any with obviously poorly written code on their GitHub. Flags to look out for are:
- Badly named functions
- No unit tests
- Poor documentation (no readme or one that is difficult to understand)
- Code that doesn’t compile
2) Once you have screened CVs, put the ones you are interested in through to a phone screening.
3) Phone screening – Very quick, no more than half an hour. This should involve a series of conceptual and practical questions around your domain. In my case this is Object Orientation (specifically TypeScript), Unit testing, Angular core concepts (this is basically to weed out people who haven’t really used the framework before) and Git knowledge (this is a surprisingly accurate indicator of how much code someone has written in a professional setting).
4) If you like them and think it is worth taking two hours out of yours and up to two other members of staff’s time, schedule a face to face technical interview.
5) The face to face technical interview involves a series of short, hands on technical challenges, each no more than ten minutes long:
-
Debugging exercise: Hand the candidate a PC/laptop with an Angular application that is broken. Ask them to debug why it is broken and fix it, then offer suggestions for how to prevent the bug happening in the future.
-
Pair programming exercise: Give the candidate a PC/laptop with a partially implemented FizzBuzz service and some unit tests. Give them a brief and have them use TDD to fill in the rest of the functionality. Cut this off after ten minutes. By then you will have a good understanding of how the candidate writes code, how they explain their thinking, how they ask questions, whether they have written unit tests before, and how they approach problems.
-
Refactoring exercise: Hand the candidate a PC/laptop with a deliberately badly written piece of code on it. In my case I use an Angular component class which is directly making http calls, is filled with cryptic comments and typos, as well as buggy code and ask the candidate to assess the quality of the code, and suggest any improvements they might like to make. This will give you an idea of how committed a candidate is to writing good quality code. I’m ideally looking for people who are visibly upset by sloppy coding practices.
-
RXJS/reactive programming and streams: This is a conceptually complex area of the current coding landscape. To understand it properly a candidate must have a good appreciation of asynchronous code, and be comfortable with abstraction. Both are ubiquitous in our work. This is not a trivia quiz, we allow the candidate to ask any questions about the syntax we are having them use, and allow them to Google anything they want. Here we present a piece of code with some console logs in it and ask the candidate to predict what will happen when it is executed. We deliberately ask at least one seriously devious question, to see how they handle really difficult problems, and how they behave under pressure.
-
Responsive design: Hand the candidate a piece of non responsive sloppy CSS and ask them how they might make it responsive. The answer we are looking for is some variation of ‘use flex and do this…’.
After this we all breathe, and we move into an open discussion where we answer any of the candidates questions, and more thoroughly explain the role, the team etc.
The key thing that has made this process successful for us is that you gain a real appreciation of how the person will be to work with, because you essentially work with them in the interview.
It also has the added benefit that you are able to sell yourself and your team to the candidate, as most are seriously impressed that you have gone to such lengths to properly assess them. The tests are also all quite fun, and even candidates that don’t perform well have said that they enjoy the experience and will go away with a good impression of your company.
Having had extensive experience of interviewing from the point of view of the candidate, I believe that this is a pretty effective and relatively painless way of assessing a candidate.
What are your thoughts?