With more than 15 years of experience, I have been a hiring manager and interviewer for small start-ups and Big Tech companies in the US and Europe. I have interviewed hundreds of Android and iOS developers, backend and frontend engineers, Tech Leads and engineering managers. Whenever I have to fill a new role, I get to review more than 50 candidates’ resumes. In big companies, this number grows exponentially.

I have seen many candidates make the common mistake of thinking the interview process starts with the first call. In reality, it starts earlier, when your resume lands in the recruiter’s inbox.

Your resume (or LinkedIn profile) is the key to opening the door to that dream job. It won't land you the job, but it is undoubtedly decisive in whether you get a chance. So, trust me, it's worth investing time refining your resume to stand out from the hundreds (thousands in BigTech) of candidates.

Let's boost your resume with ten simple tricks.

1. Focus on technical skills and experience.

Most recruiters and hiring managers do not read your resume. They SCAN it. They look for specific technologies, skills, and experience levels to quickly identify candidates worth considering for a role.

Make sure your resume highlights your experience and skills with concrete and specific examples. So, a reader can easily pick them up by scanning through it.

2. Don't describe the role. Highlight your direct contributions instead.

Most companies, and therefore people hiring for them, are already familiar with the roles (e.g. iOS Developer, Senior Android Engineer, Tech Lead, etc.). Please save your readers time describing the role for them.

Instead, highlight what you achieved and learned during that time in a few bullet points.

From

Senior Android Engineer @ Acme LLC (Sep 2020 to Present)

I was a senior Android engineer in the payments team. I worked on the company's Android app, developing new features following scrum and agile methodologies. I worked closely with other engineers, designers and product managers to define and implement new requirements. I proactively contributed to tech improvements in the codebase and documentation. Fixed several bugs to keep the app stable and helped improve technical documentation

To

Senior Android Engineer @ Acme LLC (Sep 2020 to Present)

• Developed business-critical features in the payments team, like the redesign of the paywall, which I led
• Increased the robustness of our networking layer by refactoring it to use Retrofit with Coroutines
• Documented the MVVM architecture followed with guidelines and examples

3. Back it up with data

Use data points to help the reader understand the impact and value of your direct contributions. Doing something great is fantastic but meaningless if you don’t help the reader understand why it was so amazing. Explain what you achieved and why it was important for you, the team or the business.

From

Senior Android Engineer @ Acme LLC (Sep 2020 to Present)

• Developed business-critical features in the payments team, like the redesign of the paywall, which I led
• Increased the robustness of our networking layer by refactoring it to use Retrofit with Coroutines
• Documented the MVVM architecture followed with guidelines and examples

To

Senior Android Engineer @ Acme LLC (Sep 2020 to Present)

• Led business-critical features for the app's payments team (XM MAU, >$Yk monthly)
• Delivered a redesigned paywall to reduce friction. Increased paid subscription conversions by 30% (+$Zk monthly)
• Reduced app crashes by 20% by simplifying the networking layer with Retrofit and Coroutines
• Documented the app architecture (MVVM), creating more than 10 high-quality guidelines and several code examples and templates

4. Keep it brief and to the point

A well-known rule is to limit your resume to one page. I'm not joking. I know hiring managers who do not read past the first page.

For more senior folks with 15+ years of experience, list the 2-3 most recent roles. A good rule of thumb is to cover your last 2-3 positions or the last 8-10 years, focusing on the roles and experience most relevant to the job. If you’re applying for a Director of Engineering role, listing your summer internship 20 years ago is not applicable (despite how much fun it was and all the fantastic things you learned, I get it 😛)

5. Real estate is expensive; use it wisely.

Now that we have established the one-page rule. If you are having issues adjusting the length to the above rule, here are a few tips and common mistakes to avoid:

• For each role, mention your top achievements. List only your most relevant achievements in each role (3-4 bullet points per role).
• Reduce details for older roles and education. This is particularly true with seniority. When you're a recent graduate or have less experience, it's okay to have details on your degrees and school projects. It becomes less relevant as you accumulate hands-on, on-the-job experience.
• Push down and prune the rest. Side Projects, Certifications, Open Source Contributions, Interests and Hobbies are relevant as long as you can highlight clearly why. Keep them to the most relevant and tailored to the job spec.

6. Tailor it to the role and company

The perfect resume should tell a story that matches the specific job spec and the hiring company's values. Create a template and produce different versions for each role and company you apply to. That way, you can highlight the key technologies, practices and experiences they seek.

Don't list all the technologies, tools, or languages you have ever used. Instead, only mention technologies relevant to the role and that you are confident with (live-coding interview confident) that you could go deep into if requested in the interview.

From

Experienced with the following technologies, programming languages and tools: Kotlin, Java, C#, Rust, Jira, GitHub, CircleCI, Android Studio, Ruby, Rails, Fastlane, Gradle, Amazon AWS, Firebase, Retrofit, Coroutines, MVP, MVVM, JSON, Visual Studio, SQLite, Trello, Sketch, Adobe Photoshop, Sublime, Git, Jetpack, XML

To

Experience:

• Languages: Kotlin, Java, C#
• Technologies: Retrofit, Combine, Firebase, AWS
• Other: Modular Architectures, E2E Testing, A/B Testing, API Design, Relational DBs

If you are applying to an Android developer role:

• Everyone expects you to have experience with Android Studio.
• You did C# in school but have yet to use it since? Toyed with Rust on your side project? Unless relevant, do not mention them.
• Remove all tools and skills that anyone can pick up (e.g. GitHub, Jira, Sketch, CircleCI, JSON, etc)

