Optimizations

for getting that first junior position

New mobile engineers often ask me how to get their first job. And the truth is: it’s really hard. If you just came out of a bootcamp or you’re self-taught, you’re not in demand. There are almost no junior positions publicly advertised. Everyone wants a Senior Engineer (or at least someone with a CS degree.)

But it’s not impossible! It just takes time, tenacity, and careful planning. Don’t give up.

I myself have had a pretty charmed career and I don’t have a CS degree. I actually come from the theatre world which is a far more brutal business. Actors say, “It takes 100 auditions for every job.” When you’re a junior engineer, that’s true for you, too, and the interviews are hard to come by. But after 1–2 years of solid experience, the number of interviews you’ll need will go down to 10. And then when you’re more senior, you’ll have to turn off your LinkedIn notifications, you’ll have so many offers.

So, is there anything you can do to optimize your chances of getting a job?

Yes! A lot.

Over the years, both as a hiring manager and a mentor, I’ve seen a lot of bad hiring packets and portfolios. (And it’s always the same mistakes.) This article will focus on the fixes everyone can make to their resume, example app, and code sample. Think of it as An Optimization Checklist for Job-Seeking, Junior Mobile Engineers.

Disclaimer: These are my opinions. This is my article. It doesn’t represent the opinions of my employer or any other entity besides myself.

Do you have to do all these things? Nope! People have been hired without doing anything I’ve put on this list. And a lot of the things I’m going to recommend for the example app are actually kinda advanced or niche and not necessarily required by every job. But you’re not in a position where ‘just enough’ is acceptable. You need to out-shine all the other applicants. These optimizations will make your app look more impressive to a larger group of hiring managers (the people at companies that make the final decision to add you to their team).

Good advice for mid-level, too? Certainly. Full of opinions? Read the disclaimer. Good for Android? Sure. Most of my career has been iOS and Flutter, but this good stuff should help any mobile engineer. (Although, I will use iOS examples here.) Will it lead to a job? No guarantees. I can’t get you a job or even leads. You have to do that hard work for yourself. But do all this and you’ll probably have an easier time.

Is this what you should do if you’re applying to FAANG? NO. There’s already a lot written about applying to major tech companies (and companies that mimic their formal processes). As someone without a CS degree, your best bets for work are at agencies and startups (companies that often prize applied skills over theoretical knowledge.)

If you want to work at the big companies, that’s possible! I have and I was in your position once. Look on the career websites of those companies for information on that. Just know, it’s a whole other ballgame.

Ok. On to the recommendations.

Résumé

Don’t try to be clever on this one. It’s literally supposed to be derivative.

1: It has to be pretty

99% of mobile jobs are on the front-end. You will spend 99% of your time working on the part of the app that people see. Users don’t want ugly apps. Employers want to please users. You need to show employers you can deliver them something polished and design-aware. In fact, a lot of time, you’ll be working closer to your team’s designer than any other non-engineer.

I found this image on an article about resumes for designers. Just replace “Graphic Designer” with “iOS Engineer”. (And always say “engineer”. It’s more expensive sounding than “developer”.)

There are lots of resume templates out there. The template for my resume came from Pages. You want something pretty with a left column that’s about a third of the width that can hold your ‘at a glance’ info.

Make sure your text lines up, uses font sizes consistently, and your content has been checked for spelling. Then save it as PDF on your computer, your phone, Drive/Dropbox, and in an email to yourself. You wanna be able to find it when you need it.

Some will say that a beautiful layout isn’t scannable by resume scanning systems. That’s not a concern for you. You’re not gonna get work at the biggest companies. Your best chances for work are at digital agencies and startups. They don’t use Applicant Tracking Systems. They may not even have HR people.

Some recruiters will tell you to give them an all-text Word document version. They want that so they can replace your information with theirs. Do it if you think they can get you work. But most recruiters are useless to junior engineers. Recruiters are expensive. Companies that use them or contract with them are usually looking for experienced, trusted, senior engineers to bring a good return on that investment, not juniors.

Shady fact: recruiters will send you on interviews for senior positions even if you’re junior which isn’t really fair or fun for you. If you ever find yourself in that position, try to talk your way to an internship or junior job. But do not accept a position that’s actually meant for a senior or lead engineer. They’ll say things like, “Oh, we believe you can do it!” But you’ll have unreasonable expectations put on you, you will fail, and you’ll be job-hunting again before you know it.

Also, don’t accept a position where you’re the only engineer of your kind. You don’t know what you’re doing yet! Some sketchy people are desperate and will offer you a solo role. It’ll be so tempting. But you need mentorship. You need to work under someone experienced. That’s the whole point of the first job.

