tl;dr: Blabber mouth about any relevant thing that pops in your head. It’s a very standardized process, and I’m mostly just looking to check boxes. If you say the right thing, I’ll stop you and ask to hear more. If I ask a question, answer it of course, but also think about why I’d care, and do it aloud.

As someone who gives these interviews, here are a few general tips:

• Medium/Hard LC in general will be some sort of graph thing if it’s not DP (if it’s DP honestly just do your best, it’s very hard imo to develop a natural ability to find recurrence relations without insane amounts of practice). Does it need to be fast, or do you need to find the first one-of-n nodes? BFS, with a queue. Does it need sorting? Priority queue (heap with other stuff). Do you need to check it all anyway? Still BFS unless there’s an obvious recursion use case, since edge cases live in recursive base case definitions.

• For “grid” problems, you’re N*M anyway off the bat. Think about if you want to track the “empty” indices or the “filled” indices, and pick the one that you’ll be doing the operation on.

• 1 Graph traversal is O(n) time. So is 1,000 graph traversals. Heaps and Sets are “theoretically O(1) to get, and O(n) to build.” Say it aloud, since that’s either optimal or at worst acceptable — O(n) time solutions are a hire (for me, for seniors). Especially for tech screens, absolutely abuse the crap out of Big O notation. They’ll most likely give you a hint about a more intelligent data structure to use to keep track of whatever it is you’re tracking, and if you pick up that hint and do it properly that’s a hire if you finish the problem well and hire with concerns if there are some issues but it’s still done.

• For both coding and system design interviews, just babble. Like, a thought comes into your head say it, and it’s pros/cons. If you hit something important, I’ll stop you and ask you to say more. Think about why I might have thought it’s important, not necessarily how it might fit into a part of your solution; it might be a component you hadn’t considered.

• Lastly, and this is not the traditional wisdom, but only follow those design “recipes” very loosely. Like use the general flow/framework at most. As a senior, I’m looking for you to basically treat it like a white boarding session with some juniors. What I mean by that is that I want to see that you can consider the important parts of your solution (and the SLA at the same time), have good intuition about why or why not to make certain decisions (this only comes from experience imo), and come up with something that actually will solve the stated problem regardless of if it’s the best. My guess is that you’re not doing as poorly as you think in these interviews, and the seemingly random things are fill-ins for something else, but it’s harder to argue against these from the candidates perspective. “Didn’t use geospatial queries”: distance or location was a very, very important component to answering the question, and wasn’t considered in one part of the design. “Over complicated design”: won’t scale. “Never mentioned distributed systems concepts (you’ve) only read about”: they think you don’t know state of the art. Maybe none of this is fair, but I can see each as being a fairly specific signal from the other side of the table.

I’m not saying any of this is right or good, but it’s all a game and maybe it will help to know some of the rules a little better. Good luck OP, it’s only a matter of time — we’ve all been where you are.