Algorithm interviews often involve rote memorization of said problem or of a similar one. Alternatively, if you have never seen the problem you could identify some truths and cases about it, which could eventually lead to the solution. Often times you’re allotted only ~1hr, making it difficult to work through AND then code it. Has this ever been enough for anyone to pass an interview challenge?
> Has this ever been enough for anyone to pass an interview challenge?<p>Yes.<p><i>Ideally</i>, you shouldn't be "memorizing" solutions. You should be first attempting problems on your own with your very best effort, and only after successful completion, or after sufficient effort, should you look at the solution. If glancing at the solution for 15-20 seconds is enough to understand "the trick" you should then close the solution immediately and try the problem again. If the methodology or technique is more complex, then you should spend more time trying to understand it, which may include revisiting some prerequisites and relevant foundational concepts.<p>If you understand a large enough variety of problems, then you will find that the techniques that you have learned are applicable for many novel problems you may be asked during an interview. After taking 5-10 minutes to properly understand what exactly the problem is asking, and clarifying assumptions/preconditions, you should already have an understanding of how you would solve AND code out the problem.<p>It is difficult to come up with a working solution in code in a short amount of time - practice makes perfect. Good interviewers try to filter out small bugs/discrepancies that are introduced due to time trouble, and will focus on the bigger picture of your algorithm and function design.<p>Some problems are simple enough that it is possible to:<p>* receive the problem description<p>* clarify all assumptions<p>* discuss a potential solution / thought process<p>* illustrate a couple of examples of input/output<p>* discuss edge cases<p>* implement a solution in code<p>* trace execution with some input examples, verify it matches expected output<p>* discuss how the algorithm could be expanded if the problem was amended<p>-- all within 60 minutes.