All Things Development

An Approach To Technical Interviewing

Josh Holat -

At Fullscreen Media I serve as the lead of a backend development team that has grown over the past year. In that time we've had developers move on to other positions, too. We've also hired some who didn't end up being great fits even after making it through our interview process.

In this joining and departing of teammates I like to think I've learned a fair amount about interviewing. Like most things in life, most of these learnings came through mistakes. However, just as being a successful interviewee requires experience and time so does becoming a successful interviewer.

The reason this post has been titled "an approach" is that this method is always evolving and changing. I imagine some elements may differ greatly depending on the size of your team or culture of your company. For instance, before Fullscreen I was the CTO of StageBloc (acquired by Fullscreen), a much smaller team wherein our hiring process was quite different from today.

For some context, our backend team is currently five developers including myself. Our current process is as follows:

  1. A technical recruiter in HR filters out resumes and passes along promising ones to me as the tech lead. We currently use Lever for this which I have grown to enjoy.
  2. I complete a phone screen of the candidate where I ask basic technical questions based on the candidate's resume. My goal is essentially to ensure the candidate has a good amount of experience with the technologies we use. However, this is also an easy time to get a general sense of a candidate's communication skills.
  3. I send the candidate a code challenge. This code challenge is designed to take only 1-2 hours of work. It was designed by the team to help show competency in the concepts we felt strongly embodied what would make a successful team member.
  4. Assuming the code challenge is satisfactory, we then schedule an in person interview. The candidate typically meets with the backend team itself as well as with other team members (the frontend team lead, etc).

Below is the outline we currently use for our in person interviews, specifically for backend developers. As I mentioned earlier, this is a living document that changes as we discover which questions or approaches work better than others.

General

  1. Team overview

    • Introduce ourselves
    • General team structure

  2. Any questions before we get started (about the team or project or company)

  3. Share your background with us

    • Talk to me about your code review process
      • How did you resolve conflicts (in methodology / implementations)? Explain a scenario where your opinion changed and one where it may not have.
    • Tell me about the roles on various teams you worked with in the past (on call schedules, etc)
      • Tell me about what went well and what didn’t go well
    • What do you enjoy doing outside of work?

Code Challenge Feedback

This part varies based on specific solutions to the code challenge the candidate provided. Typically there isn't a ton of questions here since if the code challenge was that bad we wouldn't have brought them in for an interiview with the team. It's mostly just a conversation about why they chose to solve the problem in the particular way they did.

Questions

  • Describe a design pattern you’ve used recently. What did you like about it and where did it fail to solve the problem you had? How did you supplement it?
  • Describe a design pattern that was recommended to you that you decided not to use and why did you opt for a different solution?

Whiteboarding

Write a program that prints the numbers from 1 to 100. For multiples of three print "Company" instead of the number and for the multiples of five print "Name".

Some of you may have noticed this is essentially FizzBuzz. I'd recommend reading that post to understand why we use this question.

You are creating software to manage a library of books and their authors. This software needs a catalog searching feature.

  1. How would you manage this data? What datastore would you use and how would it be organized?
  2. How would you output a list of each book and it’s author?
  3. Your library become successful and you are now receiving thousands of queries a second against your datastore? What problems might you encounter and how would you solve them?

The point of this question is essentially to ensure the candidate understands basic database schema modeling. We typically also have them whiteboard database queries (in our case MySQL) to check that skillset.

Scenarios

  • Let’s say your software has a reporting system where customers can generate CSV reports of their data. Some of these reports have a small amount of data and are quick, others have large datasets that are beginning to cause issues (table locks, timeouts, file size). Describe a couple of solutions to these problems.
  • You wake up to a page at 4 AM saying the CPU on your main writer database is above your 60% threshold. What steps do you take to solve this?

Other

  • Describe a scenario where message queueing systems would be a good solution. What message queueing services are you aware of?
  • What are your favorite and least favorite monitoring tools?
  • What are you favorite AWS / Azure / Google Cloud tools?
  • What is your preferred development toolset?
  • What is your favorite framework and why?
  • What is your approach to technical debt or issues that may arise during the week that need immediate attention?

I hope you find this useful! If anything, I'd think of it as a starting point of which you can pick and choose which pieces make sense for your hiring process.

unsplash-logoBreather