独家优惠奖金 100% 高达 1 BTC + 180 免费旋转

I followed these 7 simple steps and became an iOS coding test BOSS!

So you took the bait. Your route to success starts here! 🤑 But unlike the many get-rich quick schemes promised on the side-panes of particular websites, I hope to actually deliver on my click-bait.

When completing an iOS coding test, there are a number of simple ways to make your submission stand out and give reviewers confidence that you know what you’re doing.

The common theme here is:

By following the suggestions below, interviewers will barely need to look at what your code actually does. Good programming techniques can be taught after you’ve landed the job. It’s more difficult to teach someone to love their code. But it’s so important! After all, you shouldn’t need to be taught this, given this is your chosen career. 🤓

I don’t want this article to come across as arrogant; I’m not suggesting going through a company’s hiring process is easy. I just want to help people that are completing coding tests to make their submission the best it can be. I think there are a few very simple ways to do that.

It shouldn’t take a long time to make a simple app as part of a coding test—depending on experience of course—but you don’t want it to appear rushed. Show your code the love it deserves. It’s easy to keep your code clean and it all starts with the app delegate.

Usually known as the AppDelegate, this is the entry point into your app. As such it’s the first place interviewers look. If your code was a book, this would be the first page. Show it the love it deserves and an interviewer will love it too.

For a simple test, your AppDelegate could look as simple as this:

The window property is required if you’re loading your interface from a storyboard. You don’t have to load your interface from a storyboard, but for a short coding test it’s the simplest thing to do. It’s the default when creating a new Xcode project and you probably won’t be required to create too many screens in a simple test. There are advantages to loading from a .xib, but the pros and cons are something you should feel confident talking about at interview stage rather than demonstrating in your test submission.

The AppDelegate.swift file that’s created by default with a new project comes with a load of commented-out method implementations that don’t do anything. Get rid of them. This rule should be applied across the whole of your project’s codebase…

By empty methods, I mean methods that only call the super class’ implementation and/or only contain comments. These are usually methods that were created for you by Xcode when you created a file from a template. If you don’t need these methods then delete them.

This is what a UIViewController subclass will look like when you create it:

The first thing you should do when creating this file is delete the template code. You’ll know if and when you need to implement viewDidLoad and you’ll know to call the super implementation (well, you should know). Don’t clutter your codebase with comments unless you think they will benefit the prospective employer reviewing your code. They probably already know that the viewDidLoad method is where you “do any additional setup after loading the view.” So remove the comment and remove the method if you don’t need it. (And of course, remove the comment block that includes the prepare(for:sender:) method.)

Before submitting a test, go through the codebase with a fine-tooth comb for any code that you wrote as part of “work in progress” that may no longer be needed. If code is no longer needed, don’t just comment it out, delete it. It’s also best not to leave comments to explain what you’re doing. Code should be self-documenting, so if you find yourself leaving a comment, instead try to find another way of writing the code to make it more clear what’s happening. Often this is as simple as moving the code into separate method.

Another place to look for redundant code is in your unit test target. If you selected to create unit tests during project initialisation, that’s great, but please don’t just submit the auto-generated template methods. It’s such a tease for the reviewer that wants to see tests. If you don’t need the setUp and tearDown methods, delete them. Reviewers don’t want to see the below submitted as part of a coding test.

It’s not always easy to make something simple. Making something simple is a challenge and when doing so, you’re doing it for the benefit of the consumer:

The last point there is much simpler than the others. Making a simple user experience is a challenge. Making a test project simple to review should be simple itself. You don’t need to demonstrate your knowledge of every architecture pattern under the sun.

You can talk about your love of MVVIP-UPVCA at interview stage. 😎

Being pragmatic is important in programming. You need to determine when an elaborate architecture is appropriate. For an app of two or three simple screens, it’s probably overkill. Don’t just keep it simple, make it simple.

It’ll be better use of your time to group related files into Xcode groups (and therefore directories on disk). This is another great way to show the reviewer how you keep yourself organised and it makes reviewing your project a breeze. But again, don’t go overboard. If every .swift file is in its own group then you’ve misunderstood the definition of grouping. There are lots of different ways to group and there’s no right or wrong, within reason. For a simple project, I suggest grouping your model objects together; grouping any networking/backend-related components; grouping user interface components by feature/screen. Go with what you’re comfortable with and make sure you have a rationale for how you’ve organised your files.

Removing empty methods also contributes to making your app simple to review and the methods you have should be kept as small as possible. To “keep methods small and files smaller” is an impossible challenge, but I dare you to try.

There’s no need for three or more levels of indentation. Instead call out to another method. Because methods are named, they make your intention much more clear than yet another level of indentation. If you’re calling out to another method in the same file, you should declare that method private…

Demonstrating that you understand access control and mutability can go a long way with reviewers. Don’t give them anything to find fault in.

This is Swift best practice 101:

If you’re unsure on any of the above, go with the most restrictive first (private, let, final) and increase flexibility only if really needed.

For example, if you’re not sure what should be private, then make everything private, hit Build and see what fails to compile so you know what must be exposed. Any code that isn’t private should just be left with no access modifier at all; no need to declare anything internal as it’s the default and it’s unlikely you’d need to declare anything public in a coding test. But anything that can be private should be.

Any views or subviews (such as those declared with the@IBOutlet decorator) should definitely be private. Incidentally, @IBOutlet properties are the only excuse for implicitly unwrapped optionals or any type of forced unwrapping/casting. I’m referring to the dreaded exclamation mark…