2: Keep it short

1 page. You’re junior. You aren’t supposed to have a long resume. If you’re coming in for a junior position and you have a long resume, they’ll be like, “Their resume is so long. Why are they still junior?”

Should you put your ‘projects’ / homework from bootcamp or school? No. If they are done for a class and everyone else is building the same thing, they don’t count and they junk up your resume. But do put that you had education at a bootcamp or vocational program and list the technologies you studied. And I mean literally list “iOS: Core Data, Core Animation, Objective-C, Swift, SpriteKit. General: git, Sketch” etc.

Should you put work from before you were an engineer? Only one. When you’re junior, it’s great to put down one office position (if you’ve had one) to let people know you can be professional and hold a job. But only one. Any more than that and they junk up your resume.

Should you put your college / degree? Yes. Even if it’s in music theatre. (It’s always a good conversation starter.) Even if you didn’t finish it. (You can just put the years if it’s incomplete.) Even if it’s at an off-shore, unaccredited, correspondence college. (No one cares where you went unless it’s Stanford, MIT, Yale, Harvard, or the college they went to. “OMG! I went to BoCo!”)

Should you put your GPA? No. Unless it was unbelievably high. 3.95+

Put a section with special skills, volunteering, interests, or just more information about you as a person. You want good conversation starters in that section. Hopefully someone who sees it will also have those interests or at least wanna know more.

3: LinkedIn, GitHub, Stack Overflow…

You need to have professional looking and sounding profiles on all public platforms. That means a clear friendly headshot where we can see your eyes (not a sultry pic or one of you with sunglasses mountain climbing.) Prolific Interactive (a digital agency in Brooklyn) does a great job with theirs. For job searches, look into the camera and smile at least a little. Save the silly shot for your introduction email to your new iOS team later.

You don’t have to have them done by a professional photographer to look great. Just put on a shirt with no text on it, go to a room with lots of sunlight and have a friend take a bunch of you from the waist up in different places. (Look at the pictures before you leave the room to make sure you got some good options.)

Make sure your name is the same on all of the profiles, set the job title to “iOS Software Engineer”. Avoid language that says “seeking” or “looking for positions” (it should be about what you are not what you need). That subliminally makes you stronger.

And clear away anything that you wouldn’t want your new boss to see. Speak respectfully in your questions, answers, and comments. Make only your best code repos public and pin them to your profile. Hide all the others.

I’ve pinned the 4 repos that I’ve done the best public work in, put a friendly headshot, and filled it out. Your bio line should say “iOS Software Engineer” because you’re looking for work. When you have a job, you can tweak it to fit your new position.

Of course, your resume doesn’t matter at all if you don’t have a great sample app.

Sample Apps

It’s almost impossible to get a job without an app. I always say, “My resume is the AppStore.” People make quick judgements based on very few artifacts.

Here’s how most hiring managers check out a prospective hire:

Download their app(s).
If they’re good and look like they’re built with the same technologies you need to hire for, ask for resume.
If no red flags, either interview or code sample or code challenge.

The else to all these conditionals is usually “get back to work and ghost the candidate.”

But you don’t have to overthink this app. Seriously. It’s just your calling card.

1: Don’t worry about brilliant ideas

Just make something that shows some skills and execute it well. I once had someone show me an app that just showed publicly available UV index information for where you are. But it had really cool animations.

Was it the next big thing? No. There are lots of ways people get that information if they want it. In fact, this app probably only had a handful of downloads ever. That’s fine! It’s just proof to employers that you can do this job. You’re not starting a business.

Try to include a sizzle feature like cool animations or video or AR or custom drawing if you can. Something exciting.

2: It has to look good

This part is honestly the hardest. You will need help or at least other people’s opinions.

Look at design websites or wherever people have published example designs. Look at the operating system’s apps. Look at other people’s apps. Don’t copy them. But check your ideas against them.

If you really feel like you have no talent for design, go for a minimalist aesthetic. Or retro.

Just do it perfectly. Here’s a checklist (some of which is good ideas for your resume design too):

Is everything aligned on a grid?
Is all text and iconography at a reasonable contrast ratio to its background?
Does your app respect platform expectations? (Seriously, don’t be creative with navigation. And use system fonts for small type: San Francisco on iOS and Roboto on Android.) Your iOS app shouldn’t deviate from Apple’s Human Interface Guidelines and it’s always a good idea for Android interfaces to be based on Material Design.
Are all visual assets high def? (Assets are images like icons and photos.) That means including all the necessary sizes for variable screen pixel density.
Does it look good on all supported devices? Smallest iPhone you support to largest iPad you support and everything in between.

