My main suggestion is taking a mock interviews. There are companies who do that for about 150-200$ per-session (e.g. Gainlo). But turns out (thanks Ryan) some do it for free (interviewing.io, Pramp).
Another option is to find a friend who’s done interviews and willing to spend some time with you.
The big advantage is obvious – you get an honest and detailed feedback on how did, both technically and personally (this is another important point – practice your communication skills).
Questions about design and system design (which are different things) are a little more tricky. I don’t have good sources for practicing that.
As for online-automated-interviews (where you are presented with a problem and you have 15-30 minutes to solve it) – they could get tricky, and I’ll try to help.
Personally, I don’t like this method very much, because not everyone are quick to write code. In a real-world setting, the bottom line is what matters. It doesn’t really matter if it took 30 minutes or 45 minutes to write function foo.
However, some companies (including Facebook and Google) likes to do that, so here are some tips (some are relevant for on-site coding interview).
How to practice?
- For coding practice I use mostly LeetCode.
- Other good options are: HackerRank , InterviewBit, GeeksforGeeks (a little more difficult to navigate but has interesting articles).
- codility has some lessons – try it!
- I stumbled upon Interview Cake, which is a for-profit company, but has some free resources.
- Paid course about system design (important for seniors) which I haven’t taken myself, but recommended by a good friend (Yariv): Grokking the System Design Interview.
- A good resource in Hebrew for learning algorithms: Algorithms by Maya
When you practice, time yourself and try to be as quick as possible. Be honest about it and really make an effort. When you are sitting to practice, find a quiet environment, turn off your phone and focus. Don’t put music on and try to simulate interview setting as much as possible.
Don’t forget to practice complexity (both time and space) analysis of your code. Some online judges (I know LeetCode does) will measure you code’s performance and penalize for it.
Prepare your environment
If your upcoming codility interview is automated, then it’s allowed to actually use an IDE during the automated interview. They even tell you so. So practice writing code quickly with your IDE in the target language. Have a template console application in the target language. Prepare a parsing function for data structures (like trees), compare methods (for arrays, tree, dictionaries, sets etc.). Sometimes it can be achieved by actually create a unit-test. This classes have some of that functionality built-in.
Know the online judge
Try to know in advance the format the target framework is using for data-structures. codility, for instance, is using this format (5, (3, (20, None, None), (21, None, None)), (10, (1, None, None), None)). You can do a training task and try it.
During the interview – writing code
Basic
Like in real-life, you should have something up-and-running as soon as you can, no matter how crude. Then you can start running more tests against it and refining it.
Tests
Run tests!
Using assertions or by creating actual unit-test methods/classes, every case you are testing, write it as an assertion. Then, in the process of refining your code, handling more and more test-cases you are guaranteed not to create regression issues. I’m not talking about a fully-fledged project. just add assertions to the cases you are testing so it’s easy to re-run it every change you make to your code.
Simplicity
Simplify things (that’s another tip relevant for actual work) – write a “story” by writing significant method names (even before writing the actual method) and knowing what you are passing and getting back from these theoretical methods.
Edge cases
This is a tricky part but naturally pretty important. You need to come-up with as many edge cases you can think off to make sure your code will pass all unit-tests being run by the automated-judge. Think of empty or small groups/string/trees/array, very large ones, array with duplicated numbers, integers, floats, zeros, sorted/unsorted, tree that are wide and low or deep and narrow (tree that only has single child per node), with graphs – think about large number of edges compared to nodes or no edges at all, fully connected components and components that aren’t connected at all. When you practice on sites like Leetcode, they will tell you when your submission fails on what test-case tripped it. Take mental notes when this happens so next time you will identify this edge case yourself (because in an automated interviews, there’re no multiple submits of course).
Code Complexity
Don’t forget to asses the complexity, both memory and run-time. In automated online interviews you will most likely not need to provide that analysis. But naturally you could be penalized by using too much memory or taking too much CPU time.
Identify nested loops, and understand the complexity of the method you are invoking. If you are calling library functions they might incur cost – know what it is to avoid pitfalls (for instance, inserting an element in the first index of an array will have O(n)time-complexity but seems like a single operation.
Recursion – it’s a useful tool, sometimes very much so, esp. with trees, but very dangerous. You might end up calculating the same thing more than once (even exponential amount of times) and it will be pretty hard to notice. Recursion also incurs cost of memory – you must not forget that. If you are traversing a tree recursively, even without allocating any additional space, your space-complexity is O(h) = O(n)where h is the height of the tree. Be careful – trees aren’t usually balanced. By default h = O(n) (where n is the number of nodes). In a balanced tree h = O(log(n)).
More Links
Check out “How to practice” section in this post for more links.