9 Common Android Interview Gotchas

So you’ve landed an Android interview! Congratulations. Let’s get to work and set you up for success for your upcoming phone screen or (perhaps virtual) on-site.

I usually interview Android candidates at least once a week, which means I’ve talked to a lot of candidates over the years. I see similar knowledge gaps pop up again and again, and I’m hoping this list can help guide you on what topics to review before the big day.

First, let’s talk about the common structure of Android interviews. Some companies value core computer science concepts as well as Android expertise. Some companies don’t care to quiz you on computer science concepts at all. Usually, in addition to Android and computer science, there is a behavioral portion of your interview where you’ll have a chance to talk about your past projects and experience. Talk to your recruiter or hiring manager for details so you can best prepare for your interview. This article only addresses the Android portion of your interview.

For Android interviews, the structure will vary by company but the general idea falls into two categories: project-based interviews and coding challenge interviews.

In project-based interviews, you guessed it, you build a project. Sometimes, you design the project from a high level and sometimes you’re expected to provide working code for the project. The most common project that you’ll see in an Android interview is displaying a list of data (it’s always a safe bet that you will be using a RecylerView in the interview, so brush up on the ins-and-outs). This is a super popular interview project for a reason. If you think about it, most of your favorite apps do nothing more than display a list of data (think social media news feeds, grocery lists, retail apps, etc). A good exercise to come into a project-based interview well-prepared is to go through your top 5 favorite apps on your phone and think about how you would design/implement them.

In coding challenge interviews, you are usually tasked with a “challenge” where you build a feature. Common tasks include creating a screen that takes and sends an image, displaying a list of data (again), or sharing location with another user. You should know the basics around how to accomplish these tasks in Android, but don’t waste time memorizing every detail of every Android or third party API. You can usually look up API specifics or ask your interviewer for help. If you’re expected to have every public method on RecylerView memorized, it’s probably not a well-designed interview.

Now that we’ve covered some Android interview basics, let’s dive in.

1. Solve problems with an architecture-oriented mindset.

This list isn’t necessarily ordered, but this is definitely number one by design. Write code as if you would be submitting a pull request to master. Don’t litter your Fragment or Activity class with business logic! Pick an architecture pattern that you’re comfortable with, and use it. When you’re preparing for the interview, always use your architecture pattern to solve common tasks.

For example, let’s say your interview coding challenge expects you to display some text on the screen after a user clicks a button.

You could write something that “just works”, like this:

This is fine, but this isn’t great. You missed out on an opportunity to demonstrate that you know how to write production-ready Android code.

This is much better:

Wow, you’ve just gone from “just works” to “great”! You’ve taken the opportunity to demonstrate your knowledge of industry best practices and you’ve wow’ed your interviewer. You can also mention all the “why’s” behind choosing MVVM over other architecture patterns like MVP or MVC. You can mention all the fabulous unit tests you would write, or even write them if time permits.

I know this example was simple, but stay on your toes during your interview when it comes to the design and architecture behind your code. A really common pitfall here is saving state. Beware of saving any state inside of a Fragment or Activity, and be wary of how you’re storing state. Use Kotlin data classes for data modeling (please do not use a boolean or a String). Remember, if you wouldn’t submit this code in a PR, its not good enough to submit during an interview!

2. Use ViewModel correctly.

It’s a really unfortunate mistake that I see way too often. You’ve remembered the first item on this list and you’ve got your chosen architecture pattern DOWN. You have opted to apply MVVM and use a ViewModel to store data for your Fragment or Activity, wonderful! But… you’ve made a mistake.

Can you spot the issue with this code?

What happens when the user rotates the screen? The instance of our ViewModel is preserved, sure. But did we make any wins on our network usage? No. We call the network again and again every time onCreate() is called.

How do we fix this? Cache the response data we need in our instance of LiveData and move the network call into our ViewModel’s init() method. That way, we don’t couple our network usage to our Activity’s onCreate() and we can leverage our retained ViewModel instance properly.

Beautiful!

3. Stick to the problem at hand.

This manifests in a couple different ways. It can get you in trouble, especially with time, if you broaden your focus too much on what you’re building and how you’re building it. Let me explain more.

It’s a good thing to be product-oriented! In fact, it is a great thing, especially as a mobile developer. However, it’s best to be product-oriented and focused on the task at hand. If you’re asked to build an app that displays a list of “to-do” items to a user, it shows a healthy and desirable product mind-set if you mention cool additional features for this app like location-based reminders or notifications. As you’re coding, mention ideas if they come to mind — but make sure that you finish the assignment at hand before diving into extra features.

Most companies will grade you objectively on how far along you can get in the assigned project or coding challenge. These are typically associated with numerical scores, and you won’t pass the interview unless you reach a certain score. You need to be mindful of your time and complete as much of the assigned task as you can. Once you’re done with the objective, ask your interviewer if they want you to write tests. If not, go ahead and add the cool extra stuff.

This also comes up with extra libraries, namely Dagger or Hilt for dependency injection or new Architecture Component libraries. If you’re aware of these things, great! Mention them — but don’t spend precious interview minutes on implementing these extras if you do not have a finished product. They won’t count for much if you haven’t already completed the task your interviewer has asked for.

4. Stick to the language you’re comfortable with.

You usually have two (practical) choices for most Android interviews: Kotlin and Java. Kotlin is the shiny new-new, so it’s tempting to use Kotlin even if you’re not comfortable with it. RESIST THE TEMPTATION. Using Kotlin when you don’t know the ins-and-outs of the language will hurt you more than help you. Just use Java if that’s what you’re used to! I would also argue that it is a poor interview design if using Java would be counted against you. Kotlin is still reasonably new on the scene, especially if you’re a new university grad.