I know that you aren’t a designer and this step will take the longest. It’s not fair but it’s true. If you have a designer friend, ask them for ideas and feedback. Chances are good that if you show them something ugly, they will want to fix it all.

And never forget that the answers to most of your questions are in the Material Design guidelines (which also has some cool code you can use) and Apple’s Human Interface Guidelines.

Now that the outside is taken care of, let’s talk about the inside.

Code

You should have the code for your app (except for secure info like API keys) in a public repo you own on GitHub with a nice README.md. It should be perfect and full of easy wins. The things I’m going to suggest here aren’t complex. But each one makes your app fancier, shows more skills you’d use on the job, and increases the chances you’ll be an impressive candidate.

Use this as a checklist. You need a job: do them all. At the very least, you’ll learn a ton.

JSON API HTTP calls
Your app has to talk to the internet. That was what I learned in my first rejection many years ago. What it talks to is up to you. You can have a custom backend that you or a friend built. Or use a publicly available service. Doesn’t matter as long as it’s showing HTTP calls. That means CloudKit and Firebase don’t count. (You can still use out-of-the-box backends like CloudKit and Firebase but include, somewhere, a couple calls to an HTTP service to show you know how.) It also doesn’t matter if you do it the hard way with NSURLSession or with a networking package like AlamoFire; they both require you to show basic understanding of HTTP methods, JSON decoding, and blocks.
MVC (The basics)
Apple sets up the V and the C for you. (You’d have to go out of your way to mess it up.) And when it comes to the M, you want to show you can keep the model out of the controller: don’t put your API calls in the view controller. Abstract the model into its own type and have a manager type that handles the model and the API calls. So, if your app is selling milk, maybe you have a MilkManager that’s a singleton and a method for buying x number of Cartons with a success block and a fail block. There’s a million examples of this out there for inspiration. (BTW: This is just one way to do this and it’s only scratching the surface of MVC. But it’s a common pattern. Sadly, almost no students come out of bootcamp knowing any way to encapsulate and isolate the different layers of an app.) Could you show MVVM instead? Sure. But it’s used slightly less than MVC and might be easier to learn after you understand MVC. Since this is a harder concept to explain quickly, I’ve created a sample app you can see in my GitHub repo that illustrates what I mean about basic MVC. Could you do dependency injection instead of a singleton? Absolutely, and be sure to mention that you did. It’s a $50 word for a 25¢ concept. Impressive. In the end, it just matters you keep things organized by purpose as much as possible.
Other language
iOS jobs are mostly in Objective-C and Swift (and in Java and Kotlin for Android.) Right now you have no idea which language your job will have you working in. So, show them both. Have at least one file (of substance!) that is in the language you are least comfortable with. Don’t just throw in a constants file in Objective-C. One of your view controllers or something like that should be in the other language.
Formatting / Style Guide
Style guides are formatting guidelines for code. They make your code more readable and much prettier. Be sure all your code is formatted according to a style guide. Don’t come up with your own style guide. Use one of the published ones like Google’s Objective-C style guide and Ray Wenderlich’s Swift style guide. But don’t try to read them. Just run command line tools that format your code for you. I’ve included a slightly modified version of the script we use in Material Components for iOS in my GitHub repo. If you run it from the root of your project (`.\format_all.sh`), it will go thru and reformat all your Objective-C and Swift code using clang-format and swiftlint. Run it every day. (iOS-Specific note: Also make sure that all your IBActions for buttons end with ‘DidTouch:’ like ‘submitDidTouch:’ or ‘cancelDidTouch’.)
Rotation
Support both portrait and landscape in your app. It’s not very hard (especially with Auto Layout). Here’s a tutorial on doing it in storyboards and here’s one for programmatic layout.
Dynamic Type
On an iPhone, if you go to Settings -> General -> Accessibility -> Larger Text, you can tell apps you want to see text larger. (Instructions for Android here.) This is the #1 used Accessibility (aka A11y) feature on mobile devices and on iOS we call it Dynamic Type. You can learn more in this article. I’ve also added labels in the example project that show you how to do it programmatically and in storyboard labels.
Minimum Contrast Ratio
Another easy win in A11y is making sure your content has a minimum contrast ratio to its background. That means making sure things like text and icons are much brighter or much darker than whatever they are in front of. (The luminance to luminance ratio of colors is called the contrast ratio. You can read all about it in the Material Design guidelines.) You want small text and iconography, like body text and system icons, to have a 4.5:1 ratio and large text, like titles, to have 3:1. Ex: you’re probably reading this body text as 84% black text on a white background. According to contrast-ratio.com, that’s a ratio of 14.58 which passes! You can learn more on using contrast-ratio.com in this Boring Development Show episode. tl;dr Make sure people can easily see everything in your app, measure it to be sure, and then you have something else to show off when you’re walking through your app with a potential employer.
Analytics
Businesses want to measure how their features perform. They do this by counting ‘events’ like particular button clicks or the viewing of particular screens. Add one event analytic to your app to show you know how. This could be one button click or even just the main screen showing. It doesn’t matter which service you use but Firebase’s Google Analytics is particularly easy to integrate.
Internationalization
Translate your app into another language. Or 3. You must know someone who is multilingual if you yourself are not. At the very least, use Google Translate. Here’s a Ray Wenderlich tutorial on internationalization.
Programmatic Layout (Some)
Not all UI is built with storyboards and nibs/xibs. (BTW: the part of Xcode that lets you edit those files in a wysiwig manner is called Interface Builder which used to be a separate application from Xcode.) At large companies, almost no UI is built with Interface Builder. As your team grows, it becomes easier to maintain programmatic UI. Put in something that is programmatic. Maybe a UITableViewCell subclass that’s all programmatic layout or a modal. I’ve included a programmatically added label in the example program. (Don’t forget to turn off translatesAutoresizingMaskIntoConstraints on your programmatically-added views in Auto Layout!)
No Warnings
Make sure Xcode is serving no yellow warnings in the Issue Navigator except for ones having to do with the build settings from CocoaPods. (You can’t do anything about those.) And I don’t mean for you to turn off the warnings. You need to resolve all the issues they present even if they are no big deal. For each of those issues, there’s an engineer who cares deeply about it. You don’t wanna be showing your app to them while you still haven’t fixed it.
Tablet
An easy win is making your app universal (supporting both iPhone and iPad.) This is a lot like supporting rotations. You can do it almost exclusively through Auto Layout in storyboards. But it’s very impressive. Just make sure it looks good and makes sense. Your UI should change with the new form factor. The same tutorial that is helpful with rotations will help you with supporting iPad.
Testing
Include at least 1 unit test or UI test. It doesn’t have to be profound. “Given the app launched, expect the home screen to show.” Here’s a tutorial on both kinds of testing by Ray Wenderlich.
Documentation and Comments
Make sure you’ve documented all of your new code (ie: Objective-C headers and Swift apis you wrote yourself). This includes classes, protocols, interfaces, extensions, categories, properties, constants, methods, and functions. Read your platform’s system header documentation for examples of how to write, what to document, and syntax. Documenting your code provides two benefits: your interviewers will understand your code better (and know that you do as well), and you can occasionally find bugs or think of better ways to do something. If it’s hard to describe what a piece of code does succinctly, you may find it easier to break it up. Bonus: there are tools that read your code’s documentation and turn it into great reference docs or sites. See this article on Doxygen by Ibrahim Ulukaya to learn about one of them.
Git
If you don’t know anything about git, read Kevin Miller’s article on git for beginners. Make sure your project is in a git repository that is saved to a remote service like GitHub or BitBucket. This will not only show your potential employers that you have a basic understanding of git, it will give you a way to distribute your code to recruiters and hiring managers. You also want a good .gitignore file. (The easiest way is to allow Xcode to initialize a git repo for you when you make your project but you can also find good .gitignore files on GitHub.) And don’t check in your /Pods directory. It’s generated. This will keep it clean.
Bonus: Simple data persistence (if possible)
If your project would benefit from it, it’s impressive to have data persistence. Especially if you save the data to files. Out-of-the-box solutions (Realm, NSUserDefaults, etc) are intended to be easy-to-adopt. But that’s ok; use them if you need to. There’s nothing wrong with them per se even if they are a little less impressive. Just don’t use Core Data. It’s far too powerful for whatever you come up with. Keep it simple. Here’s a tutorial from Ray Wenderlich on archiving to disk.
Bonus: Cross-platform project
Cross-platform tools are more powerful and impressive than ever. Try your hand at a simple Flutter or React Native project. Here’s a series of codelabs on Flutter. I can’t recommend Flutter enough. :)

This is a lot to do. But each thing in this article sets you apart from another candidate in the very competitive world of junior mobile dev. Do as much as you can, be tenacious, and get that job.

Advice for Junior Mobile Engineers Seeking Their First Job