In our first installment, we discussed some of the more frequently asked questions by aspiring devs and we explored a bit of what managers usually want to see in order to grant you an interview.
In our second installment, we explored what to do once you do get an interview. There’s different types of interviews and different behaviors you should adopt for each one.
Today we’ll explore the interview type that is on the rise: the take-home test.
Why is the take-home test becoming more common?
Programming used to be very difficult to get into. We only need to go back a few years to understand how difficult it was to get good programming information. Hacking with Swift? Founded in 2014. Stack Overflow? Founded in 2008. Right off the bat, if you wanted to learn to program in the last 10 to 12 years, you’d probably need to be extremely gifted, or live in a household with programmers, or go to college. These weren’t your only options, but they were the most common.
Today, you can pick up a used Mac from eBay, download Xcode, fire up Youtube and start learning.
This dramatic change has had consequences for all companies. Previously, you’d need to pass a complex interview solving Computer Science (CS) problems in a whiteboard. Reverse a singly-linked list without using recursion. Why? Well, because if you’re a real developer, you know about CS.
Now? A decent iOS developer may have very little CS knowledge. It’s way more important for app developers to understand the ecosystem, the frameworks, the language.
And companies have noticed this. So instead of asking you CS questions, they’ve began to judge candidates by their ability to perform the job they would be hired for. Along with skipping CS fundamentals, part of the industry has gone ahead and completely removed the synchronous part of the interview. This is because they have placed value on quality over speed. Judging a good candidate by how quickly they can think on the spot is a terrible idea, especially if, as a developer, you take your time to think through solutions and not just spew them randomly.
A lot of big companies, like Basecamp, have adopted take-home tests and they have seen great success.
How to ace the interview?
Take-home tests are usually a 2-part interview.
The first part consists of the take-home test itself.
A take-home test is, in essence, a self-contained exercise that the company thinks will be a good assessment of your skills. Tests are usually simple enough to be completed in a few hours. Most tests I’ve taken vary between 2-8 hours. To ace a take-home test you need to balance three things: the minimum requirements, the time it takes you to code, additional flare.
These tests will usually have a list of minimum requirements that you need to fulfill: pass some unit tests, print something on console, build a small UI for a backend. The requirements will usually come in a ReadMe file or in an email. However, it’s extremely important for you to understand that a take-home test is an interview in an of itself. Fulfilling the minimum requirements is like attending an interview; it’s the bare minimum.
During a take-home test you should be careful to meet the requirements but also try to have your code stand out. How?Take care in finding out the edge cases and, at the very least, add a comment or a print statement.Add animations or loading views if you’re using network calls.Make your code clean and modular using Dependency InjectionAdd comments explaining your design decisions.Finally, if the take-home test says it should take you 4 hours, don’t go too far past the 4-hour mark. First, the interviewer is a more experienced developer than you are. It’s very likely they’ll know you went beyond the time limit. This shows that you don’t know how to follow instructions. Second, if they don’t notice, you’re setting up yourself for failure because they’ll be expecting a higher output than you’re used to.
The second part consists on the face-to-face interview
If you followed my advise and you managed to code something clean that stands out among other applications, you’ll either be called in to explain your code changes or move to the next stage.
Either way, you should be prepared to explain design decisions that you took in your project. Be sure to understand the why you did something and not just do it mechanically. For example, one of my beta testers for the mock interview I designed told me they just used DispatchQueue to update the UI, but couldn’t explain why. It may not have cost him the job, but it certainly didn’t help.
During this part of the process, the interviewer is trying to find your strengths and weaknesses. They have a general idea of both by seeing your code, so be prepared to answer difficult questions.
The last piece of advice I can give you is that it’s ok to say “I don’t know”. As an interviewer, I want to know your limitations and that means you must be ready to admit that you haven’t used a framework or the you’ve never seen a certain architecture. Developers are fantastic at detecting bullshit. Don’t try it.
I said it before, but I’ll say it again: the interview process is, at its simplest, a popularity contest. You want your interviewers to like you and you want to demonstrate that you’re the person for the job. Be polite, be humble, and make sure to speak up when you need to.
Well, that’s the end of the series. I hope that this was informative and that it helped you build your game plan for your next interview. All I wrote is a good foundation, but you will see variations of every step as you interview. Keep notes and you’ll do great.
Remember, it’s about grit. Keep trying and keep moving forward.
In case you do want to practice your take-home tests, I’ve designed a mock interview with a video solution and a commentated “real” interview with me as the interviewer.
Mock Interview: iOS Networking
iOS Mock Interview: Networking is a 1-hour take-home test I created based on my experience as an iOS team lead. I have used this same exercise to assess candidates’ skills when hiring up-and-coming developers. It is a test on architecture, generics, networking, unit tests and general code hygiene.
It is a take-home test with a video solution, so you can easily see what a Senior would code to solve the test. In the video, I explain why the take-home test is great at judging an interviewee’s abilities as well as go through how I would explain each part of the code during a code review.
It also has a nice bonus video: a one-on-one session between a junior developer and myself where I explain in detail the common pitfalls that they fell into and how to avoid them.
Both videos are rare peeks into how a real interview would take place.
I also send interesting iOS-related news and interviews from members of our community. Subscribe to improve your coding skills! Follow me on my weekly mailing list and I’ll keep you posted!