Every hiring interview, much like any other meeting, should have a clear agenda. Personally, in the end, I want to be able to answer these questions:
- Is the candidate a good fit for the team?
- Can the candidate challenge the ways we do things, propose ideas, and improve the team?
I've been on the other side too, and in that case, my questions to answer are the following:
- Does this job align with my preferred working conditions?
- Can I get ownership? How much?
- What's the pace like?
- What's their engineering culture?
- Do they care about their craft? How do they comb their code debt?
- Will I grow? If I stay for 4 years, will I feel I repeated the same year four times?
- Are they remote-first or remote-out-of-necessity?
- Is it a step up money-wise?
- How are promotions handled? Is being an IC viable?
Starting with an honest intro
I preface the interview with an introduction about me. I let them know about my role, its responsibilities, and how long I've been doing it. Then, I move on and tell them a bit about my previous job and any other one before that. Lastly, I tell them about how I got into the industry and how I experienced the JavaScript popularity explosion. It shouldn't take more than a minute.
Then, I let the candidate share their experience.
I might be a spoke person for my company, but to have an honest conversation with the candidate, I have to open up. Let them know, that I'm too a developer who has a career, who has changed jobs, and will do it again. We are pretty much in the same position, and we're having a call to see if we can collaborate.
Expanding on company, team, and role specifics
Next up, I will share more about the company, the position, and how we work. I don't expect the candidate to know much about the company, but I want to make sure they know what we do.
Succinctly, I'll cover
- The company product, the clients, and which problem it solves for them
- The company size, its growth projection, and funding status
- How the company is structured
- How the team operates
- The stack, the development process, and practices we follow.
- The responsibilities of the role
- Continuous learning and growth
- Remote policies, if applicable
And finally answer any questions.
It's best to be transparent, even if it means losing the candidate. For example, if they want to work in a small company, and the plan is to hire 100 more people, they have to know it now. No surprises.
Evaluating working experience
Moving on, the goal is to discuss their relevant working experience. Since I'm interviewing for front-end positions, I'll probably lead with React. I'll point out problems I've faced when building apps, and ask the candidate to join me and share their thoughts, based on their experience.
Just having a normal discussion as if we're discussing a ticket. I want to understand what challenges they've faced, their takeaways, things they care about, and all these nice stuff you don't get from code-golfing.
Aligning
So far the candidate should have a good idea if they like what they hear. Maybe it's not clear, so let's align.
Here, I'm asking the candidate what are they hoping to find in our team (money aside). Essentially what is it that they value. It might sound tacky, I know, but different teams have different cultures. Better clear any misunderstandings now.
Recap
One final call for QA, and we wrap this up.
I'll inform them of the next steps, and ask them if they would like to proceed.
* waves and closes zoom *
Notes
Questions to ask
Are you a candidate and don't know what to ask? Here are some good ones.
Questions are welcome and *not* evaluated
It's important for the candidate to feel confident to ask questions they care about. It should be clear that it's for their benefit and they won't be evaluated for them. Asking about the number of meetings, employee retention, and such, is not a taboo. I'm also an employee, who had my fair share of bad experiences because I didn't ask enough questions beforehand.
Questions with "most" should be avoided
This is taken from Stop Asking Questions by Andrew Garner. Great book, I recommend it.
Questions like "What's the most cool thing you worked on", or "What's the hardest situation you have faced" suck. It's hard for anyone to do this mental exercise. You have to make a list of experiences, sort them and pick the first one. Who has time for that?
A better way to phrase it is "What's something that you worked on and are proud of? Either because it was challenging, fun, or just great because of its impact?" This lowers the barrier, gives options, and allows for the candidate to expand more. They are not looking to find something specific to wow the interview, instead, they will list a couple of things that mattered to them.
Textbook questions that I dislike
Where do you see yourself in X years?
This question is less about the candidate's future and more about what they value. Still, it's much better to just ask them that, and avoid getting that scripted answer you deserve.
How would a friend describe you?
I would rather have an enemy describe me. But anyhow, they would describe me as #compassionate, #hardworker, #stubborn (😉), and #selfless.
Which are your weaknesses?
- 👉👈"I work so hard and I get carried away, sometimes working overtime" 😢
- 👉👈"I want everything to be perfect, and might rub some people the wrong way" 😢
No.
Fin
If you're interviewing and can take anything from this post, let it be this one. That great job opportunity you advertise is nothing more than just another job in the vast sea of jobs. Try to have an honest conversation, don't hide anything, and remember you'll be on the opposite side soon.