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 simulation is a really good way of eliminating accidental bias in that process. To that end, we do have every engineer submit actual code during the interview process, and we generally avoid white-board programming in favor of higher-level discussions (that may also use the whiteboard). But perfect simulation is possible (and time-consuming), so we've tried to focus on the higher order bits.
- 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
Was expecting to then see a list of specific resources that a candidate could use to become prepared and confident. Instead, the guide provides a high-level overview of "algorithms", "data structures", and "modeling" and refers me to "HackerRank and Interviewing.io" for tips on how to prepare.
This seems like it could be improved. You value learning -- so give candidates something to learn and see if they can do it.
> Our goal is not to simulate day-to-day software development — where we read docs and write lots of tests!
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.