How We Hire: Product, Design & Engineering

Gorillas was founded in spring 2020. By the end of its first year, the company decided to create a comprehensive Product, Design & Engineering department to support its ambitious growth and expansion. In December of that same year, the first hires for that department were made, myself included.

When I joined Gorillas on January 1st, 2021, our newly formed department consisted of 10 people at most. One year later, we are now 140+ people. That means we have hired over 10 people a month across the entirety of 2021, which equates to pretty serious growth. Hiring 10 persons within a month basically means signing a new candidate every 2 days. That’s intense.

This growth extends beyond just hiring people. It’s also about onboarding them when they join (something my colleagues Anita Mavridis and Mariia Punda amongst others have done an outstanding job at). And shaping our organizational structure and processes so that we can actually scale that big and that fast without it crumbling under its own weight — something we owe a lot to Andrea Franke. That’s the challenge. And when we manage to solve all this, how do we retain people? Sure, we can hire a lot of people rather quickly, but what if they don’t like it here? Or they don’t feel safe or represented or have no sentiment of belonging?

I often say “you can hire fast, or you can hire well”, which is the short and sensational version because the reality is that I think doing both is possible. It‘s just hard and expensive. Not just in terms of money, but in terms of time, effort and energy. But considering Gorillas’ ambitions and desire for speed above all else, hiring slowly was not an option, and early leads (such as Anita Singh, Barbara Orsingher and myself) had no intention of hiring whoever just for the sake of filling head counts. That means that we had to think carefully about how we wanted to hire.

A good way to design a healthy hiring process is to look at the pieces you don’t want. There are a lot of things that are done because “we’ve always done them like this“, without sparing a second thought for whether they make sense. The first example that comes to mind is the existence of algorithmic technical tests, on which I can only recommend Why Do Interviewers Ask Linked List Questions by Hillel Wayne, as they dug into the history of the practice, dating back to the 70’s.

So what didn’t we want? We wanted to avoid having an interview process that’s overly focused on the core skills for the role, such as technical skills for engineers or visual skills for designers. There is a lot of value in polyvalence. Looking back, the best people I’ve ever worked with were the ones that could adapt and reason beyond their specific function. In practice, that meant not exclusively assessing technical skills, and when assessing them, doing so in a relevant and thoughtful way (more on that later).

Coming up with a structured process to interview candidates is tricky. It is tricky because we need to find the balance between giving hiring managers the ability to assess candidates in the way that makes sense for the role they are trying to fill, while ensuring the process remains somewhat consistent and relevant across the whole organization.

The specifics vary from discipline to discipline, but generally speaking, our process goes something like this (although leadership positions have a few extra steps):

1. Initial contact. This is done either by candidates applying to our open jobs, or by our recruiters reaching out to potential candidates on LinkedIn. In the first case, there is some input requested from the individual: Sometimes it’s a resume, but we are leaning more and more towards a short form (more on that later).
2. Recruiter interview. The first person a candidate will speak with is one of our recruiters. The call is usually relatively short and serves as an introduction for both parties. The candidate gets to talk about their profile, their expectations and the recruiter can tell them more about the company and more importantly the Product, Design & Engineering department.
3. Technical interview. I’m using the word “technical” broadly here, because it’s about assessing the specific skills for the role, so it could be technical skills for engineers, product management for Product Owners, or design, research or content for designers. Depending on level and discipline, there might be some sort of take home assignment review, otherwise a lengthy conversational interview around the responsibilities of the role itself.
4. Culture-add interview. The culture-add interview is a key stage of our process, during which we assess whether our values and the candidate’s align. This is also a good time for the person to figure out whether they’ll feel comfortable at Gorillas, so we expect it to go both ways, really.
5. Offer wrap-up. Finally, the recruiter sends an offer to the candidate and wraps up the interview process with them, also kicking off their onboarding.

There was a rumour going around in 2021 that alleged we hired anyone, engineers included, without really interviewing people. Like all rumours, it’s hard to figure out where it originated. Perhaps its author confused our hiring process with the one we use for our ground crew (which, by the way, also includes a process)? Or perhaps they heard we don’t always give take-home assignments? Who knows for sure, and that’s beyond the point. That being said, I’d like to pause for a moment and talk about technical tests.

