How to be prepared for an Android Developer job interview and improve your skills
First of all, this article isn’t just for fresh starters. Most of the information I have is from lessons I have learned while I have been working. They could be very useful whether you are looking for a job or seeking to improve yourself.
I have been working as an Android Developer for 7 years. I have also worked as a freelancer for 2 years while I was studying. Then I started to work as a full-time developer after I graduated from my computer engineering program.
I have reviewed resumes, code challenges and joined meetings as an interviewer over 200 times. That is why I want to share my knowledge and experience.
Staying up to Date
I want to speak about this first because it is such a crucial part of software development. There are so many articles, videos, podcasts on the internet about it. I find it great that people share their knowledge and experience.
Some of them were the best practices before. However, they are now deprecated and are not as efficient. So be aware of what you are using and what you should use. Let me give you some examples that usually generate negative feedback to an interviewer.
Using MVC instead of MVP, MVVM or MVI
Using ListView instead of RecyclerView
Using AsyncTask instead of RxJava or Coroutines
Using Picasso instead of Coil, Glide
Using HttpUrlConnection instead of Ktor, Retrofit, Apollo
Making json parsing manually instead of kotlinx.serialization, Moshi, Gson, Jackson
Using RelativeLayout instead of ConstraintLayout
Using highly coupled dependencies instead of dependency injection
I will not give any more examples regarding this topic, but if you want a detailed article about this, please let me know, I can happily write an article just about Staying up to Date.
So how can you stay up to date?
Following official google Android websites, YouTube channels, GitHub repositories. The Google Android team is the most interactive and social team I have ever seen.
Follow as many communities as possible.
Check GitHub Projects
At first, I was just checking the latest version of projects. Then I realized as I was checking commits and comparing it with previous versions, you get more aware about the following things.
Seeing what kind of technologies migrated
Seeing what kind of bugs have been fixed
Seeing how to avoid boilerplate and make code syntactic sugar
And more!
Do not copy the code before understanding it!
Yes, I know the deadline has already passed, and you realize you don’t have time. I’ve made these mistakes too. However, just ask this question to yourself: “If I didn’t understand how the code works, what would I do when it doesn’t work?”
Let me give you an example,
https://www.theverge.com/tldr/2016/5/4/11593084/dont-get-busted-copying-code-from-stack-overflow
There is nothing wrong with copying a code; we do not have to reinvent the wheel again. However, we must fully understand how the wheel works.
This is one of my tricky questions.
https://developer.android.com/kotlin/flow/stateflow-and-sharedflow
The developer could use either MutableLiveData or LiveData too. And conversations about it start like this
%95 of answers 🤔
I : Why should we make a private modifier MutableStateFlow and expose it as a StateFlow to the UI.
D : Because it is the best practice.
I : Yep there is nothing that you are totally right about but why is it best practice and what would happen if I use just the MutableStateFlow without downcasting ?
D : Sorry I do not have an idea.
%5 of answers 😲 😍
I : Why should we make a private modifier MutableStateFlow and expose it as a StateFlow to the UI.
D : Because it is the best practice to keep the state safe. MutableStateFlow is mutable as the name suggests. The UI side should not change the state if it is changeable from the UI side, ViewModel’s state and the UI state would be different, and it will end with unexpected behaviors. The UI’s role is just to show the data that comes from ViewModel. And ViewModel’s role is to keep the state safe against restoration and process death. We restrict the state’s modification at the UI side with this way and separate the concerns.
Sometimes Android Articles about a subject do not explain everything in the code necessarily for the sake of the topic at hand. Like the in the official Android article above, they do not have to describe why they restrict state with immutable type. Because the article’s main purpose is understanding StateFlow and SharedFlow.
At the first sight you may not understand what the purpose of this approach is but you can google it like,
What is the difference between MutableStateFlow and StateFlow ?
What is the difference between MutableLiveData and LiveData ?
Why should I expose MutableStateFlow instead of StateFlow ?
Why should I expose LiveData instead of MutableLiveData ?
Also, you can just keep it simple like
MutableStateFlow vs StateFlow
Sample questions like that,
If the developer used Recyclerview.ListAdapter ;
What are the benefits of ViewHolder, DiffUtil ?
If the developer used Dispatchers.IO ;
What is the difference between Dispatcher.IO and Dispatcher.Default ?
In Stack Overflow, the comments are just as important as the most upvoted answer. Sometimes the most upvoted answer may not necessarily be the best solution. If you do not read sub comments, please start reading them, you will see what I mean.
Stable May Be Unstable or vice versa
Check your research before using libraries. Check issues at GitHub and find articles about those who used and experienced it before. Using new features and opening issues is the best thing we can do to contribute to the Android ecosystem. You can check out your personal or small project before suggesting new features to big companies where you work.
For example, stable versions may not necessarily be stable in practice.,
Compose is stable. You can use them for production projects but if you do some research, you will see when using both Compose and XML together, it will have less performance if you were to use XML alone. In this case companies wouldn’t want to make a sacrifice on their projects. The Navigation Component’s implementation is not as good as Fragment implementation. Many people got stuck when they could not send Parcelable data as an argument.
For example, unstable does not mean unstable every time,
I remember Hilt had been unstable for over 3 months. However, when you do some research, you could find out why most of the bigger projects migrated their projects from Dagger to Hilt. The reason for it being unstable was part of Compose and other parts of Hilt works as a charm as there were no issues. If you have not used Compose, you wouldn’t have to wait for Hilt’s stable version.
Being a Social Programmer
Some developers complain when finding other developers as they constantly talk about new features or discussions as did I. However, there are so many good places to interact and join discussions to help improve.
You can find them on Reddit, Twitter, Slack, Discord. You might be surprised to hear that there are many things you can learn on these platforms, even on Instagram.
Let me give two examples
https://www.reddit.com/r/androiddev/
https://www.instagram.com/jetpack_compose/
Do Not Start With Android Development
Learn algorithms and data structures before learning Android development. They may seem kind of boring, but they will make you think and help you find a good sustainable solution when you face algorithmically issues. So, starting with just pure Kotlin instead of Android will be a good choice. You can use coroutines, Flow and so on. For example, you can easily find cryptocurrency API, one of the crypto markets and try to make a triangular arbitrage on IntelliJ Idea with pure Kotlin without Android dependencies. It completely depends on your hobbies. You can find fantastic algorithm challenges on them.
Also, there are many algorithm question platforms on the internet. You can improve your algorithm skills on most of them.
Do Not Stop With Android Development
There are many things growing nowadays and I know it’s impossible to catch all of them. Just being aware that they exist and getting prepared will be good for you.
For example, I have been developing Flutter apps for 3 years. So, it was easy to understand and start Android Compose’s declarative UI approach.
Let me give some keywords you would face in the future.
Kotlin Multiplatform
Web 3.0
AWS Amplify
ML Kit
TensorFlow Lite
Do Not Say I Am Okay
Never think it is enough, that there is nothing new to learn.
How the backend works; middleware, Memcached, load balancer, stateless web service, auto scale and so on.
How designers make UI/UX and what are the trends of 2022.
Perhaps you can give advice and contribute to other departments of the team.
Here is my mantra to keep me willing to learn.
“No matter how much you know, consider yourself a beginner and work towards improving.”
I made up this sentence three years ago, saying it and accepting it in my mind made me humble and gave me the desire to learn something new every day.
I hope this article will be useful to you and if you want a more detailed analysis of the topics just let me know, so I can discuss the topic in another article.
