The interview process moved very swiftly. The HR team was excellent, prompt and courteous in their communications and timelines. It was one of the better interview experiences to be had. Each session lasts about 45 minutes and includes about 10-15 minutes of introductions and 5 minutes at the end for questions. The technical phase utilizes Coderpad, a shared IDE workspace. Python is the primary preferred language but the selection was open. Having written mostly in Kotlin in my most recent role, I opted to use this. It was immediately noticeable that Coderpad didn't have Kotlin with intellisense as a first-rate citizen in their platform. Much of the autocomplete and nice-to-haves that an engineer forgets about having, which allow one easily move through any minor semantical or syntactical issues, were not present. The initial screen was straightforward - a question with some data structure and list comprehension. The second technical interview had a more complex problem, but not extraordinarily challenging once the problem space was clearly determined. The interviewer is a highly decorated academic and had an exceptional understanding of his space and was very gracious in his discussing various approaches to a solution. This interview was also focused on data structure comprehension and parsing, relating to unbounded sets. The third interview was with the hiring manager and came with a third technical challenge. Again, the problem was not a particularly difficult one by any means. However I soon faced difficulties with my chosen language and the platform, as well as my having suffered a bit from taking a recent hiatus and forgetting some very basic but easily forgotten subtleties of Kotlin vs Java which had slipped me during the course of the exercise. The issue, while minor in nature and nearly negligible in a standard working environment, resulted in my having to spend many cycles just to understand exactly which part was failing from println() statments, a mess of cumulative error codes in the console output, wishing for a debugger and a 10 second wait time between each test run. This resulted in a lot of wasted time waiting for subsequent test runs on the platform while also attempting to reasonably walk through my process of addressing such a minor-problem-turned-major, all while being distracted and seeking a better way to quickly test and recall the answer to my issue of populating my nested list at time of instantiation using Kotlin -> answer: Array(n) { Array(n) { 0 } } This was also somewhat compounded by both of the latter interviewers' message and alert notifications going off throughout the coding exercise and added a unnerving sense of indifference and judgement around the time that the interviewers had given for the interview process. By the end of the final stage, I was left without any time to ask questions or pursue any discussion. The hiring manager appeared visibly irked with the struggles faced on the platform, and there didn't seem to be much sympathy or regard for the process at all relating to the overall functionality or process behind writing the solution which was otherwise, more or less, working and which had been written without the use of any autocomplete or real-world environmental aids that even most coding challenge sites provide. It was a disappointing end to a promising interview process, and I'm certain that's not just a sentiment that I hold. It seems that Junior engineers are plentiful all around while senior engineers with real world experience are high in demand. These sort of black and white technical screens, while having their merits, pose problems for those who have been working in the real world for too long and may overlook the conveniences of being able to focus on delivering product while rarely experiencing such contrived stress factors that only tend to exist while interviewing with a new organization even while shipping on tight deadlines and launching innovative software.