It is impossible to predict the challenges you’ll face in your first start-up. Sure, we had some expectations – coding challenges, pitching for funding, etc… When we started looking for a front-end developer, we were nervous that we wouldn’t generate any interest. We’d had a few hiring faux-pas in the recent past – mostly from hiring whoever was close by and convenient – so we wanted to widen the pool. When we cracked open our inbox a few days after posting the job, we realized we had the opposite problem: we had over 120 messages! Already stretched impossibly for time, how were we going to choose the right person?

This article is written about how we managed the hiring process at MedicSana. It is really the third iteration of our process and has been heavily influenced by the immensely helpful Zapier post on the topic. There are two key parts to this process that we concentrated on: The qualities in people we were looking for, and the logistics of dealing with a huge pile of candidates.

There were a couple of key factors that we were cognizant of when searching for employees or long-term individual contractors for MedicSana:

We had already been doing a lot of research about building remote teams. The core insights came from Zapier’s Ultimate Guide to Remote Work and 37 Signals’ two books, Remote and ReWork. Specifically, we concentrated on three key points:

MedicSana was a very early-stage start-up based in the US that served a Latino market. This added an additional layer of qualities that we’d look for. None of these were absolute tablestakes, but they did influence our decisions.

I’d learned from an earlier iteration of this project that hiring can be a HUGE time drain. The time consuming aspects aren’t necessarily in the interviews themselves, but in the logistics – Cover letters, resumes, portfolios, PDF’s, Word Documents… Attachments get lost, people respond to the wrong email address, everyone has different times when they can interview, etc… Just getting the mess organized into a form where things can be measured objectively is a nightmare. For this iteration of our process, we made two fundamental changes:

In Wrike, we created a “Folder” for each job post with Sub-folders for each part of the process: Posting the job, First Candidate Pass-through, Second Candidate Pass-through, Interviewing, Discussing, Accepting, and Rejecting.

“Job Post” always had the same tasks: Post to Facebook, Linkedin, and a few remote-specific places like Remoteok.io. We’d also post on eLance – now UpWork, but we really got any good quality candidates from it. Remoteok.io has a terrible interface, but seems to have the community of people who are more purposeful about being remote workers.

The “Task” page for each point in the process had notes for completing the task. On the “Post Job” task, we kept a form letter about the company that was about 80% written about the parts of the company that wouldn’t change. Who we were, what we were doing, what we looked for in candidates, etc. Before posting the job, we would update it with specifics based on the job before copying and pasting it to each of the job-post websites.

It was our VA, Alexandra’s job to take the first pass through candidates. Once again, we left the instructions in the “First Pass” task page itself.

She would copy and paste a candidate’s cover letter, contact information, and a few key pieces of information (for instance, years of experience, languages spoken, etc…) at the top of the “task” for a candidate.

By including some automatic rejection criteria, we could let Alexandra actually take the first pass of cleaning out people that we knew wouldn’t be a good fit. This included things sent in languages other than English (obviously) but also anyone who didn’t submit a cover letter. We still believe cover letters are important, and they serve as our first understanding of someone’s written proficiency. More so, we feel like if someone doesn’t send us a customized cover letter that they just didn’t care. We want passionate people.

Taking a page from Zapier’s book, we drafted a rejection letter so that candidates that didn’t make the cut wouldn’t have to deal with an uncomfortable wait. Applying for jobs sucks sometimes – immediate rejection is better than hearing nothing. We’d love to customize rejection letters, but with the number of candidates it would be impossible.

We also wanted to set expectations for people who were still in the running. Again, this is about being polite – when you hear nothing, sometimes you think the worst.

More importantly, it gave us a second chance to ask people for their portfolios. I would prefer to reject people outright who do not submit portfolios for design or development positions, but unfortunately it is still very common for people to not submit them with their first inquiry.

As a personal note, I LOVE it when developers submit portfolios. Designers wouldn’t dream of getting a job without a portfolio review, and these days it seems that most serious devs have a github account with portfolio work in it. It is a personal bias for me, but when I get to play with something, it goes a long way.

For people in professions where there isn’t as much traditional “portfolio” work associated, it is worth thinking about what you expect a person to do after they read your cover letter. The more a person can engage with your personal brand, the more likely it is that they’ll remember you as a person, not just a (figurative) page in the resume stack. I love reading blog posts people have written about their personal philosophies for their craft, or interesting companies that they’ve worked with.

A problem that we didn’t anticipate was the huge number of development shops that applied for our front-end developer position. We weren’t looking for a shop (and explicitly stated it),but since saturating potential clients with cold-call emails is the norm these days, we got a bunch of messages anyways. We ended up writing a specific rejection letter for them, and we had Alexandra keep their information in a file in case we needed a shop in the future.

