What makes a good (Android) Software Engineer

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 above categories 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 is mistakenly perceived 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:

• Decent software engineering and Craftmanship skills. That includes topics like: SOLID principles, writing clean code, application architecture and testing. Data-structures and Algorithms are important too, but I would not hold against a candidate if s/he does not know how to balance a BST. I definitely care though whether the candidate knows at least the basic data-structures (Lists, Queues, Trees, Hash Maps…), understand what the Big-O notation is and be able to talk about time vs memory tradeoff. See? Just the basic stuff.
• Proficiency in Java (though if the candidate is outstanding and knows another language very well, I would not hold it against her/him).
• Understanding of concurrency. Because the apps need to be responsive, it is important not to perform any long running task on the event thread. That means, that a lot of things will need to be performed on a separate thread. If the candidate does not know the challenges of building concurrent apps, chances are they will learn about it on the job and in production!
• High level understanding of distributed systems. As mobile apps need to become more and more responsive, they will inherently be designed with an offline first approach. That means, that as the network can be faulty, the app can be in different states for the same user. Hence, the need to know about the CAP Theorem and the notion of consensus in distributed systems.
• Ability to analyze problems and solve them. Does the candidate know how to think through a problem, uncover all the unknowns unknowns, discover all the paths leading to a solution, comparing them one against another, come up with a plan to implement the solution.
• Ability to describe the tech stack of their current company. It is important that you hire candidates who are curious about how things work and who understand the importance of knowing the big picture.
• Good verbal and writing skills. In technology, communication is key. It is crucial that the candidates know how to convey their ideas clearly, as well as the importance of properly documenting their work. Also, chances are that their writing skills represent a good indicator of their ability to write good code.
• Understanding of the current technological context and how they affect design and engineering.

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):

• Ability to draw on the board, what, at a high level the Android architecture looks like.
• Ability to describe, at a high level, what happens when you hit the build button on Android Studio.
• Ability to describe, at a high level, what happens when you install an application on the device.
• Basic understanding of how Dalvik and ART VMs work.
• How Inter-Process-Communication works on Android.
• How apps are sandboxed and why it matters.
• The permission models (how permissions are granted at a low level).
• Processes and application lifecycle.
• Another 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.

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.

As Montaigne said: “J’aime mieux une tête bien faite, qu’une tête bien pleine” (which can be translated as: “I prefer a sharp mind over a full one”).

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:

• Clean Code — by Uncle Bob Martin
• The Pragmatic Programmer — by Andy Hunt and Dave Thomas
• Refactoring — by Martin Fowler
• Head First Design Patterns — by Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra
• Patterns of Enterprise Application Architecture — by Martin Fowler (his blog is also worth following)

Java:

• Effective Java, Second Edition — by Joshua Bloch

Concurrency:

• Java Concurrency In Practice — by Brian Goetz

Data Structures and Algorithms:

• Introduction to Algorithms (a.k.a The Cormen book) — by Charles E. Leiserson, Clifford Stein, Ronald Rivest and Thomas H. Cormen.
  or The Algorithm Design Manual — by Steven Skienna

CS culture:

• Subscribe to ACM Queue
• Love the Papers
• Listen to Software Engineering Radio and/or Software Engineering Daily

Problem solving skills:

• How To Solve It — by G. Polya and John H. Conway

Writing skills:

• On Writing Well — by William Zinsser

Blogs worth following for Android specific knowledge and critical thinking (not exhaustive, please suggest in comments):

• Chet Haas’s blog. Specifically These series of articles he (Chet) wrote about Android development
• Dan Lew’s blog
• Jake Wharton’s blog
• Jesse Wilson’ blog
• Cyril Mottier’s blog
• Chris Bane’s and Roman Nurik’s blogs for UI related subjects.
• Listen to Android Backstage and The Fragmented Podcast.
• And finally do subscribe to Android Weekly, to read about the latest stuff in the Android development world.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!