I love that Asana missed the opportunity that Slack captured.
Asana Engineering Interview Guide
141–150 of 152 posts
Re: Asana Engineering Interview Guide
#142Earlier quoted context omitted.
I don't think anyone is arguing that you shouldn't ask candidates to prove domain specific knowledge as part of the hiring process. The issue is that typically people use proxies for proving the candidates have the skills they need for a job, and you should design the proxies to be as close to the job as possible. So if deriving log likelihood formula in high pressure, time limited situations, is a good proxy for the…
It sounds like they are trying to do exactly what you suggest: 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…
Absolutely nobody has suggested that formal reasoning about algorithms is a useless skill.
Re: Asana Engineering Interview Guide
#143Earlier quoted context omitted.
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…
Hopefully this thread's not too stale yet to escape notice.
I just wanted to add that the user above, Jack, absolutely made good on what he said.
He sent me some very well-written, extremely professional, and constructive feedback about my interview process. I am able to see a lot of things I can improve and it will help me for future interviews. I think it also highlights some things about the process that Asana can improve, and by all evidence of Jack's sincerity in the feedback, I believe Asana is very interested in ways of improving.
Don't let anyone say that all I do on Hacker News is grumble about open-plan offices... in this case I am expressing my sincere gratitude and appreciation for Jack's feedback.
If I had received this kind of response in a timely manner when Asana decided not to continue the interview process with me, I would have walked away with a significant positive feeling about interviewing with them.
Re: Asana Engineering Interview Guide
#144Earlier quoted context omitted.
In Java 8, collisions in Maps are stored in a tree structure so worst case is O(log n)
Is it a balanced tree? If not, worst case could still be O(n).
Haha, that would be an odd set of data indeed. I have no idea how they implement it but I hope I have made a point(I feel I have). I wouldn't be too impressed with an interviewer or interviewee arguing one side or the other about the complexity of "unspecified hashmap implementation".
Too clever by half.
Re: Asana Engineering Interview Guide
#145Earlier quoted context omitted.
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…
Wow, you really read way more into that than I would have. I barely even looked at the first bullet in the "How to Prepare" section. I suspect it's was just there for completeness and I think it's basically a given that people should brush up on technical interview-type questions before going into a technical interview. For me, the real meat of that section was in the 2nd and 3rd bullets! The 2nd bullet is telling pe…
Yeah, I have much less of a problem with those, as they're not "cram for this test" and instead "reflect upon what you already know/wish to know, so that you're prepared to voice it". That's useful advice if you're not used to interviewing, and worth pointing out.
Re: Asana Engineering Interview Guide
#146> 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?
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"?
You're kidding, right?
Re: Asana Engineering Interview Guide
#147Earlier quoted context omitted.
> Yeah, I spend most of my time fiddling with binary trees and hashes at the office, said no one ever. There are a lot of people agreeing with you so I guess I'm just the outlier here but I don't see why you would not want people to know about hashmaps/binary trees. Sure we don't normally have to implement them ourselves but I imagine most people use them all the time. Balanced binary trees are often used to implemen…
> Balanced binary trees are often used to implement Maps/Sets so by knowing what the time/space complexity of operations on them you should know how they behave. Knowing them off the top of your head also makes it easy to compare them to choose the optimal data structure for whatever it is you are doing. I don't see any virtue in knowing in-depth complexity analysis of any data structure off the top of your head. Sur…
I'm not even sure we are agreeing or disagreeing anymore. I don't like tricky algorithm questions. Well that's a lie, I like them but I don't think they are appropriate for interviews.
On the other hand, I don't feel like knowing the time/space complexity of data structures you would normally encounter in day to day coding to be "tricky". I wouldn't expect people to know about suffix trees or segment trees for example.
> Writing code is about building robust and scalable things. This involves planning and execution.
I completely agree! But I would argue that's why it's important to know your common data structures because otherwise how can you plan? I do find most interviews awful because of the time pressure which is completely unrealistic. On the other hand, if I'm looking at code my coworker wrote and ask them why they decided to use an array instead of a linked list, I would hope they have an answer.
Re: Asana Engineering Interview Guide
#148Earlier quoted context omitted.
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 s…
What's your primary tech stack?
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-... - Using to Amazon RDS (hosted MySQL) and Redis as our primary backing stores - Running on top of kubernetes, docker, AWS
Re: Asana Engineering Interview Guide
#149Earlier quoted context omitted.
It sounds like they are trying to do exactly what you suggest: 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…
Absolutely nobody has suggested that formal reasoning about algorithms is a useless skill.
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?
To me it sounds exactly like they want you to demonstrate some semi-formal reasoning about algorithms, and you think this is not a realistic representation of work. What do you think they mean, and what do you oppose?
Re: Asana Engineering Interview Guide
#150Do 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…
It is not really possible to cram for these interviews. No matter how much you cram, the process will usually tease out the real you, because a group of people will evaluate you and debate your performance at the end of it.
If you got in with cramming, you very likely would have gotten in without.
Not to mean otherwise; one should definitely prepare for the process, because interviews are competitive. There is no worthwhile competition on the planet where you would go without preparation. It is almost insulting to the ecosystem if you don't prepare.
But preparation is not cramming. Depending on your level of practice, you may end up memorizing some things, but that is different from cramming to "beat the process".
I make these observations based on my experience as someone who runs a successful bootcamp for interview prep (http://interviewkickstart.com) and being an early engineer and a hiring manager (Director of engineering) at Box prior to that.
We have seen that candidates who prepare well with the right mindset, are at a distinct advantage over those who don't. And those are also often the right candidates. If you are working on an important goal, I, as an engineering manager, want you to have prepared for it. Interviews/job are just another goal, and it better be important for you that you want a job here.
Hope this helps; not a popular perspective, but closer to reality in my experience.