How to ace an iOS developer take home test

Recorded May 2nd 2020 – watch the full episode on YouTube.

So when it comes to doing a really good job on a take home test, what are your top three tips for really acing it?

Sean Allen: So my first tip is superficial, right? I think you have to have a great looking clean UI. Because again, I don't know, I tend to lean towards in just general programming terms, again, creating a great product. That's my number one priority.

The sad thing is people do judge a book by its cover. So if you have an amazing looking UI from the start, in my opinion, that's your first impression. So you're automatically starting up here, and if your code sucks, then you just slowly fall down, but you started up here. Whereas if your project is ugly, you're starting down here and now your great code has to dig you out of a hole. Right?

So that's why I like to focus on the UI to start off pretty high with that first impression. Then hopefully, the code backs it up and goes even higher.

“Take the time to proofread your code. Just like if you were turning in a book report, you're not going to just scrap it together and turn in your rough draft. Go through, make sure your spacing is constant, your indents, clean up comments and print statements.”

Another one is, surprising enough to say this, but I do, based on experience is, take the time to proofread your code. Just like if you were turning in a book report, you're not going to just scrap it together and turn in your rough draft. Go through, make sure your spacing is constant, your indents, clean up comments and print statements. Right. I've seen take home tests get turned in that literally had full functions commented out, and code was just so messy.

The reason why I like code cleanliness and readability is because remember, you're most likely applying to be on a team. When you're on a team, your code readability and ease of understanding is in my opinion, just as important as the functionality of the code. Because other people have to work within your code and deal with your code. So that's very, very important.

And then the last tip, we kind of touched on this before, but that's the handle, the edge cases, and the errors, right? If you just have a simple email form, can your email handle all kinds of random emojis and characters. It shows that you're taking the time, like you mentioned earlier, Paul – you have the foresight to think about this stuff. Because honestly, thinking about edge cases and handling errors, that's where most of the hard work of programming comes in. Building the happy path as they call it, that's the easy part. Handling all the crazy edge cases, that's where it gets tricky. So if you can show that you're thinking about that stuff, you can handle that stuff, I think that goes a long way.

“Honestly, thinking about edge cases and handling errors, that's where most of the hard work of programming comes in.”

Paul Hudson: I certainly agree. I think in SwiftUI, Apple has managed to make the perfect WWDC framework. You can go on stage and it just looks brilliant out of the box. Like, wow, amazing, easy, easy, easy. And when you start using in practice, you realize those edge cases kick in extremely hard and extremely quickly right now. It'll get better in SwiftUI 2.0 hopefully, but right now, there are a whole bunch of edge cases that does not handle very well at all. And as a result, that kind of thing, it's a hard thing to do in a take home test, because you want to build it and it is robust.

I'd rather ship a simple app that covered the areas across the board, had great accessibility everywhere, had direct type or whatever, had a really nice testing and commenting rather than go whiz, bang, pop, super cool, and have edge cases all over the place I haven't bothered covering.

"If you can't get to all the edge cases, that's another great thing to throw into that paragraph of like, these are the edge cases I would have handled. That at least shows that you thought of all these edge cases, whatever they may be."

Sean Allen: Back to kind of reiterate the point we talked about earlier, if you can't get to all the edge cases, that's another great thing to throw into that paragraph of like, these are the edge cases I would have handled. That at least shows that you thought of all these edge cases, whatever they may be. Even if you didn't take the time to actually implement the fix for them, you at least took the time to think about them.

Sponsor Hacking with Swift and reach the world's largest Swift community!