Even better, inline the technologies with the projects. It helps understand recency.

Oh! Talking about expertise. Please do not rate yourself. I've seen many candidates adding a section with scores, rating themselves stars or scores in the technology. At the risk of being blunt, let me tell you a secret: hiring managers don't care how good you think you are. Their job is to assess that by themselves.

Self-rating your skills is likely to harm you more than help you.

• If you rate yourself as an expert or 5/5 stars on a technology. Many managers will doubtfully read this. If you've spent enough time in the industry, you know no one knows everything
• If you rate yourself in technologies as proficient or 4/5 or less, it is probably a good sign that you should not be mentioning this technology at all. Also, if this technology happens to be essential to the job, the recruiter may see it as a gap and disqualify you immediately

7. Format for readability

Optimise for a format that lets the reader find out the information they are looking for quickly—for example, the latest role, years of experience, career progression, etc.

Small tricks like aligning all job titles, dates, and company info can make a huge difference. I’d encourage you to check The Pragmatic Engineer's template as a fantastic example of a clean, clear, easy-to-read resume (>6,500 downloads).

8. Quality Matters. Avoid typos and other clumsy mistakes.

Don't do them, period. Use a spell-checker like Grammarly and ensure you are not giving the impression of being careless by easy-to-make clumsy typos. Oh! And double check all links work and take the reader where you want them.

9. Ask for a second opinion

Ask a friend with a relevant background to review your resume and give you honest, constructive feedback. Take it on board!

10. Iterate

If you are not receiving callbacks to the jobs you are applying for, the resume is not doing its job. Review it and iterate over it, trying different ideas to see what improves conversion as you would do with any other app or product. A/B test your resume!

Templates, Tools and Other Helpful Resources

If you would like to take it a step further and learn more about making your resume the best it can be, I suggest the following resources:

• Follow a standard clean template: I recommend you have a look and follow The Pragmatic Engineer's template.
• Read 'The Tech Resume Inside Out' by Gergely Orosz. The book will teach you the best practice to make your resume stand out through lots of examples and input from experienced tech recruiters and engineering managers from FAANG (Facebook/Meta, Amazon, Apple, Netflix and Google) and some of the most popular Big Tech companies like Microsoft, Shopify, Miro, Uber, Atlassian, Spotify, Square, Airbnb and Disney.

Happy interviewing!

Support me

If you found this content helpful, you can show your gratitude and contribute to help me continue writing by supporting me.

I am so glad to have you here. Please come in, grab a warm cup of your favourite hot beverage, and sit in one of our comfy armchairs. While you sip that delicious drink, let me share with you a little story.

Who am I?

I sometimes wish I had a romantic background. I would love to tell you that I started coding in BASIC when I was ten on my dad's i386 computer. That I was selling my games to high-school mates by the age of fourteen, or that I had created a killer website before starting University.

Truthfully, my background is quite far from the classic hacker story. I was raised in a pretty average household in the 1980s. My parents were quite conservative in everything regarding screens: TV, video games, or computers. They tried to limit the time I spent in front of them and encouraged me to play football (soccer) outside, read a book or build stuff (I loved to make things: race tracks for my remote control car, mini villages, etc.). Therefore, I was never a geek nor particularly passionate about computers.

When the time came to start University, I wasn't even sure about studying Computer Science. It was a last-minute decision. I was pretty good at maths and loved science. So I hesitated between majoring in more traditional sciences like Maths and Physics or taking a more applied option like Industrial Engineering (really hot at the time). Computer Science came into the picture by accident.

That summer, a friend of mine got a book to learn to code, and we followed it together. Programming allowed me to understand the challenges behind complex problems, yet offering the skills to build things on my own. It was a great mix of theory and creativity.

University started, and yet again, I would love to say that I was a natural at it, but I wasn't. I had to study hard to pass my tests. With time and practice, I became a good student and a fast learner. I developed the ability to identify the most relevant topics and skills to learn. I became good at studying!

That is the most crucial skill which has allowed me to have a pretty good and comfortable career in the Tech Industry. I have been a Software Engineer for almost 15 years. I started doing web development with jQuery. Then I had the opportunity to go into lower-level challenges, programming a real-time communication middleware for embedded systems in ANSI C. Around ten years ago, I discovered mobile development, and I became instantly in love with its technical challenges and broad reach. In my career, I have worked on small projects in start-ups where I was the sole mobile engineer and in big tech companies with multiple teams and 50+ developers, supporting millions of users worldwide.

On many occasions over the years, I felt overwhelmed. I believed I was not good enough, and I did not belong to this industry. My mind travelled back several times to that summer when I learned to program with my friend and wondered if I had just made the wrong choice. But many years later, I am still enjoying building software!

Why am I writing The Mobile Interview?

Last year, after more than seven years without interviewing as a candidate, I was once again back in the arena. As you can imagine, after so long, my interviewing skills felt a bit rusty, and I had to prepare consciously. I had to refresh my coding and technical design skills for mobile applications development.

I was astonished about how many materials there are nowadays to help candidates prepare for technical interviews, from coding platforms to online courses and youtube video series, together with the more classic books. There are lots of complete guides and helpful resources for anyone preparing for a technical interview.

But there was something odd: all the resources I found concentrated on Full-Stack or Backend profiles. When I searched for mobile development oriented content, there seemed to be a huge gap.

