Initial chat with the recruiter seemed like they were trying to sell Hopper to me as if I was an investor, which was a bit weird, but I still had a few minutes at the end of our 45 minute chat to ask the questions I was interested in. I did not have a good experience in the second interview. Question seemed like "standard leetcode stuff", but, as an interviewer myself for many years, I've learned that knowing how to code bubble sort wasn't an indicator of a person's coding ability (neither is such a skill normally required in the workplaces I've been in), so being asked this type of question was unexpected (especially as I'd expressed interest in the Infrastructure team, not the Core Team). As an example, I began with "I could solve it this way (using standard libraries), but it seems like that isn't what you might be looking for". I got zero feedback on whether that was a correct statement. I did not actually claw the requirement of "we want you to create your own sort method" out of my interviewer until I had 20-30 minutes left of the 1 hour interview. They seemed to not care whether I test drove or produced iterable code. I was annoyed that using standard libraries wasn't allowed in the solution, and I mentioned multiple times that "I am not going to produce a better algorithm than the standard library". again, very little feedback on this statement. There is more to coding than just "can you solve this sort algorithm". Is my code maintainable? do I think about naming conventions? Do I think about the long term implications of a solution? Am I thinking through edge cases that could cause issues in running code? The entire interview, it felt like they had an answer they wanted, and I wasn't delivering. What this tells me, is that this company cares less about process, and more about result. Which is fine, but not a company I care to work for.