The same went for people who had a high quality of the wrong type of work. This is particularly a problem as our industry is getting more and more careless about the difference between “UI,” “UX,” “Design,” and front-end developers. Anyone who we liked, but not for this job, was politely rejected and we had Alexandra file their information so that we could reach out if we needed them in the future.

The Second Pass was my favorite part of the process. For the front-end developer position, the first pass whittled our 130 applicants or so down to 28. Arranging and conducting 28 skype interviews would have been a nightmare, so we opted for something that ended up being better anyways: written interview questions.

More importantly, written interview questions gave us a chance to assess how a person communicates. Judging “communication” ability in a certain language depends on what a person is applying for. Because we weren’t interviewing people to product public-facing material in English, and a considerable number of our applicants were either foriegn or otherwise spoke English as a second language, we weren’t too concerned with grammar, sentence structure, or vocabulary.

What was important was that a candidate could clearly and concisely get a point across and that he or she had a tendency to take a position on an issue and defend it. Because we have a relatively flat hierarchy – and don’t have the time to be experts in everything or direct every decision – we were looking for people who could be decisive on their own, but open to (and articulate in) conversation.

We also placed a lot of weight on a person’s ability to understand and express learnings from past mistakes. I think a lot of entry-level candidates see these sorts of questions as a trap, and we did see our share of ducking the question (“I try to hard”) and simple disagreement (“I’m very experienced and I don’t make mistakes”). I think that there are some cultural factors at play here, but we don’t really have enough data to say anything definitively.

The honest truth is that we make a lot of mistakes and know that when errors go hidden – or worse, unrecognized – that it ends up costing us big in the end. A company the size of MedicSana doesn’t have the time to deal with policing one another or internal political conflict, so we were extremely protective of our open culture. We also know that people with a lot of experience have made a lot of mistakes and we want to have a culture where we learn from each other.

The best candidates recalled a particular mistake that they made, the consequences, and their learnings. Even better were candidates that could connect their mistakes with overall personal shortcomings and articulate the ways that they form habits within teams to compensate with them.

We believe that personality is an important part of building a balanced team, and open-ended questions gave us that ability to hire people based on people we thought would be a good fit. This is a delicate area, I’ll discuss my thoughts on managing personal bias below, but whenever possible, I do believe personality is a critical factor when adding to a team.

Because Jonathan was SWAMPED most of the time, I took the first pass through the written interviews. We would mark, using Wrike’s highlight function, positive attributes of answers in Green and negative in Red. After reading, we would write comments as the bottom about what resonated most (or least) with each candidate for us.

Many candidates I was able to reject outright, but probably half of the responses warranted discussion after Jonathan took his pass.

From 130 candidates, we sent written interviews to 28 and decided to follow up with 7 skype interviews. With the help of Alexandra and Calendly we scheduled 30 minute interviews with these 7 over the course of a few days.

By this point, it didn’t really seem necessary to talk much longer than 30 minutes – we already felt that we were familiar with most of the candidates through their written responses, so we were mainly interested in their verbal communication abilities, clarifications on the questions, and the way they framed themselves in past projects.

In particular, we were interested in the way they talked about past teams. Did they take credit for successes personally, or talk about their team? We really liked candidates that were able to link a personal attribute with the way they helped the team out. For instance, we had a candidate who regarded herself as a very organized person and talked about how she used this “super power” to help other team members keep up with meetings and deadlines. Others talked about occasions where they got to mentor junior team members – and the things they learned from the people they mentored.

Rejecting people at the end is hard – by now about every candidate would be a good fit for the job. Unlike rejections at previous rounds, we write custom rejection letters for each of these candidates and keep their information on file in case we have another chance to hire them.

This was a huge learning experience for me. Not so long ago, I graduated from college with a portfolio under my arm thinking employment decisions were all about me. If I got a job, it was because I was great. If I didn’t I wasn’t.

This understanding wasn’t untrue, but it was very narrow and showed an unfortunate lack of empathy for the people doing the hiring. Over the past few years, I’ve had the pleasure of helping others prepare their personal brands to apply for jobs, and my advice generally revolves around:

MedicSana was my first opportunity to build and manage a team – over the course of the project, I had the opportunity to bring on about 8 people. My sample size isn’t huge, and I have a lot of learning to do, but here are some thoughts I have at the moment (on issues large and small).

As Thaler and Sunstien tell us in Nudge, it is impossible to be unbiased in a decision we make, so it pays to be cognitive of the Choice Architecture: the frameworks around us that affect our biases. It is worth looking into the numerous studies about racial or gender biases in hiring, but we also need to be cognizant of other factors that influence us as well (and when we apply for jobs, it may pay to use these to our advantage).

It is impossible to control for bias completely, but I believe the only way to improve is to constantly question – and experiment with – one’s process.

Read More

Read more about the MedicSana project, other design case studies, or more about me on my homepage.