I'm giving and taking interviews for a long time now (obviously giving interviews for a longer time than taking interviews), I gave interviews to a few big startups/companies (I now work at one of them 😉), I also took a lot of interviews (currently I'm taking ~2 interviews every working day), I also talked to a few experts in Android domain I know personally about their interview experiences and a few of my friends who are regularly taking interviews (both in my organization and outside). So, I'm gonna summarise them here to help you make a better-informed decision on your interview rounds/policies/technics.

Before starting, let's agree on something. We do interviews to check the following, not to test if they can be a successor of Alan Turing.

  • Is the candidate a good fit for the team culturally? (Mostly done in Bar Raiser / Management / HR rounds)
  • Are they good at communication? (again, mostly done in Bar Raiser / Management / HR rounds)
  • Is the candidate good / can be good at the Day to Day job they'll have to do here if selected? (Main purpose of Tech Rounds)

Now that we agreed on what we check for in the interviews, let us now focus on what exactly that day to day job is.

So, I'm in the Software Development industry for almost a decade now, currently working as a Sr. Software Engineer (Android) at BYJU'S (India's biggest Ed-Tech startup).

So, what do I do in my day to day job? Or, let's say, what do most of the Sr. Developers / Sr. Engineers in the Android domain do in their Day to Day job (let's talk about Product based companies/startups)?The answer is that we all develop features, sometimes we work alone in a feature, sometimes we with a team on a feature, sometimes we develop MVP (not Model-View-Presenter, Minimal Viable Product) apps, and sometimes we lead a small team of developers developing an MVP / Feature, and sometimes we fix bugs (yes, it's sometimes not most of the times, if you do proper Unit Testing).
Now, when we write code, how much Data Structure do we need? Well obviously we do sorting and searching, so yes, we use Data Structure, but how much concise decision do we need to make that requires Data Structure knowledge? Confused with the question!?, let's put it the other way, what do we write when you're sorting a list? Mostly the below.

list.sortedBy {
    it.property
}

Same for search, we use the Language / Library / Framework defined algorithms for our tasks, we don't write those algorithms ourselves. Now what the regular optimizations we perform on your algorithms for which we believe we need DS rounds? The list is below

  • Try to avoid nested loops
  • Instead of having multiple loops back to back, if things can be done in a single loop and that won't affect the cleanliness then use a single loop
  • Try to run a loop as much less as you can

Now, tell me how much DS knowledge do you need to make these decisions? You just need an understanding of what is Time Complexity, that's all you need to know. I'm sure backend devs or developers working on System Programming does a lot more than these and really require high skills in DS. Also, in Android, if you're building something like LeakCanary or if your day to day work includes working extensively in Annotation processors / Compiler optimizations, I can understand you need really good Data Structure skills, this also explains why companies like Microsoft / Google needs to have extensive DS rounds.

But, if the job role of the candidate is to work on an Android app, no matter how big/complex the project is, you don't need much Data Structure knowledge, you just need a regular understanding of Time Complexities and how to optimize them.

A popular argument I hear when I present the above logic is, then how to check the candidate's skills properly, frameworks may change any day and for good programmers, it's easy to pick up any framework. Another opinion is there are only so many good questions you can ask in a framework, also asking a well-experienced candidate to explain the difference between Activity and Fragment is not a good choice either. The thing is I'll not oppose these arguments, rather I agree to all these arguments totally, I'm here to give an opinion that will answer to these arguments / give a better alternative. Here comes the second and crucial part of this blog - Design Patterns.
Now, let's re-run the exercise. What do we do in our day to day work? we develop features, sometimes we work alone in a feature, sometimes we with a team on a feature, sometimes we develop MVP (Minimal Viable Product) apps, and sometimes we lead a small team of developers developing an MVP / Feature, and sometimes we fix bugs, sometimes we also refactor / re-architecture old codebase.
So, let's say you're building an MVP (Minimal Viable Product), while coding, you need to move faster, you can't spend a huge time on discussing and deciding the architecture, but you also need to keep future scope in mind, i.e. in near future, it might be taken forward as a product, and then you'd want to re-use what you're building now, rather than writing everything from scratch. To do that you need to be very good about Architectures / Architecture patterns.
Forget about choosing Architecture for MVP or for feature, or even refactoring old codebase, we don't get that opportunity every day, that's actually our dream work right. But there are few decisions we make every day, below is a non-exclusive list.

  • Should we use Dagger or Koin for this project?
  • Should this class be Singleton?
  • Should I use @Singleton annotation for this dependency or @FeatureScope?
  • Should I create an interface for this class?
  • Should I use Mocking / Faking for this test?
  • Should I create a new callback interface or add a method to the existing one?

Now think what knowledge/skill we use most to make those decisions every day? Is that Data Structures? No, DS is no way related to this. This is nothing else but Design Patterns. I'm not saying if you know Design Patterns you'll never need to have discussions before making those decisions, but Design Patterns / Design Principle knowledge will help you immensely take a logical decision. Not for the above-mentioned list of decisions, but Design Principles / Design Patterns are required for numerous day to day Programming jobs, irrespective of platform.

I recently gave an online talk about Android Architecture Patterns, there as well, I started with discussing SOLID principles, because of their close relation with every Architecture Pattern. If you look close enough to any Architecture / Architecture pattern, you will find most of the part if that architecture is inspired by some Design Pattern.

Dive into Android Architectures
https://speakerdeck.com/rivuchk/arch-patterns-in-android
YouTube

So, to answer the arguments we started this part with, we can replace Data Structure rounds with intensive Design Pattern rounds, so that we don't have to depend only on the frameworks for evaluating the candidate if a person is good with Design Pattern, they're generally good with programming as a whole and should be able to keep pace with changes in framework or pickup another framework if it needs to be. Just like in DS round, you can come up with complex custom made problems to test DS skills of a candidate, in Design Pattern rounds as well, you can give a problem to the candidate and let the candidate solve that using Design Pattern knowledge/skills, this way you'll subtly evaluate the analyzing / problem-solving skills of the candidate as well.
Another thing you can do (a lot of startups are already doing this), is give the candidates an assignment, to develop an app over a given problem statement (for example ask them to build an app to show a list of Trending Repositories from GitHub), also if the candidate already has some interesting project and willing to share, you can consider evaluating that as well. Do this before any of the interview rounds, that way you can evaluate candidate's Android skills firsthand and save both the panel's and candidate's time as well.

I would like to mention here something I noticed lately while taking interviews. Most of the candidates say they follow MVVM, LiveData, etc. because Google recommends them. That's great right, earlier there were very few who were even interested in Architectures right? No, if you go a bit deeper and ask them questions on not how to set up your project with MVVM, but how they work or theory behind a component of the said Architecture, most of the candidates get stuck there. I believe that's not a result of not-updating yourself, but rather a result of not giving care to the basics - Design Patterns, once you understand Design Patterns properly, it'll be easier for you to get the theory behind every component of any Architecture.
So, I'd like to end this post requesting all my fellow developers/interviewers to set up a common practice to have Design Patterns, especially for senior roles. Can we agree? Let me know in the comments section.