· 7 min read

Hiring and Interviews

# Random Talk
This article was auto-translated from Chinese. Some nuances may be lost in translation.

“Humble,” “Hungry,” and “Smart” are the three key traits identified by Patrick Lencioni in The Ideal Team Player as the qualities of an ideal team. I think this is a very useful framework for evaluation.

  • Smart
  • Humble
  • Hungry

One thing to note is that “Smart” here does not mean only book smart; it also refers to high emotional intelligence and strong interpersonal skills, the ability to understand and manage how one’s words and actions affect others. An ideal colleague should possess all three of these traits at once. That said, for development roles, I still think intellectual intelligence is quite necessary. I don’t mean someone who must have competed in math Olympiads or programming contests since childhood, but rather someone with the ability to solve problems hands-on and keep digging deeper.

If it’s a junior engineer, having Smart + Humble is enough. But these two combinations won’t work:

  • Smart + Hungry
  • Humble + Hungry

Being smart and hungry may mean having more ideas when building products or developing software, but it also comes with the risk of being stubborn and ignoring the team’s opinions. To me, Smart & Hungry alone usually does not work well within an organization, and may even harm the team. Humble + Hungry goes without saying; the organization does not need people who are humble but consistently fail to get things done, or who overestimate their own ability.

Evan, the author of Vue, once mentioned that some people are truly very smart, but they will reject any suggestion you make. People like that usually can’t help a project move forward 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 very smart, but simply doesn’t show it because they’re too modest. For this type of person, you can start by asking more about the project, and let them shine in the areas they’re good at.

Since problem-solving ability is now valued more highly, in general you still need to adjust your hiring strategy according to the kind of talent the company wants:

  • If the company needs specialists, then you should evaluate more professional expertise
    • For frontend roles, whether the candidate has deep knowledge of performance, accessibility, CSS, and design principles
    • For backend roles, whether the candidate has enough command of their programming language and enough familiarity with the components needed in large-scale systems
  • If the company needs generalists, then you should evaluate more problem-solving ability
    • See whether they have experience taking a project from start to finish: this should not just be a side project for practice, but actual problem-solving in the real world
    • Whether they have insights beyond development, such as marketing, sales, product optimization, finding product-market fit, and so on

Denny once shared with me an article by DHH, You can’t fix core competency with a stern conversation. DHH argues that when a new hire doesn’t work out, the situation usually falls into two categories: Engagement and Competency.

If it’s an Engagement issue, such as communication or collaboration not meeting expectations, then it’s simple: talk it through openly and align on each other’s understanding and goals. But if it’s a competency issue, conversation alone won’t solve it. DHH’s point is that professional technical ability takes a long time to develop, and if what the person shows is already like this, expecting a conversation to change that is unrealistic.

I think DHH wrote this very well, and it has also become one of the ways I evaluate candidates. For any project a candidate mentions, if they’ve written it on their resume, I try to ask for as much detail as possible. Whether they really built it themselves or merely changed a small thing and took credit is often easy to confirm at this stage.

Another thing I do is live coding on the spot. It doesn’t have to be a full program; it can be a simple feature implementation, a language feature (if you use JavaScript, you should know about async, right?), or a code review together. I also don’t object to, and in fact encourage, candidates using AI as assistance.

What I want to observe includes:

  • How they solve unfamiliar problems
  • What they value when working on a project
  • Whether they have truly done development work, and whether they can talk in detail about the pitfalls they’ve encountered and the technical decisions they’ve made
  • Whether they know how to make good use of AI to improve efficiency
  • Taste

Hiring is hard, especially in startups. If the person is not a good fit, it often has a big impact on team morale. In a short interview, finding a candidate with potential is, frankly, somewhat like drawing lots. In this situation, the only thing you can do is improve precision. I only realized this recently.

A while ago, I was always thinking that I should keep an open mind—if the resume looked decent, I’d interview them. But after the interview, I often found the gap from my expectations was huge. With limited resources, you can only screen using more objective data: education, companies they’ve worked at, experience, projects.

When resources are limited, hiring should aim to optimize talent precision, not increase recall.

Interviewing Others

Since interviewees have not worked inside the company, their impression of the company often comes from the interviewer and the interview process. So the interview process is not just about finding the right person; the quality of the process also affects the company’s reputation. When I interview, I try to follow these principles as much as possible:

  • Try to help the interviewee perform at their best while they’re in a comfortable state
    • Take the initiative to maintain that comfortable state
  • Approach the interviewee with the mindset of “I want to help you pass”
    • Assume every interviewee is a potential future collaborator
  • Don’t make it your goal to “stump” the other person
    • We are looking for partners

Many interviewers aim to stump the candidate, then proudly mock them on social media. I strongly disagree with this kind of culture and find it very distasteful. Setting aside how difficult the questions are, if an interviewer approaches a candidate with the mindset of “You don’t even know this, and you still dare to apply?”, then it’s already doomed to be an ineffective interview.

After saying all this, the most important thing is probably this: treat people like people.

Of course, interviews are two-way. If you feel you’ve already gathered enough information to make an assessment, then being straightforward and saying, “I’ve already received enough information to evaluate this; perhaps we can end a bit early,” is also an option.