My Android Engineer Interview Process

As someone who often struggles with imposter syndrome, making the decision to interview was honestly pretty nerve-wrecking. I was genuinely convinced that since I wanted to focus on take home projects rather than leetcode style questions, I would barely get interviews, much less an offer. When I finally decided to start studying for interviews, I reread one of my favorite books from college, Growth Mindset by Dr. Carol Dweck to remind myself that I (and you!) can always learn if I don't know something right now. How else would I (we!) have made it this far?

Anyways, this article is to share my interview process and tips for mobile engineering interviews with a take home approach.

Part 1: Career Reflection, Researching Companies, HR Interview

I started off with doing a career reflection based on my previous work experiences, a great piece of advice one of my mentors gave me as I started to prepare for interviews. I have mentors with different backgrounds in tech and wanted to share the helpful questions they posed to me as I started to think about my career.

• Thinking all the way back to college, what were my favorite activities? Why did I like those activities? What activities didn't I like? 

• What do I like from my current job? What is my current job lacking? What are non-negotiables? 

• What do I require from a company? Individually and as a team? 

• In 5 years from now, what would you have gained from your job? Where do you want to be in your job 5 years from now?

• What do you want from your job? What are your career goals?

As I began to research different companies, I was able to narrow my job search because of the career reflection. My research usually looked into glassdoor employee reviews, investment numbers if they were a startup, diversity & inclusion, and more. While I knew of a few companies that didn't hire using whiteboards, but I also looked at this airtable, Hiring Without Whiteboards, as a reference. A good piece of advice I read on Twitter was organizing the interview process by making a simple chart with the company and current status (applied, HR call, technical interview, virtual onsite, offer) so that I can prepare appropriately.

The HR Interview

This interview usually consists of learning more about you as a candidate and what you're looking for to ensure that it's the correct match on both sides. 

For my introduction, I made sure to provide my background, what I currently work on, what I enjoy about my current job, and what I'm looking for in my next role. This is a good reminder that you're also interviewing them as much as they are interviewing you. Then, they usually ask logistical questions (work visa, timeline, etc) and give an overview of the interview process. This is the best time to ask questions to see if it's a good fit before going through the interview process, but I would say that interviews are great practice for future interviews. Some questions I asked were related to team size, career development, mentorship, and tech stack.

I was surprised to see that this was something that made me stand out, but I came with questions prepared either about the company, work culture, or diversity. One of my recruiters told me how, of all candidate pools, engineers tended to feel entitled and treated recruiters rudely, so this is just a reminder to be nice to everyone you meet. I can say this because it's helped me in the past, but having a positive relationship with your recruiter definitely makes a difference.

Part 2: Technical Interviews

To no surprise, I'm not a fan of technical interviews. The pressure as someone watches me live code, constantly reminding myself to talk about what I'm thinking, on top of actually coding within the time frame is a lot. For android engineers, I would highly recommend What To Expect for your Android Interview, where Sherry also gives a great overview of different types of interviews and shares resources. I utilized some, but not all since I was taking a different interview approach.

General Programming & Android:

I started off by reviewing Sherry's great blog series, Kotlin For Interviews, and brushed up on data structures and some algorithms with BaseCS. Additionally, I reviewed Android concepts such as live data/flows, dependency injection, unit testing, MVVM architecture, recycler views, and more by looking at the Android documentation or doing a codelab. Some useful android guides I would recommend reviewing are:

• Guide to App Architecture 

• Application Fundamentals

• User Interface & Navigation - I only reviewed a few sections such as layouts, designing effective navigation, swipe to refresh, and search overview.

Take Home Projects

I'm a fan of take home projects because it removes the pressure of someone watching me code live and it feels more like I'm working on a side project rather than an "interview." All of my take home projects involved making a network request, receiving some list of data, and creating a recycler view with that data. Of course, there were differences in layouts and functionality, but that was the general pattern. My go-to libraries were Retrofit, Moshi, and OkHttp and I only used Kotlin with MVVM architecture, coroutines, and navigation components. This worked for me because it's similar to my work, but you should use whatever you're most comfortable working with.

I started off by going through this 3-part codelab project where you display data and images from the internet. While there is an order, each codelab is set up with starter code if you don't want to go in order/if you want to skip steps.

8.1 Getting Data From the Internet

8.2 Loading and Displaying Images from the Internet

8.3 Filtering and detail views with Internet Data

On top of this, I also practiced simple features such as sorting on the options menu, clicking an item in the recycler view, and swipe to refresh. I also practiced using the Pokemon Api to practice with retrieving different types of data.

Some Advice...

• Ask clarifying questions

• Have a template with all the libraries and dependencies set up with a basic activity/fragment to save time

• Practice by talking with a friend over zoom/google meets! It helps make the actual interview seem like a practice session and taught me how to share my thought process. I also tried to avoid being quiet for too long, even when I didn't know what to do.

Some of my common sentence starters were:

• I'm taking this approach because...

• If I had more time, I would.....

• I'm trying to figure out how to....

• So I tried this, which didn't work because.... So now I'm going to try doing.....

I'm not sure if it's because I'm a mobile engineer or because I'm mid-level, but I didn't have too many system design interviews like the ones I've read about where a person is asked to design a system from scratch. Nevertheless, I practiced simple systems and practiced talking about the lifecycle of two projects I was tech lead on. Here's the template I made and filled out for two features:

Feature Name/Purpose: 

Planning 

• What currently exists in the app? 

• Which teams are involved in the process? 

Requirements 

• What data do we need? 

• Any external parties?

• What are the business rules?

• What's the MVP versus the next phase or follow ups?

Design

