Some comments here are asking what would be a better process. I think a big step is just stopping with the requirement to get the optimal solution. If I was d

Some comments here are asking what would be a better process. I think a big step is just stopping with the requirement to get the optimal solution. If I was doing these interviews, brute force is fine. If they can come up with a brute force and write code for it, they completely pass my coding bar. Some may say that's a low bar, but it's not. Because expecting anything more is going into rote memorization territory of algorithms. It's also not realistic. In the real world, brute force is always the first solution and it's the right first choice for a number of reasons: - Brute force is often simple to understand. That directly translates into maintainable code. - The business constraints on the input size may make the brute force an acceptable solution. - If you need a better optimized algorithm, brute force is a great place to start. It's basically your test case generator for verifying that your more complex algorithm is right. After they get brute force code written, the coding part is over and the rest of the interview is about discussing why it's brute force and what we could do about it. But no more coding is expected. It's a chance to be creative. If they want to talk about improving the algorithm that's fine, let's draw some diagrams. They want to throw more hardware at it? Sure, let's talk about how to scale that. Maybe they've actually seen a business problem before that was similar? Great, let's discuss how you solved it.