We’ve made a lot of mistakes over the past three years of Hacker School. Sometimes our bad decisions are immediately obvious, but sometimes they’re more subtle and it’s only with time, feedback, and reflection that we realize we’ve screwed up. These mistakes are like poor architectural decisions that don’t manifest themselves until you’ve lived with them for a while.

This is a post about mistakes we’ve made and tried to fix. In the interest of brevity, this post is greatly abridged, since the entire list would be much too long and embarrassing.

We no longer believe people must “love” programming to come to Hacker School. We learned that many of our alumni nearly didn’t apply because they worried they didn’t really “love” programming. Around the same time, Hacker School alumna Sunah Suh recommended the excellent book Unlocking the Clubhouse, which presents strong evidence that this language is gendered. We’ve since stopped saying that people must “love” programming (see my post about the word “hacker”).

We no longer tell people not to think about jobs until the end of the batch. The purpose of going to Hacker School is to be become a better programmer, and so we long advised people not to get distracted by jobs during the batch. But we found that this advice was hard for many people to follow, since most people quit their jobs for Hacker School, and it’s natural to think about what you’ll do afterwards. Given this, we now help people with jobs whenever they want and have optional interview prep sessions throughout the batch on Fridays. We’ve found that these changes have made it easier for people to focus on their education (and not worry about jobs) during the rest of their time at Hacker School.

We no longer have assigned facilitators or mandatory group dinners. These were two things we experimented with in the fall of 2012. At the time, they seemed like minor, positive changes, but we now see them as straying from our core principles. Dave wrote about this in detail in his post, Treating people like adults.

We don’t compare applicants to alumni who share superficial characteristics or demographics. This mistake is a bit different from the others because it’s not something we ever intentionally did. We realized about a year ago that we frequently found ourselves saying, “applicant X reminds me a lot of Y,” where X and Y more often than not shared the same race and gender, or other irrelevant demographics or traits. A similar voice or speech pattern can conjure up feelings, good or bad, about someone else and lead you to wrongly project other less superficial attributes onto that person. Given this, we now have a policy of not making comparisons betweens people who share superficial characteristics and call each other out any time we do.

Our interview process now includes a pairing session. For our first five batches, our interview process didn’t include any programming or time working with applicants. In retrospect, this seems obviously wrong: One of the biggest questions we try to answer in our admissions process is what it’s like to work with someone, and yet we were never working with them at any point in the process. We’ve since tried to fix this by turning our second round interview into a pairing session, where the goal is to treat applicants as if they were already working with us at Hacker School. They get to choose the language to use and the project to work on, as well as what specifically they want to do (e.g., to add a small new feature, refactor a chunk of their code, etc.). Many applicants have told us that they really enjoyed the pairing sessions, and benefited from it regardless of whether they got in.

We shouldn’t have named our company “Hacker School.” Both parts of our name have caused us trouble: Hacker because so many people take it to mean a person who breaks into computers rather than a clever programmer. School because it implies a rigid and traditional approach to education that we emphatically reject. This mistake is different from the others on this list because we haven’t yet corrected it, and probably never will, given how time-consuming and costly it would be.