Skip to main content

Asana Interview Guide

https://asana.com/eng/interview-guide

Engineering Interview Guide

We’re excited to have you come in and 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. We want you to feel comfortable throughout our interview process to give you the best chance of showing your strengths. To help with that, we’ve written this guide to give you expectations about the structure and content of our interviews.
Please let us know if you have any questions. Also, please let us know if you have suggestions about how to interview you: In what areas do you excel? Are there any additional resources or accommodations you might need?

Types of Questions

We design our interview questions to see how engineers work through technical problems they don’t know the answer to yet.

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. Notably, we ask candidates not to compile or run their code during this exercise, and not to refer to online resources. Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests! — but rather to see how you reason about your code and input cases. For that same reason, we won’t ding you for superficial syntax errors or misremembered function names. 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 and Data Structures

Most engineering interviews contain some algorithmic questions. At Asana, we particularly love questions that involve the use of data structures. Hashes, sets, heaps, binary trees, linked lists, all the usual suspects. Using the right data structure for the right job is a skill we consider fundamental because it is key to efficiency. Things to think about: Do you know the different types of operations for which a data structure is suited? What kind of run-time complexity do the operations have? 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. We also value thoroughness and being able to catch your own mistakes, even in the edge cases.

Modeling and Design

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 to a real-world problem (often based on a problem that we’ve worked on in the course of building Asana). Break the problem down into smaller components. You might prefer an object-oriented design, or a functional design, or perhaps even take a declarative approach; the key is being able to articulate not only a solution, but also why you made the choices you did. Being able to identify trade-offs explicitly and why you are making them is the sign of mindful design.

What We’re Looking For

This isn’t an exhaustive list, but it’s some of the qualities we look for that we think are especially valued at Asana (while not unique to us).
Communication: We’d love to see you clearly explain your solutions, and your thought processes towards them. We try to design our interview questions to see how you work through unknowns. We also want to see you able to exchange ideas and collaborate with your interviewer, including taking feedback.
User empathy: We don’t expect you to be a product designer, but knowing how your engineering decisions will affect users is important to us. Will certain trade-offs you make create confusion or pain-points for the user? How might it constrain their abilities, or force them to deal with complexity?
Learning: You’ll definitely have to learn new things on the job, and we love evidence that you’ll pick up things fast. Don’t worry if you get stuck; that’s bound to happen when exploring new territory. This happens to everyone! Be honest with your interviewer and see if you can talk through where you’re stuck. Listen for hints they might be giving you.

How To Prepare

Below are just a few ways we’ve heard on how successful candidates have prepared for their interviews.
  • Read through technical interview prep resources
    HackerRank and Interviewing.io are good places to start. We’re also fans of InterviewCake’s Coding Interview Tips.
  • Reflect on your experience and interesting technical problems you’ve worked on
    We want to hear your story and witness your expertise. The more you tell us about your past work, the more we can adapt our interview to suit your strengths.
  • Bring questions for your interviewers
    As important as it is for us to evaluate if you’re a good fit for Asana, we want you to be able to make the same call. What matters to you in a working environment? What are you looking for in your future projects and teammates?

Comments

Popular posts from this blog

The Difference Between LEGO MINDSTORMS EV3 Home Edition (#31313) and LEGO MINDSTORMS Education EV3 (#45544)

http://robotsquare.com/2013/11/25/difference-between-ev3-home-edition-and-education-ev3/ This article covers the difference between the LEGO MINDSTORMS EV3 Home Edition and LEGO MINDSTORMS Education EV3 products. Other articles in the ‘difference between’ series: * The difference and compatibility between EV3 and NXT ( link ) * The difference between NXT Home Edition and NXT Education products ( link ) One robotics platform, two targets The LEGO MINDSTORMS EV3 robotics platform has been developed for two different target audiences. We have home users (children and hobbyists) and educational users (students and teachers). LEGO has designed a base set for each group, as well as several add on sets. There isn’t a clear line between home users and educational users, though. It’s fine to use the Education set at home, and it’s fine to use the Home Edition set at school. This article aims to clarify the differences between the two product lines so you can decide which

Let’s ban PowerPoint in lectures – it makes students more stupid and professors more boring

https://theconversation.com/lets-ban-powerpoint-in-lectures-it-makes-students-more-stupid-and-professors-more-boring-36183 Reading bullet points off a screen doesn't teach anyone anything. Author Bent Meier Sørensen Professor in Philosophy and Business at Copenhagen Business School Disclosure Statement Bent Meier Sørensen does not work for, consult to, own shares in or receive funding from any company or organisation that would benefit from this article, and has no relevant affiliations. The Conversation is funded by CSIRO, Melbourne, Monash, RMIT, UTS, UWA, ACU, ANU, ASB, Baker IDI, Canberra, CDU, Curtin, Deakin, ECU, Flinders, Griffith, the Harry Perkins Institute, JCU, La Trobe, Massey, Murdoch, Newcastle, UQ, QUT, SAHMRI, Swinburne, Sydney, UNDA, UNE, UniSA, UNSW, USC, USQ, UTAS, UWS, VU and Wollongong.

Logic Analyzer with STM32 Boards

https://sysprogs.com/w/how-we-turned-8-popular-stm32-boards-into-powerful-logic-analyzers/ How We Turned 8 Popular STM32 Boards into Powerful Logic Analyzers March 23, 2017 Ivan Shcherbakov The idea of making a “soft logic analyzer” that will run on top of popular prototyping boards has been crossing my mind since we first got acquainted with the STM32 Discovery and Nucleo boards. The STM32 GPIO is blazingly fast and the built-in DMA controller looks powerful enough to handle high bandwidths. So having that in mind, we spent several months perfecting both software and firmware side and here is what we got in the end. Capturing the signals The main challenge when using a microcontroller like STM32 as a core of a logic analyzer is dealing with sampling irregularities. Unlike FPGA-based analyzers, the microcontroller has to share the same resources to load instructions from memory, read/write the program state and capture the external inputs from the G