| You have entered the world of "competitive programming". Companies have started to incorporate competitive programming problems into their interview processes. They're hard, and often don't overlap a lot with what you may do at work, but there's not much you can do about it other than to prepare. A good book is "Competitive programmer's handbook", available for free in https://cses.fi/book.html. This book is programmer to programmer advice that will take you very very far into these kinds of problems, and gets to the point really fast. The code examples are clean and well formatted. For interviews, it gives you about 70% of the competence you would get from reading much longer books like Skiena's or Sedgewick's. My approach to these interviews is: - Read the requirements very well. Try to read between the lines as much as you can. - Ask if there are follow up questions or if the exercise has multiple parts. This helps you plan your time. - If you do not have an ideal approach, try a bruteforce approach first. - Try to narrow down candidate solutions: what happens if I use an array? a list? a tree (binary search, trie, heap, etc)? a stack? a queue? a graph? a combination of them? You can practice on sites like Leetcode, Hackerearth and so on so forth. If you want to try something harder, you've got this (not for the faint of heart): https://techdevguide.withgoogle.com/ But first, try to implement common data structures from scratch and get a better intuition about them. Remember to try recursive and iterative versions of operations. You can output Graphviz data and use that to debug. Finally, even if you fail an interview, many companies will let you reapply after some period of time. I failed an interview a few years ago and I still get contacted by that same company today. It's not a life sentence. |