Hacker News Reader

Comment by lostcolony | Hacker News Reader

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?

View on HN

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

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.

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

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.

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 people to reflect on their experiences and come prepared to discuss. This may be a no-brainer for some, but for those who don't have a lot of interview experience, I suspect it's easy to get caught up with the "what should I know" mentality and forget to spend a little time reconstructing the interesting projects and situations that they've navigated in your career. For most of us, only the most recent stuff tends to be fresh in our minds.

The 3rd bullet emphasizes that you should come prepared to evaluate them. Again, perhaps a no-brainer for most experienced candidates, but it's nice to see the interviewers acknowledging that this is a two-way evaluation and encouraging candidates to be sure they're making the right choice.

While it's unusual for candidates to show up unprepared for technical questions, I've seen many candidates show up completely unprepared to discuss their experiences or ask questions that will help them evaluate the position/team/company/manager.

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.

I couldn't have said it better myself. You really summed up how the job interview got so fucked up in our field.

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

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.

Have you tried this? :) https://codefights.com/bots/botasana

I like how they slip in "Oh, all you have to do is parse HTML with regex" on the last problem.

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

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 (???).

I'm assuming it's a reference to http://stackoverflow.com/a/1732454

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

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.

Absolutely and thanks for the advice. I think we should change that sentence. Looking forward to the one from Justworks!

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.

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.

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

Reply on news.ycombinator.com