The tech industry is divided on whether or not engineers should go through coding challenges. Gorillas is no exception, and we do not all see eye-to-eye on how to best assess engineering skills. As mentioned previously, ultimately hiring managers (people like me) are left to conduct that portion of the hiring process the way they see fit.

I happen to have a lot of opinions about coding challenges and they all boil down to: they (generally) suck. I think they’re a tragic legacy of our past which is dragging us down. I’ll concede there are cases where they might make sense, but more often than not they are a counter-productive tool that brings little to no value to the table while actively harming candidates. I won’t go too deep into the reasons why I think coding challenges don’t work — you can read my rant about it.

The point is, some of our hiring managers (myself included) are moving away from take-home assignments and towards a different way to assess candidates. I do not want to speak for my counterparts, so I’ll be focusing mainly on web engineer roles for the time being.

Generally speaking, we want to make sure our web engineers are somewhat versatile. They should be comfortable with web fundamental languages of course, but also accessibility, automated testing as well as working in cross-functional agile teams. Depending on the candidate’s interest, we might also brush on performance, internationalization and security. Basically we want to make sure they have a polyvalent frontend profile so they can join us and be comfortable relatively quickly, without having to learn fundamentals. A typical profile we try to avoid is the fullstack engineer who’s specialized in JavaScript but pretty inadequate when it comes to CSS and unaware of accessibility.

We quickly realized that designing a take-home test that covers all these topics would be impossible, or way too difficult and/or time consuming. We have no intention of asking our candidates to do unpaid work, and we also can’t spend hours reviewing a project for every candidate going through that stage. Myself and my peer web engineers truly believe that take-home tests do not tell the full story.

So Mike Smart and I designed a conversational technical interview instead. It’s a little long (we schedule 90 minutes, up to 120 minutes for leadership roles), because we have to brush through all these topics. We also make the point of discussing diversity and inclusion during that technical stage (even though we have the culture-add interview coming later), because we cannot compromise on this. For every topic, we ask the candidate to walk us through their experience, their knowledge, and we ask a few questions. There is no gotcha, there is no quiz — we’re not opposing teams on a field. We want to get a feel for their experience, their appreciation for the discipline, and what knowledge they bring (or not).

This works surprisingly (or is it?) well. Not that we don’t reject anyone at that stage; we do. I say it works well because it’s a healthy way to assess technical expertise and we had good feedback about it. It’s relatively time-efficient (more so than any take-home challenge I’ve seen at least), and both parties benefit from it. The candidate also gets a chance to meet us, ask questions, get a feel for what it’s going to be like to work with us — none of which happens with a silly coding exercise given as homework.

Although the conversational technical stage works well, we also realized that it‘s not perfect because it comes relatively late into the process. It happens after the candidate has applied and had a first call with the recruiter. Then we sit together for 90 minutes, and if we realize it won’t work out, that’s a lot of emotional and time investment for both the candidate and us.

Unfortunately, sometimes we realize pretty quickly in the interview that it’s not going to work. When I’m interviewing a senior candidate whom I ask about accessibility, and they struggle to give me any example or share any knowledge they have on the topic, looking for excuses it didn’t apply to their work so far, I know I probably won’t be hiring them. Because we care about accessibility, and there is enough advocacy to do for a lifetime without having to convince our own engineers.

So we needed to find a way to move our filter a little earlier. We have taken inspiration from Rachel Carrell’s work at Koru Kids (I highly recommend you read her entire thread). When you apply, you don’t provide your resume. Screw that, as it comes with its own set of problems. Instead, we ask you for a moment of your time to fill in a short form that asks open-ended technical questions. Things like:

• What do you consider fundamental knowledge when it comes to CSS?
• What does digital accessibility mean concretely, and what do you think a frontend engineer should know?
• How do you conduct code reviews for your peers and what do you pay attention to?

We want our candidates to feel comfortable and not pressed, which is why we designed the process in a way that they can spend as little or as much time on this as they want. There is no time pressure anyway, since at this stage we’re not in touch yet. They have to submit that form to get started and get contacted by our recruiters.

On our side, we review the application anonymously. At this stage, as reviewers, we have no name, no email, no CV, just their answers to our questions. And based on the answers, we decide whether or not we want to get in touch. If we don’t, our recruiter will reach out to kindly decline their application. Otherwise they get a first call with the recruiter to discuss the job and their background in more detail.

