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 , you will notice that the distribution of the apps by their quality describes a : There are a few very poor apps, just as few very good apps a LOT of mediocre apps. PlayStore Gaussian distribution Let me try to define what I mean by here: mediocrity 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 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. the visual language 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 and the notion of consensus in distributed systems. CAP Theorem 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. . 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. In technology, communication is key 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. , 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. You don’t want to hire library users For crying out loud, don’t hire a candidate just because they know how to use one or two libraries. As said: “J’aime mieux une tête bien faite, qu’une tête bien pleine” ( : “I prefer a sharp mind over a full one”). Montaigne which can be translated as 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: — by Uncle Bob Martin Clean Code — by Andy Hunt and Dave Thomas The Pragmatic Programmer — by Martin Fowler Refactoring — by Elisabeth Freeman, Eric Freeman, Bert Bates and Kathy Sierra Head First Design Patterns — by Martin Fowler (his is also worth following) Patterns of Enterprise Application Architecture blog Java: — by Joshua Bloch Effective Java, Second Edition Concurrency: — by Brian Goetz Java Concurrency In Practice Data Structures and Algorithms: — by Charles E. Leiserson, Clifford Stein, Ronald Rivest and Thomas H. Cormen.or — by Steven Skienna Introduction to Algorithms (a.k.a The Cormen book) The Algorithm Design Manual CS culture: Subscribe to ACM Queue Love the Papers Listen to and/or Software Engineering Radio Software Engineering Daily Problem solving skills: — by G. Polya and John H. Conway How To Solve It Writing skills: — by William Zinsser On Writing Well Blogs worth following for Android specific knowledge and critical thinking (not exhaustive, please suggest in comments): . Specifically Chet Haas’s blog These series of articles he (Chet) wrote about Android development s Dan Lew’ blog Jake Wharton’s blog Jesse Wilson’ blog Cyril Mottier’s blog and blogs for UI related subjects. Chris Bane’s Roman Nurik’s Listen to and . Android Backstage The Fragmented Podcast , to read about the latest stuff in the Android development world. And finally do subscribe to Android Weekly is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories