- 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.
Asana Engineering Interview Guide
81–90 of 152 posts
Re: Asana Engineering Interview Guide
#82I 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,…
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.
> 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.
Re: Asana Engineering Interview Guide
#83I 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.
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.
Re: Asana Engineering Interview Guide
#84Earlier quoted context omitted.
>It sounds like Asana wants to determine if people can do this kind of thing. Same for Facebook/Google/Apple/Microsoft/Amazon/etc that also use whiteboard interviews. Those types of companies value seeing candidates' thought process more than the final code of work-at-home test questions. There's a signal there in whiteboard interviews that can't be replicated by at-home tests. Whether that unique signal is valuable…
I am not disputing that it is possible to design serious, rigorous evaluations that somehow hinge on candidates not using their normal tools to answer programming questions. What I dispute is that anyone really does that. It is awfully easy to rationalize any hazing ritual with this sort of six- degrees- of- concurrency- and- formal- methods logic. But there's a simple observation to make about all these questions: t…
I think one thing often missed in these discussions is that the interviews that work best for AmaGooBookSoft are not necessarily the same as the interviews that work best for smaller companies.
I've interviewed at startups that have some of the best work-sample testing that I've ever seen - but I could immediately tell these systems wouldn't work well at larger companies.
There are entire companies devoted to helping people prepare for GooAmaBookSoft interviews. If any one of these companies standardized on a single interview for all candidates it would immediately turn into a situation like standardized testing in high school where students study to the test instead of learning the core material.
I guess my advice is that if you're a startup, take advantage of this! You can do things that don't scale. Interview in ways larger companies can't. Don't assume that the way these companies interview is the best for you.
Re: Asana Engineering Interview Guide
#85Sigh, 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 t…
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.
Re: Asana Engineering Interview Guide
#86Earlier quoted context omitted.
> let's provide a study guide so that they -can- cram before the test Did you look at the guide? I don't see anything you would be motivated to cram after reading through that other than to brush up on the "usual suspects" of data structures, but you should be doing that before any technical interview anyways IMO. Seems like the guide is mostly intended to give candidates an idea of what to expect during their interv…
Yes. Under "How To Prepare" - 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. I.e., "here, go study and cram for your quiz". If you expect people to know the data structures and algorithms off the top of their heads (because you believe that to be useful), then why tell them to prep? That's what boggles…
I couldn't have said it better myself. You really summed up how the job interview got so fucked up in our field.
Re: Asana Engineering Interview Guide
#87> 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…
No, they shouldn't be as hard as the hardest you'll do on the job, because what is hard on the job has nothing to do with the real issue with an interview: a 30-60 minute window between solution and problem statement.
I have been programming professionally for about two decades. Algorithms? Easy, there are a lot of papers, and The Art of Programming for that. Designing something completely novel? I'll be looking at it for a long time before I can trust it. Performance optimizations? I'll count cycles if I have to. A little bit of time fixes all of it.
So what is actually hard about programming? Making sure my system is observable, so that when there is a problem, I know what is going on within seconds, if not minutes. Building a system that self heals. Making API decisions that I will not rue in 6 months to a year. Helping a coworker figure out a more sensible architecture without turning it into a pissing contest, or having to pull rank.
How can I actually show ANY of the hardest things I'll do on the job in that short amount of time? I can't. In practice, I get my best salaries, where I am the most valued, either the second time around in a place, or when, either through someone on the inside or well know third party references tell the prospective employer what I can actually do.
I have worked with amazing people that I'd never refer to a company that is trying to do this google-derived interview style, because what really matters in that interview is first, the 10 second likeability, second, to read the cues on what the interviewer is thinking of what you are saying, so you can change course if he is not liking you, and third, the ability to think on your feet fast enough while you are getting the other two things done. Someone that takes 6 hours looking at a problem but comes back with an amazing, production-grade solution every time is not welcome there, because they will always get culled.
So the problem of the interviews Asana is describing is that they can cull some people, but there is no proof whatsoever that anything they are doing correlates at all with the things that really make a good developer. This is great through, as anyone using a better interviewing system will be able to get far better developers on the cheap, as all this SV companies that copy each other just chase the same style of candidate.
Re: Asana Engineering Interview Guide
#88I 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.
Re: Asana Engineering Interview Guide
#89Do 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…
> let's provide a study guide so that they -can- cram before the test Did you look at the guide? I don't see anything you would be motivated to cram after reading through that other than to brush up on the "usual suspects" of data structures, but you should be doing that before any technical interview anyways IMO. Seems like the guide is mostly intended to give candidates an idea of what to expect during their interv…
> other than to brush up on the "usual suspects" of data structures, but you should be doing that before any technical interview anyways IMO.
I think that most people need to do that to go through the normal interview today, but that it's bullshit and a symptom of how shitty interviews are.
Re: Asana Engineering Interview Guide
#90Earlier quoted context omitted.
The more concrete feedback is in the previous post (you commented on that one too). But I will elaborate here: On 8/4/15, I received a message from an Asana representative via Stack Overflow Careers. After a few back-and-forths discussing specifics about whether I was a good fit, I then agree to do the take-home test. I received the take home test on 8/7/15. I emailed back on 8/8/15 with a verifiable error in a times…
After that, the interviewers asked the questions about how to develop a news feed ranking algorithm at a super vague, high level. I spoke about how you would need to account for seasonality or cyclic effects -- e.g. election news would clearly be ranked higher in newsworthiness when approaching important elections, or the same idea for sports-related articles, etc. I talked about trying to determine which news articl…
Yep, I'm that Jack. I remember you now. Thanks for the clear
picture of what it's like to be on the candidate side.
Efficiency is clearly a goal, and we clearly failed here given that it took us a week to get back to you after the phone interivew. I do think your interview was an outlier in that regard, but that doesn't excuse it.
Re: the questions themselves, although I don't agree with your characterization of what's going on or what we're looking for, I definitely think there's a lot of room to improve on our data-science screening. I'll send you an email with more re: what specifically came up in your interview that made us reject.
Again, thanks for taking the time to share this really explicit feedback.
(For the record, I don't really know what you're referring to re: Asana and Agile.)