“Unconditional unwrapping” (or forced unwrapping) is where you incorrectly assume an optional won’t be nil at runtime. A common example is retrieving the first or last element in a collection, e.g. let heroImage = images.first!. Always assume the worst. Even if you’ve set the images up from a static list, you cannot guarantee it won’t crash at runtime. Always assume the worst! It shows that you understand the use of optionals and you understand that just because it doesn’t crash now, that doesn’t mean it won’t crash if someone changes the code later. Use if let or guard let syntax to ensure you have the non-optional you require.

Forced type casting is where you incorrectly assume one type can be treated as another type at runtime. A common example is when reading from a [String: Any] type dictionary. You’ll read values like so:

Using as! is dangerous. Even if you’re confident it won’t crash at runtime, you don’t have the guarantee of Swift’s strong type system. So always assume the worst and safely unwrap these using as? like so:

Implicitly unwrapped optionals are those declared with a ! next to their type when originally defined. A common example is a view model that you will provide later, so you know it’s gonna be there, right? Right?! Wrong! Implicitly unwrapped optionals are a lazy hack to get your code to compile, e.g. var viewModel: ProfileViewModel!. The exclamation mark on the end tells the compiler you’ll give this a value later and it can assume it won’t be nil, so the compiler won’t require you to do the if let/guard let dance. But it’s dangerous. You can avoid this either by declaring your property as a normal optional with ? after the type, or by ensuring the property is passed in on init, so you don’t have to use an optional at all. The latter is preferred because it means you can declare the property with let and you don’t need the if let syntax because you‘ve explicitly defined that it cannot be nil.

If you don’t follow any of my previous suggestions, you should at least follow this one. My previous suggestions are code-related and following them will make your submission stand out.

This suggestion will ensure the reviewer actually looks at the code you’ve slaved over and doesn’t just reject it immediately.

The first thing I do when reviewing a test submission is to run the app in the simulator, so you should ensure your project:

Then make sure your project meets the requirements laid out in the test description. Check each of the requirements and double check that you’ve covered them.

If you don’t understand any of the requirements given to you by a prospective employer, you should check with your contact at the company. Don’t make them feel bad for not explaining the criteria clearly enough, after all you want them to give you a job, so be nice. Politely ask for clarification and feel free to go back and forth as much as necessary until you fully understand what’s required of you. This demonstrates a collaborative way of working.

If you cannot meet the requirements, don’t worry too much, presumably it’s due to a lack of experience and that’s fine! There’s always something to learn, so don’t worry! Explain the difficulties and explain what you tried. Write it up in the README.md file or in an accompanying email. If you notice bugs that you don’t know how to fix, let the reviewer know and hopefully they’ll work with you at interview stage to find a solution together.

If you don’t explain, then the reviewer will have no choice but to assume you either missed the requirement(s) completely or chose to ignore them. Both of which are equally as bad.

Once you’re happy you’ve met the requirements and your codebase is as clean and tidy as it can be, then you’re ready to submit, right? But…

You’re applying for a developer role and you want to make apps, right? So make an app! An app has an app icon. Sometimes even a catchy title. Show that you take pride in your work.

You wouldn’t upload an app to the App Store with no icon, so why treat a job application any differently?

The same applies to the app name. Perhaps this isn’t so important, but why not surprise the reviewer with a creative app name. Don’t include the word Test in your app name. You wouldn’t submit to the App Store with this name and it can get confusing with test targets which by default append the Tests suffix (e.g. RecipeCodingTestTests). If you’re asked to make a recipe app, show your creativity with the app name (unless the requirements state otherwise)… Recipeasy, Recipe Idol, Recipe For Me, Bake With XYZ where XYZ is the company name to which you’re applying. These are all better names than RecipeCodingTest.

Pretend you’re wrapping up your project ready for the App Store, but also for others to collaborate on in future. Of course this won’t be the case with your coding test, but in reality it’s very unlikely you’ll be working alone once you start the job. Adding a README.md file isn’t always required, but it’s so easy, so why not? You only need the project name and brief description. But for the purpose of the hiring process, you could use the readme to describe any challenges you faced or anything you’d do in the future, i.e. a project roadmap or TODO list. If you write a TODO list, ensure it lists future features that you’ve thought of yourself, features that are out of scope of what was asked of you. Don’t submit an incomplete test or explain that you ran out of time. And remember the readme is for project collaborators (i.e. the reviewer). The readme is not an App Store description for your users.

While you’re applying the polish, it’s as good a time as any to check that any images in your app are not stretched. Set any image view’s content mode to “Aspect Fill” in Interface Builder or set it to .scaleAspectFill in code.

I believe the above suggestions can followed by anyone, regardless of experience. But there are of course lots of things you can do over and above this to demonstrate more experience if you have it, such as demonstrating an understanding of Git, unit testing, UI testing, Fastlane, SwiftLint and “hot” language features such as Codable.

Whether you are actively applying for jobs or you’re recruiting and reviewing tests yourself, I hope you found this article useful. Please share if you think others will find it useful too!

Add a comment

What is your view?

Send

Related posts:

Defeated

when you feel defeated. “Defeated” is published by Yan.

Increasing Customer Satisfaction Using Social Media

Businesses are battling for loyal customers more than ever. As consumers are demanding more and more from businesses, brand loyalty is becoming harder and harder for businesses to achieve. When a…

How social media complements sales

By helping your business connect and engage with your customers.. “How social media complements sales” is published by Naveen Sivakumaran in Naveen Sivakumaran.