The problem with using Kotlin when you’re more comfortable with Java is that, spoiler alert, it’s super obvious to your interviewer. Kotlin is an incredible language, but there’s a lot of Kotlin language paradigms that you have to know well to use the language effectively for Android. If you’re new to Kotlin, I recommend reading this book cover-to-cover to equip you with the ins-and-outs that will most likely come up in interviews if you choose to code in Kotlin.

What if you are comfortable in Kotlin, but you’re not an expert? That’s ok, just do not use Kotlin language features that you’re not familiar with. Don’t use the in or out modifiers if you don’t know what they do! Don’t use the by keyword if you don’t know how it works! If you’ve been using data classes for your API responses, be prepared to answer in-depth questions about data classes! Read up on these things if you’re not familiar.

If any Kotlin language feature is a mystery to you, demystify it and become an expert. This will set you up for success if you’re interviewing in Kotlin.

5. Stick to the libraries you’re comfortable with.

Following the same logic as our Java vs. Kotlin discussion, do not use a library in your interview project or coding challenge that you do not know well.

Adding Dagger to your project when you can’t speak to how Dagger generally works behind the scenes or why it’s better than DIY dependency injection is not a good idea. When you add a library to your project or reference it in your coding challenge, you are serving up the library to your interviewer as fair game for questions. It would be better to simply avoid adding the library than add it and not be able to explain your “why” behind using it.

Before your interview, it would be good to look at common Android libraries, pick the one you’ll use for an interview and make sure you can speak to why you chose it as opposed to other available libraries.

Using Glide for loading images in your interview photo app? Great! Make sure you can state exactly why you’re not using Picasso. How do both compare when it comes to image caching? What about the library size of each?

Are you using Hilt for dependency injection? Amazing! You should be able to tell the interviewer why you’re not using Dagger.

Remember our discussion about sticking to the task at hand? All of these libraries are “extras”. It usually is not criteria for an Android role that you know exactly how Dagger works underneath the hood. If you use Dagger in an interview, know Dagger. If you don’t, just skip it. Only use these libraries if they can demonstrate your strengths, not point out a weakness or a gap in knowledge.

6. Think about error states.

This comes up a lot. It’s an easy opportunity for an interviewer to poke holes in your code.

A good mobile developer knows to proactively handle bad network connectivity. If one of the requirements for your interview prompt has anything to do with a network connection, do not forget to handle error states. After you’ve gotten a first draft of your networking code out in the IDE or on a whiteboard, the immediate next step you should take is verbally point out potentials for network errors and address them with code. This shows attention to detail. Make sure to also run through scenarios where perhaps a user rotates the screen mid-network request. Don’t forget to call out common threading “uh oh”’s here.

A good mobile developer also knows how likely it is for their app to be killed in the background after the user answered a phone call mid-scroll or switched to a messaging app to reply to a text. Look for these common mobile edge cases, call them out, and if you have time — address them!

7. Write code for BILLIONS.

This item won’t always necessarily count against you, especially for more junior roles. However, what sets Android software engineering apart from other disciplines is that Android runs on all kinds of devices in all kinds of places.

Android runs on mobile phones, and Android runs on refrigerators. Android runs on 5G network connections, and Android runs on… way slower network connections. Did you know that data plans in some countries can cost 10% of a user’s monthly income? It will set you apart in an interview if you demonstrate Android app design skills with a “code for billions” mentality.

Familiarize yourself with proper architecture patterns to support users with low-end devices on slow networks. For example, if your interviewer asks you to build an instagram-like app, you should proactively call out things like image resolution and image caching. Would you check for network connection quality before asking the server for a high-resolution image? If you need to perform some long running background task to download these images, how would that impact battery usage?

8. Don’t over-index on performance concerns.

After the previous item on this list, it might confuse you that I would tell you “code for billions, but at the same time, don’t care TOO much about performance”! Let me explain.

It’s reasonable for you to call out that you’ll use WorkManager to schedule long-running background tasks when the user is connected to WiFi and the device is connected to a charger because you are concerned about performance. It is not as reasonable for you to say that you’re going to avoid allocating a Enum variable in your MainActivity and sacrifice readability for the memory allocation cost of an Enum.

In the days of Dalvik and the days before Dalvik, it was probably more reasonable for you to worry about Enum objects in regards to memory allocation or maybe even pool objects in memory (gasp!). We could go over all of the details about improvements Google has made to the Android runtime, but let’s save that for another blog post.

Long story short, don’t sacrifice minuscule performance gains for clean, readable code in your interviews in the name of performance.

9. TALK. Yes, talk out loud!

This is a big one, and doesn’t come naturally for everyone (especially me!) — but allow me to let you in on a little secret.

The more you talk, the more your interviewer can understand your thought process, and the more you will gain points for team-work and collaboration. Even better — if you’re pressed for time and can’t get to some of the extra stuff like writing unit tests, using fancy libraries, or adding error states simply mentioning these things will demonstrate that you’re at least thinking about them! What might seem obvious to you is not always obvious to all candidates, so think out loud and let your interviewer know exactly what’s going through your mind.

Especially if this does not come natural for you, practice! When preparing for your interviews, say your thoughts out loud as you practice coding. Get used to thinking out loud! Trust me, this will only help you.

—

I hope this list was helpful, and please drop a comment if you have questions or feedback. Good luck interviewing, and happy coding!