The process was standard at the beginning, speaking with the HR representative. Followed by a technical phone interview with the current remaining iOS developer (the position was filling the former senior/lead engineer position, but wasn't necessarily for a senior iOS engineer). The technical interview was one-on-one, which can be okay when the interviewer is well-prepared and -experienced. They started off by asking me to walk them through the user experience of an app referenced on my résumé with justifications for the decisions I had made. I had to inform them that it was a client app and not my own. This was clear on my résumé I felt, as it was listed under the Freelance job history among other apps denoted as client apps. They then shifted gears and proceeded to ask myriad questions that were also answered on my résumé such as my work history, educational history, and some general iOS development questions. It was casual, which isn't a bad thing, but it was frustrating that the interviewer did not seem to have given much attention to their preparation. It would have been easy for them to browse my GitHub profile for questions to ask regarding my projects and code. Afterward came the code challenge portion of the interview, the specifics of which I'll include in the next section of this review. But it was a fairly standard, if contrived challenge testing knowledge of a particular aspect of Swift development. Certainly, much can still be gleaned from observing interviewees work through challenges such as these, including their broader problem solving abilities, ingenuity, google-fu, and debugging, even while they may not actually complete the challenge. I was careful to continually vocalize my internal thought process while proceeding through the challenge, especially while I was stuck, so that they could gauge these aspects. Ultimately I did not fully solve the challenge, but I felt I provided sufficient demonstration of my skills along the way to show that I am a capable developer even in unfamiliar situations. Unfortunately, when I received the follow up phone call communicating their decline of my application, the primary reason cited was that I simply did not complete the challenge. This was especially frustrating to me as someone who has overseen interviews and code challenges in the past because I know that this is not the point of code challenges. Most of the time, they are too difficult to complete on purpose so that a broad picture of an applicant's capabilities can be determined. If they solve it easily, this isn't achieved. It was disheartening that this was seemingly lost on the interviewer, at least based on the feedback I was provided. My own personal opinion is that the interviewer was biased against my application from the start. I can speculate on where the bias stemmed, but it's not especially relevant for this review. I could feel throughout the interview a general lack of interest, in addition to the clear evidence of unpreparedness. I feel that the incomplete code challenge was the easiest excuse for the interviewer to disqualify my application. Even if it wasn't bias, it was certainly inexperience in performing interviews. ParkWhiz as a company could have mitigated this by including a second, experienced interviewer into the process, even if they were from another development team (such as Android or web), as this is common practice.