Wow. I’ve just had a 2nd rejection within a month on one of those interview projects, and I’m starting to become a little spooked over where my skillset is lacking.
I’m referring to them as interview “projects” instead of demos, because that’s what they’ve morphed into now. The previous time I was looking for work a couple of years ago, these demos were just starting to become a more common replacement for the whiteboard tests. I even got paid for one by the humane team at Follow Up Boss, which was pretty cool.
Fast forward to the present, my wife and I moved back to Toronto, and I’m starting to look for work again. So one contrast I’m noticing now is a shift away from demos. The workload is taking on the state of a project, and perhaps the expectations that come with it (I don’t know technically, seeing as I’m not the one interviewing. Which brings me to this blog post…).
The Quest For Insight
I know that my code may not be perfect. In fact I hope it’s not, otherwise we really are far away from flying cars if my code is the golden standard!
But I’m not sure if the goal for these interview projects is perfect code. I’ve consulted a few ex-colleagues to get their opinion on the projects I’ve submitted. While I appreciate their help, they’re perhaps too subjectively nice in their opinions.
Perhaps everything needs to be impossibly perfect when assessing for a Sr iOS Developer (I’m on the cusp of Intermediate/Sr). Or perhaps there are genuine, gaping holes in my knowledge, and I haven’t had the right kind of feedback in recent years.
Internet, I turn to you. I need real objective opinions, whether positive or negative or a bit of both. Because honestly, right now I have no idea where I stand.
The Latest
So I’ve decided to publicly upload the code from my latest interview project to my GitHub account here.
Please if you have time, check it out and offer some insight from an interviewer perspective. It doesn’t matter if you’re junior or senior, or have been in charge of hiring or not. I’m mainly interested in the perspective of being an interviewer though.
The app uses no 3rd party libraries. But to run it, you’ll need to register an API key on http://api.openweathermap.org/data/2.5/, and add the key to the API_KEY constant in the NetworkManager class.
Regarding that void of perfection touched on above, I know that I need to work on the following areas in iOS:
- Protocol-Oriented Programming. I use protocols extensively, especially with the typical delegation pattern in iOS. However, I’m specifically referring to the direction that Apple champions we should adopt in Swift in this WWDC talk . I need to wrap my head around this POP paradigm and start using it.
- MVVM, MVP, and VIPER architectures. While I feel like I’ve educated myself on the current conventional alternatives to MVC, I still don’t feel confident at implementing one of these alternatives when the time constraints are so tight. Also, in a project that’s still relatively small (vs production code), MVC is still the pattern that involves the least amount of boilerplate code (this changes for larger projects, IMO).
- Unit Tests. I try to implement unit testing whenever I can, but didn’t in this interview project because of the time constraints, and the fact that they didn’t explicitly ask for it. I still think that I came up with very testable architecture due to my heavy use of composition, aggregation, and property dependency injection.
What they asked for:
- Provide a search interface to search for a weather location from an API.
- Download and parse this data from the API if the user selects it.
- Present this data as the local forecast.
- Present the previously displayed local forecast on app launch, and keep track of the previsouly selected location forecasts. (goodbye NSUserDefaults, hello Core Data).
- Provide localization support (I didn’t get to that).
- Provide error handling for main scenarios and edge cases (I didn’t get to every single edge case).
“This should take 2–3 hours”. I’ve found that no matter how small or large one of these interview projects has been, HR always communicates an expectation that it should take 2–3 hours. Thankfully I had an actual time constraint of 2 days. Achievable, but very tight. Perhaps unrealistic in a workplace setting. In a Scrum environment anyway.
I’m under the assumption that a few voids in knowledge would be taken into account. For example, I haven’t implemented a UISearchView in perhaps 2 years, and coincidently that took me the longest to work on out of all the other implementations.But again, I don’t know and this is where I need insight.
In terms of complexity, I would rate it as a 4/10. I didn’t feel challenged mentally. The main challenge was the time constraints for the feature set that was asked for, and the ambiguity as to what they were assessing on (was it number of features implemented, use of 3rd party libraries, 1 or 2 areas of the app as opposed to the architecture holistically? Etc.).
Anyway, because these interview projects are still relatively uncharted territory in the tech community, I feel as if we could benefit from having a feedback forum devised to help each other through what’s expected here. Unlike a coding bootcamp, or a “cracking the coding interview” book focusing on algorithms, the boundaries are not defined here, and I have no idea if my code sucks or not. Or if I’ve been unlucky in my recent encounter and the company sucks. Or perhaps a combination of both.
