14 ms·

Asana Engineering Interview Guide

227 points by pspeter3 11y ago

swagv 11y ago
When does a blog post become a "guide"?
artimaeis 11y ago
Much more interesting is the guide that this blog post mentions at https://asana.com/eng/interview-guide https://asana.com/eng/interview-guide.
- toomuchtodo 11y ago
  Yes! Would be interested in seeing how much coding they ask for when interviewing for devops or ops positions. Some orgs require only scripting, some go so far as to want application engineers who also know everything about AWS for devops/ops roles. Disclaimer: I already asked via their google form for this information to be added in their docs.
  - pspeter3 11y ago
    I haven't followed the recent updates to our interview process closely but we traditionally looked for general knowledge over specific knowledge. I'm not sure how much that has changed recently though. Edited In Response To Parent Edit: Thanks for asking! We should definitely make it clearer if there are differences per role.
    - toomuchtodo 11y ago
      So very awesome of you. Thank you for the reply!
    - neofrommatrix 11y ago
      "looked for general knowledge over specific knowledge" - incidentally, I was rejected because I could not answer (to the interviewer's satisfaction) how to implement an in-memory LRU cache. I made some good recommendations but the interviewers were expecting a very specific answer which exactly matched http://www.programcreek.com/2013/03/leetcode-lru-cache-java/ http://www.programcreek.com/2013/03/leetcode-lru-cache-java/
      - riyadparvez 11y ago
        > looked for general knowledge over specific knowledge This is one commonly thrown BS regarding interviews. At the end of the day it is all about one-dimensional usual algorithmic questions. Regarding LRU cache, I think this is one of less crazy interview questions. In one phone interview, I had to solve a DP problem, code it perfectly and pass all the test-cases on HackerRank in less than twenty minutes. I am not certain how many developers out there can pass such interviews without months of preparation in such situations. Tech interviews are basically programming contests. I am not against programming contests or algorithmic questions. But it seems the interview questions are getting crazier day by day.
- twphonebillsoon 11y ago
  I don't really see whats interesting about this either way. Lots of places you interview at tell you what the interview is going to be like and what you are expected to be familiar with. This is just 'write code and we'll be testing you on data structures and algorithms!' There's some flowery language there about having a genuine desire to want to hire you unlike those 'other evil companies!'... sounds like the same shit pretty much every other company does to me.
  - deleted 11y ago
    [deleted]
  - riyadparvez 11y ago
    I had also the same impression. I think one of the best approaches is let the best engineers at the company go through same interview process. If they can't get pass through the hiring bar of the company, then maybe that company should re-think their hiring process.
    - th0raway 11y ago
      My current company has a very similar interview style, and I later learned that I was pretty close to not being hired because I didn't do quite as well as one interviewer wanted on a coding challenge: I ran out of time. But what I also learned is that the interviewer had never solved the problem in the language I used! I had one of our most senior engineers, who has worked in this language's compiler, to try to solve the exercise. Instead of 40 minutes, it took him three hours! If a candidate is going to interview in a language, for the love of god, have as a prereq that the interviewer is actually capable of doing the exercise in that language.
- biot 11y ago
  Why is it more interesting? The purpose of the blog post is to explain the rationale for the guide itself and directly links to it. I find it just as interesting to read about why they're doing it.
trjordan 11y ago
> 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. Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this finally broke something loose: Coding in interviews should be as hard as the hardest coding you'll do on the job. Heck, anything in the interview should be about how you do things when the job is hard. Now, this doesn't mean under stress. That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. They'll pass over people who are exceptionally good at searching / synthesizing information. They'll ding people who focus on tightening the iteration time as a way of learning faster. But that's OK. They've probably built a culture where that kind of person thrives, and they're trying to find more engineers who will thrive at Asana.
- vonmoltke 11y ago
  > That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. > They'll pass over people who are exceptionally good at searching / synthesizing information. I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way. "[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.
  - thedufer 11y ago
pklausler 11y ago
> We design our interview questions to see how engineers work through technical problems they don’t know the answer to yet. That's the way to do it, I think. In my own technical interviews, I pose (relatively) simple questions that require some problem analysis, a strategy discussion, and then some coding and testing, with a goal of testing aptitude for basic programming abilities like modularization, indirection, recursion, defensive programming, unit testing, etc. I keep things interactive and collaborative and see how much the candidate can do for themselves.
- p4wnc6 11y ago
  The problem is that Asana seems to have preconceived ideas of what answers are supposed to look like, but the questions are vague and open-ended enough that even very good candidates can give good answers that simply diverge from the manner of thinking that the Asana question designer had in mind. If the question has a well-defined answer, then this is good. If you are asking questions that the candidate "doesn't know the answer to" merely as a parochial side effect of the question's vagueness and the vast space of possible good approaches, then you're really only screening for people who happen to think about things the same way you already do, and thus are good at guessing what you want to hear. I'd argue that this is very bad in terms of diversity of thought.
  - pklausler 11y ago
    I use problems with multiple acceptable solutions and easy tests of correctness -- i.e., it's obvious whether or not the approach is sound and the code works. For example, write a function that determines whether two rectangles on a display overlap, given the coordinates of their corners. Solving it requires the ability to analyze the problem and describe the conditions, the ability to code a simple Boolean predicate, and some aptitude for checking boundary cases and writing unit tests. I have others; what they have in common is that they're really easy problems for great programmers, and well within the limits of a 45-minute technical interview for competent coders, and good at exposing candidates who lack some basic skills.
  - jacklionheart 11y ago
avoutthere 11y ago
> Our goal is not to simulate day-to-day software development... I don't understand this. Why do they not want to see how well a candidate performs the tasks that they will be expected to perform on the job? Does this not result in them selecting for the wrong set of skills/knowledge?
- gkop 11y ago
  Plus they're using this goal to justify not letting you run your code during the interview, which prohibits a "try it and see" problem-solving approach. Asana engineering team, what's wrong with "try it and see"?
  - rmah 11y ago
    You're kidding, right?
    - gkop 11y ago
      Not kidding! "Try it and see" is a legitimate problem-solving approach.
deleted 11y ago
[deleted]
orangetabbycat 11y ago
I had an onsite interview for a new grad engineering position at Asana recently. It's true that they test you on technical problems you don't know the answer to; sometimes it seems like they tested me on technical problems that had no answer. One of their interviewers, who was in charge of both conducting a one-on-one with me and explaining the programming questions to me, was very friendly but also had a hard time clarifying any of his questions for me. I didn't really understand him and it was obvious from his facial expressions that he believed that his explanations had sufficed from the very beginning. The questions were either too vague and could be approached from many different directions or were so specific that it was obvious the right solution would have to be found in an epiphany-like "aha!" moment of mathematical understanding. I was able to answer and program most of the questions. I have to say that I was really happy to receive feedback following my interview, which no other company did. My advice to Asana: Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) Of course, that's just my experience. I ended up finding a good position somewhere else and think Asana's interviews were some of the best ones I had the honor of failing.
- riyadparvez 11y ago
  > Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) I think this a common problem. Many companies let a single interviewer has huge influence on hiring decisions. What if the interviewer himself/herself had some bias that s/he wasn't aware of?
