RSS Feed: https://ericrallen.dev/

How I Interview Developers

Sat, 29 Jan 2022 21:15:07 GMT

I'd like to talk about interviewing.

I know what you're thinking:

Another blog post about hiring developers? Don't we have enough of those already?

We probably do, but I've spent a lot of time on both sides of the interview table lately and I get asked about interviewing often enough that I thought I should try to consolidate some of my thoughts and share them here.

Disclaimer: This post only reflects my personal approach to interviewing and does not necessarily reflect the thoughts of any past, present, or future employers.

Why Might You Consider Listening to Me?

If you don't know me (thanks for reading this, internet stranger!), you're probably also wondering why I think I'm qualified to talk about this subject.

Note: If you don't care about any of that and just want to see what questions I ask, you can skip to My Interview Questions.

I have interviewed well over a thousand developers for front end and full stack positions in my last few roles - one role in particular involved over 500 interviews over the course of a year for positions across various front end teams and physical locations - 60 of those were in a single week during a "hiring blitz."

As much time as I've spent interviewing candidates, I've spent even more time reading about interviews; talking about interviews with other developers, recruiters, managers (pretty much anyone who will talk with me about them); and refining my approach. Several of my employers have also had extensive interview training related to behavioral interviewing and inclusive interviewing, though I am by no means an expert in either.

At this point in my career, I feel confident saying that I am a good interviewer. Candidates seem to have a good experience - so much so that I've even received thank you messages from candidates that we didn't end up hiring.

Here's an actual message I received from a candidate we did not hire after an interview in 2018:

Hey! Thanks for the swell interview experience the other day! :)

I share all of this with you not to inflate my own ego, but to hopefully establish some credibility with you and show you that I've been putting in the work when it comes to interviews.

If you still aren't sure about me, that's cool - I get it. I have provided some links to great posts from lots of other people you might want to listen to instead in Further Reading.

Disclaimer: I do have to confess that I wasn't always a good interviewer. In fact, I started out as a pretty bad one who fumbled through dozens of interviews before starting to understand there was a problem and wanting to fix it. If you're one of those unlucky candidates I interviewed early on, I'm sorry - hit me up if you ever want help preparing for another interview, a resume review, or just to tell me how bad I was at it. If I have interviewed you recently and you want to refute my assertions that I'm a good interviewer, feel encouraged to reach out - I genuinely want to hear from you.

The Interview

I prefer to schedule one hour if the candidate has that much time free, but this same interview can be performed in 45ish minutes with some practice on knowing how long you can let a candidate take to answer and how long you can take to respond to questions, but you may have to cut out a few things.

This can also be condensed to 30ish minutes once you've got a really good feel for the timing of everything, but it leaves significantly less time for conversation and for the interviewee to ask questions, and ultimately provides a less optimal experience for everyone involved. Shorter interview windows generally leave the candidate with less time to ask their own questions. I always prefer to schedule a longer interview and end early if we're both out of questions than to schedule a short one and end with either of us having unanswered questions.

While this isn't necessarily always the order or the exact wording of the questions I ask, what I'm outlining below is pretty close to the interview experience that every developer should have with me.

Some roles or candidates involve digging into other topics a little more deeply or a candidate's answer may provide an interesting segue to learn more about them or may answer another question I was going to ask, etc. This means things change in small ways here and there, but the goal is to give everyone a similar experience that helps enable them to feel comfortable and present the best version of themselves. Interviews are already stressful situations (even for experienced interviewees) so there's no need to push anyone towards a panic attack.

Aside: I did actually have a candidate start to have a mild panic attack once - it was during that "hiring blitz" I mentioned earlier. It all turned out okay, but it really solidified for me just how stressful these things can be.

While you can't always avoid it, I try not to take too many notes during the discussion. Just some high-level bits and then I flesh them out after. You really want to engage with the candidate as another human being and that requires listening and actively participating in the conversation. If something feels really important and you want to make sure you capture it, ask the candidate if they are okay pausing for a few seconds so you can write it down correctly and then get back to the conversation.

My Interview Questions

I break a basic interview into roughly 6 parts:

