Since starting my career as a software developer, I have been to interviews at a few different companies. I have, however, more often been on the other side of the process: reviewing CVs, analysing code submissions and conducting interviews. On a few different occasions, I have been asked how I think we should be structuring our recruitment process and what to look for in Android developers. These questions simply don’t have an answer which applies to all situations.

Hiring (and not hiring) many developers over the last few years has helped me to shape the way I approach it. This doesn’t mean I think of myself as an expert on the subject, but just someone who believes (and hopes) he has some valuable insights that might help someone else. Therefore, I will attempt to write down some different steps you could include in your recruitment process. 🤔

A cartoon candidate taking an Android interview
The Android interview

Reviewing CVs

This stage shouldn’t really be a surprise to anyone, as obviously you will need some way for candidates to apply for the position. This is the first opportunity for the candidate to tell you why they think they are right for the job.

For some people a CV might be self explanatory, but it is quite amazing how varied CVs can be. Over time I must have reviewed hundreds of CVs and I can quite confidently say that every one has been different. I have seen a few killer CVs and unfortunately some that weren’t as good.

One does not simply write a perfect CV meme
CVs are hard

As the person reviewing CVs, it is very important to be fair and as objective as possible. This means that you should be comparing each CV to the requirements you have decided are needed to do the job. For an Android developer these might include things like:

  • Live apps on Google Play
  • X years Android development experience
  • Performing app releases to Google Play
  • Network communication: REST, JSON, OkHttp, Retrofit etc.
  • Automated testing: JUnit, Espresso etc.

If possible try to look for a skill rather than its specific application. For example, knowledge of how to communicate with a server in a RESTful manner, rather than just whether they mention Retrofit. Obviously if a candidate already knows the libraries you use, this can be a great bonus. The focus should, however, be on spotting their level of experience and their ability to learn new skills quickly. 🎢

I’m not keen on online tests

The next stage in the process for many companies would involve some form of online test or screening process such as Codility. These tools might make sense for some positions, for example a job that requires lots of problem solving or for coding really quickly under pressure. However, from my experience:

  • They are quite impersonal.
  • They can be time consuming and stressful.
  • The problems are rarely similar to the type of work the job entails.
  • People often do better or worse than they would do in a real-world scenario.
  • They only check the solution rather than the journey to get there.

I’m not saying these online tests are wrong and should never be used. It is more that I believe there are better ways to find people who are right for the role.

Skype / phone interview

Once you find a candidate you think looks promising it is important to meet them as soon as possible. If the number of applications you are receiving is fairly low you could consider going straight to the onsite interview at this stage. In most situations though you will want a remote interview to take place first.

A man running a phone interview
The phone interview

Remote interviews are usually much shorter than their onsite counterpart, preferably something in the region of 30 minutes or less. The shorter length and the fact they are remote can make them much quicker and easier to schedule with the person applying. They can be a good way to quickly gauge the candidate’s experience, their interest in the position and how well they would fit into the team. By having a conversation, it allows them to form a connection with you and the company. Without this having taken place, if another offer comes from elsewhere they would have a lot less driving them to continue the process with you. 🤷‍

Importantly, this shouldn’t feel like an interview and should be as informal as you can manage, allowing the candidate to relax. Some potential talking points:

  • Their current role
  • Working on a particular task
  • Code reviews
  • Testing
  • Continuous Integration

You may also be recruiting for a completely remote position or prefer to do your interviews entirely remotely for ease, in which case you would have a longer remote interview.

App test

You are looking to hire an Android developer and so the best way to check their technical proficiency is by looking at how they program an Android application. This might seem obvious, but you will find many recruitment processes that rely on object-oriented programming challenges and whiteboard exercises. I gave my stance on online testing earlier, however, there is a key difference here in that the candidate will be programming an Android app in their own time and sending it to you.

The person applying will be able to use the tools they are familiar with, such as Android Studio and work at their own pace. The app you ask for them to complete should be incredibly simple so that they can complete it in a reasonable amount of time. You should also make it clear that they can use whatever approach they want and use whichever libraries they wish. This will allow you to see how they think an Android app should be developed.

There are many advantages to seeing applicant’s Android code before they come in to interview. You can gain insights into their development processes and how they would work as an Android developer. An important consideration though is that completing an app test does increase the amount of effort they have to put in. Therefore, you will have to decide if you think it makes sense for your company to include this in the recruitment process.

