This post is part of a series I’m writing on better technical interviews. I’d love your feedback in the comments!
- Part 1 - What’s the Point?
- Part 2 - Preparation
- Part 3 - The Actual Interview
- Part 4 - My Opinion on Various Techniques
- Part 5 - Common Interview Questions
OK, now that we understand the point of the technical interview and are in the right mindset, we need to prepare.
Preparing for the Interview
I firmly believe that a successful interview is based on the preparation the interviewer is able to do. Some of my ground rules include:
- Allow time to prep.
- Study the resume and the candidate.
- Come up with open-ended questions that go beyond the standard
- Find areas you need to dig deeper, and come up with questions for that* Add these questions / concerns / etc. to a cheat sheet so that you can use it in the interview
More information on this below.
Studying the Resume
I look at:
- The way they describe impact they make. Do they appear to grasp that their software matters to real people and stakeholders?
- Whether the resume is buzzword-heavy.
- If there are many short-term work engagements or large gaps.
- Is there anything I feel the need to challenge? A listed achievement or piece of experience that seems worth confirming or exploring?
- Do they take individual credit for what really seems like a team activity?
- Or conversely, do they not mention their involvement in large accomplishments at all?
- What don’t they list that I might be concerned about them not walking in with (a critical technology, a conceptual understanding, etc.)
There’s an important next step: countering bias in these cases. Does someone have a lot of short-term work? That doesn’t necessarily mean anything; it could mean they worked for a staffing firm and were asked to move around a lot, or that they sought out short-term gigs for a period of time. There are many good reasons for someone to have a large gap, including caring for a loved one, raising a child, illness, etc.
The key is to think in order to process those findings correctly. I’ve developed a process that I think works for me, at least personally. I’ll talk about it below.
Don’t forget the positives! I also look for:
- Awesome things they’ve accomplished that we could really utilize
- What they might bring to our environment / culture that we don’t already have
- Any technology experience that could round out our overall capabilities.
- Any leadership or core skills – mentoring, teaching, facilitating, presenting, writing.
Findings –> Concerns –> Questions –> Conversation
OK, so say I’ve made some notes or seen some “flags” on a resume, and I want to address them but in a way that is truly open and keeps me rooting for the interviewee.
- I note my findings while reading through the resume. I encourage myself to be critical, and I don’t hold back. I’m picky even.
- I take a step back, and I think about what concerns these findings give me, or what areas I need to follow up on / challenge / explore further.
- At this point, my findings are no longer relevant. I am only considering the concerns I’ve surfaced. Oftentimes, I disregard some of my findings as unhelpful, because they aren’t tied to a real concern that I can express.
- I create open-ended questions based on these concerns to explore things further.
- In the interview, we have a conversation around these questions, where I am rooting for someone and genuinely trying to get to know them.
I have found that this allows me to explore concerns I might have while providing someone space to speak about them in an open way, which usually tells me if a concern is actually a concern.
How does this work in practice? I’ll take one (potentially problematic) example: a number of short-term jobs in someone’s recent work history.
- Finding: “Uh-oh, I see a lot of short-term gigs here. That looks like a red flag. Did they not work out? Is there a persistent issue with this person? Are they job hopping and only looking to use us as a stepping stone rather than committing?” (remember: this is the spot where I allow myself to be human with biases, concerns, and not much of a filter).
- Concern: What’s the actual concern here? We’re looking for folks to grow with our company, and I need someone who is going to stick around and embrace our company, at least in good faith at first assuming that it stays mutually beneficial.
- Questions: OK, how can I help someone explore that topic in a way that will address my potential concerns. Maybe some questions would be:
- “What do you look for in a long-term fit with a company?”
- “What is an ideal day-to-day experience like?”
- “When have you felt best when working with a team?”
- “What do you think keeps you engaged when working somewhere?”
- Conversation: Potential results could be:
- Oh, it turns out that this person is really looking for the kind of culture and experience we offer, but hadn’t found it yet and was willing to keep moving.
- Oh, it turns out that this person really wants to affect change in ways that I’m completely on board with, but they kept hitting walls and knew they wouldn’t be able to make a long-term impact.
- Oh, this person took a gig with a staffing agency because they needed some specific flexibility but they’re looking for a long-term fit now. That makes sense.
- Oh, this person is really only looking for something short-term and weren’t entirely clear on how we operate, but we were able to have a conversation around it.
- Oh, this person really seems to be motivated by money, and they mentioned that they kept getting better offers and jumping ship. This tells me that our potential offer might not be compelling, and also that they don’t appear to be ready to put down roots somewhere for a bit. There’s nothing wrong with money, but this might not be the right person to invest in on-boarding at this time, especially if other aspects don’t line up.
What about alternate resumes? GitHub presence, portfolios, and things like that?
My stance on this is that I’m interested in anything a candidate is willing to put forth. I don’t require someone to have a GitHub profile (people can do things outside of work that aren’t coding!), but if they pass one along I’ll happily look at it.
The Importance of Open-Ended Questions
If I’m looking for a colleague that I can collaborate with, I want to know that I can have a conversation with them, and that they will not expect to be a lone wolf developer in a basement somewhere. I think that conversation is key to that. You learn a lot about a person’s capabilities, personality, values, and expectations when you give them space to tell you.
- Am I concerned about someone’s depth on a concept? I might ask them to apply it to a certain problem or situation.
- Am I concerned that they appear to be a lone wolf? I might ask them what makes a great team, or what it means to them to be a leader.
- Am I concerned that someone has very narrow experience? I may ask what technology interests them, what new things they’re excited about, or how they keep their skills up to date to understand what’s coming in the future.
- Am I concerned about someone’s potential engagement? I might ask what has them excited about the field or their potential upcoming work, or when they’ve been happiest. Oftentimes I’m concerned about this with any candidate, so I try to provide a question up front that lets someone demonstrate their engagement.
Write down these open-ended questions ahead of time, and try to get them in a rough order. This way you don’t word them poorly when you ask them, and you have a sort of structure to the conversation, which allows you to segue between in a natural way.
With all of this preparation underway, you’re ready to execute the interview. Onward!