When stymied with a problem you can't seem to get your head around; try thinking about how you would test it. Imagine the potential inputs (pre-processing/post processing too), error cases and success cases. What would the API look like? How would you break the problem down into individual functions that could be tested separately from the entire solution. How you'd test it will cause you to think about how the problem should be solved, but from a different direction... sometimes you can have an epiphany and then immediately solve the problem.
In many cases, interviewers are looking to see how you can solve problems and not always if you've memorized the compiler (personally "what would the compiler do" questions indicate a clueless interviewer, because any idiot can memorize how the compiler works, but may not be able to get HelloWorld to work). A problem that is concisely broken down and is possible to have unit tests is dramatically better than a problem that is one huge function. A problem with smaller parts can also potentially be optimized differently from a large solution.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.