Right, so most of the problems in coding interviews that I've done are closer to CS111 trivia or ACM contest prep than an interview of your real-world abilities. Therefore, the best way to practice for that problem set is to practice doing problems like that problem set. There are plenty of resources online to help prepare for that.
That said, a surprising number of problems in life tend to reduce or closely resemble a fundamental data structure or computer science problem. (A lot of problems tend to approximate to graphs.) Additionally, even though most languages have support for fundamental data structures or algorithms in their standard libraries, knowing the performance implication of a double-for loop or understanding when to use a binary search tree compared to a B-Tree or RB Tree can make huge performance differences that real users care about.
This is where the value of the coding trivia interview sort-of comes in. It is the clearest indicator of ones skills in CS primitives you can have, and it does a good job in setting a quality bar within an engineering organization (at least everyone knows how to do these).
I personally think that more comprehensive and system-level interview questions are more valuable in assessing the technical abilities of a candidate in toto. In asking something like "How would you design an app like Instagram," you get a clearer sense of how the candidate thinks, how they approach problems, how much of their CS fundamentals they've retained, and, to some degree, what they're like to work with. It also allows more flexibility than the trivia-style interview. If you want to assess coding ability, you can ask them to write their idea of a feed algorithm. Conversely, if you want to assess their abilities as a lead, you can ask them about maintaining the system and finding the right team to build an app like this.
That said, a surprising number of problems in life tend to reduce or closely resemble a fundamental data structure or computer science problem. (A lot of problems tend to approximate to graphs.) Additionally, even though most languages have support for fundamental data structures or algorithms in their standard libraries, knowing the performance implication of a double-for loop or understanding when to use a binary search tree compared to a B-Tree or RB Tree can make huge performance differences that real users care about.
This is where the value of the coding trivia interview sort-of comes in. It is the clearest indicator of ones skills in CS primitives you can have, and it does a good job in setting a quality bar within an engineering organization (at least everyone knows how to do these).
I personally think that more comprehensive and system-level interview questions are more valuable in assessing the technical abilities of a candidate in toto. In asking something like "How would you design an app like Instagram," you get a clearer sense of how the candidate thinks, how they approach problems, how much of their CS fundamentals they've retained, and, to some degree, what they're like to work with. It also allows more flexibility than the trivia-style interview. If you want to assess coding ability, you can ask them to write their idea of a feed algorithm. Conversely, if you want to assess their abilities as a lead, you can ask them about maintaining the system and finding the right team to build an app like this.