Interviewing Android Developers

A friend of mine recently asked me for some advice about interviewing Android developers. We talked for a while, and I said I’d write some stuff down and send it to him. Over the last few years I’ve interviewed dozens of candidates from around the world, and brought several colleagues in on in the interview process to share the experience with them too. As a byproduct of that, there were emails and wiki pages full of attempts to distil our thoughts into something informative and concise.

By no means am I an expert on the subject, but when I first started, I found immense value in some thoughts a senior colleague shared with me, on what to ask and what to look for. I hope that by writing these words, I can someday provide that value for someone else.

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.

Being the interviewer is also difficult. You have a short amount of time to gain enough information about a human being to make a decision about them that has potentially huge implications to them, to you, and to the company.

Interviews should be conversations

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

I hate the notion that an interview is a unidirectional series of questions that have right and wrong answers. We might as well just hand people a paper questionnaire to fill out. Why bother interviewing them if we’re going to do it like this? It’s unnecessarily adversarial. It shines a searchlight on the candidate, limiting the scope of what can be learned to only those things which fall within the searchlight’s narrow beam. Anything you don’t ask, you don’t hear about. The candidate learns nothing about you or your company, except that you view this as an acceptable way to treat people. Is this what working there will feel like?

This is an extreme example, obviously — I’m sure even the most scripted set of interview questions allows room (admittedly, at the end) for any questions the candidate might have. But still, what’s the point? Surely that’s not what conversations in your team are actually like. If you’re trying to get a feeling for what it would be like to work with this person, shouldn’t the interview try to approximate that situation?

I like an interview to feel like a real conversation. Sure, one person is trying to convince the other to give them a job, but that doesn’t mean it can’t still be a chat. If you’re interviewing someone, there’s a good chance you’ll be working closely with them if they get the job. That can mean sitting beside them for eight or more hours a day, five days a week, forever. Or maybe you’ll just be dealing with each other’s code all the time. Or anything in between. You should be able to talk to them, freely and comfortably.

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.

Once we’re ready to go, I use questions to open up discussions, or as follow-up questions to clarify details. Closed questions, with right/wrong answers, are generally less useful.

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 Activity lifecycle?
• 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?

If these questions seem vague, they’re supposed to. The Activity lifecycle should be pretty straightforward and self-explanatory, but beyond that all of these questions should be most often answered with either “it depends” or a question from the candidate. This strengthens the conversational nature of the interview, since more communication is required from both sides to move forward. As any capable Android developer will know, there are multiple ways to persist data, to perform long-running operations, and to communicate between Fragments. All of these things — even using Fragments at all — are worthy topics of discussion. They can tell you a lot about how someone approaches things and what they’ve done.

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.

Android development has a huge community of third-party open-source libraries, and a strong affinity for using these libraries to avoid reinventing the wheel. Of course, it’s possible for people to go overboard, solving (perceived) problems in their apps by applying third-party solutions, without fully understanding the problem, or the solution, or both. I find it helpful to ask about solutions candidates have used, focusing on categories rather than specific libraries. Here’s a few:

• Networking: OkHttp and Retrofit have become pretty ubiquitous these days. Volley still pops up from time to time though, and I’m always curious to find out why someone favours it. I still have nightmares about Spring RestTemplate.
• 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.

Testing

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.

For a candidate above the level of intern or junior developer, I want to hear that they’ve had some exposure to:

1. Unit testing
2. Instrumentation testing
3. UI testing with Espresso

And I want to hear what their opinions are about all of these things.

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.

Writing a CV is a horrible exercise in trying to fit a lot of information into a relatively short document and still having it nicely formatted with plenty of friendly bits of whitespace. You have to prioritise and cut and revise, and sometimes your best or most interesting work only gets a couple of words on the page. It’s important to provide an opportunity for people to talk about these things.

Some stuff doesn’t get a place on the CV, but can still be very relevant. What was your favourite, or “best” project that you worked on? Why?

As well as the good stuff, it’s useful to ask about the bad. I like to ask about the most difficult problem (or project) a candidate has encountered, and what they did to solve it (did they solve it?). How did they approach that difficulty? It doesn’t necessarily have to be technical. It could be something about the team or the customer. Either way, it can tell you a lot about someone — good or bad.

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.

I try to frame a question around the candidate and their experience of (or interest in) some aspect of the wider tech/Android world, preferably something recent. Is that a Moto 360 on your wrist? Were you at Droidcon [location] last week? Did you watch the I/O keynote yesterday? All of these questions serve to open a topic for more conversation. Personally, I want to hear that a candidate had some engagement in something like the I/O keynote — they should have at least one opinion about at least one announcement, and something they’re curious to hear more about.

How do you keep up to date with Android news? I always ask this at the end, and I’m not sure if it’s for me or for them. Any particular blogs, websites, podcasts — I can barely keep up with all the ones I follow, but I’m always curious to hear what other people are using.

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.