The HR team was very professional — scheduling, preparation, and post-interview feedback were all timely and friendly. I really appreciated their responsiveness. However, the technical rounds left me puzzled. 1. One of the questions focused on string manipulation with regex. While regex is indeed a tool, it is often less readable and typically something developers look up when needed. I genuinely do not understand what capability the interviewer was trying to assess by testing regex usage for quick string matching and replacement. I solved the problem using a for-loop, and when asked if there was a “better” way, I mentioned regex — but pointed out that the time complexity is essentially the same. To my surprise, the interviewer laughed. I can only assume they were proud of thinking that regex provides an O(n) solution compared to a supposed O(n²) for a for-loop. In reality, one should take the time to understand how regex actually work — laughing at others only exposes one’s own lack of knowledge. 2. The code review exercise was also unexpected. I was anticipating issues like redundant rendering, memory leaks, or deadlocks in async code. Instead, the problems highlighted were things like methods defined with a return type but missing a return statement, or objects declared but never used. If these kinds of issues truly exist in your codebase, then I would strongly suggest reconfiguring your ESLint and TypeScript setup. These are the sort of errors that the compiler and linter should catch automatically — they should never make it to a code review. If reviewers are spending time pointing these out, it says more about the inadequacy of your tooling than the quality of the candidate.