This post aims to demystify some of the steps in a typical Android interview process. We’ll discuss steps, strategies, targets and solutions. Getting you better prepared to get your next Android role.
This blog is from personal experience, caveat up front that your experience could be completely different, but I’ve been through A LOT of interview processes and can safely say (imo) they all end up following the same split and compartmentalised structure. It’s just some companies leave some bits out and add others in. Like an interview spicy gumbo.
Below are all the typical steps of a multi-step interview process. They won’t be all at once and typically in a linear fashion, future steps will be gated based on the results of previous steps. Meaning, if you flunk the “get to know you chat” they aren’t going to ask you to continue on and do the “pair coding exercise”. Let’s take a read through them:
Get to know you chat
- This’ll be ~20 minutes, sometimes it’ll be organised straight after your application, other times it’ll be an ad-hoc phone call, be prepared to not be prepared; they’ll be asking questions casually, ensure you are up to speed with your own CV details 🙂
- A casual chat about your experience, your previous roles, the role you are applying for, the company you are applying for
- Typically run by the hiring manager for the role, sometimes ran by the recruiter managing your process
- They’re looking to check that you are an Android developer, are positive in your attitude, and have an eagerness to work for/with them
- Be prepared to talk through your previous roles at a high level, have some questions prepared about the target role and questions about the target company (which hints at: do some research)
Take Home Exercise
- This is typically a small rubric asking you to create an Android application
- Here is one I did recently where they asked me to push it to GitHub once finished. I’ve also written a whole blog post, specifically on this interview
- The rubric is the key to this task. What it says, goes. For example, if it says “use animations” then you had best make sure you have animations or it’ll be an instant rejection. Read the rubric carefully.
- Use comments in your code. This isn’t a production app, this is a showing of your experience on paper. If you feel pushed for time, or if you feel something is outside the rubric but would be worth while. Write a comment explaining. “// Here, for a production app, I would added X because of Y, Z but in the constraints of the interview I have left it out.”
- Sometimes you’ll be given a template app to start from. Don’t be afraid to upgrade the Gradle dependencies & Gradle itself, they aren’ t testing if you can handle their legacy stack – they just don’t have time to keep the template up to date, but they will want to see you using the latest and greatest tools available.
- They say spend “N hours” on the task, I would say always spend N+N and tell them you spent N+2 max. In a typical environment you would be more accustomed to the domain and perhaps an already existing stack, so spending a bit more time but not recording that accounts for this.
- All take home exercises that require an app to be built typically have the same structure: Pull some data from the internet, display the data in the list, optionally click through to details of an item, ensure you are comfortable with the latest concepts and architecture from the official Google Android docs, this is your best reference
- Every take home exercise I did and feedback discussion I had involved the following: MVVM/MVI, Jetpack Compose, Jetpack ViewModel, the Repository pattern, Hilt, Modularisation and unit tests. (If you make yourself a demo app using the previous mentioned, you are well on the way to passing this step every time.)
Pair Coding Exercise
- A pairing exercise is when you share your screen and write some code, or the interviewer shares a website where you can write code whilst they watch
- Whilst it’s called a ‘pairing’ exercise – you will be driving 99% of the time, typing all of the code and talking through your thoughts
- Talk through your thoughts, this involves repeating the rubric out loud and talking about how you will address the points
- Ensure to ask qualifying questions, there may be points you don’t need to implement in the way you are thinking, or other constraints not written down at the beginning
- This can be instead of or as well as the ‘take home exercise’ therefore a lot of the same learnings apply (Such as Compose, ViewModel, Repository Pattern.)
- As this is typically 45 minutes or an hour, they do not expect you to write professional production code, but they do expect you to talk about the shortcuts you are taking and what the advantage of that would be. For example “typically I would split this into a networking module for a better separation of concerns, but is it ok if we just create the file here to save time?”
- Talk about testing with your interviewer, and gauge if/how they want you to test the solution. Sometimes this is as simple as running the code and walking through it line by line moving the cursor, other times it may be logging out results, and lastly it may be writing at least one unit test. But check first, you can waste a lot of time writing unit tests when they are not expected.
- Sometimes this interview is not about getting to the full solution, its more about seeing how you work, making sure you can express your thoughts and seeing you are enjoyable to work with. Take your time and talk it through, never be silently coding.
Leetcode Question
- A subset of the pair coding exercise
- Leetcode questions can be tough! Your best bet for success in this interview is to practice, practice, practice on one of the available websites (e.g. leetcode, hackerrank).
- You need all the help you can get, talk to your recruiter or anyone you know at the company, if you can get any hints about the level or category of the questions to be asked, this will let you narrow down your research area, a lot! Don’t underestimate asking for further information before your interview!
- Questions are typically of the medium difficulty, you may get a hard question but if you want to narrow the scope of your practice, concentrate on medium questions
- Get the basics down: be able to describe code in terms of big O, solve questions with array & string based solutions, solve questions with hash based solutions, keep practicing.
Review of Take Home
- Involves a discussion with you and engineers from the company.
- They will have reviewed your code and may have questions for you or they may expect you to talk through the architecture and describe your solution
- Be comfortable explaining what patterns you have followed.
- Know the alternatives to the patterns you have used.
- Have at least 2 advantages and 1 disadvantage for each pattern you are using.
- You will already have added comments in the codebase with extra things you did not do, be prepared to revisit these and remind the interviewers that you considered them at the time, they may not have noticed the comment.
- Have a strong opinion but hold it weakly. You want to be able to defend your reasoning but be open to alternatives at the same time.
- Conclude any debate with having a personal preference but also being open to alternatives. These alternatives may potentially have been forced on the companies code base from other factors or are there for legacy reasons. You need to be flexible as you don’t ever know what cobwebs are in a companies code base and they are see’ing if you are up for working on them. 🙂
Systems Design
- This is all about talking through the creation of a software system: in our case typically an Android app displaying data from a back end
- Your system architecture will typically be very similar to the app you created for a take home exercise step or a pairing interview step
- Get used to drawing a typical high level architecture diagram that involves a backend sending data to/from an app that uses the repository pattern and some sort of front end UI architecture
- You may not have time to cover all these topics, but be considerate of: typical patterns, the learning curve of your choices, logging/monitoring, feature switches, GDPR/Personal Information, accessibility, flaky connections, bandwidth use, caching/persistence, testability and ability for multi-developer collaboration
- I can’t do this interview stage as much justice as this post by Alex Lementuev. It goes into much more detail and gives guidance specifically for mobile systems design interviews: mobile-system-design
Behavioural Questions
- It’s not typically called “culture fit” or “sanity test” any more, but the company wants to know you are capable of working with and for them
- Use the S.T.A.R method to answer any questions, what was the Situation, what was your Task, what Action did you do and what was the Result
- Sometimes this interview involves walking through your CV with repeated questions about each role:
- What where you hired to do here
- Leadership & Influence
- Name a time you had a … [Challenge/Teamwork/Success/Conflict]
- What would Manager X say is a Strengths
- What would Manager X say is a Weaknesses
- Sometimes its typical social questions:
- tell me about a time you mentored someone
- tell me about a time you had to change someone’s mind
- tell me about a time you had to give tough feedback
- Have questions ready for the interviewer. Have at least 1 question about the company, 1 question about the team/role and 1 question about future growth.
- For that extra bonus, research your interviewer before hand and have a question about them. “I watched/read/saw your recent X, for the role I am applying for – could that mean Y?” or “for that role I am applying for – is that how you Y?“
Recap
You can have multiple interviews that are either composite or separate interviews with the following areas: “Get to know you chat“, “Take home exercise“, “Pair coding exercise“, “Leetcode question“, “Review of the take home“, “Systems design“, “Android questions” and “Behavioural questions“.
With all of these interviews, you can ask your recruiter before hand for clarification of what the interview type is and what is expected. Its ok to ask.
I hope this breakdown gives you some food for thought for how to prep for these interviews and wish you luck on your Android interviewing journey!
If you would like to ask me any questions about “Proven Prepping for Easy Android Interviews” or discussion about any upcoming interview you have, you can find me on:
Twitter @Blundell_apps
BlueSky @Blundell