There’s a saying at Clio: “draw the fucking owl.” Last year, for me, that owl was an iOS app. This year, it was the Android app. From absolutely no Android app development experience to leading a team of six amazing product members and building a full-spec practice management app, it’s been truly an amazing journey.
On September 22nd, when I witnessed the launch of the Android app at the Clio Cloud Conference in Chicago, I was absolutely amazed at how everything came together.
It’s hard to believe that it was only eleven months ago that we started the project. I was definitely nervous. It wasn’t really because of the new responsibilities that came with being a team lead; it was because I had no experience with Android, yet I had to lead a team of developers and make a million decisions. I powered through a handful of Android development books and met with a few key players in Android development communities in Vancouver. I want to thank Jerome from Amazon, Mike Worth, and Jeff Stautz from HootSuite for giving me advice and tons of tips. I also went to a local mobile app development shop, SteamClock Software, and arranged a workshop; in two days, we covered topics like multi-threading, UI implementation, animations, best practices, and some major differences between iOS and Android. These were just some of the steps I took to get into the Android game.
Our team started with one product manager who oversaw both Android and iOS as well as API, one UI designer/developer, and three developers including myself. We added another developer and a new mobile QA analyst. Hiring was/still is challenging because there’s a lot of pressure to make a decision with just a few hours of interviewing, but I had to make a call. Criteria for a talented software developer remain consistent regardless of the field, but I’m definitely a lot more comfortable interviewing now with the experience and knowledge I’ve gained.
These are some of the things I look for from candidates: a deep understanding of the Activity and Fragment lifecycles, various issues with a runtime configuration change, consequences in dealing with a runtime configuration change in a variety of situations, threading, and processes, UI view elements, database knowledge, Java skills, experience with major HTTP libraries, etc. For a QA analyst, I’d like to see experience in Continuous Integration systems and configuring with mobile environment, various integration testing tools for mobile app development, and some programming experience.
It comes down to: “if you have to plan for an Android app release and need to have support for thousands of devices, multi-OS versions, and a variety of screen resolution sizes, what is your plan to meet our quality standard with these conditions and being able to confidently ship an app at a release date?” We’ve been working on that since the beginning and are still trying to get it right. If you can give me a solid answer for this question, you’re all set. Come chat with me.