Interviewing Android Developers

Interviews are hard, for both sides of the table.

Being an interview candidate is a nerve-wracking situation. It can also be intimidating, and in some rare cases, humiliating. It’s easy to suffer from a bit of white coat syndrome, performing more poorly than you would if you weren’t in an interview. I forgot what Maps were for, once.

Interviews should be conversations

I have a bee in my bonnet about the way some people do interviews.

How to have the conversation

While I like to treat an interview as a conversation, it still needs to have direction. I still have things I want to find out, things I want to talk to them about. I like to break it up into several sections, and I’ll outline that basic structure to the candidate at the start of the interview. These sections are flexible, both in time and specific aspects of the subject matter. Sharing the structure with the candidate helps them feel more comfortable; it gives them an idea of what to expect, and extends a friendly gesture of information-sharing. It’s subtle, but it makes a difference.

Openers: Android basics

I like to start with some questions on Android basics, starting with a particularly easy question. This serves the double purpose of both putting people at their ease by giving them a quick and easy win, and flagging a surprising number of people who clearly don’t know a lot about Android.

  • Can you describe the difference between a Service and a ContentProvider?
  • How would you persist data in an Android app?
  • How would you perform a long-running operation in an application?
  • How would you communicate between two Fragments?

Tools and technologies

It’s always a good idea to get an idea of what kind of tools and technologies someone uses to do the job. If they’re still using Eclipse, or vim, or anything that’s not Git, I want to know why. For the most part, people answer with Android Studio and Git. That’s great. But it’s still good to find the outliers.

  • JSON serialisation/deserialisation: most people use GSON these days, though Moshi is growing in popularity. I find Moshi to be a great topic for a bit of discussion, as its advantages over GSON are not immediately obvious to someone unless they’ve looked into it. I can’t decide which one is more of a red flag to me — using Jackson or doing it manually. Jackson’s method count is absolutely insane, and writing your own JSON handler is time-consuming, brittle, and downright unnecessary.
  • Source control: as mentioned above, I find it very strange in this day and age if someone isn’t using (or has never used) Git. Leading on from that, I’m curious about how people use Git, both from a process point of view and a tools point of view. Do they use feature branches? Do they use pull requests? Do they have a develop and a master branch, or just master? Personally, I find myself commonly using both terminal and Android Studio’s Git client for my general needs (creating/switching branches, creating commits, rebasing, merging etc), and occasionally going to SourceTree for visualisation. But when something gets mixed up and I end up in a confusing conflict state that needs to resolved, I put all GUIs aside and go back to the ultimate source of truth, the terminal. Some people have never worked with Git on the command line. I find that worth talking about.
  • Dependency injection: with the rise of Dagger (1 and 2), dependency injection has become much more common in Android apps. And as anyone who uses it can tell you, it’s fantastic. But it’s important to know what dependency injection is, how it’s implemented, and why we want to do it in the first place. What makes Dagger 2 better than Dagger 1? Are there any other dependency injection solutions for Android? What’s good/bad about them?
  • RxJava: I’m a huge fan of RxJava. It changed the way I write Android apps. I love it. Not everyone uses it, not everyone has used it, and that’s fine. But it has been a hot topic in the Android community for some time now, and if someone hasn’t heard about it, or hasn’t tried it, that’s not a great indication of their awareness of the state of the art, or their interest in trying new things. If they have used it, I want to know how much. What’s your favourite thing you’ve ever done with RxJava? What were the hurdles or drawbacks you found?
  • Kotlin: Kotlin is a lovely language. It’s another hot topic in the Android development community. Like RxJava, I’m curious about whether people have used it, and what they thought of working with it. What’s your favourite feature of the language? Did you ever have any problems with it?
  • Android Support Libraries: part of Google’s partial solution to the age-old fragmentation problem that tech journalists like to crow about, the support and design support libraries have become fairly ubiquitous. The advent of Material Design only strengthened this. But they bring with them their own problems. These are worth talking about. It’s also good to ask about some of the less common, or newer components. At the time of writing, ConstraintLayout is one I’d ask about. VectorDrawable too.
  • Google Play Services: I’ve recently come to blows with GoogleApiClient and some of the Google Play Services APIs. They can be somewhat awkward to use, but provide immense power to your app when used correctly. I like to hear what a candidate experiences are with Google Play Services.


I consider testing to be its own section in my list of topics to cover. It’s important. In the early days, the state of testing on Android was quite poor, but it’s come along by leaps and bounds over the last couple of years, with JVM JUnit tests, Espresso, and the Android Testing Support Library. Talking about testing naturally involves talking about app architecture — an app isn’t testable unless it was written to be testable. So this has some crossover with the dependency injection questions mentioned above, but also has potential to bring in MVP in its various incarnations, MVVM, and any other strategy someone might use to structure their app’s code.

  1. Instrumentation testing
  2. UI testing with Espresso

CV projects and war stories

When you read over the CV of a candidate, make a note of anything on it that caught your eye. In the interview, ask about each one of those things.

Personal interest in Android/technology

This is the last section in my list. I feel like this can be the most casual, most informal part of the whole conversation. The goal is to get a sense of how much the candidate is really interested in Android, or in technology in general. For some people, it’s just a job, and that’s OK. For others, they go home every night and work on their own side projects or read every tech article they can. It’s good to know these things, to get a better understanding of who you’re talking to.

Closing up

It’s important to leave time for candidates to ask any questions they might have. Obviously these don’t have to wait until the end, but it’s good to explicitly prompt them for any questions they didn’t get a chance to ask already. You’re interviewing them, but they’re also learning about you, and your company. Remember, it’s a two-way conversation.

Android Developer in Dublin, Ireland

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