5 ms·

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

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...
    - dvt 11y ago
      God, I really hope they grasp the stupidity of using regular expressions to parse an irregular language. Implementing a very simple HTML parser takes at least a half-dozen man hours; seeing that question honestly makes Asana seem like amateur hour, and I've had to do some pretty stupid shit in my time. Snapchat, for example, had me solve Sudoku (???).
      - clentaminator 11y ago
        I'm assuming it's a reference to http://stackoverflow.com/a/1732454 http://stackoverflow.com/a/1732454
      - deleted 11y ago
        [deleted]
wdewind 11y ago
> 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?
- pspeter3 11y ago
  As an interviewer at Asana, my favorite questions to ask are based on actual technical problems we have had to solve.
  - wdewind 11y ago
    Yep this does not surprise me. Reading the guide it's clear to me that when you say: > 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.
    - pspeter3 11y ago
      Absolutely and thanks for the advice. I think we should change that sentence. Looking forward to the one from Justworks!
  - mattmanser 11y ago
    This generally means asking an obscure edge case which was only challenging because you can't Google it and so is a wildly inappropriate question for an interview.
bostonpete 11y ago
> 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 interview.
- lostcolony 11y ago
  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 my mind. Technical interviews relying on data structure and algorithmic questions started with a few companies (primarily Google) thinking it was a good way to gauge how strong a candidate was. For their purposes, it might have been. But as other companies started to cargo cult it (despite their businesses requiring far less algorithmic work), a cottage industry of interview prep sprung up (Cracking the Coding Interview, various sites intended to help you practice, etc). And since that then raised the bar (you were now competing against people who were -explicitly preparing- for these kinds of questions, and frequently would have seen the exact question they're being asked, or one akin to it), companies, such as Asana, decided "Okay, to be fair to everyone, we need to warn them that we're asking these kinds of questions and so they should prepare well in advance for them". Or...you could take a good hard look to decide if that's the skillset that is really important in your hires. If it is, you can probably give them legitimate business questions (which to be fair, Asana might do), as it will cover some of the same basics, but then giving the candidate access to Google, and access to querying and digging and figuring out how best to solve it might be a better gauge of their ability to solve those problems in the real world (unless for some reason they're going to be developing without access to technical resources and the internet). Or, you might find that your business actually requires people able to solve different problems, where implementing fisher yates is not the key technical deliverable, and so you can instead ask those kinds of questions, and see who can solve them based on what they know, and what they think to ask you during the interview.
deleted 11y ago
[deleted]
golergka 11y ago
Well, they did specify that they want people who are able and willing to learn, so it makes perfect sense.
hkmurakami 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!" That's exactly how the top management consulting firms operate their recruiting process. McKinsey even has a webinar for how to prepare for their interview and exactly what category of questions will be asked. The webinar is run by current associates. Their recruiting works pretty darn well.
- DoubleMalt 11y ago
  Not surprising, that a bullshit friendly recruiting process works when you hire for jobs that consist to a big part of producing bullshit ;) When the goal is to get people that actually solve problems ymmv. Btw. that is not a dig against management consultants. I honestly think the world needs bullshit.
soham 11y ago
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 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.

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...
  - dvt 11y ago
    God, I really hope they grasp the stupidity of using regular expressions to parse an irregular language. Implementing a very simple HTML parser takes at least a half-dozen man hours; seeing that question honestly makes Asana seem like amateur hour, and I've had to do some pretty stupid shit in my time. Snapchat, for example, had me solve Sudoku (???).
    - clentaminator 11y ago
      I'm assuming it's a reference to http://stackoverflow.com/a/1732454 http://stackoverflow.com/a/1732454
    - deleted 11y ago
      [deleted]

wdewind 11y ago

> 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?

pspeter3 11y ago
As an interviewer at Asana, my favorite questions to ask are based on actual technical problems we have had to solve.
- wdewind 11y ago
  Yep this does not surprise me. Reading the guide it's clear to me that when you say: > 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.
  - pspeter3 11y ago
    Absolutely and thanks for the advice. I think we should change that sentence. Looking forward to the one from Justworks!
- mattmanser 11y ago
  This generally means asking an obscure edge case which was only challenging because you can't Google it and so is a wildly inappropriate question for an interview.

bostonpete 11y ago

> 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 interview.

lostcolony 11y ago
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 my mind. Technical interviews relying on data structure and algorithmic questions started with a few companies (primarily Google) thinking it was a good way to gauge how strong a candidate was. For their purposes, it might have been. But as other companies started to cargo cult it (despite their businesses requiring far less algorithmic work), a cottage industry of interview prep sprung up (Cracking the Coding Interview, various sites intended to help you practice, etc). And since that then raised the bar (you were now competing against people who were -explicitly preparing- for these kinds of questions, and frequently would have seen the exact question they're being asked, or one akin to it), companies, such as Asana, decided "Okay, to be fair to everyone, we need to warn them that we're asking these kinds of questions and so they should prepare well in advance for them". Or...you could take a good hard look to decide if that's the skillset that is really important in your hires. If it is, you can probably give them legitimate business questions (which to be fair, Asana might do), as it will cover some of the same basics, but then giving the candidate access to Google, and access to querying and digging and figuring out how best to solve it might be a better gauge of their ability to solve those problems in the real world (unless for some reason they're going to be developing without access to technical resources and the internet). Or, you might find that your business actually requires people able to solve different problems, where implementing fisher yates is not the key technical deliverable, and so you can instead ask those kinds of questions, and see who can solve them based on what they know, and what they think to ask you during the interview.

deleted 11y ago

[deleted]

golergka 11y ago

Well, they did specify that they want people who are able and willing to learn, so it makes perfect sense.

hkmurakami 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!" That's exactly how the top management consulting firms operate their recruiting process. McKinsey even has a webinar for how to prepare for their interview and exactly what category of questions will be asked. The webinar is run by current associates. Their recruiting works pretty darn well.

DoubleMalt 11y ago
Not surprising, that a bullshit friendly recruiting process works when you hire for jobs that consist to a big part of producing bullshit ;) When the goal is to get people that actually solve problems ymmv. Btw. that is not a dig against management consultants. I honestly think the world needs bullshit.

soham 11y ago

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 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.