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