TL;DR; Google interview but you aren't interviewing for Google I first spoke to a recruiter who told me all about Rally Health and we talked about what type of role would be best for me. He told me about a senior full stack role (React frontend/Scala backend/AWS/Microservice architecture) that might be a good fit for me. I really enjoyed hearing about the company and the culture and looked forward to the next step. The next step was a phone screen with another senior engineer. The interview was scheduled for an hour and the first half was me talking about my background. The second half of the interview is where it really turned sour for me. The interviewer asked me to join a coding share website called codinghire.com. I quickly realized that this was going to be a virtual white board problem and this was an immediate turn off for me. I have over 10 years experience in software development and have delivered on several Fortune 500 applications. I've been on both sides of white boarding problems for interviews and know from experience that this is by far the worst way to judge an engineering candidate. My main issue with them is that most of the problems that are asked in these interviews you would never even encounter on a daily basis. Even if you did, in 99.999999% of cases, you would go to Google to find the optimum solution and move on. That being said, I decided to power through because maybe these questions were going to be relevant to the job description. As it turns out, they were not. The interviewer didn't have a question picked out ahead of time and just randomly picked one from the list. The question was to write a function that determined if two strings were anagrams. Perfect example of a function that in a real world application, an engineer would Google for the optimum solution. I chose to go for a simple solution that was only a few lines and explained that this code would be easier to understand for anyone encountering it in a review or coming across the code in a codebase and trying to figure out how it worked. The interviewer disregarded that response and proceeded to ask me how efficient my solution was and wanted Big O notation. I was completely thrown off by this question because I had prepared for a full stack engineering interview with questions about JS frameworks and design patterns, not questions about CS algorithm efficiency. In my 10 years experience delivering applications, I can't remember ever referencing Big O notation to determine efficiency of an algorithm. If I did, it was because I had found an article that included the explanation of the algorithm but never coming up with this on my own. After giving him my answer in Big O notation, he then proceeded to tell me to re-write the function using a hash map. I gave it my best effort but again, since I hadn't prepared for this style of interview, my solution wasn't ideal. He helped me work through it and then at the end, he again asked me for how efficient the algorithm was with Big O notation. I gave what I thought was the answer but I am not confident it was correct. He then asked me of the two solutions which one I would prefer. Again, I told him that I would prefer my simple one since it was easy to review, easy to understand for future developers, and less error prone. He didn't seem satisfied with this answer. We ended the interview with me asking a few questions but at this point, I was very disinterested in working for Rally Health. In my mind, they are evaluating candidates completely wrong and I would be worried about the other people I would be working with if they were also evaluated using this interview technique.

1. Call with 3rd party recruiter. 2. Initial screening interview with codding exercise. 3.1 interview with hiring manager 3.2 data structures interview 3.3 system design interview 3.4 coding interview - leetcode mid task long time waiting on feedback, week later got scheduled one more coding interview. 4. extra coding interview - 2 leetcode tasks