The first interview was with a recruiter who did a great job of creating interest in the role and company, and they performed a basic assessment of my background.

The second round started with an office tour, and then I was interviewed for two hours by two Android engineers. This was a fairly negative experience, not because there was anything wrong with the company or interviewers, but because I felt like the questions were more about showing who had the most arcane knowledge, rather than asking anything evaluable.

I was asked questions on data structures and then given a coding challenge, which seemed to assess system design rather than algorithms.

Their questions did a great job of showcasing their knowledge (their generic data structure knowledge was impressive) but also revealed gaps in some important Android knowledge, such as:

• How memory and the garbage collection algorithm work
• Which threads services run in
• The difference between a process and a thread

They also revealed gaps in how Kotlin bytecode is generated and uses static structures (both developers work in Kotlin). I only mention these gaps as the interviewers seemed to doubt or reject some of my answers based on them.

I felt that only a couple of their questions did much to probe what I actually knew.

Which is better: MVVM or MVP?

Do you not like Kotlin? (I have not worked with it.)

How does a HashSet work?

What components does Android have?

What differences are there between Activities and Fragments? What happens when you rotate the screen? What is retain instance? What happens when restoring state?

What Android data structures have you used? Why are they better?

How can you avoid memory leaks with an AsyncTask?

What does the synchronized keyword do?

After the coding sample: In an ideal world, what would you improve?

After the coding sample: Why did you pass a WeakReference? You can pass a Context and then wrap it inside the task.