Frustrated with not finding enough insightful content focused on preparing for Android and iOS interviews, a quick thought ran through my brain like lightning: I certainly couldn't be the only one feeling disappointed and a bit cast aside by the broader community.

So I decided to do something about it, and that's how TheMobileInterview.com was born. Since I couldn't find the materials to help me prepare for my interviews, I decided to create my own and share them with you.

My goal is to help anyone get their next iOS or Android Engineering role, from anyone trying to land their first mobile development job to more seasoned developers looking to advance their careers. With the help of a few friends and my own experience, I will be compiling a complete archive of resources, helpful tips, and insightful learnings entirely focused on the technical interview process for mobile.

Who is The Mobile Interview for?

This publication is for anyone preparing an interview process for mobile application development roles, independently of their years of experience.

Any iOS and Android engineers who are already working but would like to sharpen their skills, refresh and learn new concepts regarding mobile apps architecture, performance, etc.

I will also help managers and interviewers participating in hiring processes for Android and iOS developers. I will be sharing my learnings and insights on how to put together a fair, accurate and inclusive hiring process to find the best talent.

And in particular, to anyone who ever left an interview thinking they could have done a better job if they had prepared. To anyone who has ever believed they were not smart enough, and to anyone who has ever felt they did not belong.

You are good enough. You are smart and can harness the skills required to excel at this job. You can be yourself and still belong to this industry. You can have a very successful career in tech. And with a bit of guidance and focused effort, you can ace your next interview!

Last Updated: September 2023

A long-time favourite of FAANG companies (Facebook/Meta, Amazon, Apple, Netflix and Google), system design interviews have grown in popularity since Big Tech introduced them over a decade ago. These interviews are a standard part of any interview process for most backend roles. And now, they have eventually reached us, mobile engineers, who were more accustomed to demonstrating our technical design skills and architectural knowledge through take-home assignments.

The mobile system design interview focuses primarily on those two topics (design and architecture). As a candidate, you will likely be tasked with the technical design of a mobile application or a feature. Something brief and short, along the lines of:

• Design a photo-sharing app (i.e. Instagram)
• Design a messenger app (i.e. WhatsApp or Messenger)
• Design a newsfeed feature (like in Twitter)

The aim is for the interviewer(s) to gather signals on how well you tackle the process of transforming an abstract set of requirements into a precise and meticulous solution. It also allows your interviewer to picture the breadth of your knowledge through the different decisions you make along the way. While certainly not perfect, they have one significant benefit over take-home challenges: a considerable reduction of the time required by both candidate and interviewer.

In the current competitive market to hire great talent, big tech companies and small startups are regularly looking at new ways to streamline their hiring process. As part of that effort, more and more companies are adopting this type of interview, replacing take-home challenges for Android and iOS developer roles. In fact, I did it myself when growing my last team. We reduced our time-to-hire from 3+ weeks on average to just about one week. The change worked fantastically for both candidates and interviewers, but that's probably a story for another post.

System design interviews may seem scary, particularly when you have never done them or don’t have much experience designing large applications that serve millions of users and have dozens of engineers working on them. There is also an aura of mystery around how these interviews are set for mobile. If you have searched around, you have probably realised that there are plenty of materials, courses and fantastic books explaining how backend system design interviews work and with help to prepare for them, but not so much for mobile. We are rookies in the matter, and that's why I decided to share my experience tackling these interviews both as a candidate and interviewer.

You will shortly discover there is no reason to be afraid. Getting yourself comfortable preparing and passing this type of interviews (as you currently do with take-home challenges) is relatively easy with a bit of guidance and practice. And perhaps you may end up even enjoying them.

The interview’s anatomy

Most system design interview last around 45 minutes (sometimes they might be extended up to 1 hour) and they all follow a very similar structure:

• 6 - 8 min: Introductions and a brief prologue by your interviewer
• 4 - 5 min: Problem statement
• 25 - 30 min: Design and discuss your solution
• 5 min: Your time to ask questions to the interviewer

A rather typical mistake I have seen many candidates make, and I have done myself as well, is to assume you have 45 min to solve the problem since that's what the interview lasts. In reality, as you can see from the schedule above, you will have around 30 minutes to design your solution. Therefore, keeping track of time is essential. You want to distribute those 30 minutes in the best possible way, allowing you to cover as much as you can. And even during those 30 minutes, there will be interruptions. So better to come up with a clear plan and enough practice to make sure you nail it.

💡 Tip: When you practice, do it with a timer and force yourself to hard-stop at 30 minutes. Then, review the topics you covered and list the ones you would have added if you had a bit more time. Go over both lists and ask yourself: Have I covered the most relevant topics for this problem? Is there any topic in the second list that I feel I should have covered? If so, how would you add it to your narrative if you did the same problem again? Doing this will help you create a consistent approach and slowly develop a sense, a feeling, for which topics/areas are more relevant to explore for each kind of problem and to what extent.

Your interviewer’s perspective

Before describing the approach to grokking these interviews, we need to understand the point of view of the person (or people) on the other side of the table. What are they looking for?

Interviews with an open-ended question are intended to find the boundaries of your knowledge. Letting you choose the topics you want to cover and see how you prioritise them when developing your solution. They are designed this way to allow your interviewer to evaluate the following:

• Your ability to navigate an ambiguous problem by asking the right questions, shaping it into a concrete set of requirements
• Your thinking process: How you break a large problem into smaller parts while keeping the whole picture connected and meeting all requirements
• How you make decisions, evaluating different alternatives and the trade-offs
• Your knowledge, which parts of Android or iOS development you're more familiar with, which ones you are less. Can you also propose a solution for the server?
• And last but not least, your communication and collaboration skills. How you synthesise your solution and get buy-in

