It was, by far, the most boring interview I've ever had to participate in. The leetcode problem was easy (detect if two strings are anagrams; solved with O(n) solution in < 10 LOC; then aggregate sets of anagrams). System design was easy because it is to the point that it is largely "formulaic". It feels like those rhythm games where you need to know when the trigger is coming and the pattern to hit those triggers (talk about functional requirements -> talk about non-functional requirements -> write some API routes -> draw a load balancer (because of course, there's always a load balancer) -> draw a service -> draw Redis/Memcached -> draw a database). It's comically laughable how it's just like a rhythm game at this point.
What I don't understand is why teams don't just "get to the point". A lot of times, the assessment is looking for specific notes. Why not just ask about those notes directly? A friend recently went through an interview where he was docked for not using C# `yield` when implementing an `IEnumerable`. But had the interviewer asked "What is `yield` and why would you use it?", the interviewer would have gained the same exact insight in 15 seconds with one question.
I think what's also striking is how slow orgs are to adapt their interview process to account for AI. There's a distinct lack of focus on code reviews as part of the assessment. If the future of coding is AIs for productivity, then teams should be adding code reviews into their process (check for correctness, check for defects, check for performance, check for security, etc).