Interview Questions for Junior to Senior Software Engineers & Architects

Or the ones I ask anyway.

Photo by Daniel McCullough on Unsplash

Just a few weeks ago, I started at a quickly growing new company and was asked to give an interview. I conducted quite a few interviews at my last job and surprisingly found it to be more enjoyable than I thought it would be.

I kept a running list of questions along with the notes I took during interviews. With each interview, I would improve upon my list of questions until I thought I had a pretty good flow to my list. The interview usually took about an hour or so depending on how much a candidate would talk. I could always skip questions to save time.

Naturally, I kept this list of questions in plain text files on the hard drive belonging to a laptop which I turned in on my last day.

As I hit cmd + n to start from scratch I had a thought. Even if only so I can copy this list of questions again for the next interview, why not also publish them so others might find them useful?

I hope you do.

Section One: Background

I use these questions to get to know the motivations behind a person being willing to write instructions interpreted by computers all day. The hope is that answers are indicative of a passion for what a candidate is doing/pursuing as opposed to “it’s a job”. A latter scenario tends to shorten the interview.

1. What got you interested in technology and programming to begin with?
2. What is are your favorite aspects of programming?
3. What is frustrating about programming?
4. What is a technology you haven’t picked up yet, but are most interested in learning? It does’t have to involve code or be relevant to this job.
5. What’s the next rad thing the cool kids are all going to be using in 3 -5 years?

Section Two: Experience / Tech Screen

Next, I usually ask questions specific to the languages, platforms or methodologies we’re using at the time. The questions I came up with are more generic but the goal is the same: To determine if a candidate is able to do the job and not trying to BS their way through the interview. It’s also helpful to get a sense of how well rounded a candidate is, or is not.

1. What’s your favorite HTTP status code?
2. What’s your strongest language right now? Was it your first?
3. Do you enjoy working on the front end or the back end more?
4. When is the last time you picked up a new language? Which one? What was your experience?
5. What was your favorite project to work on from a tech standpoint? Least favorite?
6. Which are better — SQL or NoSQL databases?
7. Do you prefer functional or object oriented programming?

Section Three: Methods, DevOps & Architecture

I mostly skip over this section for junior level candidates. These questions quickly separate those who have experience working with modern processes and patterns and those who do not. I’ve spoken with several mid level candidates who had some working knowledge of these topics, but little or no hands on hands experience. I expect that to change quickly as time goes on.

1. Describe the entire process, ideally, by which code goes from the engineering teams’ laptops into production.
2. Describe some ways you currently test code and applications.
3. TDD: Waste of time or the best way to produce quality code?
4. Now that our code is fully tested and in production, how do we make sure it’s running 24/7 and we aren’t being paged at 2am?
5. What are some the benefits we get by deploying software to cloud platforms vs self-managed infrastructure?
6. Tell me about micro services. What’s primary the theory behind them?
7. How micro should “micro” services be? What’s the best way to deploy them? Monitor them?*
8. What are some of the hardest parts of building systems with a distributed architecture? What steps might you take that solve those problems?*
9. What are some challenges associated with ephemeral compute and how might we overcome them?*

* Good answers to these questions indicate a pretty strong candidate as these are the types of problems I work on everyday. If you have good answers to these, please contact me. We’re definitely hiring.

Section Four: Teamwork / Workplace Experience

This section looks at previous work experience. More importantly, it gets at those ever important interpersonal communication skills. A candidate who has answered flawlessly so far can still bomb the interview here, in spectacular fashion. You can have a PhD and be the solo author of 5 popular programming books but if you’re an asshole, I don’t really want to work with you and no sooner would I subject my team to anyone with a bad attitude.

1. If you had an unlimited budget and resources (i.e. people) to create the new LinkedIn/Facebook/Instagram/Tinder killer, what does your team look like? How many people? What are their roles and skillsets?
2. Tell me about the teams you’ve worked on so far. How big were they? What worked well? What didn’t?
3. Your product manager/owner insists the team build out some UI / UX that deep down you know, is really truly horrible. How do you handle the situation?
4. Do you prefer to work with people at the same skill level as you, or do you also enjoy the ability to impart your knowledge to more junior team members?
5. Have you ever had an experience where you thought you had a really good idea or solution, only to have it strongly criticized and never adopted?
6. When is the last time you had to change your mind about something on which you previously held a strong opinion? If it helps it doesn’t have to be work related, better if it is.
7. Hypothetical: For the past week or two, you notice one of your team members isn’t pulling their weight. What do you do about it?
8. In your opinion, whats the most successful or fair way you, your managers and/or your company as a whole measured success?

Section Five: Personal (In Bounds) Questions

These are not always the most relevant or impactful questions, but can be helpful for determining team/personality/cultural fit. My personal reason for asking these types of questions is I’d like to know if I might hang out with this person after work.

1. What’s your favorite place in the world you’ve traveled to, or want to see?
2. What do like to do most you do when you’re not computing?

At this point, I’ll usually talk more about the specific role and then I like to open the interview up to questions.

Closing Thoughts

As of today, I’ve been on the other side of the grilling more than doing the grilling. Interviews in tech can be tough. I found some of them to be downright intimidating and off-putting. I like to view a first round of questions as a friendly introduction to the candidate. A “non-belittling, non-discouraging, non tech bro way” if you will. An interview not just to vet someone’s skills in technology, but to get to know the candidate a bit as well.

And of course, this was always just round one usually given over the phone.

In one case I wrote a coding challenge specifically for a junior candidate, but I’ve never given them to senior level candidates, my thoughts there could be a post on its own.

As you may have noticed from the above questions, while I don’t love being wrong, I am usually quick to admit when I am. I think changing your mind is just about the best thing you can do for it. A bit of constructive criticism certainly never hurt anyone — that isn’t too sensitive. Which is to say, I’d be stoked to hear any feedback or thoughts.

Happy hiring and job hunting!