swanson 11y ago
> “We want every candidate who comes into an interview with us to feel prepared and confident.” Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare. This seems like it could be improved. You value learning -- so give candidates something to learn and see if they can do it. > Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests! I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard.
- jacklionheart 11y ago
  Hey -- I work at Asana. Great idea! Took a task to add more resources to learn from to the doc. > I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard. Hmm, the way we framed that is confusing. Thanks for the feedback! To be sure, our goal is to accurately assess what your day-to-day contributions would be like, and simulation is a really good way of eliminating accidental bias in that process. To that end, we do have every engineer submit actual code during the interview process, and we generally avoid white-board programming in favor of higher-level discussions (that may also use the whiteboard). But perfect simulation is possible (and time-consuming), so we've tried to focus on the higher order bits.
  - insulanian 11y ago
    What's your primary tech stack?
    - ktothemc 11y ago
      We're in the middle of rewriting our stack to look like this: - TypeScript web code - Using React - Connecting to a custom, to-be-opensourced reactive datastore written in Scala called LunaDb: https://blog.asana.com/2015/05/the-evolution-of-asanas-luna-framework/ https://blog.asana.com/2015/05/the-evolution-of-asanas-luna-... - Using to Amazon RDS (hosted MySQL) and Redis as our primary backing stores - Running on top of kubernetes, docker, AWS
dvt 11y ago
I came looking for some new or interesting way of doing tech interviews, but it's the same typical SV bullshit. Lol: "Hashes, sets, heaps, binary trees, linked lists, all the usual suspects." Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. I'm a strong believer that there are two primary ways of testing someone's coding ability: 1) Open-source, or otherwise public, contributions. 2) Real-world take-home assignments. I've opted out of interviewing people because it's such a miserable experience. I guess I'm just not a sadist that enjoys watching some poor 22-year old squirm in his chair because he can't remember what the upper bound on the insert operation of a red-black tree is. What a joke.
- ryanSrich 11y ago
  On the flip side, Asana clearly indicates that they don't test candidates on day to day development. This is good, because now I know I would never work for Asana. Those interested in non-applicable CS problems would probably love Asana. Although I'm not sure how any of this relates to a pretty basic project management app.
  - dvt 11y ago
    Yeah, exactly! It's like fucking insane how these companies hype themselves up. All you are is a glorified to-do list, calm down, Asana.
    - Aeolun 11y ago
      It is a very, very fancy to do list though. To be honest, it was more usable when it was just released. The simplicity was one of the strong points.
  - mpd 11y ago
    > This is good, because now I know I would never work for Asana. I've actually used their product, and I'm in the same boat as you because of it.
- deleted 11y ago
  [deleted]
aiokos 11y ago
Ah, got to love the subscription pop-up with a close button that doesn't work. A timeless web design principle. Aside from that, when will we get past the requirement for data structure knowledge for positions that center around web design? Data structure knowledge is available at my fingertips throughout the work day. Why must I memorize implementation boilerplate for an interview?
lostcolony 11y ago
Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!" I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve, but to implicitly admit it, -and- to also acknowledge that it isn't something you expect people to have off the top of their head by providing a study guide? What are you trying to measure?
- mandeepj 11y ago
  I wish they (asana) listed down some of their real problems along with few possible solutions. A candidate can provide his solution or recommend one of their solutions. I think this approach can lead to a nice discussion where both parties can get to know each other.
  - Tiks 11y ago
    Have you tried this? :) https://codefights.com/bots/botasana https://codefights.com/bots/botasana
    - fapjacks 11y ago
      I like how they slip in "Oh, all you have to do is parse HTML with regex" on the last problem.
      - so0k 11y ago
        for the HTML parsing - I was able to pass all the test cases using a stack (push the tags when they open and pop them as they close). I was doing zero validation as the challenge was to take valid html. (I didn't verify that the proper tag was being closed, I knew I'd get out of bound errors due to this, but it should work for valid html) I was using a string builder to eat the input as I had parsed it... but I got an error on submitting my result - it gave "unexpected termination" even when I had replicated the "unexpected termination" error with a custom test case and caught the error - I still got an unexpected termination error when submitting - sigh - maybe it's related to using C# for the challenge... overall not so hard though...
sudo_bang_bang 11y ago
I tried interviewing with Asana and they rejected me on the basis that I didn't have a computer science degree. For the record, I've built apps that have generated millions in revenue and I have many years of experience. If they are trying to be meritocratic and community friendly with this, they should change that aspect of their culture to reflect that.
- meritt 11y ago
  Can you blame them? That CS degree provides essential knowledge when it comes to solving some of the world's most complex problems: to-do lists.
- andrewstuart 11y ago
  Remember also that Steve Jobs, Larry Ellison and Bill Gates did not have computer science degrees. They need to keep people of that calibre out of their ranks - you know, the non achievers who don't understand computers.
