When we screen candidates, they frequently ask, “What’s special about Think Through Math?”
Developers hate to repeat themselves so this post is an attempt to describe what we think makes working at TTM different than other companies. Though this post is focused on working on the Think Through Math product development team (engineering, QA, project management, UX), many of the concepts are valid for the company as a whole.
Our culture
We’ve developed a very cohesive team over the years. We’re all working at Think Through Math because we find the work meaningful and we believe in the work that we do. We also have some very specific values that are important to us as we work to fulfill our corporate mission:
Everyone is a teacher, and everyone is a learner. Literally half of the company is made up of current or former certified teachers, but even for those of us who aren’t certified, teaching and learning are core values. Our staff come from diverse backgrounds - teachers, publishers, designers, developers, but we all share an interest in teaching and learning (and math of course!). From this value, we get pair programming and peer code review as practices. We also get involved with the larger community (local and online), since we realize that the answers we seek are not always held by the people we work with directly.
Continuous Improvement. We follow many Agile processes; we do a daily standup (and some sub-teams do their own separate standup), we organize our work in to iterations while shipping features when they’re ready, and hold iteration demos. But these are just actions. As a team, the thing we care most about is continuously improving everything we do: git workflow, deployment, operations support, etc. Our git structure reflects our principle of continuous improvement. We have two primary branches for our projects: master (which reflects what’s in production) and rc (release candidate).
Giving back. We rely heavily on open source software and platforms. It would be irresponsible of us to not try to find opportunities to contribute back to that community through code, knowledge sharing (including this blog), responding to Stack Overflow questions, participating in local meetups, and so forth. In many ways, this goes hand-in-hand with our focus on teaching and learning. In addition to corporate goals, every member of the team is expected to contribute to at least one open source project every year and to give two presentations on topics in their area of expertise at national/international conferences, regional meetups, or even company lunch-and-learns.
The hiring process
For technical positions, our hiring process is two steps. The first step is a group interview with 5-6 of the current development, QA, design, UX, and project management staff. We do a group interview so that we don’t pester candidates with the same set of questions, and because one of the things we look for in a candidate is their ability to gel with the team.
We realize it can be intimidating to do a panel-style interview but they are really informal. At one point during an interview we stopped to pull up the Lego interpretation of Eddie Izzard’s Death Star Canteen skit.
Great developers will always have options when they’re looking for a job, and it’s important for us to make sure the candidate knows what it would be like to work at Think Through Math as much as it is for us to get to know the candidate.
For the second step of the interview process, we ask candidates to give a 30-minute presentation on a topic they’re passionate about. We prefer the topic be nontechnical since technical topics can be dull and we value diversity of interests. Our interview process matches our corporate culture; we are all teachers and our interview process selects for people who share that interest. Over the past year+ we’ve had this policy we’ve had presentations on coffee, henna tattooing, bowling, watches, and vinyl records, among others.
One thing we don’t do in interviews is ask people to write code, pseudo or other. We favor candidates with active open source contributions (giving back to OSS is another of TTM’s values), so typically by the time a candidate comes for an interview we’ve had a chance to see their code already. There’s not much we would learn in 45 minutes of live-code interviewing that we couldn’t see from someone’s OSS contributions.
Another reason we don’t do code in interviews is that it’s an unrealistic scenario. TTM has an aggressive roadmap, but I can’t think of a situation where we would have a 45-minute deadline to write code. It’s too easy for a live-code interview to turn in to a series of gotcha questions. Old standbys like “How do you reverse a string?” become meaningless when the language includes a .reverse method. We want our interviews to reflect what people will actually do day-to-day. If you’re working on something and don’t immediately have the answer, you search for it. Usually you end up on Stack Overflow, find something that works, and move on. In an interview situation how would a potential employer feel about a candidate going to Stack Overflow? The process of writing code in an interview feels awkward, so we tend to avoid it.
Summary
If you’re interested in working at Think Through Math, or you’re a candidate wondering what the interview process is like, hopefully this post is useful to you. If you are interested in working here, check out our openings and drop us a line!