TL;DR: we look for two things: technical excellence and agency. in interviews we push on what the candidate knows to find out how far it goes. we hire people who are better than us.
I'm writing this because I think I've gotten better at finding good talent in this hiring round, and I want to share what I did. I want to cover two things: 1) how we think about hiring at Atlas, and 2) how we actually find the best talent.
how we hire
the people we hire while we're still under 30 will shape the culture of Atlas for years. good hires save us time because they have autonomy and help us grow. and good hires mean working with brilliant people who push us forward and make us better, and that's a real luxury. for all of those reasons, we have to learn to hire well.
what an ideal candidate for Atlas looks like:
- has autonomy, ownership, agency. makes proposals, asks for what they need, suggests changes.
- has technical expertise. top 1% of everyone we interview.
- is better than us. that means: more years of experience; career milestones that are more complex than the ones we've hit in this role; makes us a little nervous to bring on, because they clearly know more than we do.
how we find the best talent
even when we agree we want people with autonomy and ownership, it's hard to actually spot one. I'll share the method I used in my last hiring round to identify high-agency people.
some general principles:
- we run a consistent interview process. ideally, keep a spreadsheet of the questions we ask each candidate and save the answers, so we can be objective and compare.
- we always look for 2 things: technical excellence and agency. we measure technical excellence through their experience leading complex projects. we measure agency by asking about projects they've proposed in their current jobs.
- we keep digging on each question to find out how far the candidate can go. we don't stop at the first answer.
what technical excellence is
- they have to know their area inside out.
- they have examples of complex projects they've built.
- usually 5 to 8 years of experience in the area.
- top 1% of the candidates we interview.
how to identify technical excellence
- the way to spot it is by asking about something they did in a previous job. I like the question what's the most complex technical challenge you've had to solve (for non-dev roles, it can just be "the most complex thing"). for me, this question is an excuse to dig into that project in depth.
what I look for in the answer:
- they can talk in real detail about the process, the tasks, the tools, the challenges of what they had to do. a red flag: not going into detail, not naming any tools, staying very general.
- they can communicate what they did. it matters that they can walk through their work and their role in it clearly. if they can't, they're someone who's going to communicate just as poorly day to day at work. red flags: jumping between several challenges without committing to one in depth; vague explanations; it staying unclear what they actually did.
- their level of involvement. we want people who led or worked closely on the project they're describing. we don't want someone who worked on a small slice or just took instructions. red flags: not being able to talk about the project in detail usually means they didn't make the decisions. they have to be able to explain why the choices were made.
- the project was actually challenging. for devs, examples of non-challenging projects: consuming an API; setting up a service in AWS; I'd look hard at blockchain and crypto projects that often hide simplicity behind complex language. for paid marketing roles, examples of non-complex projects: products that sell themselves (e.g., ecommerce); projects with infinite budget; projects with goals like "drive traffic"; only having run campaigns in places like Argentina where it's much less competitive.
- how they handle follow-up questions. my usual move is to ask the question, listen to the answer, then paraphrase what they said back to check I got the project right. from there, I ask "why" a lot, both to understand all the points above and to find the edge of what they actually know. people who don't know their stuff well usually struggle with these follow-ups, and it's normal for them to get defensive. it's important to see, because it's how this person would behave under pushback or disagreement at work.
what agency is
- takes responsibility for the area they own.
- proposes things, makes changes without asking, digs deep into the context of what they're working on because that context is what their decisions run on.
- has opinions; says what they need.
- has ideas about what they want to happen and usually just executes them.
- action-oriented. doesn't complain.
- manages their time well. plans their own work.
how to identify agency
- I like asking about a project they've proposed at their current job (whether or not it actually got done). the reason I ask is that people who propose ALWAYS propose. it doesn't depend on context, job, role, or area. if they don't have examples to share, it's a no.
what I look for in the answer:
- it's a project with business impact, not "tooling". examples of bad proposals: for sales, suggesting using a CRM. for devs, suggesting a refactor or a new library. for marketing, suggesting a tool, CRM, migration, etc. what's a good answer: a project that generated revenue or cut costs; a product or business idea.
- they can talk about whether it worked or not, and they use metrics when they do. if they don't talk about metrics, it means they're going on intuition, and that can be a problem.
- creativity: something that catches my interest, that's exciting to hear, that makes me think "wow, how did I not think of that".