- dbt00 11y ago
  I just accepted a position at Asana, and I don't have a CS degree. Are you sure you're correctly attributing your non-offer here? (Note I don't call it a failure. Hiring is a weighted RNG -- false negatives are common.)
- Aeolun 11y ago
  Just the fact that you've built (worked on?) apps that generated millions of revenue is not a measure of compatibility/competence, nor is experience. Might be different if they actually said they didn't want you because of a lack of CompSci degree though.
tptacek 11y ago
I appreciate the sentiment behind documents like this, but, Asana, you can do better. When you do, you'll find it gets easier to hire people, and, perhaps counterintuitively, the quality of your hires will go up. Specifically: It's clear from the tone that you're trying to mitigate the hostility and unfriendliness of the conventional programmer interview. Great! But you need to do more than superficially adjust your tone. What this document describes is literally the circa-1999 software developer interview, in almost every detail --- the fuzzily described coding question, the "algorithm and data structures" interview, the design review. Everyone has heard of interviews that pointlessly refuse candidates the opportunity to consult Internet references, like every working programmer does every time they code anything ever. But your process goes a step further: you won't even allow candidates to compile their code. How can this possibly be helpful to your process? The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings. But if you're going to make people code in an environment that is utterly unlike the one professionals actually work in, the onus is on you to do everything you possibly can to mitigate the performance penalty you're imposing. Why not, instead of coming up with crazy rules like "no running your own code allowed", point your creativity in the opposite direction and find ways to get candidates to be more at ease with writing code with someone looking over their shoulder? Here are some things you can do right now to make your interviewing guide actually helpful to candidates: * Provide sample questions. They do not need to be the ones you're asking in real interviews (although: if they are truly good questions, they could be!), but they should be close enough that a candidate would have no business being surprised by the real ones. * Provide a detailed breakdown of your interviewing process. Do you phone screen? How many times? Who staffs the phone screens? What kinds of questions get asked on them? Who delivers the in-person interviews? How long do they last? These are some of the questions real candidates have about interview processes. I don't understand why more companies don't just answer them up front. * Provide reference material for candidates. Don't point them to other people's interviewing guides! You know your jobs better than anyone else does... right? How about instead: what are the most popular books on the shelves at your team? (Bonus points: buy those books for candidates). What are some Github repositories you think represent really well-engineered software? What are some examples of really hard problems your team is still grappling with? I hired for years and years with a battery of over-the-top technical questions and a rolodex of personal contacts. Then my team and I had a crazy idea: we opened our whole interview process up, standardized it, and took pains to make it understandable to people with no experience in our field. What we learned was that there is a huge amount of underutilized talent out there that can't (because it's locked out due to jargon and poorly described requirements) or won't (because it's denied social permission) apply for jobs unless you go out of your way to bring them in. Many of these people are better than you are. At least, they were for me. Stop bloodying your forehead against the wall competing with Facebook and Google for people who --- if they can navigate the process you describe --- can get an offer from those companies any time they want.
szx 11y ago
The funny thing is that Asana is possibly the worst performing web app out of all the ones I use on a regular basis. I have a strong suspicion there's at least one or two O(n^2) algorithms hiding there that could use the same kind of attention and reasoning abilities they expect from their candidates.
- JonoBB 11y ago
  Yes! Honestly, they need to hire someone to fix the start up time of their app, because it's the slowest by far of any webapp that I use. That should be their first hiring priority.
  - pspeter3 11y ago
    It is one of our biggest hiring priorities and we are actively working on this.
    - srcmap 11y ago
      Why not ask questions or ask for solution about that in the hiring and interviewer process? You might just find folks who love/know how to solved that kind of problems to work for you. BTW, that is very trivial problem to solve for those who has done it.
- pspeter3 11y ago
  First, we're actively working on improving page load times. Second, having discovered issues with algorithmic complexity makes me question claims that they are not important for day to day work. What do you think?
  - szx 11y ago
    Algorithmic complexity is certainly important. Intuition and knowledge of (or ability to research) the pros and cons of existing algorithms are essential. However, I don't think you need to see a single line of code (on a whiteboard or not) in order to test for that.
sajid 11y ago
Disappointing. The links to Triplebyte and Stripe are far more informative.
- jacklionheart 11y ago
  Thanks for the feedback! What did you learn from those that yo u didn't see in the Asana one? - Jack from asana
p4wnc6 11y ago
I did an extensive set of interviews with Asana and did not enjoy the experience. After an initial screen, I was required to complete a fairly extensive take home data science problem that involved querying an AWS-hosted database, fitting a predictive model on that test data, then writing a report summarizing which factors in my model were most important and what else I might do. Considering that (a) some of the data in the database was erroneous, but when I alerted them about it they took a long time to respond and I had to just hack a work around, and (b) it was a huge time sink in an otherwise busy week for me, I was very proud of my solution. It was a simple random forest model, with no exploration of optimizing the parameters, and some simple entropy metrics for feature importance. I wrote nicely encapsulated SQLAlchemy for the database side, then modular sklearn and pandas code for the model fits and plots, including calibration curves in addition to accuracy. I put it all together into an 8 page TeX write up with plots. I got virtually no feedback, then after a long time I was asked to have a technical phone interview reviewing my submission that was with two data scientists simultaneously. They barely asked me anything about my code design. They asked a few questions about my choice of accuracy measures and entropy scores, but it was extremely hard to understand what they wanted to hear (why do companies still think that a multi-party phone call is a good use of time??). It was a major instance of "guess the teacher's password" which was a huge turnoff for me. Then they asked very vague, high-level questions about designing a news-feed-like interface, and how might you determine which articles are newsworthy on an individual basis. Again, super vague. I threw out all kinds of ideas about seasonality, correlation to major events, properties of your network, ... But nothing seemed interesting to them at all. They clearly wanted someone to recite some well-known stuff Facebook already used, but none of that was part of the job ad or even related at all. It was bizarre. After that, another mysterious block of time went by with no feedback, then I got rejected with no explanation. Later I learned that Asana has pivoted to focus on providing Agile junk for enterprise project management, so I was relieved to have dodged that bullet, but it was still a vague and time-wasting interview process, with so much magic "guess the teacher's password" nonsense.
- jacklionheart 11y ago
  Hi there -- I'm really sorry that you had such a negative experience. It sounds like we didn't honor how much time you'd put into the challenge, and that sucks. I'd be happy to share more feedback with you if you're still interested, though it seems like you've moved on happily. Feel free to reach out to jack@asana.com and we can talk more. Regardless, best of luck where you are now.
MicroBerto 11y ago
Maybe you could hire someone that will design you a mobile website? I'm not installing your app on my phone...
usaphp 11y ago
From the guide: "we ask candidates not to compile or run their code during this exercise, and not to refer to online resources" Seriously? You don't allow referring to online resources? Do you also unplug the internet connection for all of your existing programmers so they don't refer to online resources? The whole point of the interview is to see how you would perform at your job at the first place, creating an artificial job for an interview where you swap words in the array or solving some other stupid quiz + disconnecting you from online resources is just plain stupid in my opinion.
- SkidanovAlex 11y ago
  The very next sentence there is "Our goal is not to simulate day-to-day software development", so no, they probably do not unplug the internet connection for the existing programmers.
  - usaphp 11y ago
    Why don't they ask them to play soccer on the interview or see how fast a person can run, if they don't care if the candidate will perform well in their day-to-day software development?
the_cat_kittles 11y ago
i dont understand why you would even listen to them, their website is such a piece of shit- terrible performance, terrible ui. maybe their infrastructure is good, but i can tell you they absolutely suck at frontend js.
marknutter 11y ago
I find it funny that startups only implement these ridiculous hiring practices after they start to grow. Imagine if the founders had to quiz each other on algorithms before they agreed to do a startup in the first place. The first few hires at a startup are arguably the most important, yet they don't go through the bullshit that later stage startups put potential employees do.
- jacklionheart 11y ago
  > I find it funny that startups only implement these ridiculous hiring practices after they start to grow Hmm, I'm curious what you're assuming! At Asana, at least, our first hires went through many of the same questions that interviewers today go through, but we were just a lot less systematic about our evaluation and less scrupulous about accidentally testing for knowledge/context rather than ability. The intention of this guide was to make the interview /less/ bullshit-y, by giving people enough grounding to not be thrown off by unexpressed expectations.
Xyik 11y ago
Sigh, more marketing. Sorry, but at the end of the day any company that does technical interviews evaluates candidates the same ways and asks the same type of questions, having an interview guide that says things like "Instead, let’s open a dialogue. Let’s solve problems together and see what we can learn in the process. Let’s have fun!" is just trying to get more people to apply. And I'm not slamming algorithms or technical interviews, but its time companies stop trying to dress themselves and say it how it is.
- jacklionheart 11y ago
  JFYI, that's not accurate. We've been sending this to candidates for months; the genuine impetus was to try to put all candidates on a more level and accurate playing field so that we can make better hires. That's not to say it's not self-serving; of course we benefit from making more/better hires. But it's not just marketing.
deleted 11y ago
[deleted]
andrewstuart 11y ago
- smart - gets things done - able to actively engage in discussion about software development - works hard - wants to work here doing this job - loves to learn - not overly dogmatic The rest, meh.
Jormundir 11y ago
I recently interviewed with Asana, and unfortunately would review their process as the opposite of what they're going for. The first sentence is not far off from what their process is. My interviews with them were composed of one helpful database problem, after which they explained how they designed their production database, followed by a bunch of frivolous algorithms problems. I did not receive an offer from them, so take what I say with a grain of salt. Asana seemed like a company that has some great engineers, and runs well in general. I would, however, like to provide some constructive criticism for their interview process. 1. Their engineers can use some training on how to interview. Several of them came into the room noticeably anxious. Hearing what the problems were was easy, but communication was very difficult when it came to figuring out what kind of answer they were actually looking for. 2. The questions they use are very academic, which to me means they are mental exercises lacking practical grounding. As an interviewer, it's very uninspiring to have to solve academic problems without getting a peak into the business' real problems. 3. The whole process wasted way too much time. Obviously I wouldn't have cared as much if they had given an offer, but I think it's important to be conscious of this nonetheless. My suggestion would be to pick topics for interviewers to cover, and cut out the repetition of the problems. Plan a process that will lead to a decision with one shorter visit, be respectful of peoples' time. I hope that helps. I received more offers I'm excited about, and I hope to see the company succeed from the outside.
loycombinate 11y ago
There are many different types of engineers This guide is for software engineers
whitenoice 11y ago
How do these question align with the work Asana is doing? Side note: The blog site performance degrades as you keep scrolling down.
sulam 11y ago
I have interviewed (phone screened) at Asana. It was delightful. I really liked the people I met there and enjoyed the problem I worked through over the phone. It really did feel collaborative and like we were solving a problem together just as software engineers do when they're not in this artificially combative environment we often create when interviewing. Regarding the problem, I didn't have the best approach out of the gate. In fact, I had a vague memory of the right approach ("I seem to recall it uses two data structures, and if I really stretch I think it was X and Y, but I don't remember the details.") That made it harder to get to the final solution. The interviewer was very good at at talking things through with me in a way that didn't seem like they were frustrated or otherwise grumpy that I didn't know this particular problem cold. They apparently thought the results were encouraging enough to move to an onsite, but I got an offer from my current employer (where I am working with close personal friends) and had to pass on the chance to find out what that would be like. All in all I think Asana is probably a great place to work. I also like the product, although it seems like you need a whole team to adopt it to make it sticky.
bpp 11y ago
I had a really stellar interview experience at Asana (and, full disclosure, I didn't get an offer). What really stood out was the pages of notes that the recruiter sent me before inviting me to apply again in a few months. I had just been through many on-site interviews at many companies, and no one came close to providing the level of feedback that Asana did. The document that I was sent can't have been too far off from the unedited notes that the interviewers shared with each other in their debrief. It really spoke to Asana's commitment to transparency and helping develop people - even those they didn't want to hire. I'm happy where I am now, but based on this experience, I would absolutely apply again in the future.
golergka 11y ago
Why does everyone love algorithms and data structures of all the CS topics so much? I would like to be asked about covariance and contravariance, LALR parsing or some basic statistics for once. But more importantly, I would love to be asked about CS topics that arise every day in development: code organization. How many times do you get a new requirement that makes you throw all previous assumptions (that an architecture was naively built upon) out of the window? When it turns out that module A and B, which were completely different and didn't even know about each other, now need each other's data? Yes, this situation arises when original architecture wasn't thought through enough — and we all were guilty of this at one point or another. Now, what a developer does in that situation is much more important than whether he remembers what complexity what kind of hash table (with all the chaining and hashing types) is. Does he just hack it so it works, creating a lot of fun for future maintainer? Does he decide to spend 2 days to refactor the whole system into a new architecture? Or does he find a balance somewhere in between?
vain 11y ago
Their subscription pop up at the bottom of the page with a close button that does nothing only makes me sure I don't want to work for them.
krosaen 11y ago
I like the idea behind this but the actual guide is pretty thin: https://asana.com/eng/interview-guide https://asana.com/eng/interview-guide would be great to see a more detailed guide covering the concepts they like to see master of and problem solving skills they are looking for.
nanoojaboo 11y ago
I love that Asana missed the opportunity that Slack captured.
hans 11y ago
this place has so much cash, they may as well hire trial by fire, create an onboarding experience for serious candidates, morph them to your liking or let them go, stop guessing with goofball interview theater.

227 points by pspeter3 11y ago

swagv 11y ago

When does a blog post become a "guide"?

Much more interesting is the guide that this blog post mentions at https://asana.com/eng/interview-guide https://asana.com/eng/interview-guide.

toomuchtodo 11y ago
Yes! Would be interested in seeing how much coding they ask for when interviewing for devops or ops positions. Some orgs require only scripting, some go so far as to want application engineers who also know everything about AWS for devops/ops roles. Disclaimer: I already asked via their google form for this information to be added in their docs.
- pspeter3 11y ago
  I haven't followed the recent updates to our interview process closely but we traditionally looked for general knowledge over specific knowledge. I'm not sure how much that has changed recently though. Edited In Response To Parent Edit: Thanks for asking! We should definitely make it clearer if there are differences per role.
  - toomuchtodo 11y ago
    So very awesome of you. Thank you for the reply!
  - neofrommatrix 11y ago
    "looked for general knowledge over specific knowledge" - incidentally, I was rejected because I could not answer (to the interviewer's satisfaction) how to implement an in-memory LRU cache. I made some good recommendations but the interviewers were expecting a very specific answer which exactly matched http://www.programcreek.com/2013/03/leetcode-lru-cache-java/ http://www.programcreek.com/2013/03/leetcode-lru-cache-java/
    - riyadparvez 11y ago
      > looked for general knowledge over specific knowledge This is one commonly thrown BS regarding interviews. At the end of the day it is all about one-dimensional usual algorithmic questions. Regarding LRU cache, I think this is one of less crazy interview questions. In one phone interview, I had to solve a DP problem, code it perfectly and pass all the test-cases on HackerRank in less than twenty minutes. I am not certain how many developers out there can pass such interviews without months of preparation in such situations. Tech interviews are basically programming contests. I am not against programming contests or algorithmic questions. But it seems the interview questions are getting crazier day by day.
twphonebillsoon 11y ago
I don't really see whats interesting about this either way. Lots of places you interview at tell you what the interview is going to be like and what you are expected to be familiar with. This is just 'write code and we'll be testing you on data structures and algorithms!' There's some flowery language there about having a genuine desire to want to hire you unlike those 'other evil companies!'... sounds like the same shit pretty much every other company does to me.
- deleted 11y ago
  [deleted]
- riyadparvez 11y ago
  I had also the same impression. I think one of the best approaches is let the best engineers at the company go through same interview process. If they can't get pass through the hiring bar of the company, then maybe that company should re-think their hiring process.
  - th0raway 11y ago
    My current company has a very similar interview style, and I later learned that I was pretty close to not being hired because I didn't do quite as well as one interviewer wanted on a coding challenge: I ran out of time. But what I also learned is that the interviewer had never solved the problem in the language I used! I had one of our most senior engineers, who has worked in this language's compiler, to try to solve the exercise. Instead of 40 minutes, it took him three hours! If a candidate is going to interview in a language, for the love of god, have as a prereq that the interviewer is actually capable of doing the exercise in that language.
biot 11y ago
Why is it more interesting? The purpose of the blog post is to explain the rationale for the guide itself and directly links to it. I find it just as interesting to read about why they're doing it.

trjordan 11y ago

> 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. Every time interviewing comes up, I have this funny feeling about letting people look things up vs. whiteboarding them out. Reading this finally broke something loose: Coding in interviews should be as hard as the hardest coding you'll do on the job. Heck, anything in the interview should be about how you do things when the job is hard. Now, this doesn't mean under stress. That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. They'll pass over people who are exceptionally good at searching / synthesizing information. They'll ding people who focus on tightening the iteration time as a way of learning faster. But that's OK. They've probably built a culture where that kind of person thrives, and they're trying to find more engineers who will thrive at Asana.

vonmoltke 11y ago
> That may come naturally. But the difference between good and great engineers is decided when the task is hard and information is sparse. Asana is explicitly selecting for people who are going to reason about things from first principles and try to get it right the first time. I admire that they're owning up to that. > They'll pass over people who are exceptionally good at searching / synthesizing information. I also admire that they are upfront about this, but the attitude in general rubs my classical engineering self the wrong way. "[R]eason[ing] about things from first principles" is not the same thing as having those first principles memorized. That was one thing my undergrad taught me repeatedly. Engineering isn't about memorizing formulas, it is about learning what those formulas mean, how to use those formulas, and when to apply them to a task at hand. Software engineering should be no different. Expecting people to solve hard and novel problems with no resources whatsoever is ludicrous.
- thedufer 11y ago

pklausler 11y ago

> We design our interview questions to see how engineers work through technical problems they don’t know the answer to yet. That's the way to do it, I think. In my own technical interviews, I pose (relatively) simple questions that require some problem analysis, a strategy discussion, and then some coding and testing, with a goal of testing aptitude for basic programming abilities like modularization, indirection, recursion, defensive programming, unit testing, etc. I keep things interactive and collaborative and see how much the candidate can do for themselves.

p4wnc6 11y ago
The problem is that Asana seems to have preconceived ideas of what answers are supposed to look like, but the questions are vague and open-ended enough that even very good candidates can give good answers that simply diverge from the manner of thinking that the Asana question designer had in mind. If the question has a well-defined answer, then this is good. If you are asking questions that the candidate "doesn't know the answer to" merely as a parochial side effect of the question's vagueness and the vast space of possible good approaches, then you're really only screening for people who happen to think about things the same way you already do, and thus are good at guessing what you want to hear. I'd argue that this is very bad in terms of diversity of thought.
- pklausler 11y ago
  I use problems with multiple acceptable solutions and easy tests of correctness -- i.e., it's obvious whether or not the approach is sound and the code works. For example, write a function that determines whether two rectangles on a display overlap, given the coordinates of their corners. Solving it requires the ability to analyze the problem and describe the conditions, the ability to code a simple Boolean predicate, and some aptitude for checking boundary cases and writing unit tests. I have others; what they have in common is that they're really easy problems for great programmers, and well within the limits of a 45-minute technical interview for competent coders, and good at exposing candidates who lack some basic skills.
- jacklionheart 11y ago

avoutthere 11y ago

> Our goal is not to simulate day-to-day software development... I don't understand this. Why do they not want to see how well a candidate performs the tasks that they will be expected to perform on the job? Does this not result in them selecting for the wrong set of skills/knowledge?

gkop 11y ago
Plus they're using this goal to justify not letting you run your code during the interview, which prohibits a "try it and see" problem-solving approach. Asana engineering team, what's wrong with "try it and see"?
- rmah 11y ago
  You're kidding, right?
  - gkop 11y ago
    Not kidding! "Try it and see" is a legitimate problem-solving approach.

deleted 11y ago

[deleted]

orangetabbycat 11y ago

I had an onsite interview for a new grad engineering position at Asana recently. It's true that they test you on technical problems you don't know the answer to; sometimes it seems like they tested me on technical problems that had no answer. One of their interviewers, who was in charge of both conducting a one-on-one with me and explaining the programming questions to me, was very friendly but also had a hard time clarifying any of his questions for me. I didn't really understand him and it was obvious from his facial expressions that he believed that his explanations had sufficed from the very beginning. The questions were either too vague and could be approached from many different directions or were so specific that it was obvious the right solution would have to be found in an epiphany-like "aha!" moment of mathematical understanding. I was able to answer and program most of the questions. I have to say that I was really happy to receive feedback following my interview, which no other company did. My advice to Asana: Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) Of course, that's just my experience. I ended up finding a good position somewhere else and think Asana's interviews were some of the best ones I had the honor of failing.

riyadparvez 11y ago
> Don't let any one interviewer dominate the experience of the interviewee (especially if you may have suspicious that the interviewer may be overly didactic or has difficulty explaining things.) I think this a common problem. Many companies let a single interviewer has huge influence on hiring decisions. What if the interviewer himself/herself had some bias that s/he wasn't aware of?

swanson 11y ago

> “We want every candidate who comes into an interview with us to feel prepared and confident.” Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare. This seems like it could be improved. You value learning -- so give candidates something to learn and see if they can do it. > Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests! I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard.

jacklionheart 11y ago
Hey -- I work at Asana. Great idea! Took a task to add more resources to learn from to the doc. > I feel very confident in doing day-to-day software development. I do not feel as confident speaking about abstract hypotheticals in front of a whiteboard. Hmm, the way we framed that is confusing. Thanks for the feedback! To be sure, our goal is to accurately assess what your day-to-day contributions would be like, and simulation is a really good way of eliminating accidental bias in that process. To that end, we do have every engineer submit actual code during the interview process, and we generally avoid white-board programming in favor of higher-level discussions (that may also use the whiteboard). But perfect simulation is possible (and time-consuming), so we've tried to focus on the higher order bits.
- insulanian 11y ago
  What's your primary tech stack?
  - ktothemc 11y ago
    We're in the middle of rewriting our stack to look like this: - TypeScript web code - Using React - Connecting to a custom, to-be-opensourced reactive datastore written in Scala called LunaDb: https://blog.asana.com/2015/05/the-evolution-of-asanas-luna-framework/ https://blog.asana.com/2015/05/the-evolution-of-asanas-luna-... - Using to Amazon RDS (hosted MySQL) and Redis as our primary backing stores - Running on top of kubernetes, docker, AWS

dvt 11y ago

I came looking for some new or interesting way of doing tech interviews, but it's the same typical SV bullshit. Lol: "Hashes, sets, heaps, binary trees, linked lists, all the usual suspects." Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. I'm a strong believer that there are two primary ways of testing someone's coding ability: 1) Open-source, or otherwise public, contributions. 2) Real-world take-home assignments. I've opted out of interviewing people because it's such a miserable experience. I guess I'm just not a sadist that enjoys watching some poor 22-year old squirm in his chair because he can't remember what the upper bound on the insert operation of a red-black tree is. What a joke.

ryanSrich 11y ago
On the flip side, Asana clearly indicates that they don't test candidates on day to day development. This is good, because now I know I would never work for Asana. Those interested in non-applicable CS problems would probably love Asana. Although I'm not sure how any of this relates to a pretty basic project management app.
- dvt 11y ago
  Yeah, exactly! It's like fucking insane how these companies hype themselves up. All you are is a glorified to-do list, calm down, Asana.
  - Aeolun 11y ago
    It is a very, very fancy to do list though. To be honest, it was more usable when it was just released. The simplicity was one of the strong points.
- mpd 11y ago
  > This is good, because now I know I would never work for Asana. I've actually used their product, and I'm in the same boat as you because of it.
deleted 11y ago
[deleted]

aiokos 11y ago

Ah, got to love the subscription pop-up with a close button that doesn't work. A timeless web design principle. Aside from that, when will we get past the requirement for data structure knowledge for positions that center around web design? Data structure knowledge is available at my fingertips throughout the work day. Why must I memorize implementation boilerplate for an interview?

lostcolony 11y ago

Do these companies not recognize that moment of cognitive dissonance that surely -must- come when, as they're faced with "how do we determine if someone will be productive coming here" decide "I know; let's ask a bunch of questions we don't expect them to know! And then, let's provide a study guide so that they -can- cram before the test and come in and show they know it!" I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve, but to implicitly admit it, -and- to also acknowledge that it isn't something you expect people to have off the top of their head by providing a study guide? What are you trying to measure?

mandeepj 11y ago
I wish they (asana) listed down some of their real problems along with few possible solutions. A candidate can provide his solution or recommend one of their solutions. I think this approach can lead to a nice discussion where both parties can get to know each other.
- Tiks 11y ago
  Have you tried this? :) https://codefights.com/bots/botasana https://codefights.com/bots/botasana
  - fapjacks 11y ago
    I like how they slip in "Oh, all you have to do is parse HTML with regex" on the last problem.
    - so0k 11y ago
      for the HTML parsing - I was able to pass all the test cases using a stack (push the tags when they open and pop them as they close). I was doing zero validation as the challenge was to take valid html. (I didn't verify that the proper tag was being closed, I knew I'd get out of bound errors due to this, but it should work for valid html) I was using a string builder to eat the input as I had parsed it... but I got an error on submitting my result - it gave "unexpected termination" even when I had replicated the "unexpected termination" error with a custom test case and caught the error - I still got an unexpected termination error when submitting - sigh - maybe it's related to using C# for the challenge... overall not so hard though...

sudo_bang_bang 11y ago

I tried interviewing with Asana and they rejected me on the basis that I didn't have a computer science degree. For the record, I've built apps that have generated millions in revenue and I have many years of experience. If they are trying to be meritocratic and community friendly with this, they should change that aspect of their culture to reflect that.

meritt 11y ago
Can you blame them? That CS degree provides essential knowledge when it comes to solving some of the world's most complex problems: to-do lists.
andrewstuart 11y ago
Remember also that Steve Jobs, Larry Ellison and Bill Gates did not have computer science degrees. They need to keep people of that calibre out of their ranks - you know, the non achievers who don't understand computers.
dbt00 11y ago
I just accepted a position at Asana, and I don't have a CS degree. Are you sure you're correctly attributing your non-offer here? (Note I don't call it a failure. Hiring is a weighted RNG -- false negatives are common.)
Aeolun 11y ago
Just the fact that you've built (worked on?) apps that generated millions of revenue is not a measure of compatibility/competence, nor is experience. Might be different if they actually said they didn't want you because of a lack of CompSci degree though.

tptacek 11y ago

I appreciate the sentiment behind documents like this, but, Asana, you can do better. When you do, you'll find it gets easier to hire people, and, perhaps counterintuitively, the quality of your hires will go up. Specifically: It's clear from the tone that you're trying to mitigate the hostility and unfriendliness of the conventional programmer interview. Great! But you need to do more than superficially adjust your tone. What this document describes is literally the circa-1999 software developer interview, in almost every detail --- the fuzzily described coding question, the "algorithm and data structures" interview, the design review. Everyone has heard of interviews that pointlessly refuse candidates the opportunity to consult Internet references, like every working programmer does every time they code anything ever. But your process goes a step further: you won't even allow candidates to compile their code. How can this possibly be helpful to your process? The most alienating and hostile aspect of the conventional job interview is on-the-spot whiteboard programming. You shouldn't have programmers write code in interviews at all, if you can avoid it; instead, take a week or two and design programming questions that candidates can do at home, on their own schedule, in their own surroundings. But if you're going to make people code in an environment that is utterly unlike the one professionals actually work in, the onus is on you to do everything you possibly can to mitigate the performance penalty you're imposing. Why not, instead of coming up with crazy rules like "no running your own code allowed", point your creativity in the opposite direction and find ways to get candidates to be more at ease with writing code with someone looking over their shoulder? Here are some things you can do right now to make your interviewing guide actually helpful to candidates: * Provide sample questions. They do not need to be the ones you're asking in real interviews (although: if they are truly good questions, they could be!), but they should be close enough that a candidate would have no business being surprised by the real ones. * Provide a detailed breakdown of your interviewing process. Do you phone screen? How many times? Who staffs the phone screens? What kinds of questions get asked on them? Who delivers the in-person interviews? How long do they last? These are some of the questions real candidates have about interview processes. I don't understand why more companies don't just answer them up front. * Provide reference material for candidates. Don't point them to other people's interviewing guides! You know your jobs better than anyone else does... right? How about instead: what are the most popular books on the shelves at your team? (Bonus points: buy those books for candidates). What are some Github repositories you think represent really well-engineered software? What are some examples of really hard problems your team is still grappling with? I hired for years and years with a battery of over-the-top technical questions and a rolodex of personal contacts. Then my team and I had a crazy idea: we opened our whole interview process up, standardized it, and took pains to make it understandable to people with no experience in our field. What we learned was that there is a huge amount of underutilized talent out there that can't (because it's locked out due to jargon and poorly described requirements) or won't (because it's denied social permission) apply for jobs unless you go out of your way to bring them in. Many of these people are better than you are. At least, they were for me. Stop bloodying your forehead against the wall competing with Facebook and Google for people who --- if they can navigate the process you describe --- can get an offer from those companies any time they want.

szx 11y ago

The funny thing is that Asana is possibly the worst performing web app out of all the ones I use on a regular basis. I have a strong suspicion there's at least one or two O(n^2) algorithms hiding there that could use the same kind of attention and reasoning abilities they expect from their candidates.

JonoBB 11y ago
Yes! Honestly, they need to hire someone to fix the start up time of their app, because it's the slowest by far of any webapp that I use. That should be their first hiring priority.
- pspeter3 11y ago
  It is one of our biggest hiring priorities and we are actively working on this.
  - srcmap 11y ago
    Why not ask questions or ask for solution about that in the hiring and interviewer process? You might just find folks who love/know how to solved that kind of problems to work for you. BTW, that is very trivial problem to solve for those who has done it.
pspeter3 11y ago
First, we're actively working on improving page load times. Second, having discovered issues with algorithmic complexity makes me question claims that they are not important for day to day work. What do you think?
- szx 11y ago
  Algorithmic complexity is certainly important. Intuition and knowledge of (or ability to research) the pros and cons of existing algorithms are essential. However, I don't think you need to see a single line of code (on a whiteboard or not) in order to test for that.

sajid 11y ago

Disappointing. The links to Triplebyte and Stripe are far more informative.

jacklionheart 11y ago
Thanks for the feedback! What did you learn from those that yo u didn't see in the Asana one? - Jack from asana

p4wnc6 11y ago

I did an extensive set of interviews with Asana and did not enjoy the experience. After an initial screen, I was required to complete a fairly extensive take home data science problem that involved querying an AWS-hosted database, fitting a predictive model on that test data, then writing a report summarizing which factors in my model were most important and what else I might do. Considering that (a) some of the data in the database was erroneous, but when I alerted them about it they took a long time to respond and I had to just hack a work around, and (b) it was a huge time sink in an otherwise busy week for me, I was very proud of my solution. It was a simple random forest model, with no exploration of optimizing the parameters, and some simple entropy metrics for feature importance. I wrote nicely encapsulated SQLAlchemy for the database side, then modular sklearn and pandas code for the model fits and plots, including calibration curves in addition to accuracy. I put it all together into an 8 page TeX write up with plots. I got virtually no feedback, then after a long time I was asked to have a technical phone interview reviewing my submission that was with two data scientists simultaneously. They barely asked me anything about my code design. They asked a few questions about my choice of accuracy measures and entropy scores, but it was extremely hard to understand what they wanted to hear (why do companies still think that a multi-party phone call is a good use of time??). It was a major instance of "guess the teacher's password" which was a huge turnoff for me. Then they asked very vague, high-level questions about designing a news-feed-like interface, and how might you determine which articles are newsworthy on an individual basis. Again, super vague. I threw out all kinds of ideas about seasonality, correlation to major events, properties of your network, ... But nothing seemed interesting to them at all. They clearly wanted someone to recite some well-known stuff Facebook already used, but none of that was part of the job ad or even related at all. It was bizarre. After that, another mysterious block of time went by with no feedback, then I got rejected with no explanation. Later I learned that Asana has pivoted to focus on providing Agile junk for enterprise project management, so I was relieved to have dodged that bullet, but it was still a vague and time-wasting interview process, with so much magic "guess the teacher's password" nonsense.

jacklionheart 11y ago
Hi there -- I'm really sorry that you had such a negative experience. It sounds like we didn't honor how much time you'd put into the challenge, and that sucks. I'd be happy to share more feedback with you if you're still interested, though it seems like you've moved on happily. Feel free to reach out to jack@asana.com and we can talk more. Regardless, best of luck where you are now.

MicroBerto 11y ago

Maybe you could hire someone that will design you a mobile website? I'm not installing your app on my phone...

usaphp 11y ago

From the guide: "we ask candidates not to compile or run their code during this exercise, and not to refer to online resources" Seriously? You don't allow referring to online resources? Do you also unplug the internet connection for all of your existing programmers so they don't refer to online resources? The whole point of the interview is to see how you would perform at your job at the first place, creating an artificial job for an interview where you swap words in the array or solving some other stupid quiz + disconnecting you from online resources is just plain stupid in my opinion.

SkidanovAlex 11y ago
The very next sentence there is "Our goal is not to simulate day-to-day software development", so no, they probably do not unplug the internet connection for the existing programmers.
- usaphp 11y ago
  Why don't they ask them to play soccer on the interview or see how fast a person can run, if they don't care if the candidate will perform well in their day-to-day software development?

the_cat_kittles 11y ago

i dont understand why you would even listen to them, their website is such a piece of shit- terrible performance, terrible ui. maybe their infrastructure is good, but i can tell you they absolutely suck at frontend js.

marknutter 11y ago

I find it funny that startups only implement these ridiculous hiring practices after they start to grow. Imagine if the founders had to quiz each other on algorithms before they agreed to do a startup in the first place. The first few hires at a startup are arguably the most important, yet they don't go through the bullshit that later stage startups put potential employees do.

jacklionheart 11y ago
> I find it funny that startups only implement these ridiculous hiring practices after they start to grow Hmm, I'm curious what you're assuming! At Asana, at least, our first hires went through many of the same questions that interviewers today go through, but we were just a lot less systematic about our evaluation and less scrupulous about accidentally testing for knowledge/context rather than ability. The intention of this guide was to make the interview /less/ bullshit-y, by giving people enough grounding to not be thrown off by unexpressed expectations.

Xyik 11y ago

Sigh, more marketing. Sorry, but at the end of the day any company that does technical interviews evaluates candidates the same ways and asks the same type of questions, having an interview guide that says things like "Instead, let’s open a dialogue. Let’s solve problems together and see what we can learn in the process. Let’s have fun!" is just trying to get more people to apply. And I'm not slamming algorithms or technical interviews, but its time companies stop trying to dress themselves and say it how it is.

jacklionheart 11y ago
JFYI, that's not accurate. We've been sending this to candidates for months; the genuine impetus was to try to put all candidates on a more level and accurate playing field so that we can make better hires. That's not to say it's not self-serving; of course we benefit from making more/better hires. But it's not just marketing.

deleted 11y ago

[deleted]

andrewstuart 11y ago

- smart - gets things done - able to actively engage in discussion about software development - works hard - wants to work here doing this job - loves to learn - not overly dogmatic The rest, meh.

Jormundir 11y ago

I recently interviewed with Asana, and unfortunately would review their process as the opposite of what they're going for. The first sentence is not far off from what their process is. My interviews with them were composed of one helpful database problem, after which they explained how they designed their production database, followed by a bunch of frivolous algorithms problems. I did not receive an offer from them, so take what I say with a grain of salt. Asana seemed like a company that has some great engineers, and runs well in general. I would, however, like to provide some constructive criticism for their interview process. 1. Their engineers can use some training on how to interview. Several of them came into the room noticeably anxious. Hearing what the problems were was easy, but communication was very difficult when it came to figuring out what kind of answer they were actually looking for. 2. The questions they use are very academic, which to me means they are mental exercises lacking practical grounding. As an interviewer, it's very uninspiring to have to solve academic problems without getting a peak into the business' real problems. 3. The whole process wasted way too much time. Obviously I wouldn't have cared as much if they had given an offer, but I think it's important to be conscious of this nonetheless. My suggestion would be to pick topics for interviewers to cover, and cut out the repetition of the problems. Plan a process that will lead to a decision with one shorter visit, be respectful of peoples' time. I hope that helps. I received more offers I'm excited about, and I hope to see the company succeed from the outside.

loycombinate 11y ago

There are many different types of engineers This guide is for software engineers

whitenoice 11y ago

How do these question align with the work Asana is doing? Side note: The blog site performance degrades as you keep scrolling down.

sulam 11y ago

I have interviewed (phone screened) at Asana. It was delightful. I really liked the people I met there and enjoyed the problem I worked through over the phone. It really did feel collaborative and like we were solving a problem together just as software engineers do when they're not in this artificially combative environment we often create when interviewing. Regarding the problem, I didn't have the best approach out of the gate. In fact, I had a vague memory of the right approach ("I seem to recall it uses two data structures, and if I really stretch I think it was X and Y, but I don't remember the details.") That made it harder to get to the final solution. The interviewer was very good at at talking things through with me in a way that didn't seem like they were frustrated or otherwise grumpy that I didn't know this particular problem cold. They apparently thought the results were encouraging enough to move to an onsite, but I got an offer from my current employer (where I am working with close personal friends) and had to pass on the chance to find out what that would be like. All in all I think Asana is probably a great place to work. I also like the product, although it seems like you need a whole team to adopt it to make it sticky.

bpp 11y ago

I had a really stellar interview experience at Asana (and, full disclosure, I didn't get an offer). What really stood out was the pages of notes that the recruiter sent me before inviting me to apply again in a few months. I had just been through many on-site interviews at many companies, and no one came close to providing the level of feedback that Asana did. The document that I was sent can't have been too far off from the unedited notes that the interviewers shared with each other in their debrief. It really spoke to Asana's commitment to transparency and helping develop people - even those they didn't want to hire. I'm happy where I am now, but based on this experience, I would absolutely apply again in the future.

golergka 11y ago

Why does everyone love algorithms and data structures of all the CS topics so much? I would like to be asked about covariance and contravariance, LALR parsing or some basic statistics for once. But more importantly, I would love to be asked about CS topics that arise every day in development: code organization. How many times do you get a new requirement that makes you throw all previous assumptions (that an architecture was naively built upon) out of the window? When it turns out that module A and B, which were completely different and didn't even know about each other, now need each other's data? Yes, this situation arises when original architecture wasn't thought through enough — and we all were guilty of this at one point or another. Now, what a developer does in that situation is much more important than whether he remembers what complexity what kind of hash table (with all the chaining and hashing types) is. Does he just hack it so it works, creating a lot of fun for future maintainer? Does he decide to spend 2 days to refactor the whole system into a new architecture? Or does he find a balance somewhere in between?

vain 11y ago

Their subscription pop up at the bottom of the page with a close button that does nothing only makes me sure I don't want to work for them.

krosaen 11y ago

I like the idea behind this but the actual guide is pretty thin: https://asana.com/eng/interview-guide https://asana.com/eng/interview-guide would be great to see a more detailed guide covering the concepts they like to see master of and problem solving skills they are looking for.

nanoojaboo 11y ago

I love that Asana missed the opportunity that Slack captured.

hans 11y ago

this place has so much cash, they may as well hire trial by fire, create an onboarding experience for serious candidates, morph them to your liking or let them go, stop guessing with goofball interview theater.