There are lots of resources available for general programming interviews, but during my interview prep over the past few months, I had difficulty finding Android-specific guides. My goal in writing this article is to fill that gap.
For context, I interviewed at six different companies between April and August 2020 for Android positions in the junior to intermediate range. They were all Bay Area-based and sized around 500 to 5000 employees. The interviews were remote due to COVID-19 (even though two of the companies had offices less than a mile from my SF apartment!). In total, I had six technical phone screens, moved onto the virtual onsite stage for four of those companies, and did 15 onsite sessions between the four. This article will go over the seven different interview formats I encountered and some tips for preparing for them.
Algorithms and Data Structures
2/6 phone screens, 3/15 onsites
This is the most common technical interview format, with a lot of existing prep resources, so I won’t go into it in detail. For Android-specific positions, interviewers will usually ask you if you’d like to implement your solution in Kotlin or Java. I chose to do all of mine in Kotlin; the companies I interviewed at were all Kotlin-first, and I got the impression that my interviewers preferred Kotlin. That said, I would still recommend being prepared to write Java for interviews, in case you encounter a company that’s still Java-first or a non-Android interviewer who doesn’t know Kotlin.
I prepared for these with Leetcode’s Top Interview Questions, Hackerrank’s Interview Preparation Kit, Cracking the Coding Interview, and Elements of Programming Interviews. I did about 80% of my practice problems in Kotlin and the rest in Java. In retrospect, I would’ve practiced more Hackerrank and fewer Leetcode problems because many companies use Hackerrank as their remote interviewing platform, so being familiar with the editor is helpful. Two of the six companies I interviewed with used it; the rest opted for Coderpad, another popular virtual coding interview platform.
0/6 phone screens, 3/15 onsites
System design interviews are also pretty standard across all engineering interviews. You’re asked to design a large system, such as Twitter, Instagram, or a URL shortener. For Android positions, you may be asked either a general system design question or an Android-specific one.
A general engineering question will focus on database design and web services at a high level. There are lots of good resources for studying for these interviews, such as this Youtube video, this system design primer, and this system design overview. These interviews tend to be open-ended, so you have some leeway to steer the conversation into domains you’re more comfortable with. You will generally have to know some basics about databases, but you can let the interviewer know if, as a mobile engineer, you haven’t worked with them very much, and focus more on the client-side implementation. I read this blog post to get a high-level understanding of commonly used databases and their trade-offs.
For Android-specific questions, you’ll spend less time discussing the backend and database and more on the app itself. For example, you may be asked which View or Layout class you’d use to implement a carousel feature. Some companies will focus more on the data layer of the app than the UI, so you should know how to design clear data models and how they flow throughout your design. You may also be asked about mobile-specific considerations for API design. For example, since network calls drain battery, mobile APIs are often designed to have as few API calls per screen as possible, which isn’t as important for web APIs. Resources for this type of question are harder to find; the most useful one I found was this Medium article.
A Web Whiteboard seems to be the most popular platform for these.
1/6 phone screens, 2.5/15 onsites
The behavioural Q&A interview is where you’re asked about your experience working with others. You may be asked about how you collaborate with product managers, designers, backend engineers, iOS engineers, or other Android engineers. The STAR method is a good way to frame your responses to these questions. I recommend having a few stories prepared, like the time you fixed a critical bug, the time you implemented a stretch goal for a project, the time you improved a process for your team, or so on.
0/6 phone screens, 2.5/15 onsites
The technical Q&A interview is where you’re asked about your Android-specific knowledge and experience, often in the context of projects you’ve worked on. I like this table from Cracking the Coding Interview as a framework for discussing projects; it’s helpful to fill it out as part of your interview prep. The nice part about virtual interviews is you can keep your prep documents open in part of your screen and look at them during the interview.
Make sure you can articulate your specific contributions to each project. You should also be able to explain the architectural decisions for the projects, even if you’re not the one who made them.
Beyond individual projects, you may also be asked to talk about your general approach to starting a new project and monitoring or iterating on it afterwards.
You may also be asked “trivia” questions, like the difference between an Activity and a Fragment or the purpose of dependency injection. To prepare for these, I recommend reviewing Google’s Android app fundamentals guide, Ray Wenderlich’s Android Interview post, and Mindork’s Android interview questions Github repo.
The technical Q&A is often combined with other formats; you may be asked to talk about projects for 10–15 minutes before starting an algorithms problem, or have it be combined with a behavioural Q&A interview.
Android Feature Implementation
1/6 phone screens, 2/15 onsites
In Android feature interviews, you’re asked to implement one or several features in either a new app or an existing codebase provided by your interviewer. You’ll be coding in Android Studio on your personal laptop and screensharing with your interviewer. The actual feature will vary a lot between companies, but I would recommend being comfortable with starting a new project in Android Studio and implementing basic features, like switching between activities and fragments, creating a new RecyclerView, and making network calls. You won’t have much time to make many architectural decisions, but you can still aim for clean code.
For these interviews, all my interviewers allowed me to look things up on Google and copy and paste in code snippets from StackOverflow. They also provided more hints than they did for the algorithms questions. The Android interviews felt a bit like pair programming.
If you take any shortcuts for the sake of completing the feature in time, you should mention what you’d do normally without the time pressure. For example, if you use an HttpUrlConnection to make an API request, you can mention that for real projects you’d prefer Retrofit for scalability and built-in caching.
If you don’t use Android Studio very often on your personal computer, make sure you’re comfortable doing so before the interview. If there are custom keyboard shortcuts you use in Android Studio at work, you may want to copy them over to your personal computer’s Android Studio before the interview. And make sure you have an emulator available, since screensharing with an emulator is more straightforward than with a physical device.
Finally, my biggest tip is to collect your favourite dependencies in a single file beforehand so that you can copy and paste them into the interview project’s
build.gradle right away, rather than waste five minutes of precious interview time tracking down the latest release of OkHttp.
2/6 phone screens, 0/15 onsites
For take-home projects, you’re given a list of requirements for an app and asked to implement it on your own time. Both of mine required making an app from scratch, although I’ve heard from others that they were asked to add features to an existing codebase instead. They generally take ~5 hours, although this can depend a lot on your skill level and familiarity with the required features, and companies may give you from one day to one week to submit it. A prototypical example is to display a scrollable list where each item contains a movie’s thumbnail, title, and synopsis, powered by a given endpoint.
These projects are usually complex enough that you’ll need to pull in some libraries, and are a good way to show off parts of the Android stack you’re familiar with, for example RxJava, Coroutines, or Room. My interviewers told me that they do expect the project to have some architectural organization. I used MVVM for both of mine, but I think you can use MVwhatever as long as you implement it cleanly and are comfortable discussing it. Performance optimizations (eg. image caching), unit tests, and clean, commented code will help make a good impression on interviewers.
Given the longer timeframe, the expectation is that you had time to weigh tradeoffs and make informed decisions, so be prepared to defend your choices. For example, if you’re asked why a file seems to have more than a single responsibility, “I didn’t extract the data layer into a separate file because the project is small.” is a lot better than “I don’t know.”
Some companies will explicitly ask you to submit the project with a
README file. Even if they don’t mention it, I highly recommend writing one to communicate your decisions in terms of which features you focused on, which libraries pulled in, and how you approached the architecture.
0/6 phone screens, 2/15 onsites
For code review interviews, you’re given a few files of Android code and asked to review them. One interviewer asked me to make changes to the code directly; the other only asked me to discuss the code. If you don’t do code reviews very often, I recommend reading through a few on a repository at work you’re familiar with to get a better sense of what to expect. If your workplace doesn’t really do code review, you can read pull request reviews on Github open source projects instead. Bento, Yelp’s UI library, and soil topARgraphy, an augmented reality Android app developed by UBC students, are some projects you can check out.
The main difference between these interviews and regular code reviews is that the code you’re reviewing will have many more bugs. For example, I had to identify a few memory leaks. The code will also likely use lower-level built-in Android libraries than what you’re used to; interviewers can’t assume you’ve worked with RxJava or Coroutines before, so you may see Handlers and AsyncTasks instead. I recommend reviewing the Activity and Fragment lifecycles and bugs that they can cause, especially memory leaks. Finally, you’ll likely be reviewing an entire file or block of code rather than looking at a diff of changes to a file.
Here’s a code review checklist that I really like as a guide for regular code reviews, and should be helpful for these interviews as well.
Here are all the interview prep resources I mentioned throughout the article:
Algorithms and data structures:
- Leetcode’s Top Interview Questions
- Hackerrank’s Interview Preparation Kit
- Cracking the Coding Interview
- Elements of Programming Interviews
- Youtube video explaining how to design TinyURL
- System design primer Github repo
- System design overview Github repo
- Blog post comparing common database management systems
- Medium article about mobile system design interviews
- Android app fundamentals guide
- Ray Wenderlich’s Android Interview post
- Mindork’s Android interview questions Github repo
Finally, I would love to hear about your interview experiences and which formats you encountered, and whether there are any I missed. I created a brief anonymous survey where Android engineers can share information about their interview experiences and view responses from other engineers. You can fill it out and view the results here.
Best of luck on your interviews!