Hiring Android Developers

Since starting my career as a software developer, I have been to interviews at various 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 the recruitment process should be structured and what is best to look for in Android developers. These questions don't have a simple answer that applies to all situations.

Hiring (and unfortunately not hiring) many developers across my working life has helped me to shape the way I approach it. I am by no means an expert and still have plenty to learn from others on the topic, but I believe (and hope) I have some valuable insights that may help other people hiring developers. Therefore, I will attempt to write down some different steps you could include in your hiring process.

Reviewing CVs

This stage shouldn’t come as 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 pretty amazing how varied CVs can be. Over time I must have reviewed hundreds of CVs and almost every single CV is different in length, style, format and content. I have seen a few killer CVs and unfortunately some that weren’t as good.

When reviewing CVs, it is crucial that you be as fair and objective as possible, avoiding any biases you may have. A good way to achieve this is to compare each CV to the same set of requirements that you have decided are needed to do the job. For an Android developer these may include things like:

• Live apps on Google Play
• X years Android development experience
• Performing app releases to Google Play
• Network communication such as consuming REST APIs
• Automation via Continuous Integration services like Bitrise
• Automated unit and UI testing

If possible try to look for a skill rather than its specific application. For example, knowledge of how to consume a REST API, rather than just whether they mention Retrofit and OkHttp. 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 can 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 intense problem solving or coding quickly under pressure. However, from my experience:

• They are very impersonal.
• They can be time consuming and stressful for the candidate.
• 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. My preference is just to use other ways to find the right person for the role.

Remote / phone / video interview

Once you find a candidate that 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 on-site interview at this stage. In most situations though you will want a remote interview to take place first.

Remote interviews are usually much shorter than their on-site 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.

App programming

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 or functional 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 in Android, using the tools they are familiar with and often in their own time.

The candidate applying may already have examples of their Android development skills via open source app(s) on GitHub, you could consider looking at these instead to make the hiring process quicker for the candidate.

If you do decide to ask the candidate to work on an app project of yours, the app should either be very simple so that they can complete it in a reasonable amount of time or it should already be partially developed. 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.

On-site interviews

This will make up the meat of your hiring 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 developer 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.

Behavioural

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.

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

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.

Technical

How to run effective technical interviews is a very large and heavily discussed topic. You will also find people have many 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 a Compose modifier 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 they wish.

When working on an Android app, people use libraries like Coroutines, 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 with the world of 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.

I hope the article was useful. If you have any feedback or questions please feel free to reach out.

Thanks for reading!