• What are the edge cases (empty/wrong input, different types of errors, loading state)

• Accessibility

• Orientation/different screen sizes/platforms

• How do we show certain rules/information for the user?

• Animations

Develop the product

• Making sure it's consistent across platforms

• Collaborating with other engineering teams 

• Libraries/API's used

Testing

• Support QA in testing

• Ensuring tickets written early are good for both developers and for QA 

Deploy/Launch

• Mobile app store rollout process

• Tracking crashes as we continue to roll out

Maintenance

• Bug fixes

• Upgrading or downgrading certain external third parties based on existing behavior or if they're still in beta

• Future refactor improvement 

Those were a majority of my technical interviews, but I would say there were some android specific questions where they asked about opinions on different practices/tools/libraries or direct questions about android development (ex: what's the purpose of the viewmodel? How long does a viewmodel's lifecycle last?)

Part 3: Behavioral Interviews

All of my virtual onsites had behavioral interviews and some focused more on the company's values, while others focused more on candidates as an individual.

For company focused ones, they often asked questions like:

• Why X company? What do you know about our company?

• How do you interpret this companies values? What's an example in your previous experience where you embraced this value?

Common Questions

• Describe a past project - who did you collaborate with? What was your role? What technical challenges did you have?

• Working with a difficult coworker and team - how did you resolve the situation? How do you handle conflict? How do you handle pressure?

• How do you work with other people/teams? What's your definition of a team player?

• Have you ever had to sell an idea to your team? How did you do it? Talk about a situation where you had to speak up to get a point across that was important to you.

• How do you respond to positive and negative feedback?

• What mistakes have you made? What lessons have you learned from those mistakes? How have you improved?

• Most challenging, enjoyed the most, most interesting?

• Describe a time you'd do something differently or an experience that could have gone better.

• What's the hardest bug you had to fix?

• What are your strengths and weaknesses?

• Talk about a time you've shown leadership.

While I did prepare general answers that could apply to multiple questions, I also made a STAR (Situation. Task. Action. Result.) template with starter sentences that helped me make sure I hit the crucial points and sound more natural.

Situation

• We were assigned with ____ task. 

• My team/I was working on ______. 

• Because of X need, we were asked to ____.

Task

• The challenge/issue was that _____.

• I was responsible for ______.

• We realized that we couldn't do it this way because _____.

• The requirements were that __________.

Action

• To resolve this, I/we _____.

• I decided/had to _______.

• I made the choice to ______. 

• We worked together to ________.

Result 

• Because of this, _______. 

• Doing this then led to ___________.

• I learned/am still learning how to _________.

• The launch was successful since _________.

• The results were ____________.

• This experience taught me __________.

These were just a few that I used often and helped me in explaining the entire project, but feel free to use your own based on your experiences.

Part 4: Post Interviewing

A small note on rejection: 

Before going into the offer process, I wanted to share that I got rejected from companies/start ups that I was really excited about (I'm not saying dream jobs because I don't dream of working lol). I remember seeing a tweet talk about how the engineering interview process is broken and while it's unfortunate, it's still the reality that a lot of us engineers have to go through to get a job. Understanding this, on top of reading the growth mindset book I mentioned earlier helped me handle rejection because I didn't take it as a sign that I'm not smart (though college me 100% would have). This is my reminder to whoever is reading this that failing an interview doesn't mean you're not smart. I failed one of my technical interviews because I didn't notice a difference between a {} and [] and handled the json wrong. Sometimes it's just a question I didn't have in my study guide, sometimes I just had a bad day, sometimes I actually did well and would still get rejected. After each interview, whether it went well or didn't, I always made sure to learn from my mistakes and that was the most important takeaway for me.

Okay, now onto the offer! First of all, congrats! Regardless of whether or not you'll accept, you made it through the interview process and that's a huge deal in itself. When I received an offer, I looked back at that initial career reflection that I did and asked a lot of questions to ensure I was confident of my final decision. I actually had a section of questions in my notebook whether someone was a hiring manager, recruiter, engineer at the company, and engineer on the team I'd be working with. My questions were related to work-life balance, team culture, the company's employee resource groups, diversity initiatives, technical libraries I'd use, and more. This was really helpful for me and something I'd really encourage anyone to do. For one startup, I noticed they avoided giving me clear answers on work life balance and later found on glassdoor reviews that they worked most weekends.

Money money money

First of all, this is your reminder to always negotiate, no matter what your level is. I negotiated as a new-grad with no work experience yet and recruiters always expect candidates to negotiate.

For specific numbers, I'd highly recommend looking at levels.fyi and teamblind.com. I personally wouldn't recommend using Glassdoor for salary information. I also want to highlight the 81cents resource library, specifically the following resources

• Getting Past Your Nerves 

• New Offer Best Practices 

• Sample Negotiation Scripts, 1 and 2

When thinking about your ask from a company, it's important to look at the entire compensation package and figure out what areas are open to negotiation and what your range is. My notes from Latesha Byrd's workshop describe how a range consists of your minimum ask to your dream salary with the middle being your goal between that. I started off by having an ideal base salary and making sure I thoroughly looked through the overall compensation package. I didn't really practice negotiating, but the best piece of advice I did was pretending as if I was negotiating for a friend.

Wrap Up

Phew that was a lot, but my intention with this article was to share my personal experience since I didn't find many articles focusing on mobile engineering interviews when I first started, much less those focused on mid-level positions or take home projects. I really hope this helps anyone going through the interview process and I'd be more than happy to answer questions through twitter or here on dev.to. Also, a quick big thank you to my mentors/friends who supported me throughout the whole process.

Good luck and thank you for reading!!