Two interviews, one with the CTO and the other one with the team leader. The first one about the company, like an hour long, and the second one more technical, two hours long.

Waste of time. It started out promising. I've been a map nerd since I was 9 years old, navigating solo in dense forrest and organizing my own orienteering courses. Their office is also a very small commute for me. I was excited! They didn't really have a strong product vision though. There were no grand plans to use machine learning, or unify mapping UX, etc. Or at least none that wasn't confidential. So I was willing to give them the benefit of the doubt until a more in-depth onsite interview. Moving onto tech questions... It didn't help that there was snickering and overtalking when trying to explain answers, so nervousness was compounded and core concepts such as async and serialization probably came off as the "wrong" answers. At least in the wording they were looking for. I got the sense that they were after only a narrow scope of wording with textbook phrasing. But you can only provide a textbook answer if you A) get lucky, or B) use a concept every single day... and you shouldn't ever test for A. Oh, and there was also quite a lot of digression on how I'd need to become an "expert on C++" ...I don't know to what extent that C++ is baked into their native apps, but if it's an amount large enough that an iOS developer needs to become a C++ expert just to get by, that seems like there's going to be a crazy amount of C++ in there. I'd be willing to learn, but the sheer amount seemed like a red flag! There was nothing on Swift, no persistent storage or networking integration questions, nothing about how to build complex architecture, nothing much on design patterns, and nothing on how to optimize the UI and data fetching. Even algorithms and data structures have more relevance than 60-80% of their questions. Even the 20-40% of questions that may have been remotely relevant, were offset by the style of the interview. In that each question was asked in a "gotcha" sense, instead of in a collaborative sense or any other way that you'd openly discuss ambiguity prominent in the real software world. When this became obvious, I explained to the interviewer that I didn't think that they'd be able to find good mobile developers who know how to build complex systems, by asking these types of gotcha questions solely designed to make the interviewer feel smarter. The interviewer claimed that these were concepts they use every day. It was at that point that I had to withhold snickering of my own, politely thanked him for his time, and said that I wouldn't be moving forward.