The interview followed a standard process: recruiter chat, technical phone screen, then onsite interview, and of course emails for logistics in between. The phone screen went well, but I didn't hear back for a good while, so I thought I wasn't under consideration any more. I pinged the recruiter a couple times, and after some back and forth they finally got back about scheduling an onsite. There was about a month gap between the phone screen and the onsite, which was pretty long. The recruiter seemed to have difficulty getting info from the hiring manager on whether to proceed, and may have been out of the office for a period of time. The onsite itself was fine. It consisted of five hour-long interviews: four technical with code written in coderpad, and one chat with the hiring manager. I thought they all went very well, and I enjoyed chatting with just about everyone. I was disappointed when I didn't get an offer, but it happens. One of the recruiters was even able to give me very detailed feedback on the technical rounds, which was very much appreciated. I've found most companies refuse to provide this, or give some vague response that doesn't make much sense. The experience was positive overall. What makes me give them a negative review is the feedback I received. First, they seem to have judged me on concepts and technologies that were NOT in the job description, and some that had specifically been called out as "not required" by the recruiter and interviewers. Had I known that these would be part of the interview, I could have studied up on them. The feedback was also extraordinarily nit-picky, with comments like my code not being "production quality", and that I ran the code too often, indicating I lacked problem solving skills. Addressing the second comment, I finished every bit of the coding problems, so I'd think that would speak to my problem solving abilities. This was a TDD session with Javascript. For anyone that's done TDD, running the code often is pretty common practice, and many modern tools watch your code for changes and autorun it anyway. This comment smacks of a very old mentality, when compiling and running code was slow and expensive, so you would minimize that step and try to analyze every character of your code before running it. But as I mentioned, this was Javascript - no need to compile, and modern tooling makes it cheap and easy to execute. I used to see interviews like this 10-15 years ago, where interviewers would often ask candidates to debug/analyze complex code with a pen and paper, syntax errors and all. In practice this is not reflective of how people actually work now, and is a poor way to judge a candidate. Clean code is important, but expecting code in an interview to be "production quality"? That's a first. Everywhere I worked, and in every interview I've done, except this one, there was always an expectation that code might not be optimal or perfectly clean in the context of an interview. Given ~45 minutes to solve a complex problem under pressure, you often have to make tradeoffs and work much quicker than you normally would. This is pretty well accepted. Looking back at my code, there were definitely areas that could be cleaned up. But Cruise was looking for perfection. I was very disappointed that this didn't work out, as the role and team sounded quite interesting. Perhaps I ran into the wrong interviewer(s) on the wrong day - that happens, and is emblematic of how interviews can be a bit of a crap shoot. All things considered, I think this interview experience is probably reflective of the company's culture, and it might be a good thing that I didn't get an offer.