Introduction (1-2 minutes): set expectations
- Make sure it's still a good time and the candidate is free for the scheduled duration. You should also find out if they have a hard stop at the end and let them know if you do - sometimes interview discussions go out of the original timebox and that's okay if it's a good conversation and interviewer and interviewee are equally engaged.
- Basic introduction: just your name, role, and how long you've been with the company; anything more is wasting time - the candidate can ask if they are curious.
- This will be a conversational interview; questions, follow-up questions, and back and forth discussion are all encouraged - due to time constraints, we may need to move on from a topic, but we can circle back or follow up in email.
- There are no right or wrong answers.
- There will be time for their questions near the halfway point and again at the end.
- Don't hesitate to ask for clarification or more explanation.
- Protip: Let them know upfront if you might have to mute a bunch because your dog somehow knows when you're interviewing and sometimes decides to be as annoying as possible during interviews
Interviewer Questions Round 1 (15-30 minutes): This section has some easy getting started questions and then some specific behavioral interview questions.
1. Tell me briefly about a project you've been working on in the last 6-12 months. What tech stack have you been using?
  - There's no need to get into everything a candidate has done throughout their career - you've seen their resume and/or LinkedIn, right? - just get into what they've been doing lately as that's generally the most relevant.
  - Protip: You may need to stop the candidate if they go too long on this one; about 5 minutes should be the upper bound, but 2-3 minutes is ideal.
2. What kind of role are you looking for? Are there any other experiences you'd like to highlight that you think would make you successful in that role?
  - This gives them a chance to describe what they are looking to do in their next role and also gives you a deeper dive into any other experience they have that might be relevant.
3. What technologies are you looking to work with? Are there any you would specifically like to avoid working?
  - Avoiding some tech is totally okay. Sometimes a specific language, framework, etc. just isn't our thing. I avoid Java and Ember because I just don't really like or fully grok them.
4. Tell me about a project where you feel like you really succeeded. What about your contribution to that project made it so successful?
  - Let them tell you about that time they totally crushed it. This is a chance to ask more questions and dig deeper into what they did, how they did it, and what they feel they are bringing to the table.
5. Tell me about a project where you feel like you failed. What happened? What, if anything, would you do differently now?
  - Everyone has struggled on a project at some point. It's okay to fail as long as you learn something from it. (Ask me how I know you always need to back up the production database.) This is a chance for the candidate to be a little vulnerable, show how they take (or shift) responsibility, and how they've learned from past mistakes.
  - Some people won't feel comfortable talking about failure, so if someone gives you a non-commital answer you may need to probe deeper for an actual real-world example. Be sure to let them know that failure is a thing that happens to all of us and they don't have to incriminate themselves for taking down us-east-1, but we want to hear about a situation where they learned from a mistake.
6. Tell me about a conflict you had with a coworker, stakeholder, customer, etc. What happened? How did you resolve it? In hindsight, would you approach it differently?
  - How do they approach conflicts? What do they do when they can't come to an agreement? No one wants conflict at work, but there are lots of times that we might disagree about how to approach solving some problem, how some business request degrades user experience, or how some user request is not possible given our current resources.
  - Protip: This could be a good time to reflect on how your current team approaches conflict and maybe briefly discuss it with the candidate in relation to their answer.
Candidate Questions Round 1 (5-10 minutes): This is a good time to shift gears and let the candidate ask some questions - remember this is as much a chance for them to interview the company as it is for the company to interview them.
- Engage as openly and honestly with the candidate as you can. Try not to ramble and to answer questions concisely. After you've done a lot of interviews, you'll start to refine the answers to certain questions and find that you've got certain responses ready.
- Protip: To avoid rambling, sometimes I start a stopwatch and glance at it every so often while answering a question so I know how long I've been talking. Remember, this is the candidate's time to learn about the company, and the longer you spend answering one question the less time they have to ask other questions.
Interviewer Questions Round 2 (10-15 minutes): This section gets into some more technical interview questions and also allows you a chance to dig deeper into any follow-up questions you want to ask based on anything that's been talked about so far.
1. Tell me about an interesting or particularly challenging problem you solved in the last 3-6 months. What made this problem interesting? How did you approach solving it?
  - This gives the candidate another chance to show off their skillset and talk about it passionately. You can probe deeper into any specifics around this and just sort of talk about it with them a bit.