There is no right or wrong answer —just different alternatives. And your interviewer knows this. So please don't focus on finding the perfect solution. Instead, focus on designing a solution as you would typically do in your day-to-day job, applying the knowledge you possess to emphasise your strengths. A piece of advice someone gave me once and I always find helpful is to focus on the bits you know. If the interviewer truly cares about helping you succeed, they would be more interested in understanding what you know instead of what you don't. Plus, you usually score extra points for proposing a solution fast and then improving it gradually. In most cases, the initial question will not be the whole exercise, and your interviewer will expect to cover a few follow-ups. That's why following an iterative approach, starting with a high-level "simpler" solution and evolving it as new requirements are added, works relatively well.

The freedom to pick the areas you want to focus on your exercise is a double-edged sword. It gives you the liberty to drive the conversation and explore the parts you are more comfortable with, but at the same time, the interviewer may assume that anything you don't cover is because you don't know it. Remember that most interviewers (more so in big companies) tend to fall on the conservative side when writing their evaluation. Hence why the trickiest bit is to strike the right balance between briefly covering all topics relevant to the question asked while digging into the more relevant ones for the problem.

Finding this balance is hard to master, mainly because what you and your interviewer deem relevant may not be the same. Luckily, most interviewers will give you a hand here. They may hint you when you are missing something they consider necessary or even ask you directly to cover a specific part they are interested in exploring. Therefore, the best you can do is listen to your interviewer and use her hints to guide your solution. And if in doubt, do not be afraid of asking her as many questions as you need.

The approach

Below I describe a strategy to tackle mobile system design interviews. I have developed it over the years from doing these interviews myself and seeing many successful candidates excel.

💡 Tip: Don't just take this as a one-size-fits-all strategy. I would encourage you to spend the time to understand it, learn each step's importance and goal, and then make it yours. Bend it to what feels more natural to you, at the end of the day, there aren't two equal candidates, and you are the one who will know better what works best for you. You have the skills, and you have the experience, trust yourself.

It consists of a sequence of six straightforward steps:

1. Understand the problem
2. Define the scope
3. Identify technical requirements
4. Propose a high-level design
5. Deep-dive into one component
6. Wrap up

Let’s run through the six steps into more detail.

1. Understand the problem

The first step should be no surprise. Before creating a solution, we need to understand the question.

It's probably the most obvious step and yet is the one where most candidates fail, myself included —multiple times. Why? Because we jump to conclusions too quickly. But let's not be too hard on ourselves. There is a good reason for so many of us falling into the trap. It's a well-known bias, which the interview environment accentuates (the pressure to prove yourself).

"The jumping conclusion bias, also referred to as the inference-observation confusion, is a psychological term referring to making decisions without having enough information to be sure that one is right, this can give rise to poor or rash decisions that often cause more harm to something than good."
Source: Wikipedia

So, now that you know it, just don't jump to conclusions. Slow down your wish to start designing your solution and avoid being that candidate who jumps into the solution without fully understanding the problem. Instead, concentrate on knowing what the interviewer wants you to focus on, the most relevant challenges of this type of apps, and what similar situations have you solved previously.

There is a reason why the interviewer gave you a vague, open-ended problem, and this step is precisely it. Remember, she is evaluating your ability to analyse an incomplete question, identify the dark areas, and ask the right questions.

Therefore, in this step, you want to ask clarifying questions to understand the problem better. Think of the information you have been given and then ask relevant questions to complete the picture.

These are a few questions that I found useful to ask at this stage, depending on the problem:

• What are we being asked to design?
• Who is the user, and how will they use our system?
• What's the initial number of users? And the expected growth?
• Are we being given an initial design/wireframes, or should we produce them as well?
• Are we designing an MVP or final-product?
• Are we building this from scratch, or can we leverage any existing components? Any existing patterns/architecture we should follow?
• How big is the team who will implement and maintain our system?
• Are we expected to design just the mobile application or other parts of the overall system too (e.g. API)?
• Is it iOS or Android only, or cross-platform? Shall we support smartphones, tablets, both?

You don't need to ask all of them. Depending on the problem, and the information you have been provided, some of these questions might be redundant. Just prioritise the most relevant ones for the task.

2. Define the scope

The second step is to figure out and agree on the functional requirements for the app or feature you will be designing.

Think of similar famous apps or systems you have used in the past and how they solve a similar problem. What features they offer and what's their primary functionality. You can suggest many potential features you can think of and seek agreement with your interviewer on which features you will focus on in this particular design session. It should be quite a collaborative part of the interview.

Once the scope is clear and agreed with your interviewer, you are ready to move to the next step and slowly unfold your solution.

3. Identify technical requirements

This is when the real fun begins! Once the functional requirements are clarified, you should switch hats and start thinking on the technical considerations necessary to build a solution capable of providing the desired user experience you and your interviewer just agreed.

Let's jump straight into what are usually the most common aspects to consider when designing a mobile app:

Networking

Most apps nowadays either share or retrieve their state from a backend. Spend a bit of time thinking about how this backend might look like. For most cases, a REST API will do. Is this API provided? If so, how does it look?

May any features require low latency to simulate live updates? If so, how will you push this information to the client? You may need to use a more sophisticated approach than plain HTTP requests. You could use push notifications, WebSockets, polling, etc. Each option has trade-offs for you to consider.

Security

