How to get your first job as an iOS Engineer

Becoming an iOS Engineer is no easy feat. It’s a super competitive market with a demanding skill set. However, the reward of becoming an iOS Dev is so worth the struggle. Salary and benefits aside, you get to work on and build iPhone apps that will be used by millions of users. The people you meet along the way will further expand your knowledge both in and out of tech.

That said, I think most aspiring iOS Devs (or most new Software Engineers in general) don’t quite know what it takes to get that first job. After all, following Youtube tutorials is one thing, but getting an offer is another.

I recently accepted an offer for my very first full-time position as an iOS Engineer. I want to share a bit of my experience with job hunt & prep and what I would suggest to any Jr iOS Dev who is getting ready to take that first step.

Things to know before you prep for interviews

If you’re an absolute beginner, you should not be trying to work on interview prep, at least not yet. Instead, focus on the fundamentals. This foundational knowledge will be the bedrock for your development career. If your foundation is shaky, your building will collapse.

There are a couple of things you should absolutely be familiar with before you begin to prep for the interview.

Computer Science

If you want to be a software engineer, iOS or not, fundamental CS knowledge must always come first. These ideas are the building blocks for everything.

While this article is more focused on your interview prep, not your study roadmap, I will not break everything down here, but here are some concepts you MUST be familiar with

• CS fundamentals
• Object Oriented Programming
• Data Structures (Array, Hash-Map, Stack, Queue, Linked-List, Binary-Tree, Graph)
• Algorithms (Search Algorithms, Sorting Algorithms, DFS, BFS)
• Big-O Notation

Domain Specific (iOS)

Given that you are interested in applying to an iOS-specific role, it’s without question that you should be prepared for iOS-specific questions.

Before I break down what to expect from the iOS Specific questions, you should be familiar with the following BEFORE interviewing

• Swift fundamentals
• Basic UI (storyboard & programmatic, UIKit & SwiftUI)
• App Life Cycle
• Design Patterns (MVC, MVVM, VIPER)
• Unit Testing, POP, and TDD
• Networking
• Local Persistence
• Concurrency, Threading, & Parallelism
• Memory Management, Reference Counting, and ARC

Interview Prep

Of course, if you want to get your first job, you have to apply and go through the interview process. That process, along with the style of questions they ask, differs between each company. But overall, if you want to ace any iOS interview, there are a few areas you should be ready for.

iOS Specific Questions

As for what to expect for the iOS questions, there are actually multiple flavors in which these questions can be presented.

TAKE HOME PROJECT

The Take Home project is exactly what it sounds like. If you receive this style of question, the recruiter will give you a project/challenge and you will be given X amount of time to complete it and turn in your solution.

They could ask you to build an app from scratch, they may also provide you with some incomplete project and ask you to complete, fix, debug/refactor, or just do something to it.

Depending on your schedule and enjoyment of building something from scratch, you’ll either love or hate this one.

If you love building apps, then you will love this style of question. It allows you to flex your coding muscles and display your skill. Plus, there is no one-hour time limit, so you don’t have the stress of a clock looming over you as much as a live interview.

If you have a busy schedule, this might be a bit problematic because these styles of questions take up A LOT of time. If your interview is generous you may be given a week to complete it, but some might ask for a solution within 24 hours. If you do get this question, make sure you clear your schedule and get it done asap.

This style of question isn’t too common, at least not as much as the other two. During my job hunt, I interviewed for 19 companies, and only 1 gave me a take-home project.

iOS CODING CHALLENGE (CODER PAD)

For this style of question, you will likely be paired with an Engineer from the team you are applying to and be asked to complete a simple iOS Coding Challenge.

A common example of this could be “given this URL, display the data onto the screen” A question like this will test if you are comfortable and knowledgable writing a networking layer as well as creating a UI interface.

Keep in mind that you are being proctored during this challenge, so your communication is also super important. One mistake most interviewees make is staying quiet and building the perfect solution. Remember, they’re not just trying to find out if you have the technical skills needed for the role, but are you, someone, they want to work with? It’s super important to verbalize your thought process and solution.