We discovered this works great for us! We found that it’s really good at filtering for competency very early on, while preventing any bias coming in the review process at that stage. This also saves applicants and us time down the line by making sure candidates reaching the technical interview are attuned to what we are looking for. In fact, that works so well that we are slowly spreading that to other hiring pipelines within our organization (for instance Paradise Wright started using a similar exercise for backend roles).

As much as we love our socially awkward, emotionally closeted genius jerks on TV — your Dr. House and your Sherlocks — they make for terrible coworkers. Abundance of competence is not a replacement for empathy, morals and values. It doesn’t matter how talented or excellent someone is if no one wants or can work with them. Genius jerks are typically way more jerks and way less geniuses than advertised anyway.

Knowing all that, we wanted to find a way to get to know our candidates during our interview process (as much as a professional setting allows, that is) so we could figure out whether we would like to work with them or not. All the while without succumbing to implicit biases and personal favoritism. What we needed was an interview where we could discuss work beyond the sole responsibilities of the role we interview for.

So, since pretty much the beginning, we have had a “culture-add interview” as part of the process for all our roles. Now I know what some of you may be thinking. Too often, the concept of a cultural interview — sometimes named “culture fit” — is problematic because it ultimately encourages homogeneity within an organization by rejecting anyone seemingly “different”. A woman in a predominantly male org, a person of color in an overwhelmingly white environment, a disabled person in a generally abled and unaware community. This is a recipe for cultivating systemic issues and perpetrating them at scale within a company. There is this fantastic illustration from Meg that shows a woman sitting across the table of 6 men in suits, with the caption “Not a culture fit.” Touché.

This is why we call it “culture-add” and not “culture fit.” The difference may be subtle but it matters. The goal is not to fit into our culture, but to enhance it. We emphasize on the fact that the objective is not to find out whether one would want to hang out with the candidate outside of work, but to look for wherever we believe there is the possibility of efficient collaboration. Truth be told, we haven‘t always been perfect with that: the first draft of our documentation dating back to January 2021 recommended conducting the “airport test”, in which the interviewer has to figure out whether they’d feel comfortable being stuck in an airport with the candidate. Needless to say this is a horrendous idea.

Since then we have standardized our guide to conduct that interview so things are more fair, and more relevant. I am taking the liberty to quote directly from our interview guide here:

“The aim of a culture-add interview is to assess whether the candidate will contribute positively to the culture we are working to create inside the Product, Design & Engineering department.

We are trying to assess if the applicant fits our team values, our motivation, and supports our vision. This is essentially a conversation about social impact. We do these interviews because it enables us to know candidates better, and understand how they think about inclusivity, the impact of tech on society, and talk about how they see the world and technology.

For instance, social justice, bias and historically marginalized people in tech, or the unintended social consequences of technology are but a few of the topics that can be brought up during such interview. While it does sound heavy, most people come away from the conversation feeling quite energized and excited because it’s a chance to explore and discuss issues they’re passionate about.

So, these are the main three things we will want to dig into: what they know, Gorillas culture and alignment, and their experience and credibility. We just want to see who they are as a person along the way.”

It’s typically the last round before sending out the offer, although it does not make it a guaranteed-pass — we have rejected candidates because things didn't work out at that stage. Not necessarily because we didn’t appreciate them, or because they were unqualified for the job, but because we did not think they would be a good fit in our teams, or because we didn’t think we would be a good place for them.

Alright, this was a lot. Let’s walk through some key takeaways I’d like you to leave with:

• We grew a lot, and rapidly, however (or rather therefore) we do think a lot about how we hire, and how we create an environment where people can feel safe and do their best work. We do not take that lightly, and that’s something we put a lot of work into.
• We are using somewhat non-traditional ways to assess technical skills (mainly because traditional ways come with a wide set of problems and yield mixed results). These minimize time and emotional waste for both our candidates and us, while still allowing us to keep the bar high in terms of expected experience and adequacy. It also improves diversity by eliminating designs that typically further disadvantage already marginalized people (such as expecting unpaid work, or engaging in incredibly long and tedious processes).
• We work towards a somewhat standardized process across roles so we eliminate as much bias and make things as fair as possible, while still providing our hiring managers leeway into how to best hire for their role.

Knowing all that, how about checking our open positions? Hopefully there is something that tickles your fancy and we get a chance to meet soon! And if you’d like some more information, feel free to reach out to Andrea Franke on LinkedIn, or myself on Twitter or LinkedIn. ✨