#42: How to Answer Hiring Manager's Questions in Interviews

Hey friend,

In my previous letters, I wrote you about the growth path in an existing company, covering promotions, promotion expectations, and career frameworks for how to get there. One of the parts of our career journey I didn't touch yet is the interviews for a new job. In this letter, I wanted to talk about the STAR method you can use for your next hiring manager interview.

Before I get to the method, there is one aspect I need to write about first: what these hiring managers are looking for. What's their goal?

Hiring managers are often the managers of the team you'll join. As I have been a hiring manager for a while, I can list down the most common three criteria a hiring manager evaluates you. The below three are not the only ones; there are more they look for specific to the role you are applying for.

The first and the most obvious is, how do you fit into the current team structure, and can the team work with you? They direct questions according to the team they hire. They ask questions about conflicts, how you work with feedback, mistakes you've made, your learnings from them, and your collaboration approach.

Second, they look for your experience to understand the level you're in. Your leveling decision is not made only on the technical interviews. The technical part is ~40-45% of the job. It's fundamental, but there is the other half of the job you are expected to do. You might be very knowledgeable on the technical side because you worked and studied hard. How you leverage that technical side and your approach to work defines your level. They ask additional questions about mentoring, projects in which you had the lead role, initiatives you took, processes you built, and so on.

Last, can they support you while you're working together? Hiring managers don't only consider what they expect from you; they also think about how to support you. Because if they can't, you'll probably leave the company quickly and they have to start searching again. Their goal is to identify which skills you lack and need some support. Think about the last time you had an awful interview but passed it. That shows that the hiring manager was willing to and had time to support you.

According to your answers and how you give those answers, the hiring manager creates a risk and support portfolio. Their decision will be based on the amount of risk in hiring you. The risk portfolio is based on how likely you will be a strong team member, how long you will stay, and how much you will contribute to the business. The support portfolio is based on which areas you lack skills.

If you focus on drawing a clear risk and support portfolio, the result will be good for both sides. Sooo, how do you bring clarity to them?

That's where the STAR method comes in.

STAR Method stands for Situation, Task, Actions, Results
STAR Method

Let's have an example.

Think about the question: "Could you tell me about a mentoring you did before?" You can structure your answer with the STAR method to bring clarity.

Define the situation first. Then explain what your task was and what exactly you did—your actions. Last but not least, how your actions resulted.

Without the STAR method, I often hear answers like this:

When I mentor, I begin by understanding the person's level and what they need. I ask them questions. Once I know, we devise a plan together and meet weekly to stay on track and help the mentee with their struggles. Also, they reach out to me when they have problems they cannot solve.

There is a lot of ambiguity. Although the explanation gives some idea about how the person approaches mentoring, it says nothing about their prior experience. It sounds hypothetical. The hiring manager needs to ask a few more questions to uncover the hidden story.

Let's try answering by using the STAR method.

(Situation:) When I mentored a junior engineer in my ex-company, they needed to develop debugging skills. The engineer struggled to find cues for bugs and didn't know how to use tools correctly. (Task:) My goal was to guide them when they struggled and purposely improve the challenges they worked on to step up in debugging. (Actions:) To achieve this, I asked a few questions and watched them while debugging to understand how much they knew the tools and where they got stuck the most. After figuring it out, we created a step-by-step plan and a weekly 1:1 appointment. In each 1:1 meeting, we looked at where they faced problems, solved them together, and looked at the following week's task. During these meetings, I also give some recommendations. (Result:) In three months, the mentee found out most issues without anyone's help and started helping others who struggled to debug our distributed systems. My mentee later gave a talk on a meetup about the debugging best practices of distributed systems and hosted a workshop in our company about improving the debug-ability of our services.

The ambiguity is gone. When you answer like this, it also sounds like you know what you're talking about. That's the beauty of using methods, frameworks, and mental models. They put your experience in a shape that is visible to others. The STAR method is no different. When you use it in behavioral interviews, it brings clarity and visibility.

On top, when you make your approach visible, the hiring manager has a better idea of which level you're in and can also understand where they can support you. Thus, it reduces the risk of hiring you—the decision point for a hiring manager. ;)

Although the method is helpful, it won't apply to every situation. If you have no experience in mentoring, simply saying, "I have no experience in mentoring, but I would approach it this way." is better than trying to create an imaginary case.

Until next time, keep your authenticity alive and prepare for interviews!


P.S. Do reverse interviews.

What I Published Over The Last Two Weeks

I wrote an essay about the goal of life, my life. Or the absence of it. I pursue two questions: How do we know we're on the right track? How can we ensure that we're progressing in the right direction?

Goals and Existence
How do we know that we’re on the right track?How can we ensure that we’re progressing in the right direction?

This article is about hidden monoliths that I learned while reading Team Topologies. They are everywhere and affect the software system design. When the organization is aware of its software's environment, it can thrive. If not, it faces various challenges.

Hidden Monoliths Affect The Software Design
Hidden monoliths are everywhere and affect the software system design. When the organization is aware of its software’s environment, it can thrive. If not, it faces various challenges.

I continued reading the book Designing Data-Intensive Applications. Last week, I published my notes from the fourth chapter (read chapters 1, 2, and 3 here).

Encoding, Decoding, Schemas and Data Evolution
The underlying approach to encoding and decoding decides how we approach data evolution and how we use schemas.

Newsletter Last Updated: Oct 24, 2022