Feel free to ask questions as well. If part of the question is vague, you can ask for clarification. If there is a bug, work with your interviewer. They want to hire you, so show them that you would be a great partner to collaborate with.

SIMPLY ASKING “DO YOU KNOW…” OR “CAN YOU EXPLAIN…”

This style of question is most common at the very beginning of the interview process, usually via phone, to weed out the noobs who don’t know their iOS knowledge.

These are more trivia-style questions and are used as a warmup to the rest of the interview. The questions are usually pretty simple, but sometimes you will be asked a more difficult one that requires you to think. Some common examples of this type of interview question are:

• What’s the difference between a class and a struct?
• What’s the difference between frame and bound?
• What is ARC?
• Explain the importance of background threads.

Data Structures and Algorithms Questions

The data structure and algorithm questions are probably the most standard and traditional format of questions for Software Engineers. This aims to assess your computer science skills and problem-solving ability.

Basically, this is a LeetCode-style question.

Similar to the iOS Coding Challenge, you will be paired with an engineer and code your solution live. Take full advantage of this. Ask for questions. Vocalize your thoughts. Demonstrate your communication skills. Show them that you are not just a good coder, but a pleasant person to work with.

Here are some helpful steps for tackling this problem:

1. Restate the question, and make sure you understand it.
2. Ask clarifying questions
3. State assumptions
4. Edge cases
5. Answer problem in English (maybe pseudocode while you do it)
6. Code your solution

System Design

Usually, system design is a more mid-senior level question, but I’ve had a couple of entry-level positions ask me this, so I’ll be including it.

This is NOT a coding challenge. Rather you’ll be given a super open-ended question on how you would design an app. For example, “How would you design an Instagram feed?”

For this interview, you will primarily be talking and explaining your thought process for how you would build this app. You have to figure out what all the key features are, as well as how you are going to separate your concerns and organize your code. How will different modules communicate with each other? What module will depend on what?

This is what you already do every time you build a new project and decide how you are going to organize it.

Don’t stress out too much about this interview question. Have fun with it. Don’t see it as the interviewer judging you to see if you can solve their question, but think of it more like you are a friend have a product idea and you’re brainstorming how it will work.

Behavioral Questions

This is basically your interviewer asking you open-ended non-tech-related questions. More than anything, the purpose of this question is to determine what kind of a person you are. They want to know

• How would you behave in a collaborative environment?
• How do you resolve a conflict?
• Do you have a growth mindset?
• Do you embrace ambiguity?
• Do you drive results in the team?
• Do you communicate effectively?

Here are some example questions:

• Tell me about yourself
• what is your greatest strength?
• What is your greatest weakness?
• Describe your most challenging project.
• Tell me about a time you had to manage conflicting priorities.
• etc.

You don’t want to ramble on and on when you are answering. Keep it concise. Use the STAR method to structure your answer.

S — One or two sentences about the SITUATION: What happened?

T — Describe the TASK: What was your specific goal?

A — ACTIONS you took to overcome the obstacles & complete your objective.

R — The tangible/quantifiable RESULTS of the situation: How did it help the team/company?

Helpful tips while studying

Give yourself enough time to study

Don’t rush your interview prep. Give yourself enough time to really practice and get used to the material. Personally, I advise you to study 1–2 hours per day for 8 weeks BEFORE sending your first application. This should be enough.

Study with a buddy

Studying by yourself can get boring and unmotivating. Having a friend study with you will keep you motivated and you can help and challenge each other to go further. It’s also important to practice your verbal communication for the interview, so having a person to speak with will keep you from building the habit of coding quietly.

Do Mock interviews with each other. It best simulates the actual interview environment. Take turns.

HOW SHOULD I STRUCTURE MY STUDY?

Do one topic at a time and spend that week practicing that one topic.

Binary Tree Example:

