About a week ago, someone on /r/androiddev asked the question “What are the things that every Junior Android Developer should know?”. Being the kind of guy that I am, I was browsing the subreddit at work (whilst compiling, obviously) and got an answer in early which people seemed to like a lot. So this is mostly just me expanding on my points.
Skillset
If you’re looking to come onboard as a Junior, there’s a few things that I’d expect you to know. None of them particularly in-depth, of course (not in a patronising way), but for me to see that you’re interested in the field and learning as much as you can, I’d want to see at least some low-level knowledge in the following areas:
The Activity Lifecycle
It’s Android. There’s no getting away from it. These events are absolutely crucial to developing an app that doesn’t crash when you accidentally rotate the screen because you’re browsing in bed.
On first glance this diagram doesn’t look all that friendly:
But in reality, I don’t expect a Junior to know the whole thing off by heart. As long as you’re aware of onCreate, onPause, onResume and onDestroy, what causes them and their implications, then you’re off to a good start. If you’re a bit unsure, check out the official docs. If you give an example as to how the lifecycle could cause a memory leak, I’d be mightily impressed.
Android Components
The building blocks of any app. There’s only 4 major components: Activities, Services, Content Providers and Broadcast Receivers, and each has an important part to play in creating an Android app. You won’t necessary need all of them in a single app (for instance, in my professional career I’ve never needed to write a Content Provider), but I’d still 100% like to see that a candidate can explain roughly what each one does and what they might use one for.
Persistence Options
There’s a handful of options for persisting data on Android, and each has their own pros, cons and use-cases. There’s a helpful guide on the Android Developer website which explains how to use each type, and again I’d want to see if you can recall them and in broad strokes what you might use each type for.
Networking
This is a biggie and there’s an awful lot to know, but for someone wanting to go for a Junior position there’s only a couple of things that I’d deem essential.
Basic REST knowledge is a must, and if you can’t make a simple GET or POST request from an Android app then you’ll want to get back to hacking together some basic apps. Pretty much every app I can think of makes REST requests, and this knowledge is fundamental. Android’s Volley class is a good place to start if you want to learn the absolute basics, but in an ideal world you’ll know that it’s a pretty outdated way of doing things.
As such, if you’ve used an alternative such as Retrofit then you’ll be in a good place. There are a handful of other possible ways to do networking on Android but almost all of them are pretty niche now – Retrofit is super simple, pairs nicely with the power and flexibility of OkHttp and is regularly updated with great features by the extraordinary team at Square.
Alongside that, some knowledge of serialisation would be great. Experience of Gson, Jackson, Moshi or similar is a great sign, as nobody in 2017 should be plucking values manually out of JSON.
Android Studio Skills
Android Studio has come an awfully long way since the first alpha rolled out several years ago now, back in the dark days when everyone used Eclipse. Even as a Junior, I’d want to see some indication that you know the program pretty well – navigating everywhere by hand is a bad sign and horribly unproductive, so I like to see people using shortcuts a lot. In fact one of my favourite interview questions is to ask a candidate's favourite shortcut, as there are so many that I regularly learn something new.
To be clear, I’m not expecting you to be a ninja by any stretch. But knowing your tools to a reasonable level shows interest in the craft. Knowing a few of these will make you dramatically more productive and make pair programming much less painful.
If you’re still using IntelliJ that’s fine too, and if you’re using Eclipse… well, I think I’d be more curious as to why than anything else.
Git
Another important one. Amazingly there are people these days who work without using a VCS system, and that’s a really big red flag for me. If you’re not using git right now you should be, and whilst the learning curve is a little steep the payoff is huge. Admittedly it can be difficult to see the benefit if you’ve solely worked by yourself up to this point – until you’ve realised that you’ve made a horrible error 6 hours into refactoring and want to revert to how the app was when it worked. This guide is no-nonsense and will get you started, and to be honest you don’t need any more than that.
Even if you just use git from a GUI like the excellent SourceTree, that’s fine with me.
Of course there are a handful of other VCS systems out there and knowing any of them is great – but git is the most widely used by far.
Design Patterns
This one is perhaps less essential, and I’m sure many use some of the more common patterns without realising that they’re classified as ‘design patterns’. But if you know the basics such as Builders, Singletons and Factory Methods and where you might use them (or even where you can find an example in the Android SDK), then that’s great.
If you happen to own or even just know about The Gang of Four or Effective Java, bonus points for you. Talking of which:
Bonus Points
- You’ve ever written a Unit test, or understand why writing them on Android can be so amazingly difficult
- You own at least one of the all-time classic development books
- You’ve dabbled with other languages, Kotlin in particular
- You’ve published something to the Play Store
Other Stuff
Of course there are other attributes that I really like to see in someone applying for a Junior Developer role, which can mostly be filed under ‘soft skills’.
In my opinion, the role of a Junior is mostly to learn as much as they can as quickly as possible so that they can contribute meaningfully to the product. By and large, Juniors are assigned initially simple work by a Senior that will gradually take them deeper and deeper into the stack, building the developers confidence and skills along the way.
As such, to be a good Junior I think it’s critical to have good autodidact skills, and to an extent you can prove that with what I would call peripheral knowledge. You might not know how to use it, but you know that RxJava is so hot right now and it’s been on your TODO list for some other time. A lot of blogs talk about Kotlin, so that’s on there too. You’ve heard about the awful world where we had to maintain compatibility with Gingerbread. You have some idea of what the next version of Android is bringing to the table. That sort of thing.
Anything that shows that you’ve read around a bit is a really great sign, even if you’re only aware of some libraries/techniques/common issues/features.
To that end, I’d hope that you’re signed up to the excellent Android Weekly, browse /r/androiddev, and can maybe name a couple of the most influential people in the industry and follow their blogs, Mediums, Twitter accounts etc. Maybe you listen to Fragmented too.
Ultimately what I want to see more than almost anything else is some passion for the platform. I’ve been tinkering with Android for 6 years now and developing for 4, and I still get excited when I see an update from the Android team. I wasn’t expecting the Android O preview until months after it was actually announced, and I immediately flashed the (rather unstable) alpha to my device because I just had to have a play and find out what was new.
I love checking out new devices when they get announced, I race to get the latest updates from APKMirror, I’ve flashed countless custom ROMs and bricked a few devices over the years. I always watch I/O when it’s on, and one day I’ll finally make the pilgrimage to Mountain View. I own several Android t-shirts, which for an adult male is ridiculous. If you can relate to any of that; you’re my kind of developer.
Android is the most rapidly adopted technology in history, and I’m excited to be involved in it. If that excites you and you can tick off the majority of the boxes I’ve listed here then I’d like to work with you, and I look forward to teaching you as much as I can about the platform that I love.
Top comments (16)
In my last go as a tech lead I had to hire 4 Android devs at different times. This post describes the exact things I was looking for even for senior level devs. Everything else can be learned.
Android is a mythical beast that will pull you in once you realize its not that complex. I went from avoiding the platform to embracing and publishing stuff on it.
Hi Adam. I am a college student in India and have been doing android development for about 2 years now. I really appreciate you writing this as it helps us junior devs guide ourselves to the right path, and I'm happy to say I tick most of the things you mentioned and you are pretty accurate, kotlin and testing is next on my to-do list. Cheers.
I'm a bit uncertain about the first items, Lifecycle, Components, and Persistence. This is precisely the type of thigns I wouldn't expect a junior to actually know much about. It's a highly specific API set that wouldn't transfer from any other dev job. They can also be learned relatively quickly, especially with a mentor nearby that can quickly direct them to the right places.
Using shortcuts for the studio just seems like nitpicking. If you can do everything with a shortcut why even bother using the studio, wouldn't command-line tools be quicker? A major purpose of an IDE is to make functionality easy to discover and easier to remember.
Design patterns, and perhaps git, seem fair, but your other requirements go beyond what I might expect of a Junior programmer. Most of this I'd expect them to learn on job, as it's domain specific.
I'm a C# developer and I know nothing about Android development. This post gave me proper 'peek' into the landscape and I might even find it useful to refer back to if I were to try making an app for my phone for instance. Thanks for sharing!
No problem, glad you enjoyed it!
Nice piece! It's a sad commentary on the state of the profession that EVER HAVING WRITTEN A UNIT TEST is a nice plus, rather than a basic requirement.
What about how to build the project?
I have to use Maven heavily in my work, and I don't have much exposure to Gradle. How important is it to understand Gradle?
It's not important I'd say, you can absolutely get by just knowing the basics which you can largely copy and paste from elsewhere, and Android Studio handles much of creating a Gradle file for you.
IMO Gradle is quite an advanced topic that I wouldn't expect beginners to know an awful lot about.
Loved the article ! As an amateur, I'd like to understand What makes Retrofit better than Volley?
Thanks man.
Without going into too much detail, Retrofit is just generally much easier to use. Requests return objects rather than JSON and it's far easier to test. Retrofit supports both synchronous and asynchronous requests as well as observables. SSL pinning is a breeze. Intercepting requests is built in.
Although Google still maintain Volley, they're switching to Retrofit in all of their code examples which should tell you something.
Adding to existing post, as a junior software android developer one must know basic oops concepts, i interviewed many candidates and all of them had one reserved reply, i know Android but i don't know Java. And if you ask them what is interface a static reserved answer forever is * it is used as listener*. I recommend all junior that blogs are good source of knowledge but books still remain the #1 for me. Take a programming book or pure java docs and start coding.
"You own at least one of the all-time classic development books"...
Could you please give a link for these books or just the names ...
gracias
This list has all of the books that I'd consider all-time classics jasonroell.com/2015/03/16/12-most-...
Great article! Even learned a few things thank you!