How to ace any Android Interview like a BOSS in 202X?

Oleksandr Klymenko
9 min readAug 17, 2022

--

If you want to prepare for an interview, one of the first things you may wonder is what questions you can be asked. So do I.

Read this article if you want to know why you shouldn’t go over so-called TOP <random_number> ANDROID INTERVIEW QUESTIONS lists.
What you should do instead. And with what answers you’ll come across as a guru of Android. 👩‍💻

Want to know something new about Android? You’re welcome too!

This time, I am supposed to be an interviewer and I wanted to check the most popular questions to get the trend and don’t ask candidates the most apparent and frequent questions.

Obviously, I decided to google such questions. Above all, I thought someone had trolled me. Because some questions were really weird. 💩

I’m a developer and not your granny! (sry for ageism)

Then, I thought there is a sort of conspiracy. Maybe either interviewers or owners of shit-courses had deliberately created such litter that you would fail an interview. 🤔

🤯🤯🤯

This is only half of the problem. The vast majority of such articles with “Top” Android Interview questions are titled as updated and actualized for the 2022 year. Of course, they’re not. They have merely an updated title with the current year. All Q&As older than mammoth’s shit. In some answers, Android 5.0 is said to be the latest…

top.

Another problem with such lists is that some questions are useless. 💩

Believe me, no company, no interviewer ever asks you kind of this question. As Android Developers we never solve such problems in our work. You will waste your time preparing for such far-fetched questions.

What are intent filters? What are JobScheduler, Service, and ContentProvider? What is AAPT? What is ADB? What is ANR?
I think that such questions are useless too. Because you are supposed to know all these things since you’ve called yourself Android Developer. This is foundational knowledge of our sphere. From my point of view, such questions positively shouldn’t be listed in the TOP Android Interview Questions.

And last but not least problem is those articles are copies of each other. 💩 The questions are duplicated even without changing of order. Even if you try to find useful questions, you won’t.

So long intro and what is my suggestion? I collected a few questions which in my opinion are good ones and can help both sides. For interviewer as a tool to dig deeper into a candidate's knowledge. Of course, here I am talking only about the technical interview and hard skills. And for candidates as a way to make an impression and show who is daddy. 🧠

Not a photoshop. It’s literally me. You can bulk up the same by following my list of questions and mastering it.

And the first question is What is the difference between Serializable and Parcelable? Which is the best approach for Android? Actually, these are two questions but who cares? Certainly, you are believed to know the correct answer, because it is still a common question for any Android Interview. Let's give an answer to it once again.

Both interfaces are usually used to transfer some data between app screens. And we usually put such data in the Bundle object. To make it works we need to implement one of these interfaces in our class with data. With Serializable we should justimplementthis interface and it’s done. No methods overriding is required for Serializable. Pretty simple to use, but it is the only advantage against a bunch of disadvantages. Serializable uses reflection API. It means that during the serialization process additional objects such as instances of Field and Method classes will be created. And this will lead to poor performance and overconsuming of memory. To prevent this the best practice is to use Parcelable. With Parcelable you are supposed to do some overrides, but is it a problem? You usually use the Parcelable generator plugin in Android Studio to do this. In the case of Kotlin data classes, it’s even easier since you can use androidExtension then Parcelable stuff will be generated automatically under the hood. Eventually, Serializable is an old Java interface — not your bro 👎. Parcelable is specially created and optimized for Android purposes — your bro 👍.

So, how can you impress your interviewer? Tell more about how Parcelable actually works and what mechanism it uses. Add some terminology to your answer. Parcelable uses marshaling when Serializable uses 🤷‍♂️ ️serialization. The difference is that serialization transforms an object into bytes. All object’s fields, properties, and states are transformed into bytes for further ability to recreate this object from bytes after moving them e.g. to another part of your program.
Marshaling is when the programmer can select what data of an object will be transformed into bytes. For that programmer has to create a list with an order of data types and fill this list with data according to this order.
For example, we have a class with 4 fields: integer, double, char, and boolean. We create an order something like this: first 4 bytes for theinteger field, next 8 bytes for the double field, 2 bytes for char, and 1 byte for boolean. Then, when we want to de-marshal it, we have to take these bytes and put them to our fields strictly with the order as it was marshaled. Like firstly we take the first 4 bytes and put them in the integer field, then we take 8 bytes and put them in the double field, and so on. As you can see we spare a great amount of memory and CPU efforts.
That is why we need all this overriding with the Parcelable interface — to show the order.

next quesh

What is manifest? Although, it is one of the most popular questions you can boast about your extensive knowledge here as well. Let’s give the expected answer.

Manifest is a configuration file of any Android application. It tells the Android operation system about what components are presented in your app. 🌘
Manifest describes the entry points to your app. 🌖 And for most interviews it would be enough. But few developers know about manifestPlaceholders. It allows you to create something like variables that can be used in the app’s AndroidManifest.xml file. For example, we want to have different app labels for different build types. Let’s say the app label should have a ‘debug’ suffix for debug build types. For this, we need to add the next code in our app build.gradle in the buildTypes section.