If above we said most apps require to communicate with other systems. Then it's obvious we will need to secure those communications. Think of the following topics:

• Authentication: How will your solution verify who is the user of your app (authentication) and how will it guarantee the correct level of access is provided (authorisation)
• Storing sensitive data: Will you need to save the user's credentials? Yes! Unless you want to offer quite a poor experience where the users will have to sign-in every time. Which credentials (e.g. access tokens, refresh tokens)? Do we have to handle Personally Identifiable Information (PII)? How will you store them securely? (e.g. Keychain, Smart Lock)
• Secure communications: How will you ensure your communications with the backend are secure? E.g. All requests follow the HTTPS protocol and are encrypted with TLS, certificate pinning, etc.

Availability

Does the app have to support offline mode? Most likely it will, as you don't want to start your app from an empty state each time the user opens it. You could use a local store to cache data (e.g. Core Data, Realm, SQLite, shared preferences, etc.), consider which one and why.

And what happens with images (or other media)? If needed, you can cache them locally, once retrieved from the network. That's a great option, but it certainly comes with a few challenges: handling multiple requests at once, cancelling expired requests, clean-up policy (e.g. LRU), limiting concurrent requests, etc.

Scalability

In mobile, the scalability challenges are typically a bit different from the rest of the systems. While in backend interviews, you have to design your system to support millions of QPS and partition your Terabytes of data in multiple shards. In mobile apps, scalability is usually linked to growing the codebase and team working on the app. Therefore, think of how you could prepare your design to support new features, owned by multiple teams (dozens of devs working on the same app).

You could:

• Break the UI into smaller independent components. Each of them with their stack so different people can work on them efficiently.
• Standardise your UI by building a reusable UI components library. It reduces code and ensures a consistent UX across the app.
• Modularise the app: Split the features in individual modules (which each team can own), and extract reusable components into shared and core modules.

Performance

In the nowadays mobile eco-system, more and more apps differentiate themselves by offering a slick and smooth user experience. To achieve it, you have to face the challenge of hiding the need to retrieve data from the network.

Some topics related to performance you may want to explore are:

• Are there any UI intensive operations (e.g. infinite list scrolling, heavy animations or complex transitions)? How would you support this? For example, you could pre-fetch data and create a buffer.
• Does the app load heavier data like images, videos, audio? If so, we should think on how to do it asynchronously, so we keep our UI slick, while still offering the best possible user experience. For example, by having a separate service to handle the retrieval of the media data asynchronously, notifying the UI when ready. What might be the bottlenecks and challenges of your approach?

Testing

You could briefly mention how you plan to ensure the quality of your app. Nowadays, the default should be to create a reliable suite of tests, but how you do this will most likely depend on the requirements (e.g. are you building an MVP?). You may want to think and describe what your testing strategy will be.

You may want to discuss the following briefly:

• Explain your testing strategy: How will you apply the different types of tests (unit tests, integration tests and UI/Functional tests to cover end-to-end the main app flows)
• Highlight the strengths of your architecture explaining how easy it is to test each particular component
• The use of dependency injection to make writing tests easier

Monitoring

You won't usually spend too long on this point unless the interviewer asks you to. It's important to consider how you plan to ensure the system’s correctness and facilitate a fast response when things go downhill. The two most important pillars are usually:

• Crash reporting and logging
• Analytics

Deployment

How do you foresee your system going live to production? It may depend on the requirements from the interviewer. The most common topics to mention are:

• CI/CD pipeline with automated releases (e.g. with Fastlane _lanes _to send builds to production, QA and beta)
• Leveraging remote feature flags enables rolling out changes gradually and decouple the release from the review process (e.g. ensuring the new feature is ready for a marketing campaign).

Other

Additional areas you could mention, particularly for senior+ roles are:

• Experimentation (supporting A/B tests)
• Localization
• Deeplinks
• Accessiblity

But you probably won't need to go into any of these during the interview.

And that's all for this step!

Pheww... That's a lot to cover and time is tight! But don't worry, the goal is for you to mention enough in most of them (one or two sentences), so the interviewer knows you have considered it. Without getting into detail unless it's critical for the problem, or the interviewer asks you so (remember, listen to your interviewer hints and follow the breadcrumbs).

4. Propose a high-level design

Wireframe the main flow (if not provided)

If you have not been given wireframes, the first step is to draw them before you go deeper in developing your solution. This step is vital. It will allow you and your interviewer to agree on the main screens, UI components, user interactions and navigation flow, which will later inform your technical decisions. You want to ensure you get your interviewer's buy-in for how you see the app functioning to meet all the given requirements.

It should be pretty straightforward if you follow just three simple steps:

1. Draw the main screens as boxes, describing the main content
2. Go over the flow, adding arrows to represent the user journey
3. Add more details to discuss each screen's composition: identify main UI elements, split UI components (e.g. cards/cells in a CollectionView / TableView). Think about possible reusable elements

💡 Tip: Do not spend too long on drawing a high-fidelity wireframe. Think what matters the most: describe the user experience, focusing on the different views and their main components and how the user flow will look like.

Draw the principal systems (if required)

At this point, you should check with your interviewer if she is expecting you to cover the end-to-end design or to focus only on the client-side. Most mobile system design interviews will focus just on the app, but depending on the level, the type of engineer they are looking for and the size of the team, they may want you to at least demonstrate you have a basic understanding of what's going on outside of the app.

Suppose your interviewer asks you to explore the end-to-end design. A few common elements your design will most likely need to rely on are:

