The interview consisted of three parts.
First, we had a nice call with HR on general questions, for example, why Amsterdam, salary issues, when I can start, etc. After that, they wanted to introduce me to their mobile development lead, another call, "a little more technical." The lead was a really nice Italian, also pleasant in communication, but we mainly talked about general things, for example, what technologies I used, how I realized, etc.
After the communication, they sent out a test task, which was not devoid of weirdness. For example, their server gave out an array in case there is no data, and a dictionary if there were any. In the test task was written "do not afraid to overdeliver", but no clear instructions on the design (in most cases this is absolutely normal, but not in this) or the functionality was not. After spending a total of 16-20 hours on the task, I implemented dashboards, tables, animations, normal abstractions (well, it seems to me) and sent them there.
In response, I received an invitation to the final interview with the iOS developer, was very happy. Began to prepare (I realize that in terms of theory and without Google I do not have the most senior knowledge), experienced, wrote on paper various points that I think could be asked. And here is the moment of truth:
- I looked at your test task. You could make a request through NSUrlSession in 2 lines, why did you write a full-scale network layer?
- This code from my previous projects, I wanted to use as few third-party libraries as possible, because this is critical in both my and your work. And in plus you can see how I use generics, protocols and stuff.
- And why do you have folders named for functionality, not MVVM? I do not see the folders "ViewModel" "View"
- Because MVVM is a design and separation of responsibilities template, not a folder naming template. I think that naming is a subjective thing and can be easily fixed if the company has a standard naming convention.
- Why did you use xib in the project?
- Because I think this way is more flexible, it allows you to deal less with the merge conflicts, does not hang like storyboards and takes less time to create, unlike creating a UI code.
- No, I worked in a company of 42 developers, 16 iOS, we used storyboards and all large companies use storyboards.
In general, all questions were reduced to the subjective principles of maintaining the code base, not one really serious technical issue was asked. The next day I received a letter, part of which contained the following phrase: "Unfortunately, the hiring team found that your qualifications are not the right match for this job." At this point we're looking for slightly more senior candidates. "
Well, apparently the process of naming folders is really important for this company ...