• Monday: Build a Tree from scratch
• Tuesday — Thursday: Do Leet Code problems about binary trees.
• Friday: Mock Interview (1–2)

If you think 1 week wasn’t enough to fully understand the subject, do another week. Don’t leave gaps in your knowledge. Aim for mastery.

Have a great application

Now, being prepared for the interview is one thing, but having a recruiter look at your application and invite you for an interview is another.

You probably heard of the work experience paradox. A lot of “entry-level” developer jobs require a few years of experience, but how can you get experience if you can’t get an entry-level job?

Since you are a junior dev, you probably don’t have very much experience on your resume. That’s okay. You can make yourself attractive to recruiters in other ways.

Make a Resume and LinkedIn

This should come as no surprise; if you are applying for a job, you are submitting your resume, and for recruiters to find you, you need a LinkedIn. Keep the resume concise and focused, only putting absolute relevant information; it all should fit on one page. Your LinkedIn can be a bit more personalized with even more details.

Highlight Internships

If you’ve had the opportunity to intern at a company, highlight that. This is an example of real-world experience. It shows the interview that you have the actual industry knowledge and have worked with a team before.

Highlight your education

If you are a college student majoring in Computer Science, highlight that! Recruiters want to know who is skilled enough for their position. If they see that you’ve been studying computer science for 4 years, they know you at least know something. While a college degree is not required in the tech industry, it is still nice to have.

If you studied in a coding Bootcamp instead, highlight that! Many companies hire from boot camps, they have a lot of networking connections and students usually are knowledgable enough to begin working.

If you are self-taught, the tip below will be doubly important for you.

Build (and publish) your own projects

Passing an exam and getting an “A” is one thing, but that is mainly just textbook knowledge. Do you know how to build something real? Personal projects are a great way for you to implement what you’ve learned in class or on your own. Studies have shown that the concepts you use in your personal projects vs just reading from a textbook helps you to better understand that concept.

It also gives you the chance to have some fun and show off something cool. Your learning is actually linked to your emotional state of mind. If you are building an app that excites you, you are much more motivated to complete it and do it well.

This can also be something you get to show off to your interviewer and can be a great talking point.

Networking: making connections

Part of finding a job isn’t what you know, it’s who you know. Your odds of getting your application and interview process rolling is to have a referral. Basically, if you want to work at Google, and if you know someone who works at Google, they can refer you directly to the hiring manager, and kickstart your interview. This is by far the best way to apply for a position.

If you don’t know anyone in the industry, talk to people. You can find people’s contact info via LinkedIn. You can just go onto their portfolio, find their email, and email them an invitation to an informational interview where you can ask them any question you want. Make it easy and convenient for them. Do this with Engineers, recruiters, or hiring managers to build your relationship with these people, so when it comes time to submit your application, you now have a connection inside that company.

Get used to rejection & don’t put all eggs in 1 basket

Getting a job is hard, even if you do all the prep. I’m not going to ignore that fact. When you finally start applying to jobs, it’s likely you will face rejection, and I mean a lot of it.

When I was applying for jobs, I submitted a total of 67 applications. Of those 67, only 19 invited me into the interview process. Of those 19, only 7 invited me to a coding challenge. Of those 7, only 2 invited me to an on-site. Of those 2, only 1 extended me an offer. And these are “good” ods. I’ve heard horror stories of developers applying to nearly 200 jobs before finally landing on one.

You’re going to get rejected, so get used to it. Don’t get overly attached to any one role. If you put all your eggs in one basket, and it breaks, you lost everything. At the end of the day, you are not in control of the hiring decision, so don’t bother worrying about something you can’t control. Focus instead on what you can, your persistence. Treat job hunting like a numbers game. The best way to get better at interviewing is to interview more.

It may take some time, and you may feel disheartened, but be persistent and you will finally get that job you want.

I advise first applying to jobs you don’t particularly care about as a practice round, and once you got the hang of interviewing, then apply to your dream jobs.