Onsite interviews

This will make up the meat of your recruitment process and will likely consist of various stages. The main areas you should consider covering are behavioural (team fit) and technical (skill and experience). Before getting started it is a good idea to describe the general format and timings to the candidate. This helps them to understand how much time they have got and what to expect.

Have a conversation

One way of running an interview is that the candidate sits in front of you and is asked a set of different questions, delivering an answer after each one. This approach would only give you answers to your specific questions and would be unnecessarily stressful for the person you are interviewing.

Alternatively, I try to make my interviews as conversational as possible. This means leading things in a certain direction using questions, but allowing the candidate to discuss what they want on the topic. This really shows you how the candidate would communicate with other team members and allows them to demonstrate their experience and knowledge to you. By making the questions as open as possible, it will expel the notion that there is a single correct answer you are looking for. Instead the candidate should relax and open up, telling you their opinion freely on a particular topic. You will even find you learn about new things during these conversations.


These types of interviews can often be labelled soft skills or team fit interviews. This should in no way diminish the importance of this area of questioning. If you have put the candidate through the app test already the behavioural component could actually be considered the most important part.

Tell me about a time when you prepared for a behavioural interview meme
Behavioural interviews need worthwhile questions!

You will ask questions which check the candidate fits with your company culture and the team’s way of working. It will also give the applicant some insight into how the company works. As with reviewing CVs, you should decide which characteristics are most important to you when deciding on your behavioural questions. For example:

  • Collaboration with other team members
  • Ability to learn new technologies and skills
  • Leadership qualities
  • Communication
  • How well they can learn from past mistakes
What is my worst flaw? I am too awesome!
Asking for general weakness may be a waste of time

Please don’t ask all the obvious questions we all read about online, such as asking about their strengths and weaknesses. 🙄

Instead finding out about situations where they:

  • Had to learn how to use a new library quickly.
  • Dealt with a team member who strongly disagreed with their opinion on a code review.
  • Persuaded other team members to introduce a different app architecture.


How to run effective technical interviews is a very large and heavily discussed topic. You will also find people have lots of different opinions of how to go about it.

It is very common for interviewers to ask you to write solutions to problems on a whiteboard. Personally, I have never understood this approach as developers don’t generally spend their days finding substrings, detecting palindromes and writing code by hand on the wall. 😱

Any coding you ask the candidate to do should match what they would do if they got the job. This doesn’t mean you have to get them working on the app they would actually work on. It does, however, mean that they work on an Android app, using the tools they would use and in the environment they would work in.

In reality, developers don’t remember absolutely everything and recall it perfectly on the spot. They sometimes forget the signature for creating a RecyclerView adapter or the name of the Retrofit annotation they need to use. I think it’s a good idea to tell candidates that they can use StackOverflow or the API documentation if wish.

When working on an Android app, people use libraries like RxJava, Retrofit and Dagger. This means when they are coding in the interview I think we should make it clear they can use whatever libraries they want to use. You could choose to force them to write plain Android code so you can check they know how to do it. However, I think it’s most valuable to see how they would code in a real-world situation. You may even be able to ask why they chose a particular library or particular approach.

As I mentioned earlier, any technical questioning should be as conversational as possible. I generally write down a few topics I would like to find out about and then nudge the conversation in the right direction using my questions. For example:

  • Handling a slow internet connection
  • Automated testing
  • Dependency Injection
  • Keeping up-to-date in Android development

Time for questions

It is very important that you leave time for candidates to ask you any questions they might have. If the interview was fairly conversational, this may already have been covered. However, if not then it is good to prompt them at the end just to make sure they get the chance to ask any. It is important to remember that you are trying to find the right developer for the team, but they are also trying to find the right company for them.

Closing thoughts

As I have said a few times, there are various different ways you can check candidates are right for the position. The techniques you choose to use and the questions you choose to ask, won’t be the same as other interviewers. If carefully put together, the process will help you find some really great developers who are a good fit for the team and for the company.

What are your thoughts on the state of Android developer recruitment? Do you have any suggestions for how to improve it or any thoughts on the ideas I have shared? Let me know any questions or thoughts on Twitter @lordcodes.

Good luck with your search for Android developers and thanks for reading! 🙏