At Essential Developer, we help many developers go through the iOS Interview Experience. Recently, we got this message from one of the members of our community:
“Hello Caio. I have recently had a job interview with a tech test, which I completed in two days and got rejected.
The story goes: I got a message from a successful search/indexing company willing to have an iOS interview with me. I had a 30 min conversation with an iOS developer from the company. I don’t know what level they are looking for. I said to him that I am at a mid-junior level in my opinion. He said they were going to send me a tech test to see how I organize code, objects, what architecture I use (they mentioned VIPER), design patterns, testing approaches, TDD, XP, etc.
I tried following TDD for the test, but not entirely. They replied with: "I appreciate the time you took and your interest in our company. Unfortunately, on this occasion, we have decided not to progress your application further. I really enjoyed talking to you, and I wish you success with your current job search.“
That’s it. I don’t know what’s wrong with my project . Can I send you the test description and my little project to hear your opinion on how good or how bad it is ?”
Most companies do not give full details of their decisions, and that’s fine. It’s their choice. As a job candidate after an iOS Interview Experience like that, it’s common to blame our technical skills first. Notice the “how bad is it?” question. Such negative look of the events can discourage developers from further pursuing their dream job. Maybe it has nothing to do with the candidate’s skills. So it’s important to remember that there are many factors out of our control. However, for this blog post let’s focus and assume the motives for the rejection were solely technical.
Given a text file:
Write an application that outputs the individual words (ignore punctuation and capitalization) that appear in the text file, and how many times that word appears in the text file.
Output whether the number of times each word appears is a prime number.
The test is intended to show your skills on Problem-solving, TDD, OO, Architecture, Code Quality, and Performance. Bonus if you can come up with more than one solution and explain the pros/cons.
As a job candidate, before going through an iOS Interview Experience and the tech test, it’s essential to do a bit of research on the company. So, before having a look at the candidate test project, I did a bit of research on the company. By looking at the company’s website, I quickly noticed how proud they are about their fast, efficient, scalable, reliable, great, first-class, successful, and state of the art platform. It looks like they perform several web scrapings a day and serve several clients through their APIs. In short, scalability, performance, and correctness of data are vital to the company. Also, from the conversation and the tech test description, the company looks very keen on TDD, OO, Clean Code, and Architecture.
From a quick look, the project looked good overall. The project was well organized, the classes were small and the code was readable. The candidate really proved he can make an app from scratch and I would gladly offer him a junior/mid-level position. The candidate even made an extra effort to build a very nice user interface and added a great feature to enable importing files from a URL. However, there are some areas where I believe the candidate could have focused more to fulfill the test requirements of this iOS Interview Experience.
The code was organized and readable, but it seemed not to handle errors accordingly. It might be ok for a tech test to assume input is always valid, but going the extra mile to handle error cases can help you show great programming skills.
There were common anti-patterns to avoid like primitive obsession, leaky abstractions, refused bequest, unused code, and unnecessary/redundant comments. All of which can be acceptable for junior developers, but might be red flags for the interviewer.
The code was not under version control. We suggest you always use git for your tech tests. And send it over to the interviewer. Many teams will look at the history to understand how you got to the end solution. It’s in your favor, so don’t hide this from them!
The test coverage was not throughout enough. The candidate is conscious that he couldn’t follow TDD completely, but he showed a great effort. Candidates with TDD experience are hard to find. The company could have made a choice of investing in a candidate that showed aptitude, but it’s up to them. (Tip: If you want to increase your value as a developer, TDD skills are valuable and scarce. Companies are continually looking for experienced candidates!)
The candidate followed the MVC design pattern. MVC is fine, but the company was very keen on VIPER. Maybe investing a bit of time making it more like VIPER could have won the candidate some extra points.
When trying to pass a tech test, it can be essential to tune your skills to impress the interviewer during the iOS Interview Experience. Taking the time to implement different solutions is an excellent way of doing so. The company even requested it as a bonus, but the candidate provided only one solution. The solution provided would not scale well and would not be performant with larger amounts of data. Nothing wrong with that, it is still a valid solution. However, the candidate could have invested that time to provide different approaches and explain their pros and cons. Especially because when running at scale, the cost of a lousy implementation can quickly jump up to 7 digits. Being a mid-level developer is no excuse here. A bit of research and googling around could have helped the candidate provide different solutions.
Reviewing code is very subjective. A pairing session is much better to communicate intent, but not every company would invest the time in the first stage of the iOS interview experience. Taking the time to write down some notes, draw some diagrams, and even recording a video explaining your decisions can be a great way to engage with the interviewer at this stage. Using git can also be a great way to show the progression from start to end. Small and meaning git commits can make a big difference.
The candidate took two days to complete the test, which could have been a red flag. The requirements were not complicated. However, from what I gathered, there was no agreed deadline to send the test. Also, the candidate made it clear he was not working on it full-time. The real red flag is that a lot of the time was spent on the UI and the extra unrequested feature, instead of the bonus challenge. For the test reviewer, it could have been taken as “this candidate might have a hard time following requirements.” In Lean and Agile teams, it’s important to eliminate waste, such as over-engineering/complicating implementations (YAGNI!). Of course, that can be a wrong assumption about the candidate, but how we present ourselves in the iOS interview and tech test can help eliminate those assumptions.
Always negotiate a deadline. If you work full-time and don’t have much time to work on the tech test, let the interviewer know and negotiate a reasonable delivery date that makes sense to you. The company shouldn’t expect you to stop your life to finish the test, but showing some energy and effort can help you show interest in the job.
It's important to remember that from this point we're just wondering/assuming what could have gone right/wrong.
I believe the candidate is a great developer and that he should be motivated to learn from the experience and try again. Practice makes perfect!
We wish all candidates good luck in their future iOS Interview Experience and we hope this article gave you enough tips to help you succeed.
We’ve been helping dedicated developers to get from low paying jobs to high tier roles – sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.
Originally published at www.essentialdeveloper.com.
If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.