• Mobile Clients
• An API Service (the layer the clients will communicate to)
• Backend App (the app which will do most of the heavy-lifting on the backend side)
• Data Store (to store info in the cloud)
• A Notification Service (if notifications are required)

Define basic data entities

At this point, you should have a good idea of the flow you are designing and the functionality your app will support. It should be pretty easy to describe the most important data entities applicable to your problem.

💡 Tip: Do not go into too much detail at first. You are not designing a database schema. You just want to list the entities (e.g. users, posts, comments), mentioning their most relevant attributes and relationships. If your interviewer asks for more detail, you can always go deeper.

Describe the primary endpoint(s) (if required)

Depending on whether your interviewer said the API was given to you or not when you asked her earlier, you may need to design the endpoints or not.

💡 Tip: Follow an iterative approach and do not produce a complete spec for each endpoint. List the endpoints with their HTTP method (GET, POST, PUT, DELETE) and path (e.g. GET /post/:id/comments), the input parameters the endpoint requires, and the output you expect. For the output, noting the main entities will most likely be enough (no need to write the complete JSON payload). As always, please confirm this with the interviewer.

Propose the client architecture

Back to the app, it's time to discuss and decide which architecture and common software patterns your design will follow.

Recall the standard architectures you are familiar with (e.g. MVC, MVP, MVVM+C, VIPER, RIBs, etc.), as well as the most typical patterns to abstract and encapsulate logic at the different layers of your system (e.g. Repositories, Use Cases, Services, etc.). Consider their strengths and weaknesses when applied to the problem at hand. Which ones will fit better the requirements you have? Why?

💡 Tip: You will make the rest of the exercise easier by picking a clean architecture. These architectures make it easier to break your design into small, individual components, which improves your solution's scalability, flexibility, and testability. Remember that your interviewer may start with a relatively simple problem and then ask you to evolve it to handle more complex scenarios. The more flexible your architecture is to cope with new challenges, the easier adapting your system will be when faced with them.

Unfortunately, I can't tell you the best architecture to pick. That not only depends on the problem but also your experience. Choosing a new trendy architecture may be a mistake if you don’t know it well enough. Instead, I would encourage you to rely on the one you are more familiar with. It's essential you fully understand the architecture and each component, as you may need to describe it in detail during the interview.

In my case, I tend to default to using a relatively simple and trend-agnostic clean architecture composed of the following pieces:

• Presentation Layer (UI): MVVM + Coordinator, to handle views & controller or activities & fragments and navigation logic.
• Domain Layer (Business logic): Use cases, to combine data from the user and repositories.
• Data layer:
  • Repositories, to retrieve data from the network or the local store
  • Network Data: Individual endpoints on top of the typical API Client
  • Persisted Data: Local store (if caching)
• Helper services: to extract functionality that might be shared by different features, for example:
  • Networking Service
  • Session Service (to hold a user session's info)
  • Credentials Store (to handle reading and writing of user credentials)

While using standard components, I find it helpful to keep the architecture trend-agnostic. I prefer to be pragmatic and add the pieces I require for the problem, instead of a more opinionated option (e.g. VIPER). It's obviously a matter of preference, and you and your interviewer may differ in opinions. Therefore my suggestion is to negotiate this with her during the exercise, explaining your decisions' trade-offs.

5. Deep-dive in one component

It's time to examine in more detail one of your components. While being able to solve the problem at a high-level is a great deal. Your interviewer will most likely expect you also to describe the ins and outs of one or more of the design components.

Here I share the approach I follow:

1. Choose the most interesting screen and draw its architecture: Cover all layers from the different UI components, VMs, Repos, Endpoints/Sockets, Network Layer, Local Store, etc.
2. Trace the dependencies (draw arrows from the caller)
3. Walk over the flow from the user's point of view: What is the user experience? What does the user see at every step? Describe the possible view states: Loading, Error, No Data, Data)
4. Explain the Data flow: Data transformations that happen along the way Network Model → Business Model → View State Model. Draw arrows to show data flow (different to the dependency arrows, e.g. use dotted arrows, another colour)
5. And once you have covered all the above, go in-depth into one component. Think about what might be the most challenging parts, if the design may have any bottlenecks, etc. For example:
   • "Real-Time" updates
   • Image Caching (challenges, NSOperation Queue)
   • Reusing Cells (preparing VMs)
   • Buffering data requests to improve UX

💡 Tip: Once again, listen to your interviewer. Most interviewers will let you choose which one(s), but some may guide you towards the components she wants you to cover in more detail. Possibly, also, if you have forgotten anything.

6. Wrap up

A quick recap of your design

Review the initial scope and functional requirements and how your design satisfies all of them.

Follow-up questions/stretch goals

At this point, your interviewer might already be asking follow-up questions. Listen to them and explain how your design could adapt to support them. Otherwise, ask her if there any other things she would like you to expand on.

Further refinements and considerations

Briefly cover some refinements you would do, if you had more time: Go over the design and technical considerations described above and think if you can expand in any of those in a bit more detail. Think of the technical considerations you may have left aside previously. Now might be a good time to mention them briefly. Some ideas for topics you could cover what would your testing strategy look like? How would you use your system's correctness with crash-reporting and analytics? How would you make your app more inclusive through accessibility?

Final thoughts

General advice

We have covered a lot while describing our approach's different steps (I hope by now, it's become your approach as well). Across all of them, you have probably noticed a common set of patterns. Let's go over them quickly:

