How To: Interview a developer, as a developer!

Author note: This article focuses on the interview process for a Frontend position and was inspired by a post, I interacted with, on LinkedIn.

You now have a new responsibility within your company. The HR/Recruiting department needs your help in assessing candidates, for a technical position. Luckily they've come to the right person because they know you have the soft skills and technical expertise to do just that.

But you, a senior developer, know nothing about interviewing other developers. Fortunately, for you, there are several resources on the web that can help you with that. From using CodingInterview.com as a basis for your interview or requiring that the candidates finish a certain challenge on LeetCode.com, there are multiple ways you can create your process of assessment. You could even use this great article as a starting point.

Of course, if you work in a big tech company there is a procedure for coding interviews. Still if you work for a small company then most probably that procedure is missing and you have to help the Recruiting department implement it.

My approach

Below is my process, for assessing the knowledge of a candidate. I have "perfected" this approach throughout many many interviews.

Since I'm not interested in the recruitment part, I assume that the candidate has already been screened by the Recruiting department, so depending on the time allotted for the technical interview, I structure the discussion so that it does not exceed more than 1 hour. I receive in advance a resume and hopefully a public Github or some VCS, to look over some code written by the candidate.

If the person is of Senior level, then it is more a technical discussion rather than a coding interview. So far, from what I have experienced, a Senior level candidate not knowing what they are talking about has never happened, but it doesn't mean it will never happen.

If they are of Junior or Regular level, then the coding interview process begins.

Setup

I use Notion (which is a great tool by the way), where I have the whole process structured on several pages. This includes a database for evaluation (I don't store any personal data, I score the candidate from 1 to 5, set a skill level, type of focus: Frontend, Backend, FullStack, and finally some notes), technical questions for different programming languages (usually JavaScript and PHP), frameworks and lastly coding challenges that help me in determining the candidate's ability to solve a problem or if they can explain a particular solution.

Process

The whole discussion is very informal. I start by asking the candidate what tools, frameworks, and libraries they use and what they prefer to focus more on: frontend or backend. I ask these things so that I can get an idea of ​​what the person knows, not what is written in the resume, since we all know that resumes are sometimes bloated and because I want to know if the person might be a good fit with one or more of the ongoing projects within the company.

As I mentioned at the beginning of the article, the interview is for a Frontend position, so depending on the above answers, I either start with basic JavaScript questions, and depending on the resume we go through questions about Angular / Vue / React, move on to CSS, or start with questions about PHP, databases, and OOP. Finally, I ask about a VCS, usually about Git.

Here is an example of a fundamental JavaScript question I usually ask in interviews:

Another question I could ask is:

What is the difference between undefined and not defined in JavaScript?

Here is a great article explaining this.

If I can't form an educated opinion about the candidate, since the above questions were language focused, I can switch to more agnostic things like Data Structures or Algorithms. Depending on the candidate's skill level I could also ask about stuff like Hoisting, Closures, or SOLID. If they focus more on the Backend, then I could be asking about stuff like Singletons, Prototypes, or even deadlocks.

The above was more theoretical, now I move on to ask practical code questions.

I start by showing the candidate a piece of code and ask them to solve a certain problem for me, and I make sure to mention that they can write pseudocode, because I'm more interested in assessing analogical reasoning, problem-solving rather than exact code, my reason being that the time allotted for the interview might not permit it and also:

Remember - the goal isn't to see how fast they write the right answer. I'm trying to learn about how they work and communicate.

Here is an example of a problem I would be asking, in an interview:

If they know how to solve the above problem, then it's all good, if not, I propose several solutions and ask them to explain how they work. This will allow me to understand their "train of thought" from start to end.

Conclusion

If the candidate doesn't know about a certain paradigm/concept or how to solve a practical problem, I try to briefly explain it, if the time allows it. I do this because the person is already stressed and I try to leave them with more knowledge than they came in with.

If there is still a need after the coding interview session, I have prepared some homework, for example: develop a small app with whatever frameworks, or libraries they want, put it on a public VCS, CodeSandbox, or StackBlitz so that I can evaluate it and see that it works correctly.

After the interview session is over, I provide feedback to the recruiter in a short, concise email, that covers all the assessed points.

This is my interview process. I know it's not perfect but so far it seems it got the job done and I helped in hiring some great developers. Please feel free to point out any flaws you might see in this approach or if you have any feedback you can find me at @stefanbc.