Hiring is one of the most important responsibilities of an engineering leader. The people you hire shape how your organization works long after the interview is over.
By the time candidates reach the interview with me, they have already completed coding challenges, system design interviews, or technical deep dives with people who are far better suited to evaluate those skills than I am. I trust our Tech Leads, Staff Engineers, and other specialists to assess technical excellence.
Every interview round should answer questions:
- Technical interviewers should evaluate technical ability.
- Future teammates should evaluate collaboration and team fit.
- Managers should evaluate role-specific skills.
I am mostly interested two things:
- Whether their expectations match the role we are actually offering
- Whether they would thrive in our working environment
I want to understand their motivation, how they think, in which environments they lit up, how they communicate, if they are self reflected and how they would fullfil the role.
How they approach ambiguity
I like to give candidates small scenarios, which they may come across in their role. For example, I tell Chapter Lead candidates, a role which involves people leadership, the following:
Imagine one of your engineers asks for a significant salary increase. What do you do?
Some candidates immediately jump to a solution explaining salary bands, promotion cycles or company policy. Others pause for a moment and begin to ask questions instead.
- Why are they asking now?
- Is this really about compensation or something else?
- Are they comparing themselves to another engineer?
- How important is retaining this person?
This shows me how someone approaches an ambiguous leadership situation. A strong answer shows curiosity for the small case asking questions. A weak answer rushes to a solution without understanding the deliberately open scenario. The same happens in technical discussions.
- Should tackling technical debt delay a feature release?
- Should QA be centralized or embedded?
- Should a Tech Lead still spend significant time writing production code?
I do not expect candidates to arrive at the same conclusion I would. I want to understand what information they consider important before making a decision and how they reason about it.
What brings out their best work
We often spend time talking about previous teams, companies, and projects because I am trying to understand the person behind those experiences and in which working environments they strive.
For example when interviewing an experienced Scala engineer, we spent quite some time discussing the very different environments he had worked in: startups, consulting, and large corporations. I was less interested in whether he preferred startups over large organizations than in what those experiences told me about him. Why did he enjoy? What frustrated him? How much autonomy did he need? What kind of collaboration brought out his best work? Those conversations help me understand whether team and the role they apply for is likely to energize or frustrate them.
How they explain complexity
I rarely challenge candidates on the deepest technical details of their discipline. If I interview a QA engineer, I cannot pretend to know more about testing strategies than they do. Instead, I want them to explain their reasoning in a way that someone outside QA can understand.
The same applies to Data Scientists, backend engineers or app developers. Engineering doesn’t happen in isolation. Technical decisions constantly need support from Product Managers, Engineering Managers, designers and other engineers. Being able to explain complexity is part of the job for a more senior person. If you cannot explain to me what you did, why it mattered, which tradeoffs you made and how you did it, you will likely not be able to take along your collegues either.
Respond to disagreement
Sometimes I deliberately challenge a candidate’s reasoning. If a backend engineer proposes an architectural approach, I might ask why they did not choose another solution. If a Data Scientist explains how they introduced a new model, I may challenge their choice.
What matters here is the ability to reason and argue and not an actual solution. With strong candidates I will have an interesting debate. They stay engaged, clarify assumptions, acknowledge trade offs and consider my viewpoint without becoming aggressive or defensive immediatly.
Ability to Selfreflect
After the technical interview or coding challenge I like to ask:
If you could do it again, what would you change?
Candidates who regularly reflect almost always have thoughtful answers. They talk about what they learned during the interview like trade offs they would make differently now or assumptions that turned out to be wrong.
Occasionally someone simply answers, “I think it went well.” Or “Spendung more time” Engineering is a profession where almost every project teaches you something. I expect senior people to have developed the habit of looking back and asking themselves what they would do differently next time, given new information.
Building a shared understanding of the role
One topic I always explore is how candidates understand the role they are applying for. Job titles vary between companies. A Tech Lead, Staff Engineer, QA Engineer, or Chapter Lead can have very different responsibilities even within the same company.
I like to give as much context as I can and make my expectations explicit. If a Tech Lead in a specific team needs to spend a significant amount of time mentoring junior engineers or aligning between teams or working very closely with Product, I say let them know. If I expect QA engineers to influence engineering practices beyond writing tests, I explain that. If a team has lot’s of tech debt that needs to be tacked, I won’t hide that.
More than once, these conversations revealed that we simply have had different expectations. Sometimes a candidate is looking for a role with much more or much less hands-on work. Sometimes a candidate want to lead a larger part of the organization than the position actually offers. An interview is not only successful when both sides decide to work together. It is equally successful when both sides realize that they are looking for different things.
A note for candidates
A good interview reduces uncertainty for both sides. Interviews are not only there to convince a company to hire you. They are also your opportunity to understand how the company thinks before you join. Ask about the role. Ask about the challenges. Ask how decisions are made. Ask what success looks like after six months. Explain what kind of environment helps you do your best work and find out whether this role actually offers it.
Good interviews end with both parties having a much clearer picture of whether working together is the right decision. Is a match likely to make the candidate, the team, and the organization stronger?