manifestPlaceholders = [appLabel: "AwesomeApp debug"]

Now we can use appLabel placeholder in our Manifest to change the app’s label according to selected buildType!🌝

<application
android:label=”${appLabel}”
...
>

ViewBinding vs DataBinding vs KotlinSynthetic? Which is better? Which one should I choose?

A great comparison of ViewBinding and DataBinding you can find in this article. Long story short, findViewById() is not efficient so Google introduced ViewBinding and DataBinding. Both generate a binding class that represents your XML layout. However, DataBinding allows you to use additional features such as adding variables to your XML, BindingAdapters, InverseBindingAdapter, and execution of program code in the XML.

Avoid using DataBinding at any cost. It can bring only appalling mess to your project. Writing Java/Kotlin code in the XML, are you serious? Have you ever heard about SOLID and single responsibility? It’s such a stupid idea to mix data/logic with UI. I worked with DataBinding on a huge project, so I know what I’m talking about, so never use it. You can declare local rules about what features of DataBinding are allowed on your project and which are prohibited. But such rules never work and after a few commits, later or sooner, your project will look like trash. ViewBinding is enough to cope with all needs of any app. It strictly allows you to get rid offindViewById()and nothing else. Your code will be much cleaner and more consistent.

KotlinSynthetic is known to have been popular for some period of time. But it was deprecated on 25 Jan 2019.🪦 It had some open issues that couldn’t be solved.

To sum up, using of ViewBinding is the best practice.

The most annoying topic of any Android interview is always the activity lifecycle.

In which situations Activity can be in theonPause() state and never calls onStop()?

The question may sound something weird. Let me explain it more precisely. When an app makes navigation from one activity to another the first one usually invokes onPause() and then onStop() callback. But in which situations activity can stay just in onPause() without invoking of onStop()?

And I think it’s a really good question which shows your understanding of what stands behind such activity’s states.

onStart() is called when an activity becomes visible to the user. Therefore, onStop() is called when activity is no more visible.
onResume() is called when activity is on focus and the user can interact with it. Therefore, onPause() is called when the activity is not ‘on focus’ anymore.

What does ‘on focus’ mean? Can we have more than one activity simultaneously so some of them can be not ‘on focus’? Oh yes, we can. There are 3 most common cases to reproduce this situation.

The first one is PiP (Picture-in-Picture) mode. So, the user can’t interact with the activity when it is in this mode but the user can still behold it because onStop() isn’t called.

Second is Multi-window mode i.g. split-screen mode. Once the user starts to interact with one window its activity calls onResume() when other activities become in the onPause() state. However, these activities are still visible to the user so onStop() isn’t called.

And the last case is when we start an activity with transparent background. Yes, we can create such a theme and apply it to the activity. For example, the GooglePay purchase dialog integrated into your app actually is not a dialog, but an activity with a theme with transparent background. So, when you start such an activity your previous activity is still partially visible to the user, so onStop() isn’t called afterward.

I wanted to add a question about multidex in Android, but it is always enabled since Android 5 you will never encounter 64K methods issue. Leave this question for dinosaurs. 🦖

In spite of this, your knowledge of history can help you to make a good impression by answering the question about fragments. In any Android Interview, you will touch fragments. What are they for? What is their lifecycle? When onAttach() method is called? You are supposed to give answers to all these questions. And also you can tell about the purpose of fragments and what for they were invented. 🦕

Tell that Fragments were introduced with Android 3. What also was introduced in Android 3? Correct! Supporting tablets! Tablets have a larger screen than mobile devices. Then, more content can be displayed at once on tablets. For example, we have two screens on a mobile device: ProductOverview and ProductDetails. We can use fragments and show both on one screen in the case of a tablet for better UX. So fragments were specially created for the development of tablet apps. Nowadays fragments evolved and we have what we have.

Lastly, one of the most popular questions in Android Interview is how the HashMap works under the hood. Strongly recommend familiarizing this topic. I would advise this article. You are supposed to tell what are buckets, what is load factor, and the algorithm of adding/removing elements to/from the hash map step-by-step.

Wow, you are really determined if you’ve read up to this point. Ok, one more piece of advice. The best way to prepare for an interview is to watch a video of the real interview process. You can find such videos on YouTube. Sometimes it is also called a Mock Android Interview. Usually, the duration of these videos is 1–2 hours and they can be with Junior, Middle, and Senior candidates. So, I do recommend watching a couple of such videos.

Hope my question was helpful for you and you knew something new. Thanks to my teammates who also gathered these questions.

Good luck with your interview!

--

--

Oleksandr Klymenko

I'm Lead Software Engineer with Flutter as a domain technology. Working on creating mobile solutions for diabetics. So far, enjoying my way to the FAANG.