How to deal with the dreaded live coding interview
Live coding interview tests can be daunting but are there to test a developer’s ability to solve certain problems. If you can present yourself well you often don’t even have to complete the test to pass the interview round.
The dreaded Interview Scenario
You’ve just hung up the phone with your recruiter who has made you aware you have passed your first round phone conversation and are asked to come in tomorrow for a live coding test. You try to get clues on what the test may be about and you get told to refresh yourself on UIKit and to bring your a-game. As if that was enough to calm your nerves and prepare you.
So without a real sense of direction you revise the differences between weak and strong references, you bring up the unwieldy UICollectionView documentation to remind yourself how collection view layouts work, how to animate stack views remembering to use the isHidden property; trying to guess what you don’t have to revise thinking questions about UITableViews could possibly not show up so you skip that part since you have it covered.
You show up on the day, say hello, exchange questions meant to judge your character when suddenly the lead developer walks in and it’s time for your live coding test. You’ve been blindsided. They ask you to do a live coding demonstration on how to implement self-sizing UITableView cells.
You look at the computer and your mind goes blank as you have forgotten how to simplify the task.
You start realising you’ve forgotten how to subclass a cell properly without relying on your fancy generic utility classes,
You forget how to best structure a datasource without relying on fancy paradigms you normally trust such as MVVM cell view models and so on and you say to the lead developer, I promise I know how to do this, it’s just I normally do it like this, or like that.
For the purpose of this test you concoct a fairly realistic example of an app that presents a list of articles with a title and a body in each cell. You sit quietly and churn away. You look stressed as you battle with Apple’s api and before you know it the interview is over and you get told you can finish the test at home and you never hear from the developer again. It all went wrong.
The problem with these kind of scenarios is that you’ve treated this test as though it were hackathon with minutes to spare to the deadline. We have all been in interview situations like this. There’s just no good that can come out of it when you’re stressed, and anxious. These tests most of the time are there to gauge your ability to explain the problem at hand, your ability to effectively communicate your thoughts and what you’re doing aloud. That’s all it takes! If the employer can see that you understand the problem; that you’re not aimlessly typing; and that you’re executing the task with a plan in mind you’ll often find that it doesn’t matter if you don’t finish your live coding test. The interviewer will see a coder who thinks before they code, a coder who will have fewer tickets returned to them because of a coding error, and coder who thinks about multiple solutions before they even begin! Who wouldn’t want a developer like that?
So the next time you have a live interview coding test do the following:
1. Take your time: you want to come across as a composed developer
2. Interact with the interviewer: ask questions about the problem scenario, don’t just assume the edge cases
3. Speak aloud as you code: explain why you’re tackling the problem in a certain way
4. Be the driver, be the coach: Treat the coding test as though you’re in a live pairing session where you’re the one driving and teach the interviewer as though they were a junior developer so that you come across as a person who likes to share knowledge.
Being composed and confident goes a long way in these sort of scenarios. Good luck in your next live coding test!
I hope you found this article useful. You can find me on Github here.
