How We Interview at Addepar
At Addepar, we’re committed to cracking the hard problem of technical interviewing. We know that to hire the most qualified, best matched candidates, our interview process needs to be engaging, challenging, and fair.
When we’re designing our interview process, we ask:
- How do we gather the right information effectively and without bias?
- How do we get the best odds that both Addepar and the candidate will make the right decision coming out of the phone screen or interview day?
- How do we make tradeoffs between how much time we ask current employees to devote to the process and ensuring that candidates have the best possible experience?
- The goal of an interview is to make a hire/no-hire decision and for the candidate to make a decision on whether to join. Compared to decisions like how to design or build a certain feature, these decisions are infrequent. How do we update the process to incorporate learnings as fast possible?
Seeking and sharing knowledge are among our core company values, and because of that we’re always iterating on the process to incorporate learnings we’ve gained while interviewing hundreds of candidates. So if you’ve interviewed before, or if you’d like to interview again, chances are that the experience will be different the second or third time around. We’ve tested and changed everything from the collaborative document editor we use (Collabedit vs. Stypi vs. HackerRank) to the questions themselves (tracked via Github, always open for internal PRs) to the types of questions we ask (Do we ask behavioral, experience-based, or skill-based questions? How many of each? To which candidates should we ask each set of questions?) to the way that we structure interviewer feedback. In the following sections, we’ll describe the pillars that guide our current philosophy and that we’ve used to implement the process itself.
Interviewing is Everyone’s Responsibility
Building a strong company is each employee’s responsibility. We expect all of our current employees to contribute to the interview process to the best of their abilities. We’re a small company, and making a bad hire can be dangerous for the organization. So we strongly believe that all members of the team should contribute. As soon as a new hire is onboarded and feels like they are comfortable assessing for the role, we start training them on our interviewing philosophy and practices. This training includes our high-level values and strategy of the company and the process itself, mechanics, and how to be unbiased and efficient at gathering information.
Ultimately, the decision to hire is made by a single hiring manager, not a hiring committee or by consensus of the interview loop. But our hiring managers are selected for their ability to synthesize feedback into a cohesive whole and for their ability to raise the bar in the quality of the information that they’re receiving. Some hiring managers even grade and critique the quality of the feedback they’ve been given from each interviewer as well as the mechanics and quality of the interview itself.
Potential for Impact is a Top Priority
The ability to make a positive impact is by far the most important quality we use to evaluate our employees, and therefore also our interview candidates. Is someone smart and can they get things done? That’s great to see, but only a piece of the puzzle. Resilience, big-picture thinking, the ability to work with others, and the ability to work in a cross-functional team and make everyone better are also important, as are breadth of strong software engineering skills. We ask candidates to demonstrate that they can read, write, debug, architect, and refactor both code and systems at a level we’d expect from someone with their experience.
While hard skills have a well-defined set of expectations, some softer qualities are more difficult to evaluate in a candidate. To do this to the best of our ability, we’ve developed a set of questions using the STAR (Situation, Task, Action, Result) framework, and we devote at least some portion of the interview day to evaluating these qualities. For management candidates we weight this more heavily, but even for non-management roles we expect contributors to ask hard questions, challenge assumptions, and ensure that we’re solving the right problems.
Candidates Should Interview Us Too
Our product solves problems that many candidates may not be familiar with. We don’t require prior financial experience (although it is a plus!) and unless the candidate has previously been a financial advisor, they might not understand the particular pain points we solve for. We make sure to start each interview day with a product demo and do our best to ensure that the interview slate is comprised of employees from different parts of the organization: both of these practices allow candidates to ask questions to a diverse group of people who will have different viewpoints and daily work lives. We also ask every interviewer to make sure that they plan to eat lunch at the same time as the candidate to allow the candidate to ask questions in a more informal setting.
We hate gotcha questions as much as anyone else does and we do our best to never ask them. However, the realities of many of our roles require that we assess skill and ability to contribute in hard technical areas and to complex problem solving. We ask our candidates (even for leadership roles) to write working code, to design systems and write maintainable code, debug and refactor, and to solve abstract problems on the whiteboard. While questions that require solving abstract problems on a whiteboard have a mixed reputation in the industry, they are the best way we know of to evaluate these skills. We do design many of our whiteboarding questions around actual problems that we’ve had to solve at Addepar and while every employee might not need to solve the particular problem we asked, we want to make sure they could if called upon.
We do our best to be as fair as possible in these situations. We allow candidates access to a laptop with internet connectivity and the candidate’s choice of editor or IDE and encourage candidates to ask for any additional resources that they may need. We train our interviewers to set expectations for solutions clearly to limit the chance of a candidate misinterpreting a problem, and to offer help and guidance on the question if the candidate asks for it.
Experience is a Strong Positive Signal
We love candidates that have experience and can show that they’ve learned from it. We look favorably on candidates that have built financial data systems and portfolio reporting applications, can demonstrate significant impact in previous roles, and can demonstrate an advanced engineering approach. If it’s not clear from the beginnings of this post, we love learning — and there’s no stronger “hire” signal than someone who has something to teach. Our day-to-day requires synthesizing knowledge of systems and processes that have been around for the last few decades with forward-thinking approaches that will lay the foundation for the next few and a deep understanding not just of modern frameworks and trends but also of how to best apply them to real business problems.
If this sounds exciting to you, we’re hiring!