Hiring and Interviewing

“Humble,” “Hungry,” and “Smart”—these three core virtues were introduced by Patrick Lencioni in The Ideal Team Player. I find this to be an exceptionally useful evaluation framework.

• Smart
• Humble
• Hungry

It is worth noting that “Smart” here does not just mean “book smart.” It refers to emotional intelligence, strong interpersonal skills, and the ability to understand and manage the impact of one’s words and actions on others. An ideal teammate should possess all three traits simultaneously. That said, for engineering roles, I believe intellectual smarts are still very much essential. That doesn’t mean having to compete in the Math Olympiad or competitive programming from childhood, but rather possessing the ability to solve problems hands-on and constantly dig deeper.

For junior engineers, having just Smart + Humble is usually enough. But the following two combinations should be avoided:

• Smart + Hungry
• Humble + Hungry

People who are Smart and Hungry might bring plenty of ideas to product development, but this often comes with a tendency to go rogue and disregard the team’s input. In my experience, people who are only Smart & Hungry rarely function well inside an organization and can easily cause harm to the team. Humble + Hungry goes without saying—no organization needs someone who is modest yet perpetually underdelivers and bites off more than they can chew.

Evan You, the creator of Vue, once mentioned that some people are genuinely brilliant, but they will oppose almost any idea you propose. Such people usually make it impossible for a project to progress smoothly.

https://x.com/saucedopen/status/1798973109598351683?s=46

Some people can be very technically brilliant but disagree on almost everything with you

Another possibility with Humble + Hungry is that the person is actually smart, but simply too modest to show it. For candidates like this, you can dig deeper into their project experience and give them space to shine in areas they excel at.

Since problem-solving ability is valued more than ever today, you generally need to tailor your interview strategy based on the kind of talent the company needs:

• If the company needs specialists, evaluate their deep technical expertise:
  • For frontend: Does the candidate have a deep understanding of performance, accessibility, CSS, and design principles?
  • For backend: Does the candidate have sufficient mastery over their programming languages, and are they familiar enough with the components required in large-scale systems?
• If the company needs generalists, evaluate their broader problem-solving skills:
  • Look for end-to-end project experience: Not just toy side projects built for practice, but solving real-world problems.
  • See if they have insights beyond engineering, such as marketing, sales, product optimization, finding Product-Market Fit, and so on.

Denny once shared an article by DHH with me: You can’t fix core competency with a stern conversation. DHH argues that when a new hire isn’t working out, the issue usually falls into one of two buckets—Engagement or Competency.

If it is an Engagement issue—such as communication or collaboration not meeting expectations—it is relatively simple: have an open conversation to align expectations and goals. If it is a Competency issue, conversations won’t fix it. DHH’s point is that professional technical skills take a long time to develop; if this is what they bring to the table today, expecting a conversation to change that is unrealistic.

I think DHH’s piece is spot-on, and it became one of the ways I evaluate candidates. Whenever a candidate mentions a project on their resume, I dig into the details as thoroughly as possible. Whether they actually implemented it or just tweaked a minor detail and slapped their name on it usually becomes clear at this stage.

Another thing I do is live coding. It doesn’t have to involve writing a complete, production-ready codebase—it could be implementing a simple feature, exploring language mechanics (if you write JavaScript, you should understand asynchronous behavior), or doing a code review together. Moreover, I don’t discourage candidates from using AI tools; in fact, I encourage it.

Here is what I look for:

• How they tackle unfamiliar problems
• What they prioritize when building a project
• Whether they have genuine development experience, demonstrated by speaking intimately about the pitfalls they encountered and the architectural decisions they made
• Whether they know how to leverage AI effectively to boost productivity
• Taste

Hiring is hard. Especially in a startup, a poor hire can deal a massive blow to team morale. Trying to spot high-potential candidates in short interview sessions honestly feels a bit like a lottery. In this situation, the only viable approach is to optimize for precision. I only realized this recently.

A while back, I used to think of casting a wide net—interviewing almost anyone with a decent resume. But once the interviews began, I realized there was a huge gap compared to what I had imagined. When resources are limited, you have no choice but to filter based on more objective data: education, past companies, track record, and projects.

When resources are constrained, hiring should focus on optimizing precision rather than maximizing recall.

Interviewing Others

Since candidates haven’t worked inside the company, their impression of the organization often comes entirely from the interviewer and the interview process. Therefore, the process is not just about finding the right fit; how it is conducted directly affects the company’s reputation. When interviewing, I do my best to adhere to the following principles:

• Make the candidate as comfortable as possible so they can perform at their best
  • Actively maintain this comfortable atmosphere
• Approach the candidate with a mindset of “I want to help you pass”
  • Default to viewing every candidate as a potential collaborator
• Never make “stumping the candidate” the objective
  • We are looking for partners

Many interviewers make it their mission to stump candidates, only to gloat and mock them on social media afterward. I strongly disagree with this culture and find it completely distasteful. Regardless of how difficult the questions are, if an interviewer enters the room thinking, “How dare you apply if you don’t even know this?”, the interview is doomed to be ineffective from the start.

After all is said and done, the most essential rule is simply this: treat people like human beings.

Of course, interviewing is a two-way street. If you feel you have gathered enough information to make an evaluation, it’s perfectly fine to say graciously: “I have all the information I need to make an assessment; why don’t we wrap up early?” That, too, is a good approach.