This article doesn't actually have much interesting content. It's pretty typical high-level boilerplate, to my eyes.
I'd be more interested in the actual content of the interviews. Instead of simply writing "three hours of technical interviews and one or more of other" it would have been helpful to see what the technical interviews might consist of.
For example, after reading this I have no idea if Strava's technical interviews are "implement X on the whiteboard", where X is something out of a CS textbook, or if there is any actual engineering content to them, or a mix of both.
Howdy, author here! When someone is getting ready to come onsite, we give the more detailed information about what the onsite will look like, as this varies team by team. Our iOS and Android interviews both do 90 minutes of pair programming. Roles that we're not hiring many people for typically do not have pair programming interviews.
But our focus in interviews isn't CS textbook experience. It's the types of things you actually need to know to do the job.
I'd be more interested in the actual content of the interviews. Instead of simply writing "three hours of technical interviews and one or more of other" it would have been helpful to see what the technical interviews might consist of.
For example, after reading this I have no idea if Strava's technical interviews are "implement X on the whiteboard", where X is something out of a CS textbook, or if there is any actual engineering content to them, or a mix of both.