I think you're operating under a misunderstanding of how these interviews work. The goal is not to see how many algorithms you know. Algorithms are easy to lea

I think you're operating under a misunderstanding of how these interviews work. The goal is not to see how many algorithms you know. Algorithms are easy to learn on the job. The goal is to see how you think in a social setting. How you approach a vague, imperfectly stated problem. Do you ask questions to gather more requirements? State assumptions? Then, based on that, how you try to break it down into smaller pieces. Are there different ways to model the problem or lenses you can apply? Can you think of this as a graph? A tree? A database? Can you incorporate ideas from the interviewer on the fly? The software engineering job is about taking vague problems and turning them into working code with a help of a team, and the interview process is trying emulate that as best as possible under the weird limitations of an interview. You can pass an interview without getting any of the "answers" "right" and you can fail them even while blasting out perfect algorithms on the whiteboard.