What To Expect For Your Virtual Android Interview

Sherry Yuan
Sep 29 · 9 min read
Image for post
Image for post
Photo by Maranda Vandergriff on Unsplash


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.

System Design

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.

Behavioural Q&A

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.

Technical Q&A

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.

Image for post
Image for post

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.

Take-home Project

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.

Code Review

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:

System design:

Technical Q&A:

Code review:

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!

Thanks to Russell, Daphne, and Kelvin for their valuable editing and feedback! ❤️

Tech x Talent

Insights at the intersection of tech and talent.

Sign up for Building The Future

By Tech x Talent

Forward-thinking resources, guides, and initiatives at the intersection of tech and talent Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Sherry Yuan

Written by

Android developer @ Robinhood

Tech x Talent

Insights at the intersection of tech and talent.

Sherry Yuan

Written by

Android developer @ Robinhood

Tech x Talent

Insights at the intersection of tech and talent.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store