For the past five years, I have been building stuff on Android. During this time, I have collaborated with engineers from different backgrounds and with different experience levels. Some engineers came from an enterprise background with years and years of experience, while some were just fresh out of college and the only thing they knew was what they learned in the university/college and their experience building mobile apps in their free time. Some people did not even get a formal CS education and are self taught. During this time, I have seen what each engineer of the categories above were capable of delivering and how they were delivering it.
So, if you are hiring a so-called: Android Software Engineer for your company, read this article. Why? Because, at first, mobile app development can be mistakenly seen as being easy. After all, a mobile app is merely about putting together different pages that just outputs whatever a monolith backend asks it to output. Right? This couldn’t be further from the truth. In fact, if you look at the quality of the apps on the PlayStore, you will notice that the distribution of the apps by their quality describes a Gaussian distribution: There are a few very poor apps, just as few very good apps a LOT of mediocre apps.
Let me try to define what I mean by mediocrity here:
At the very fundamental level, a mediocre mobile app is one that does not cooperate well with the environment (platform/OS) it is running on. First, it does not comply with the visual language defined by the platform and therefore it confuses users. Second, it does not integrate the fact that it is running in a constrained environment (memory, CPU, network bandwidth, battery) and therefore it ruins the user experience of the entire device. Third, it just doesn’t work under certain conditions (faulty network for example). This final point is global to the majority of softwares out there.
In a nutshell, the three points above sum up the challenges of building good mobile apps. On top of that, the app needs to integrate properly with your company infrastructure and it has to be coded with a huge volume of constantly evolving business domain problems.
Therefore, if I had to hire a Software Engineer to work on these challenges today, this is what I would look for:
Finally, I would not worry about how much the candidate knows about the SDK itself. As long as: the candidate is good with most of the above concepts, the candidate knows the Android platform as a user at least and is motivated by mobility in general and finally the candidate is a fast learner. That being said, if you are lucky enough to find a candidate that has both a great CS background and pretends to know the Android development ecosystem, make sure they understand some fundamental concepts.
Such concepts include (not exhaustive):
As you can see the emphasis is put on verifying that the candidates know the core fundamentals and concepts that indicates whether they can adapt to any set of problems that you might throw at them. For crying out loud, don’t hire a candidate just because they know how to use one or two libraries. You don’t want to hire library users, but engineers who not only can use them when necessary (better not reinvent the wheel of course), but are also able to take a step back, analyse the situation, foresee problems way before they arise and provide solutions which are unique to the problem set you are having.
For crying out loud, don’t hire a candidate just because they know how to use one or two libraries.
A good rule of thumb is to challenge, heavily, the candidate on a topic that s/he is good at. If that’s UI, then cover that extensively.
Of course, the candidate I am describing here is a rather senior one. You can, and you should, also hire junior engineers. But in that case, make sure that you keep a good ratio between junior and senior engineers in your organization. If you have a team mostly composed of junior engineers, you are in for a tumultuous journey as your team will learn a lot of things on the job, fixing one critical production bug after another, iterating over and over again until they can get a decent maintainable and testable code base etc.
If you are a Software Engineer building Android apps and want to improve on some of the concepts listed in this article, I recommend going through the following (short) reading list:
Software Engineering and Craftmanship:
Data Structures and Algorithms:
Problem solving skills:
Blogs worth following for Android specific knowledge and critical thinking (not exhaustive, please suggest in comments):