What interview techniques have been effective at finding high level candidates and what would you stop doing because it didn't help?

[cfarmer-fearless]

Hey folks! I'd like to share and explore techniques that have been effective in finding great candidates during technical interviews. We can all see that the current tech job market is changing. There is a lot of saturation and candidates are coming in with a greater variety of skills, experience, and backgrounds. In addition, cheating is becoming more common, where candidates are being coached or given answers in real time. This makes it difficult for interviewers to assess the candidate's actual skill and knowledge.

What are some interview techniques have you used to find great people that you feel confident will improve our teams at Fearless?

[fearlessrob]

It's easy to fake straightforward answers to technical questions but its significantly harder to fake (or hide) real passion for languages, platforms and processes. I've had success aligning my questions in a way that can elicit an emotional response either positive or negative to a way of doing things. I'm reminded of Kelly Slaughter's question of "what's your favorite Git function and why?" which was a part of my Fearless interview. My answer was git reflog because my team was always losing stuff from bad merges and it was a way to demonstrate that with sufficient commits nothing is truly lost in a repo. Hers was bisect for its value as a debugging diagnostic tool, which I had significantly less experience in but we were able to have a lively discussion about both functions and their role in a solid dev team.

[cfarmer-fearless]

Gonna use that Git function question for a SWE 1 interview I have today. Love it!

[cfarmer-fearless]

I feel like the challenge with this approach becomes translating subjective responses with objective skills. On paper, our job as an interviewer is to answer whether or not the candidate has specific objective skills, like "basic understanding of React". So it's up to the interviewer to ask a question that elicits a response that shows that objective skill.

Edit: not to say this isn't a good approach. It just seems like there's a trade off.

[fearlessrob]

@cfarmer-fearless If the ChatGPT facilitated answers are indistinguishable from objectively good answers then what use does the function of the interviewer "on paper" really serve?

[whytheplatypus]

I really like this too. Ask for a story, something that actually happened to them much like Rob's example. ChatGPT can come up with it but you can usually tell that it didn't happen to them when they try and read it, and you can trip them up asking for details... but mostly the story gives you a chance to see what they care about, how they think, etc.

It doesn't have to be work either, it can be from school, or a random personal project, anything.

[sublettk]

I think that there are some underlying questions to ask beforehand. For example, establishing a consensus among the interview panel about what makes a good candidate and why. There ought to be a list of objective skills and experiences that can then be cross referenced when evaluating candidates. We must ask ourselves how can we limit personal biases during the interviewing process. I am concerned with the practice of asking questions that elicit an emotional reaction in the candidate as that has the potential to introduce bias. Are we looking for emotional expressiveness or objective competency that matches the predefined competency criteria? Essentially, pivoting your posts overarching question to more granular ones can get you the answers that you are seeking. If searching for a candidate with a certain skill, a list of panel-agreed opinions of what constitutes competency can then be used to shape certain questions to establish an objective consensus of competency. For example, what constitutes an "objective understanding of React?". I try to ask questions that try to demonstrate a candidates understanding of "why" something happens, was created, or is used. Of course we care that the candidate knows "how" to do something, but LLM's are not yet adept at explaining "why" especially when it comes to relating it to an individual's past work experience. This is a way to limit the use of LLM's to construct stories on the fly for manipulating interview success.

[sublettk]

I meant to add my reply to Chase here - not as a response to Rob. 🙈

I think that there are some underlying questions to ask beforehand. For example, establishing a consensus among the interview panel about what makes a good candidate and why. There ought to be a list of objective skills and experiences that can then be cross referenced when evaluating candidates. We must ask ourselves how can we limit personal biases during the interviewing process. I am concerned with the practice of asking questions that elicit an emotional reaction in the candidate as that has the potential to introduce bias. Are we looking for emotional expressiveness or objective competency that matches the predefined competency criteria? Essentially, pivoting your posts overarching question to more granular ones can get you the answers that you are seeking. If searching for a candidate with a certain skill, a list of panel-agreed opinions of what constitutes competency can then be used to shape certain questions to establish an objective consensus of competency. For example, what constitutes an "objective understanding of React?". I try to ask questions that try to demonstrate a candidates understanding of "why" something happens, was created, or is used. Of course we care that the candidate knows "how" to do something, but LLM's are not yet adept at explaining "why" especially when it comes to relating it to an individual's past work experience. This is a way to limit the use of LLM's to construct stories on the fly for manipulating interview success.

[mikewolfd]

My interview format generally follows this approach:

Resume Review: I start by taking basic notes from the candidate's resume, focusing on key experiences and tools they've listed.

Introductions: We kick off with quick intros to set the tone and make them comfortable.

• Clarifying Questions: I give them an opportunity to ask any clarifying questions that might help during the interview. It's surprising how often candidates have no idea what role they're interviewing for—sometimes because they're juggling too many interviews or recruiting didn't clearly explain what Fearless was or the position. If they ask good questions here, it's a positive sign.

• Behavioral & Technical Mix: I then dive into a random mix of behavioral and technical questions, hitting different conceptual levels. This makes it harder for candidates to rely on tools like ChatGPT for prepped responses, as the prompt needs shift quickly. idk if this really helps tbh.

• Drilling Down on Specific Roles: I drill into their past roles, asking why they made certain decisions, why they didn’t take different approaches, and how they managed tech debt. I also ask about their decision-making process when selecting tools—what factors they weighed, what trade-offs they considered.

• Level of Involvement: One critical area I focus on is determining their actual involvement in the projects they've listed. I ask directly if they did the thing or if they were just "present" or "participated." For example, I can’t count how many times I’ve seen Terraform on a resume, only to find out the candidate merely tweaked a variable. I push hard on this because I want to know their real level of experience with specific tools. It’s useful for assessing their overall comfort, but it also forces them to be honest. And when they aren’t, it’s usually pretty obvious.

A lot of people can speak well to tools conceptually (Terraform, React, etc.), but when you ask about real-world examples, their story falls apart. I once interviewed someone who could explain Terraform modules, configuration, state, etc. in depth, but when I asked about actual hands-on experience, they couldn’t give solid examples.