41–50 of 152 posts
> 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, re…
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…
> I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve What makes you think they are asking questions they know don't really relate to the sorts of problems you have to solve?
I'm not installing your app on my phone...
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…
It's like leaving money on the table. Someone needs to moneyball the crap out of this.
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…
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 interview.
Earlier quoted context omitted.
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…
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.
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.
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.
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.
Earlier quoted context omitted.
> I mean, it's bad enough to ask questions you know don't really relate to the sorts of problems you have to solve What makes you think they are asking questions they know don't really relate to the sorts of problems you have to solve?
As an interviewer at Asana, my favorite questions to ask are based on actual technical problems we have had to solve.
> Our goal is not to simulate day-to-day software development
You don't mean at all, you mean in its entirety (so you are leaving out the aspects you are less interested in, like reading stack overflow, and emphasizing the aspects you are more interested in, like reasoning about data structures). I think a lot of people on HN are getting hung up on that sentence, honestly. Thanks for the guide, though, considering something similar for Justworks.
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.
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?
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…
Here's how.
Some problems - particularly those involving concurrency - don't lend themselves well to the standard compile/test/run/printf mode of programming. The more difficult problems you'll run into require some semiformal reasoning about the underlying problem. When I sit down to solve these problems I'm doing more or less exactly what Asana is asking for. I'm not making my code compile. I'm not running tests - with high probability they'll pass even if my code is wrong.
Eventually I'll need to actually write code which compiles and runs. But if I skip the "think hard and make sure it's right" step (what Asana is asking for) I'll wind up with wrong code in production with errors that are nearly impossible to debug.
It sounds like Asana wants to determine if people can do this kind of thing.