How Do We Hire the Best of the Best?

Last week I read a post by Laurie Voss (npm’s CTO) about the process of hiring good developers. There is some really good advice there, but the article also felt as if it described a world that was just a little bit too perfect. Maybe that’s the difference between the Apple universe and the Node universe, or maybe between the United States and Poland, but some bits and pieces of the article just didn’t stick. So I decided to write a few words on how we approach the process of hiring people. First of all, if you want to read what kind of questions do we ask at out technical interviews, Bartek wrote a good piece on it. Go ahead and read it, especially if you plan on sending your résumé our way. Here, I will try to concentrate more on the human and behind-the-scenes aspect of the process.

Let me start with a quote overheard at a conference we attended in Berlin this year:

Macoscope, the company that hired probably all of the best iOS developers in Poland. — Orta Therox

It’s an exaggeration, of course, but it’s not that far from our ultimate objective. And I believe that our hiring process and the company spirit is very important in getting closer to that ostensibly impossible goal.

The Beginning

The first thing you need to know about the Macoscope method is that basically almost every employee plays a part in the hiring process, app developers and designers alike. Not everyone participates in candidate interviews, but everyone in the office is free to recommend developers they either know or have heard about. And literally every time we finish an interview and go back to our open space or the kitchen, people come up to us to ask about the candidate, our feelings about them, etc. Personally, I think it’s amazing because it shows that we’re much more than just a company, we’re a team.

The Talk

When we find a candidate for the position of developer on our team, we invite them to our office for an interview that takes somewhere between 60 and 90 minutes. That’s quite long, we know, and believe us, after it’s over we’re no less tired than the candidates. There’s a room for improvement in this particular regard as far as I’m concerned, but the lengthy interview also allows us to get to know that person better than a 20-minute-long speed date does. Because at the end of the day, that’s what we’re aiming for: to know that person, both personally and professionally.

During the interview, the candidate is always talking with fellow developers. It’s always been this way, primarily because the founders of Macoscope were, and still are, developers, even if they don’t spend their days coding anymore. We don’t have recruiters that get to ask the candidate scores of technical questions without actually writing a single line of code in their life. This, in turn, allows us to have a conversation with that person, have better picture of them, because as developers, we share interests and passions.

The Rule

I’m not going to lie: we break one of the rules established by Laurie fairly frequently. We ask technical questions. Quite a lot of them. We even ask people to write some code. And I do agree that it’s somewhat removed from real-life challenges that a programmer may face, especially if you’re writing on a piece of paper instead of in your favorite editor. But if you don’t have a month of time and a good way to simulate real-life conditions, such an exercise may end up giving you a lot of useful information. You just have to look closely. Basically, all problems we give the candidate can be solved by writing no more than 10 lines of code. And I do believe that good developers write code in their head. The computer, the editor, the IDE are all just tools that make it quicker and easier. But if you have to rely on them just to write a couple of lines, you’re not a good programmer yet. Similarly, writing code with someone can be stressful, but it’s nothing compared to production coding for a client. And we never put undue pressure on anyone. We explain that they can do this however they want to do it. They can take as much time they need and we even try to help if they’re not sure or get stuck on something.

The Truth

But at the end of the day, the trick with all those questions is that we don’t really care whether you remember the exact names of classes or methods. To be honest, you don’t even have answer most of the questions correctly. But asking those questions enables us to learn something very important: how you think. You can dazzle us with how much you remember from Objective-C programming or from your college classes and still fail the interview. There’s a flipside to that coin: you can forget some important detail or not know the answer to one of our questions (it’s a stressful situation, we know), and still demonstrate problem-solving skills that will blow us away. Additionally, saying “I don’t know” is always a perfectly valid response. This isn’t school, not knowing something will not lead to a failing grade. Asking these questions, however, allows us to learn more about you in real life: are you more of a UI or a model person? Maybe you can create amazing architectures or have great attention to detail when it comes to animations or performance? Maybe you don’t know how to approach a problem in Objective-C, but did something similar in your previous language of choice.

The Team

Because even though we’re all Objective-C developers, the backgrounds of our staff are as varied as they come. We have team members with technical and non-technical degrees, we have high school dropouts. Even if we ask our candidates about their academic background, the question is mostly a conversation starter. At the end of the day, it doesn’t really matter. What matters is your developer experience or your potential. We have an Objective-C developer with years of frontend HTML/CSS/Javascript experience, people who love C++, Python or Ruby, people passionate about finding and trying new apps that could make the development workflow better. And people who can do magic with a couple of one letter aliases in terminal, which they have been improving and tweaking for years. We all share our experience with other team members. Even though you should at least know how to make a functioning iOS app to work with us, it’s your passion and the things that make you a great developer are more important than the number of Foundation collections you know.

The Person

That’s also why we start all of our interviews with something non-technical. We want to get to know the candidate: what have they already done, technologies or languages they have used, the way they learn new things, what are they passionate about (besides programming, that is), why are they here and want to work with us. Sometimes, the answer to one of those questions can determine whether we will hire a given person or not. Not knowing the answer to a couple of technical problems can show us how many weeks will it take for you to be able to work on a project that we currently have on our plate. How much time and effort will it take to tap that potential we saw and turn it into a great developer and team member. Or how much we can learn from you. Alas, in some cases, you can ace all the technical questions and we’ll still have to say “no.” The reasons can be manifold: what we do isn’t really a passion for you, you won’t fit the team (or the team won’t fit you), or simply because you’re a jerk and at that point we don’t care how much of a genius you are. Creating a good team is hard work. And even though not all of us have to be friends, people who like to work with each other will end up delivering much better results than individuals working on their own.

The Decision

Afterwards we always talk. Each person who had contact with the candidate voices their opinion, explains what they liked or disliked about them and whether they would like to work with that person.

After a couple of interviews, the staff usually rates the technical prowess of the candidate at similar level, but the conversations are different. Some candidates don’t have extensive iOS experience, but some of us feel that they have the right set of skills and an inkling of passion that will result in them getting up to speed in a heartbeat when given a chance. Or it’s just the opposite and someone from the team sees something disturbing that should be at least taken into account in the decision-making process. But the most important thing is that it’s always a collective conversation and we make our decision based on that.

So that’s a rough outline of how we hire new developers. It’s not a perfect process, far from it, but we’re constantly trying to tweak it to make it better. We listen to a lot of feedback and then make some changes to see whether the process is in any way improved. I feel there are still places where we can do better, but to be honest, looking at our team, our everyday lives at the office and what we’re capable of, I’m pretty sure it’s working. Our staff is made up of passionate people with broad experience, people who like to talk to each other, argue, learn from one another, and push ourselves to be better at what we do. Given a chance we can and do amazing things. We love to work with each other, at least most of the time. And when we don’t work, we eat together, do great things outside of work, and we laugh a lot.

How Does Super Work?
Applications as State Machines