Skip to main content

The Globe and Mail

How we improved our interview process at Flipp

Managing director of technology and co-founder of Flipp, a leading consumer marketplace reinventing weekly shopping.

In the past few months, Flipp has grown from 275 team members in our Toronto headquarters to 375; 150 are in our engineering team.

We've seen this rate of hiring and growth for more than a couple of years now, and we're still looking to hire high-quality team members that fit with our culture.

Story continues below advertisement

We've had to get more rigorous with our recruiting and interview processes. I'm very cognizant of Steve Jobs's thoughts on A players, and how A players want to work with others just like them.

Former Apple team member Guy Kawasaki, who'd worked with Jobs on the Macintosh computer line, paraphrased it like this: "Steve Jobs has a saying that A players hire A players; B players hire C players; and C players hire D players. It doesn't take long to get to Z players. This trickle-down effect causes bozo explosions in companies."

The idea is clear: One of the keys to a great team, and culture, is to maintain the quality of people you bring on board. Hiring one wrong person is not just one bad hire – they can be highly detrimental for the team. They might not work well with the team culturally, or they might lack the competencies we need and need too much handholding. These types of hires will actually repel the kind of team members we want to retain and attract.

Some companies prefer to hire fast and fire fast, but I don't think the ensuing paranoia leads to a great culture or team. We set out to identify great team members before we hired them, which means the interview process is critical.

The first interviews

When we started Flipp in 2007, our interview process was based on "feel." We knew we had to build out the engineering team. We had a general idea of the questions and a general idea of the roles we were looking to hire for. But our criteria wasn't very clearly defined and hiring often hinged on whether we "liked" the candidate or not.

As you can tell, the process wasn't very organized at the beginning, and it led to some poor hiring decisions. We quickly implemented more structure and started reinventing the process. When we hired somebody and it didn't work out, we would circle back with each other and attempt to figure out why. For example, if we realized they didn't fit Flipp's culture, we would ask ourselves why and create a set of questions to cover the culture areas we'd missed in earlier interviews.

Story continues below advertisement

Eventually, we developed a standardized structure – we knew that a software engineer would need to know certain specific languages (such as Ruby on Rails). We would ask a coding question and ask about their work experience. We would create more behaviour-centric culture questions and specific technical questions. We got better at planning and articulating what we wanted in each of the roles.

All of these incremental changes made our interview process improve gradually, but everything changed in 2015 when we started ramping up our hiring, shortly before our funding round.

What changed?

Two years ago, I watched Hired.com co-founder Matt Mickiewicz speak at a conference about how frustrated he was with traditional recruiters, and the challenge of finding good talent. He pointed out how references only had a moderate correlation with a successful hire, and how sample work was one of the most important factors.

When Mr. Mickiewicz mentioned Who: The A Method for Hiring, I had to get the book and figure out how to apply it to our process. And that dramatically changed how we approached interviews and our success rates for hiring.

The current interview process

Story continues below advertisement

Before we look to hire for any role, we now define what we're looking for very clearly. We're crystal clear with the outcomes we want for this new team member and understand the competencies we're looking for that will set them up for success.

We define outcomes like this:

"If an outstanding performer (top 10 per cent of possible candidates) were to join, what would they accomplish at the end of one month? Of three months?"

Through the interview, we're assessing how likely it is for each candidate to achieve those one-month and three-month objectives, and grading them. They get an A if we're at least 90-per-cent confident they will achieve these outcomes that only the top 10 per cent of possible candidates could achieve. They get a B if we're 70-89-per-cent sure they will achieve the outcomes, and a C if we don't think they will achieve them. If we grade the candidate a C for any of the competencies, we do not hire them. And we generally look for people with more A grades than Bs.

In addition to this grading system, we also shifted our interview questions from hypothetical scenarios ("What would you do if … ?") to more evidence-based questions ("Tell me about a time you did this …"). Going from hypothetical to evidence-based questions sounds simple, but it was one of our greatest challenges. It's easy to ask hypotheticals; it's hard to ask about what the candidate actually did.

For example, if we ask something hypothetical such as, "What would you do if you made a mistake?" the candidate can fall to the obvious "right" answer: "I'd tell a manager."

Instead, with our current process, we ask them, "What mistake did you make at a past job? How did you handle it?" This requires a very real answer that shows actual behaviour. As humans, we all make mistakes. The very important thing we want to learn is, how does this person respond to them? (And if someone says, "I don't make mistakes," there's a red flag.)

While the initial evidence-based question sets the stage, we've trained our interviewers to dig deeper. If we start off in a direction with, "Tell me about the conflict you had …" we might follow up with, "What did you try first to solve it?"and then, "Did you get to your resolution?" or "What did you try after that?"

Our whole interview process now has three rounds, based on "the A Method":

1. Top-grading: What you've done

This is a comprehensive round exploring work history and what the candidate has done. This could be an article on its own – and there's plenty of reading out there on how to conduct good top-grading interviews. Two of our team members interview one candidate.

2. Focus: What you can do

This interview stage focuses on what the candidate is capable of. We'll provide a take-home question to design something, or ask pointed questions describing a system the candidate has designed and challenges they've faced. Remember, sample work is important to properly evaluate a potential hire. Similar to the top-grading round, we have two of our team members interview one candidate.

3. Culture: Who you are

Typically, someone from the executive team leads this final round of interviews, which explores who the candidate is. The goal of this round is to also make sure, in the best interests of the candidate, they understand the culture and what they're getting into. Questions might include:

  • What is the biggest accomplishment in your career?
     
  • What is the biggest mistake you’ve made?

Throughout each stage of the interview process, we keep our eyes peeled for three traits we look for in team members (humble, hungry and highly intelligent) and if they share the same values as us (always reinvent, be team first and coach others).

We also look for two competencies throughout: communication and business acumen. Communication is crucial for cohesive teamwork, and this is a pretty standard competency for teams to look for. However, I do want to briefly mention why we specifically look for business acumen, even in our engineers.

Ideally, we want the engineering team to be able to make good decisions autonomously. If engineers do not understand the business reasons why we're doing something, they rely on somebody else's decision-making and thinking. This makes smaller decisions a lot more difficult than they should be, and decreases our agility and speed.

More importantly, understanding our business will enable engineers to identify new opportunities that technology can create. This is particularly important for senior members of the team. For example, if there's a new bar-code-scanning software announcement for Android, the team member should be able connect the dots: If this removes friction from what we currently do, then this technology improves the customer experience. We could find a way to make the scanning process 10 times faster, which has impact on user experience and retention.

Final thoughts

Interviewing is a relatively simple process, but it's not easy. That's why so few companies get it right. And while we've had some degree of success in creating and refining our interview process, we're certainly not patting ourselves on the back just yet – it's important for us to continue evolving and getting better with our interviews.

Interviewing and successfully hiring are crucial for maintaining your team's and company's culture and momentum, so it's best to get familiar and consistent with it before you absolutely need to.

Executives, educators and human resources experts contribute to the ongoing Leadership Lab series.

Report an error
Comments

The Globe invites you to share your views. Please stay on topic and be respectful to everyone. For more information on our commenting policies and how our community-based moderation works, please read our Community Guidelines and our Terms and Conditions.

We’ve made some technical updates to our commenting software. If you are experiencing any issues posting comments, simply log out and log back in.

Discussion loading… ✨

Combined Shape Created with Sketch.

Combined Shape Created with Sketch.

Thank you!

You are now subscribed to the newsletter at

You can unsubscribe from this newsletter or Globe promotions at any time by clicking the link at the bottom of the newsletter, or by emailing us at privacy@globeandmail.com.