DEV Community: Edu

How to write the perfect Android Developer resume

Edu — Sat, 28 Oct 2023 15:01:21 +0000

Nail your next interview with the The Mobile Interview. The missing guide to prepare the technical interview for iOS and Android developers.

I have been the hiring manager and interviewer for small start-ups and Big Tech companies in the USA and Europe. I have interviewed hundreds of Android and iOS developers, Tech Leads and Engineering Managers. Whenever I have to fill a new role, I get to review more than 50 candidate 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 inbox of a recruiter.

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 offered a chance. So, trust me, it's worth investing time in refining your resume to stand out from the rest of hundreds (thousands in BigTech) 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 are looking for specific technologies, skills and levels of experience to identify which candidates are worth considering for a role quickly.

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 in a few bullet points (or sentences) what you achieved and learned during that time.

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

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.

Help the reader understand the actual impact and value your direct contributions brought to the app, the team and the business by using quantitative data points. Doing something great is fantastic but meaningless if you don't help the reader understand why. Please explain what you achieved and why it was important for you, the team and 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

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 first-hand who do not read past the first page.

For more senior folks with 15+ years of experience, cover your last 2-3 positions or the last 8-10 years, focusing on your roles and experience most relevant to the job. If you're applying for a Director of Engineering role, don’t list your summer internship 20 years ago (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 the most relevant achievements you had 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. It usually works best to create a template and produce different versions for each role and company you apply to. That way, you can ensure it highlights the key technologies, practices and experiences they seek.

For example, don't list all the technologies, tools, and languages you have ever used. Instead, only mention relevant technologies you are confident with (whiteboard-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

Experience:

Languages: Kotlin, Java, C#

Technologies: Retrofit, Combine, Firebase, AWS

Other: Modular Architectures, E2E Testing, RESTful 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 listed as a job requirement, do not mention them.
Remove all star dare 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 and better show expertise with real examples.

Oh! Talking about expertise. Please do not rate yourself. I've seen many candidates adding a section with scores, rating themselves stars in each technology. Let me tell you a secret: interviewers 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, it is hard to know everything
If you rate yourself in technologies as proficient or 3-4 stars, it is probably a good sign that you should not be mentioning this technology at all. Plus, if this technology happens to be essential to the job, the recruiter may see it as a gap and disqualify you.

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 keeping all job titles, dates, and company info aligned can make a huge difference. I encourage you to check The Pragmatic Engineer's template as a fantastic example of a clean, clear and 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.

Happy job hunting!

I'd like to help prepare your Android or iOS interview

Edu — Tue, 30 Mar 2021 16:46:05 +0000

Do you want to learn how to approach the mobile system design interview? Please read my previous post: "Cracking the Mobile System Design Interview" (also available here at dev.to).

I am starting a new publication with the sole purpose to help fellow Android and iOS engineers prepare for their next technical interview. This is a very personal post about my background and the journey that led me to start writing about technical interview processes for Android and iOS developers. Hope you like it! ♥️

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. I was never a geek nor particularly passionate about computers. My parents were quite conservative 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, villages of mini houses with streets and lights, etc.).

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-oriented content, there seemed to be a huge hole.

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 to this industry.

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!

Cracking the Mobile System Design Interview (iOS & Android)

Edu — Thu, 21 Jan 2021 17:10:48 +0000

Nail your next mobile system design interview with the latest version of this guide.

A long-time favourite of FAANG companies, system design interviews have grown in popularity since they were initially introduced a few decades back. They 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 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 vague, in 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 to let you demonstrate how 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 a bit scary, particularly when you have never done them before or don't have much experience designing large applications serving millions of users and with 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 is 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 do, 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 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:

Understand the problem
Define the scope
Identify technical requirements
Propose a high-level design
Deep-dive into one component
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).

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:

Draw the main screens as boxes, describing the main content
Go over the flow, adding arrows to represent the user journey
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:

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.
Trace the dependencies (draw arrows from the caller)
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)
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)
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 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 entitle: what they consist on, 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]

Who am I?

I am a Software Engineer with 15 years of experience. Around ten years ago, I switched from writing ANSI C for embedded systems to mobile development. Yeap! Those were the good ol' days with iOS 3, Interface Builder, Eclipse, the iPhone 3GS, Java, and Objective-C. 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. 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.