• Do not be afraid to ask. The question will most likely be vague, and you need to gather the information required to ensure you are solving the problem your interviewer wants you to solve. There is only one way to do this: ask your interviewer.
• Validate your assumptions. Check with your interviewer any assumption you are making, to ensure you are going in the right path.
• Know and use your tools. Get genuinely good at drawing diagrams and synthesising your solution. Time is precious, and this will boost your speed articulating your solution. Whether it's on a whiteboard or using an online tool, practice structuring your thoughts in a sharp and easy to follow manner. Learn to make your diagrams easy to modify and expand.
• Share your thoughts. It's vital that you continuously communicate with your interviewer to make this an effective interview. Remember she wants to understand how you think.
• Get buy-in for your choices. For every decision you make, mention the different alternatives you consider, their strengths and weaknesses and why you pick a particular one and the trade-offs.

Practice, practice, practice

I have mentioned the importance of practising this type of interviews to increase your chances to succeed. By now, you might be wondering what the best way to do so is. Here you have a few suggestions that have worked well for me:

• Get familiar with different standard architectures: MVC, MVVM, MVP, Redux, VIPER, etc.
• Design common apps: Grab your phone and think of the top apps you use and their most famous/challenging feature (e.g. Mail client, Instagram, Spotify, Twitter, Facebook, WhatsApp, Etsy) and then think how you would design it. Grab a piece of paper and start imagining how you would implement these apps. This simple exercise is what has worked best for most people I know and me. Trust me; it works!
• Read about existing solutions: Check tech blog posts, recorded talks, etc., from engineers working at big companies and compare how they solve their challenges.
• Review a few well-known open-source projects.
• Ask friends and colleagues to review your designs, get feedback.
• Practice mock interviews with colleagues or other candidates in the same boat.

Relax and enjoy the ride

System design interviews can be difficult, and a bit overwhelming, but it's also a place to be creative and learn by imagining systems you have never worked on. Preparing any interview can be stressful, but if you learn to enjoy the preparation itself and take it as an opportunity to expand your knowledge, it can become quite an exciting experience.

So, about that coming interview

If you are reading this article, chances are you are preparing for an interview.

Mobile system design interviews are like a puzzle. One you have never built before, but you get to bring the parts to solve it. So make sure to include a broad set of parts in your toolbox and become comfortable scrutinising them and selecting the best ones for the job.

In this article, I have tried to share an approach to face these interviews. But this is just my approach, the one I have compiled from doing dozens of interviews myself and interviewing hundreds of candidates. While describing it, I have purposely tried to cover as many topics as possible, so that you can then shape them to form your own strategy. Don't just take my approach, make it yours!

Practice before the interview to get great at it, but without memorising it. There are not two equal system design interviews, as there are not two equal candidates, nor interviewers. Remember that your interviewer is there to guide you and help you succeed. Please pay attention to the small hints and suggestions your interviewer gives you and incorporate those little nibbles of data to your solution.

Thanks for reading this long. I hope you have a better understanding of what mobile system design interviews entail: what they consist of, what your interviewer will be evaluating, plus a reliable approach to tackling them successfully.

I would love to learn from your experience. If you have other tips or a different strategy, please share it in the comments.

Good luck interviewing!

Resources

Here you have a list of suggested materials (posts, WWDC videos, courses, etc.) to dive deeper and expand your knowledge in the different topics touched in this article.

• App Architecture - iOS Application Design Patterns in Swift by Chris Eidhof, Matt Gallagher, and Florian Kugler. [Book]
• 33 Engineering Challenges of Building Mobile Apps at Scale by Gergely Orosz [Post | Book]
• System Design Interview: an Insider's Guide by Alex Xu [Book | Course]
• Push technology. Wikipedia [Article]
• Advances in Networking, Part I. WWDC 2019 [Video]

Acknowledgement

This post would not have been possible without the help of the following fantastic engineers and hiring managers who have shared their personal experience so I could capture them here. They have patiently reviewed and signifticantly improved my poor writing. Thank you very much, you have made this content several orders of magnitude better!

• Gergely Orosz - Author of Building Mobile Apps at Scale and The Pragmatic Engineer newsletter, previously Engineering Manager @ Uber
• Celia Pitarch - Senior iOS Developer @ Bussu
• Juan García - Senior Software Engineer @ Lana
• Marcos Holgado - Senior Android Engineer @ DuckDuckGo

Who am I?

