What will you read in this post? I'll talk in brief about how interviewers structure a coding round, and how you as a candidate should attempt each section.
When you have 5 interviews scheduled in a day, it can be pretty freaky. But that's the way of the world now. For a big majority of engineers, they'll have at least 3 out of 5 rounds focused solely on algorithms and data structures. How complicated will the questions be? Depends entirely on the company you are applying to. But let us break this down from an interviewer's mindset.
Before the interview
If this is your first interview of the day, then all the interviewer has to go on is your resume. They have a limited scope to judge what to ask you. However, you should remember that if it isn't your first interview of the day, then your previous interviewers would have passed along some hint to the next interviewer, to the effect of "It'll be great if you can test a little deeper in data structures". Remember that your interviewers can't share actual feedback between themselves, as that gives a chance for bias to develop (good or bad)
The first 5 minutes
Typically, an interviewer will spend the first few minutes to judge your communication skills and how well you understand your previous work. This soft skill competency segment is built in to each interview. You can expect them to ask something about an interesting project you have done previously, or some challenge you have faced.
The next 10-15 minutes
It is reasonable to assume that your interview can go one of two ways. Either they can ask you a bigger question to test your algorithms application as well as fully vet your code, or more likely these days, they'll come in with the mindset of asking 2 questions, and not just one.
So the first question they'll ask you will probably be something that isn't necessarily easy, but they would expect you to come up with the algorithm and code it up pretty fast (atleast for a FAANG or similar company). In my experience, it is almost guaranteed that the code will not be lengthy for this problem, merely tricky.
What should you do? For an algorithmic-problem, always start off with going in the order of a solution with average complexity, and then to the one with the best time/space complexity. Even if you have seen a similar problem before, don't let that show up. Giving that impression creates a negative bias in the interviewer, and they won't be satisfied even if you come up with the right solution in the next 5 minutes. It'll just make them ask you an even more difficult question.
The next 20 minutes
Once you have the first question under the belt, it'll be time for another one with equal or more complexity. I usually keep the same complexity, just jump to a completely different topic. After all, I want to test logical skills in different areas.
Once again, take your time (a few minutes) coming to the right logic. And after that, start coding it up. It is possible that you don't get to the end of this code. And that is usually fine, as long as you were going in the right direction. Of course, the result of your interview and tolerance for non-completion depends on the level and company you are applying to.
The last 5 minutes
I cannot stress enough how important this is for you, as a candidate. No one is judging your interview based on this, but this is the only opportunity you get to get the dirty details from the interviewer. The team you are going to might just be doing maintenance work, or the culture might not be good, and the only way you can save yourself from getting stuck in such situations is asking some well-pointed questions. More on that in a different blog post.
For now, hopefully that was helpful ! :) See you next time.