Engineering Interview Guide

We’re excited to have you interview with us at Asana!

While onsite, you’ll meet your future teammates, learn more about Asana and our culture, and be given the opportunity to showcase the best of your abilities. To give you the best chance of showing your strengths, we want you to feel comfortable throughout our interview process. To help with that, we’ve written this guide to set expectations about the structure and content of our interviews and how to prepare for them.

Summary

Asana’s interview philosophy is that we emphasize collaborative problem-solving to understand what it looks like to work with you day to day. This means:

1. We use IDEs for coding, not whiteboards.
2. We care about how you solve problems, not just the solutions.
3. We want to collaborate with you to solve these problems.

As part of our interviews, we ask four types of questions: Coding, Algorithms, and Design questions for technical skills, with more senior roles having behavioral interviews.

For more details on our philosophy and our questions, see the relevant sections of the doc below.

Asana’s interview philosophy

Our main goal in our interviews is to understand what it’d be like to work with you day to day. Overall, our interviews emphasize collaborating together to solve problems simply and robustly. Here’s how we try to do that, with some tips on how to best show off your engineering skills.

We use IDEs for coding, not whiteboards

Since we don’t code on whiteboards day to day, we won’t ask you to do that in the interview. Instead, we’d love for you to leverage the whiteboard to collaborate with us to solve problems, writing down logic and pseudocode, as it adds clarity. We have coding-focused interviews, but they’ll be done in a code editor.

With this in mind:

1. We’ll make it explicit when we’re expecting code. Instead of code, most questions focus on using systems, data structures, and abstractions together to solve problems. Sometimes, pseudocode is useful to express the logic that connects these together, but we won’t be evaluating syntax here. If you’re confused about what your interviewer wants from a question, please ask! They’d be happy to help you find the right level to collaborate on.
2. Describe your solution as you evolve it. We find that successful candidates often sketch out their solution as they go and check in with their interviewer to make sure they’re following. Using your whiteboard/collaborative editor is a great way to provide that clarity.

We care about how you solve problems, not just the solutions

While some interview questions have a most efficient solution, this isn’t always true in the real world. You often need to understand problems deeply, generate and then evaluate tradeoffs between different solutions, and then narrow down to one recommendation. As a result, we want to understand how you solve problems, not whether you get the “right” answer.

This means that:

1. During your interview, it’s important to articulate what you’re thinking so your interviewer can follow. Make sure you’re explaining how you’re thinking through the problem, and check in with your interviewer to make sure they understand.
2. When encountering a problem, try to talk through multiple options and compare them. You might start with a brute force or MVP approach and then consider different ways to evolve your solution. Be clear what the tradeoffs are between your options, e.g. how do they compare in terms of scalability or simplicity.
3. Since we have limited time together, we often won’t have the space to explore every option to the fullest extent. Therefore, try to focus on the most important parts of your solutions and the most important criteria for evaluating them. It’s often useful to start a question with a quick discussion about what those criteria are so you and your interviewer can be on the same page. For instance, in system design focused questions, we generally look for a high-level understanding of the systems involved, as well as the scalability, simplicity, and correctness of your solution. You can start by outlining those and asking your interviewer if there’s anything else they want you to include.

We want to collaborate with you to solve these problems

Asana engineers collaborate heavily with one another—to teach and learn from one another, as well as to brainstorm and develop solutions together. As such, we want our interviews to be a collaborative process.

To do that, we’d love for you to:

1. Ask us questions! If the problem or what we’ve said is unclear, you’re not sure what to focus on, or you’re stuck and aren’t sure what the next step is, please ask us questions so we can unblock you.
2. Iterate on your solutions with your interviewer. As mentioned above, you might start with an MVP, and your interviewer may ask about how it scales. Work with your interviewer to iterate on your solution so it can solve the problems you find together.
3. Take feedback and run with it. If your interviewer notes that your solution fails in a certain case, make sure you understand what they mean, and then work to solve it.

How to prepare for Asana interviews

To help make sure your engineering skills shine in our interviews, we put together a technical interview skills guide called Asana 101 Technical Interview Guide. This is aimed at early career engineers, but it contains examples and pointers that we think are useful for everyone.

To summarize, our advice to prepare for Asana’s interview are:

• Practice problems, and refresh your knowledge for each type of Asana’s interviews. Our technical questions can be roughly bucketed into three categories: coding, algorithms, and design. Below we outline each type, and link to the full guide which has practice problems, tips for how to answer them, and other guides you can consult.
• Coding: We’ll ask you to solve some coding questions in a language and text editor of your choice. Feel free to bring your own laptop, or we’ll be happy to provide one. After leaving you to work through the questions on your own, we’ll sit down together and talk through your solutions (including any ideas you didn’t have time to commit to code).
• Algorithms: At Asana, we particularly love questions that involve the use of data structures. We don't expect you to know how to implement every data structure by heart, but we do hope to see that you could work it out in cooperation with a helpful partner.
• Design Questions: When it comes to modeling and design, we value clarity with a bias towards simplicity; we expect Asana engineers to be comfortable designing a technical solution. Being able to identify trade-offs explicitly and why you are making them is the sign of mindful design.

For behavioral interviews:

• It’s useful to spend some time and reflect on your experience and interesting technical problems you’ve worked on. We want to hear your story and witness your expertise. See some common questions to get a feel for the types of behavioral questions we might ask.
• We find that using the STAR format is a great way to structure your answers: this makes it clear what problem you were trying to solve, what you did, and the result of that, which helps us understand how you would function at Asana.

Please also bring some questions for us!

• At the end of every interview, your interviewer will try to save time for you to ask them questions. We want you to be able to evaluate whether Asana is right for you.
• Some prompts: What matters to you in a working environment? What are you looking for in your future projects and teammates?

Share Your Feedback with Us

These are the ways we approach our interview process. We’d also love to hear about your experience so far and what we can do to better accommodate your onsite visit. We’re still in the early stages of creating this guide and are always seeking ways to make it better. Let us know what you think and what else you would’ve liked to see on here.