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 should answer questions that the previous interview cannot.
- Technical interviewers should evaluate technical ability.
- Future teammates should evaluate collaboration.
- Managers should evaluate role-specific skills.
An interview round with a Director earns its place only if it reduces a different kind of uncertainty.
- Would this person thrive in our environment?
- How do they make decisions?
- Could they influence others?
- Would they make the organization better?
That does not mean the conversation is informal or based on personal chemistry. I am not looking for someone who thinks like me, speaks like me, or gives the answer I would have given. I am looking for evidence of judgment.
In practice, that means I pay close attention to a few things.
- How they frame ambiguous problems.
- Which trade-offs they notice.
- How they explain complexity to people outside their specialty.
- Whether they can influence without relying on authority.
- How they respond when challenged.
- Whether their expectations match the role we are actually offering.
Understand how people think
My interview questions rarely have a single correct answer. Take a seemingly simple question I often ask Chapter Lead candidates, a role with people leadership:
Imagine one of your engineers asks for a significant salary increase. What do you do?
Some candidates immediately talk about explaining salary bands, promotion cycles, or company policy. Others pause for a moment and begin asking 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?
At that point we are no longer talking only about compensation. We are talking about how someone approaches an ambiguous leadership situation. A strong answer has to balance empathy for the person, fairness to the team, compensation constraints, retention risk, and the manager’s responsibility to follow through. A weak answer treats the request as an administrative inconvenience.
The same happens in technical discussions.
- Should technical debt delay feature work?
- 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.
Understand the person behind the resume
Most of my interviews feel more like conversations than questionnaires, but the conversation still has a purpose. We often spend time talking about previous teams, companies, and projects because I am trying to understand the person behind those experiences.
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 one environment more than another? What frustrated him? How much autonomy did he enjoy? What kind of collaboration brought out his best work?
Those conversations tell me much more than whether someone likes startups or enterprises. They help me understand whether this role is likely to energize them or slowly frustrate them over the next few years. The same is true when candidates explain why they changed companies, why a project failed, or why they chose one technical approach over another.
This is where interviewers need to be careful. “Would I enjoy working with this person?” is not a good hiring criterion. It is too vague and too vulnerable to bias. “Can this person do strong work in the environment we are actually hiring them into?” is a much better question.
Explain complexity
I rarely challenge candidates on the deepest technical details of their discipline. If I interview a QA engineer, I don’t 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.
I remember discussing a test suite that had grown to roughly seventy automated tests but still took around two hours to execute. We ended up talking about bottlenecks, architecture, feedback loops, and why test runtime had become a meaningful engineering problem. I was not evaluating whether every technical decision was perfect. I wanted to see whether the candidate could make me understand why the problem mattered, what trade-offs were available, and how they would bring other people along.
The same applies to Data Scientists, backend engineers, or platform specialists. 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.
Build a shared understanding of the role
One topic I always explore is how candidates understand the role they are applying for.
Job titles vary enormously between companies. A Tech Lead, Staff Engineer, QA Engineer, or Chapter Lead can have very different responsibilities depending on the organization.
I prefer making my expectations explicit early in the conversation. If a Tech Lead in our organization spends a significant amount of time mentoring engineers, aligning teams, or working closely with Product, I say so. If I expect QA engineers to influence engineering practices beyond writing tests, I explain that as well.
More than once, these conversations reveal that we simply have different expectations. Sometimes a candidate is looking for a role with much more hands-on implementation. Sometimes they want to lead a larger organization than the position actually offers.
I consider those interviews successful.
An interview isn’t only successful when both sides decide to work together. It is equally successful when both sides realize early that they are looking for different things.
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.
Those discussions are often the most useful part of the interview. Strong candidates do not have to agree with me. They do not even have to change their mind. But they should be able to stay engaged, clarify assumptions, acknowledge trade-offs, and consider another viewpoint without turning the conversation into a performance of certainty.
The ability to reason collaboratively is what matters here, not the actual solution.
Reflect
One of my favorite questions comes after the technical interview or coding challenge.
If you could do it again, what would you change?
Candidates who regularly reflect almost always have thoughtful answers. They talk about trade-offs they would make differently, assumptions that turned out to be wrong, or things they learned while solving the exercise.
Occasionally someone simply answers, “I think it went well.” There is nothing wrong with confidence, but that answer gives me much less information. 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.
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?