Onsite:

Round 1:
Q1: Given a dependency adjacency list to install packages, return the installation order or throw an exception if a cycle is found. Solved using Topological Sort.

Round 2:
Q1: Design a system to track recently viewed items (with int limit initialized with class) for customers, similar to an LRU cache. I implemented the core part (O(1) for adding items) but couldn't complete return function but explained my thoughts and runtime (O(limit)).

Round 3:
Q1: System design for a smart city with millions of sensors, collecting and averaging data every hour. I came up with a basic solution and discussed tradeoffs where needed, even discussed the one point failuers and percentage of tolerance, to their question but didn’t have time for scaling to other cities and other trade-offs.

Round 4:
Q1: Write a Notification System that validates a request of notification to be valid. The problem was vague, so I spent too much time trying to get constraints and problem statement as a coding problem. While he wanted an OOPs design from me but did not even utter the word "Design" or "OOPs" in whole interview. I wrote whole lot of code from what I could scope out and it was syntactically correct. I only realized late in last 10 mins that it was an OOPs question, after few asks that he wrote down, so I rushed a basic design for validating notification JSONs.

Final Thoughts
I felt confident on coding questions but unsure about system design and OOPs. Missed the mark on the Notification System due to lack of clarification.
Not sure about my chances.

Takeaway:
Clarify vague questions early, especially for OOPs and system design. Focus on high-level structure before diving into details.
Recommened to be direct in asking if the problem is OOPs or Code or System Design, because some interviewers would just see you struggle and not help.