As software engineer with 14+ years of experience building mobile apps (since the good ol' days of iOS 3, Interface Builder, Eclipse, the iPhone 3GS, Java, and Objective-C). I have interviewed hundreds of candidates and I have done several dozens of interviews as a candidate myself during all this time from small start-ups to Big Tech companies. I have worked in small projects where I was the sole engineer, and in big apps with multiple teams and 50+ developers, supporting millions of users worldwide.

Support me

If you found this content helpful, you can show your gratitude and contribute to help me continue writing by supporting me.

This post was originally posted in Funding Circle's Engineering Blog on August 15, 2016. Co-authored with my awesome colleague Emma Makinson.

Some time ago, together with the Product and Design teams at Funding Circle, we started thinking about refreshing the whole user experience for Funding Circle investors - starting with the mobile app. We had an existing app for iPhone and iPad, written by an external agency in 2013, but it couldn’t meet our investors’ needs and was increasingly difficult for us to maintain.

This August, after many months of careful planning and hard work, a second version of our iPad app was released to Funding Circle investors. In doing so, we brought the iPad app up-to-date with the iPhone app we released at the end of last year, and were able to completely remove the earlier version of both apps, which we’d been supporting for three years. Along the way, we’ve learned a few things about rebuilding applications - this is our perspective on when you should do it, how you should do it, and what you can expect at the end of it all.

When should you rebuild an inherited application?

When you keep running into problems

There were multiple reasons for rebuilding the iOS app from scratch. For a start, the app felt old and users frequently suffered random crashes that were difficult to debug. The codebase also needed to be brought up-to-date with new technical requirements: it used deprecated Apple APIs, and supported four different versions of iOS. The original app was also created on a moving surface with the API changing constantly and not taking into account the mobile needs. Finally, the existing code was hard to maintain and did not reach the standard we wanted: some areas of the codebase were duplicated; everything was tightly coupled; and there were no tests across the whole app.

There is nothing wrong with having an external agency build your application. It is a quick way to market, and it allows you to take a pulse of what your users really want from it before you invest more heavily in the product. However, maintaining an externally-written app can be expensive in the longer term. Ultimately, great apps need dedicated specialists (developers, designers, etc.) and great design takes time to work through.

When you’ve first tried to improve it

We did not take this decision lightly, and we were conscious of how rewrites can seem very exciting and then easily go wrong, so we first tried to stabilise and improve the existing app instead. We added Crashlytics and, for three months, we worked hard on optimizing the network requests and fixing all the major issues causing crashes to our users. At the same time, we introduced functional tests across the app, so we could make sure that we were not breaking anything. In three months, we managed to increase the percentage of crash-free users by more than 20%, but there was a lot of work still to do, making any change took far longer than it should, and we hadn’t been able to deliver any new features.

When the existing product will hold you back

After working with and exploring the codebase for three months, representatives across Product, Design and Engineering felt that the existing codebase was no longer fit for purpose, and that we should not try to extend it.

While we did not want to replicate all the functionality of the desktop site, we wanted to be able to provide lots of new features as well as small delights for our users, from offering simple conveniences like Touch ID, to delivering different views and experiences for different screen sizes, to keeping up-to-date with standard UI conventions. Rebuilding the application seemed to be the obvious step, if we really wanted to achieve all these big ideas we had in mind and to transform the way our users engaged with us.

How should you go about it?

Listen to your customers

We decided that if we were going to redefine the way our customers interacted with Funding Circle, we should ask them what they wanted.

When thinking about mobile, it is easy to make the common mistake to try to match the same features that you offer on the desktop site, when in reality mobile users have different needs and different preferences. You should see mobile as an extension to your desktop experience, instead of a replacement.

We focused on content first and took the approach of building constant prototypes, validating them with our customers and iterating over them until we got the user experience right. This was an exhausting but very enlightening effort that the Design team drove, but in which the whole team participated. The true value was not only in getting a better sense of what users want to do when they open the Funding Circle app on their smartphone, but also in making sure that everyone in the team understood why we were doing things the way we were doing them, so that we all knew the reason behind every single decision.

Work closely with the rest of the business

As developers, we’ve worked closely with the design team and the product team to build the app. When we started working on the app, we worked with a dedicated product owner and designer, both of whom were really invested in delivering a beautiful - but also technically resilient - product. Everyone had a clear role and different responsibilities, but we sat together, talked often, and made decisions as a group: product owners, designers and ourselves all bringing valuable different perspectives to the table.

Take the time to get things right

That close working relationship helped us prevent and deal with issues as they arose: there was a high level of trust across the team, and we were given the space and time to get things right and fix small issues before they grew. At Funding Circle, all teams are Agile. On the Mobile team, we used our weekly demos as opportunities to review our deliverables, revise our expectations, and take time to explore assumptions and refactor existing code where needed. We had broad timelines for the project as a whole, but we engaged frequently with the product team to review our expectations of scope - ultimately cutting some features from the initial release so that we could deliver something with which everyone felt comfortable.

Surface and tackle difficult issues together

At Funding Circle, we use pair-programming to transfer knowledge about different parts of the system, and as an opportunity for wider knowledge-sharing and coaching. On the Mobile team, we do this too: we spend roughly half of every day writing code together with another member of the team. Throughout the app development process, this approach helped us to spot complex issues early and find the right solutions - by combining the knowledge, experience, and different perspectives of the wider team.

Make small changes one by one

Looking back across the project, one thing we might have done differently is to rewrite and deliver changes in the existing app, rather than trying to deliver the whole rewritten app in one go. Having defined what we wanted the app to do, and how we wanted to make the changes (involving users in user testing, for example), we could have chosen a few small areas in the old app to tackle first, delivering refactors to our investors one at a time. That would have meant continuing to work with the old application, but would have allowed us to get quicker feedback from our users, as well as managing scope-creep more tightly: with smaller changes, it’s easier to see when additional features have added significant extra pressure.

What should you expect?

At the end of this investment of time, what can you achieve? Can you solve the problems with an existing codebase? Well, our investors are happy: app users frequently call our customer relations team to tell us how much they enjoy using our product. The app doesn’t crash on them anymore, either. We have between 99.8% and 100% crash-free users on any given day. They send us their feedback, too - much of which we can now respond to in a matter of days or weeks.

And as developers, we feel much more comfortable with our codebase now, which has been reduced to 52% of the original one. We have got tests covering most of the relevant flows in the app (from unit tests to UI functional tests) and we have a completely automated Continuous Integration and Continuous Delivery pipeline (thanks to CircleCI and Fastlane). Just to give you an example of how quickly we can deliver now, last week, we were able to react to a user’s suggestion with a new submission to the App Store within three hours.