Why Google Wouldn’t Hire Max Howell (and Why That’s a Good Thing for Software)

                                                                       Photo by Evgeni Tcherkasski @evgenit on Unsplash

There are plenty of tales of able developers being turned down by Google for flunking data structure and algorithm questions. They’re hard, like the time I forgot the code for a heap and simply sat there for 15 minutes.

So, when Max Howell, the creator of Homebrew sat for his Google interview I guess the expectation on all sides was that he would easily pass whatever they threw at him. Then they asked him to invert a binary tree, and he quickly became a symbol of the disconnect between hiring practices and real-world impact of a working software developer.

Yet Google’s rejection might have been the best endorsement for Howell’s unique skill set — and a cautionary tale for all of us.

The Binary Tree Problem Isn’t About Binary Trees

Let’s understand that this isn’t about Google failing to recognize greatness. We all know there is a trade off between the skills companies test for and those required to perform in a job.

Howell openly admitted his binary tree fumbling wasn’t surprising — his chemistry degree didn’t teach him algorithm trivia. But this doesn’t diminish his talent; it only reframes it.

Google (and the countless companies mimicking its playbook) focus on algorithmic acrobatics because they believe these skills translate to better software engineering. But this hiring model overlooks creators like Howell, whose instincts for user experience and open-source community building made Homebrew indispensable to developers everywhere.

Google looks for classic computer science students while ignoring the fact that diverse candidates can bring much more to the table, even if they cannot immediately complete the trivia questions asked of them in a pressure situation.

Interviews as Short-Term Thinking

For Howell, the interview result was rejection. For Google, it was potentially missing out on someone whose influence on software is undeniable. For the rest of us, it’s a reminder to rethink how we evaluate talent and what we actually want.

A candidate with proven skills might well be able to learn any missing skills while on the job. The fact that Google doesn’t test for this trait is a red light. After all, if you want a talent pipeline the best way to do this is to develop the talent yourself (that is, Google, take a long-term view). If they did that other companies might just follow and we wouldn’t have such a base set of interviews and might just have a thriving industry. Just a thought.

Would Howell Have Thrived at Google?

At Google, Howell’s talents might have been diluted by layers of bureaucracy and the relentless march of quarterly goals. Would Google’s culture have valued Homebrew’s grassroots simplicity, or would Howell have been pushed to churn out features rather than craft something brilliant?

He’s probably best off out of it, and the interview did offer value in weeding out a bad fit. Not a bad fit for Google, but a miserable post for Howell (possibly, I don’t know him). He wanted to help people, and it seems like Google is not quite the place for that.

Conclusion

Great software isn’t just about great algorithms, it’s about solving problems. Howell’s rejection by Google, ironically, validated his strengths: empathy, simplicity, and user focus. Traits that the tech industry desperately needs.

Maybe it’s time for all of us to rethink our own binary tree moments where we’ve been unable to answer some random question in an interview. They aren’t moments of rejection, just maybe they are best thing to ever happen to us. Maybe.