2. Tell me about a tradeoff you had to make in the last 6-12 months. What were the options? How did you choose between them?
  - A lot of what we do involves managing tradeoffs: performance vs readability, faster delivery vs future maintainability, abstraction vs repetition, etc. This is a chance to dig into how the candidate thinks about these things and how they navigate the often nebulous waters around this kind of decision-making.
3. Follow-Up Questions: if you have anything you want to expand on based on your conversation with the candidate so far, this is the time for that. Want to hear more about how they used AWS for a project? Did they mention navigating a rewrite at a large company and you want to hear more about the planning and execution? Dig in a little.
4. For Senior-ish Roles: Pretend that I'm a junior developer without much context and explain [insert topic here] to me.
  - Some Example Topics (pick something relevant to the candidate's actual day-to-day work and previous experience, and, it should go without saying, but make sure you are comfortable with the topic):
    - Feature Flags
    - Blue/Green Deployments
    - A/B/N Testing
    - CSS Specificity
    - Scope in JavaScript
    - Model-View-Controller (MVC), Model-View-ViewModel (MVVM), or some other pattern relevant to their past work or your codebase
    - Functional Programming, Object-Oriented Programming, or any other programming paradigm that might be relevant to their past work or your codebase
    - Continuous Integration / Continuous Deployment (CI/CD)
    - Serverless Functions (AWS Lambda, Azure Functions, Google Cloud Functions, etc.)
    - Caching
    - Containers
5. For Junior-ish Roles: What language, library, framework, etc. are you looking forward to learning and working with in the near future? What tech is exciting to you right now?
Candidate Questions Round 2 (remaining time minus 30 seconds to a minute)
Wrap Up (30 seconds-1 minute)
1. Inform the candidate of the process from here and about how long they should expect to wait before hearing back. I also always let them know that if there is a bottleneck in the process, it is almost certainly my fault and not the fault of our internal recruiters.
2. Let them know that they can email you (or their recruiting contact) if they think of any more questions.
3. Thank them for their time.
4. Protip: Take a few minutes after the interview to compile your initial thoughts and shoot them over to your recruiting partner. If you need to think on it a little more, save that email as a Draft and set a reminder for a couple of hours - hiring is crazy right now, if you wait too long, you could easily lose that candidate.

Why This Approach

There are several benefits to this approach:

Human-Centered: It treats candidates as humans, and as equal participants in a conversation.
Hard to Game: There isn't really any coaching that can prepare someone for this interview. I've worked with a lot of recruiters and consulting firms over the years and sharing knowledge about interview questions always comes up when you're the interviewee. With these questions, you could do something like publish them on the Internet for everyone to see, and it would have no effect on the efficacy of the interview.
Enjoyable: I might be personally biased on this one, but as the interviewer, I enjoy this kind of conversation a lot more than pop quiz style interviews I've been asked to conduct in the past. As I mentioned already, candidates seem to enjoy this interview process, too.

There are some possible drawbacks, too:

Time-Consuming: If you are in a high-throughput recruiting situation (at one point I was reviewing 30-40 resumes a day for dozens of open positions), you won't have the time to engage with each person at this level and might need to introduce something that creates a quicker filter before this kind of interview. You might also want to work on improving the quality of your filter at the application stage, resume review stage, and any initial recruiter call that might happen after a resume has been reviewed.
Not Directly Technical: You only learn as much about a candidate's technical ability as you are comfortable digging into during the discussion. Some people will maintain that you need to put a candidate through some kind of whiteboard question where they are put on the spot to write code in a context that is entirely unlike their normal work, and they could be right.

Introducing @RSS bot

Sat, 25 May 2019 12:50:06 GMT

We have a lot of developers working in different places at different times at Skookum. People are sharing interesting, useful, and/or important articles at various times throughout the day. Unfortunately a lot of that content is missed by the majority of developers.

Enter @RSS bot, a Slack bot that will generate an RSS feed of links shared in channels it is invited into.

Every time a user shares a link in a channel it is listening to @RSS bot will ask that user if they would like to add the link to the channel's RSS feed, so users have control over what appears in their RSS feed.

Are you tired of missing links shared in your Slack channels?

Get @RSS bot today!

Senior Developers

Sun, 03 Mar 2019 14:19:16 GMT

While I don't care about title inflation or title absurdity, I do care about what the people doling out and receiving some of these titles assume that they mean.

One title modifier, in particular, Senior, is important to me, not because I have it, but because without people who embody its Core Principle I wouldn't be where I am today.

I wouldn't be able to help others get here if that principle hadn't been instilled in me.

Meaningless Titles

In an industry where two people can do the same job, but one is an Engineer while the other is a Ninja, I think it's safe to say that our titles are meaningless.

Which is good. You could spend your whole career chasing ever-loftier titles. That way lies madness. Unfortunately, a lot of companies either use title changes in lieu of pay raises, or tie pay to titles in a way that requires doling out new ones or adding modifies (How many of you are a [Title] II or a [Title] III?) to them every 12-18 months.

When I worked for Bank of America, my title was so long that they stripped almost all of the vowels from it and it also featured a hyphen (-) and a semicolon (;). Add to that the fact that basically every full-time employee who writes code is a "Vice President" and you end up with a silly VP title that means absolutely nothing and is impossible to explain to anyone.

I don't have any solution for this insanity in our industry, and it's not really important to me that we change it, but I wanted to make sure that we covered how meaningless we've made all of our titles before I explain why Senior is actually important and why the meaninglessness we've created could lead to an industry-wide problem.

It's also worth mentioning that the Engineer title is ridiculous given the generally ephemeral and fragile nature of what we build and the lack of any oversight or credentialing body, but that's a topic for a different rant.

The Senior Core Principle

A Senior Developer (or Engineer, Ninja, Rockstar, etc.) is not just someone who has more experience or one who is the lead on a team or a project.

The Senior title comes with a vitally important responsibility: to make those around you better Developers.

That responsibility is the Core Principle of the Senior and it is one that should span our entire industry. It is rarely listed in job descriptions, but it should be.

What we see an alarming amount of today is Developers being put into Senior positions as the next logical step in their career progression or as some reward for sticking around. While this won't have a huge immediate impact, it will radiate through the following generations of developers and amplify the effect over time.

When a Senior who embodies the Core Principle teaches the next generation of Senior developers, they go on to embody that principle and instill it in the following generation, too. Life is good.

When a Senior who only has the title doesn't instill that principle in the next generation - or, even worse, instills the idea that Seniors are arrogant and unhelpful - then that idea trickles down and more arrogant, unhelpful Senior Developers will be created. Here there be dragons.

If that eventually becomes the norm, how much more toxic would Developer culture become? How hard would it be for someone to transition into the field? How hard would it be for Junior developers to grow into Senior developers?

If you're a Senior right now: What are you doing to make those around you better Developers?

My Senior Philosophy

My approach to embodying this Core Principle involves several things, but the primary directive is trying to make time for other Developers to ask questions, talk through solutions, vent about clients, ask for code reviews, and ask about career advice.

I always caveat that my code reviews and my advice may not always be the best solution, but they are what I would do and then provide the reasoning behind that decision. I've found that it helps people learn when you show your work, and it also invites the other Developer to question your thought process and provide their own insights on things you might be overlooking.

In the service of making myself and other Developers better at what we do, I organized a few initiatives during my time at Skookum and continue to do similar things at every other place I work.

Monthly Coding Challenges: Every month we will tackle a new coding challenge and help keep each other motivated in a dedicated #coding-challenges channel in Slack. Each challenge is different and allows a wide range of Developers to hone their skills.
Monthly Developer Presentations: Every month we will invite one of our developers to present a Web-related topic to the rest of the Development Team. Hopefully, this helps Developers iron out presentations for Meetups and conferences while also giving the rest of us some new perspectives.
Bi-Weekly Video Series: Every 2 weeks we watch a Web-related video and discuss it as a group. This was previously an initiative, but the developer who started it left the company, so a colleague and I resurrected it. This gives us a chance to experience conference talks we would otherwise miss out on and also facilitates conversation between Developers at all levels.