Danny Briskin, Senior Technical Consultant
The issue
I spent a lot of hours interviewing software developers and test automation engineers (which are developers as well) candidates. Their level was from a trainee-junior to a very senior level. On the other hand, I was on the candidate side in many technical interviews during my career as well. I was aiming for senior level positions recently as you may have guessed. Let me share some thoughts about technical interviews for senior level candidates.
What is a Technical Interview?
Let’s start with very obvious things. There are several goals of technical interviews:
- To prove (or disprove) that a candidate has knowledge and skills mentioned in their resume.
- To match the level of candidate’s knowledge/skills with position requirements.
- To form an opinion on candidate’s overall mental abilities, including the way of thinking, the pace of making decisions, etc.
- To reveal other types of knowledge/skills, not mentioned in the resume but applicable for position.
First two are the main, let’s concentrate on them in this article.
How to verify?
The most usual way to verify that a candidate knows technology “A” is to ask a question about it or to solve a simple task using that technology. Interviewers usually are limited in time, so the question is not supposed to be extremely complicated, and the task must be quite simple as well.
The thing that’s gone from interviewer’s mind at this time, that they need to also verify the level of knowledge.
Most human knowledge is built in a way that advanced topics are supposed to be known only by those who know more simple ones. I.e., if a person can solve differential equations - there is no doubt that they know basic arithmetic operations and numbers as well.
On the other hand, the idea of starting an interview with the most complex question looks a little bit weird (and demotivating for a candidate).
Please don’t do it!
Your company creates sophisticated applications containing thousands of lines of multi-layered code built with modern approaches and techniques? Well, let’s ask a candidate to sort an array, or to reverse a string. Those who do it in the way you think is the best, they perfectly fit the position, right? Who are they? Fresh graduates, those who can google and memorize “100 Tech-A interview questions” - are you looking for them?
Sure, sorting algorithms are an essential part of computer science and knowledge of its advantages and drawbacks are not useless. If you are interviewing a junior level candidate it is worth asking such a question (anyway, there aren’t a lot of areas to ask about because they are juniors).
But aren’t you looking for someone who can create “sophisticated applications”? We are talking about senior software developers, aren’t we?
The difference between juniors and seniors
What is the main difference between junior and senior level candidates? The most obvious (and not correct) answer is - the amount of their knowledge in certain areas. I saw seniors with a broad but not depth knowledge in many areas and juniors with deep but not broad knowledge in one certain area. There can be opposite cases. It depends. Thus, a junior can overrun a senior for knowledge. In fact, the main difference is in their experience. While juniors will “just try”, seniors will act “for sure”.
Is there any other way?
But how to measure and verify the experience in an interview? Again, we are talking about senior software developers, not sales managers. A developer’s experience is built with the number of projects they have completed, or, in other words, with lines of code. What can talk about developer’s skills more than their code? Thousands of words will say nothing, show the code! If a senior level candidate doesn’t have a code to share, the code they are proud of - they are just not senior developer.
Let’s talk about the code
Some interviewers doubt that a code shown is created by a candidate and prefer live coding instead. I’m quite sure that it is not possible to verify all coding skills during a short interview time. While proving authenticity of the code is a very obvious task. You can ask a few questions about code artifacts in different files, ask about variations of parameter values, talk about exceptional situations, possible optimization, parallel usage of the same piece of code, unit tests for this specific function… There are so many ways to verify that you are talking to author. Even if you don’t have deep knowledge of the technology used, the way the application is written can say a lot. Are there unit tests, documentation and commentaries? Was the code convention used for example? If you can’t do it, I have sad news for you - you are just not ready to interview a senior level candidate. Sorry.
Summary
Using “talk about code” guideline instead of “the difference between List and Set”-like questions will not only save interview time (money and effort) but will not demotivate both candidate and interviewer (because both know that other one knows the next question and answer). If an interviewer refuses to talk about code and offers live coding dull tasks like “count number of different characters in a string”, it only may be a red flag for candidate to be cautious with that company. Let’s respect each other during interviews and expect your counterpart to be a smart person. Good luck!