Hiring your first Android developer

As a seasoned mobile application developer, I'm regularly approached by recruiters for new exciting opportunities, many of them from startup companies that are ready to jump into the mobile app world with existing web services.

Most companies start breaking into the mobile app development with iPhone/iPad app. This is influenced by reports that iOS users are more willing to pay. CNN reported in 2011 that Apple users buy 61% more apps! What's more, it's my personal experience that Android app simply takes longer to develop. Here are my reasons for that:

1. Apple's XCode has a wonderful emulator & profiling tool for performance.
1. Android's emulator is slow; really really slow. So slow that every developer must obtain a physical device.
2. Apple's Xcode is a mature IDE
1. Most developer still develop their Android app using the poorly executed Eclipse IDE.
2. If you're lucky and have some bravery, you've switched to Android Studio, which is based on the rock solid IntelliJ IDEA. Even though it's in beta, it will improve your life dramatically.
3. Apple's adoption rate is extremely high, so you code against only the latest SDK
1. Example: Adoption rate of iOS 7 vs Adoption rate of Android KitKat
2. In Android, you have to draw a line where your minimum SDK would be.
3. This version will have consequence in terms of how complicated your code becomes and what open source libraries you maybe able to take advantage of.
4. As an illustration, the project I'm currently involved in has an iOS and an Android team. We're building roughly the same app. Adjusted for developers dedicated to features specific to a platform, the iOS team has only 2 person, but the Android team has 4. I've been involved in developing a dozen mobile apps, and time and again, the iOS app has less bugs, jank, and requires less people.

How long does it take to make a mobile app? Answer: 18 weeks!

From: Kinvey Backend as a Service

If you've started with an iOS app, you have at least one mobile developer. She is going to understand the challenges presented to her like no other kinds of developer. She understand that you are going to be running code in someone's personal phone, which means the user care about battery life, bandwidth usage, privacy, and most obviously, the user need that phone to be a phone first, and an application second. Because of that your application can be interrupted any time. And because of these limitations, there are apps that simply doesn't belong in the mobile world, or at least not in the same form as you would on a desktop.

So what if your version 1.0 app is going to be an Android app because market research suggest that those are your primary customers? Here's what I would look for in a candidate:

Understanding application life cycle

• What type of objects would be appropriate to store in the Application?
• How would I handle the app being interrupted by a phone call in an Activity or Fragment?
• What special care to take if the app is to support orientation change?

Proper usage of thread

• What are Executors and how do you choose which Executor to use?
• When is it appropriate to use runOnUiThread and when would you use Handler instead?
• In which thread are the method in AsyncTask executed in and how would you make it safe to use if your app handles both portrait and landscape orientation?
• What things are appropriate to run in the UI thread?

Understanding Services

• What type of task is appropriate to be done in a Service?
• How does a Service notify the application UI of progress or result?
• What are the ways to start/stop a Service?

Know how to compose the UI

• Explain how LinearLayout and RelativeLayout work.
• How image size changes depending on which folder the image reside?
• How density pixel is calculated and used?
• What are 9-patch images?
• How to use themes.

Know how to write test cases in Android

And then depending on the type of application you are making, there are some area of topics that she should have experience with:

• If you plan to use a database
• Know how to create normalize tables and use SQLite database
• How to use ContentProvider
• How to use a Loader
• If you plan to have authenticated accounts
• Know how to write an Authenticator
• It would also be useful to know how to write a SyncAdapter
• Know something about caching such as the HttpResponseCache
• Familiar with popular open source libraries and can make suggestions as to which library maybe appropriate for your application.
• If you need real time update, she should know about Google Cloud Messaging
• and many many more topics, that not everyone is going to know
• Adding maps to your app
• Writing a widget
• Chrome casting
• Media playback
• Ads integration
• Facebook and Twitter integration

Lastly, you need to be able to build and distribute the app, which initially may be very simple, but soon enough you'll need someone who knows how to build, sign, and submit the app. You may want someone who's familiar with Maven, Gradle, and Google Play

I think if you're in a startup and wants to hire just one Android developer, she needs to have a good amount of diverse and deep understanding of Android. In my opinion, it's worthwhile to plan out what features you want to build so that you can ask the right questions. There's no point in hiring someone who has tons of experience in Map related apps if you're not going to be integrating maps. That's not to say you shouldn't hire a good generalist. But since this is your first and only Android developer in your startup, you need someone who is already an expert in Android, so in this case, you need someone who has already done it.

The other part of the hiring process that I find extremely flawed in the software industry is how we interview people. Most typically, we revert to CS 101 questions. While most of those questions are legitimate, many of them are useless. For example, a now popular question is about how to detect infinite loop in a linked list. This is popularized by an interview book that both interviewer and interviewee reads, and thus offer no insight today. If she ace the question right away, I'm pretty sure she just read the book. And honestly, how often do you encounter most of the things we ask in these interviews anyway.

The best interview that I've personally had was when I was asked to bring my own laptop, my own IDE, and pair program together a very simple app. For example, write an app that downloads a JSON file and display it in a ListView. Another type of question would be to design the app that you want to build. What component would we need. what open source library can we utilize. Perhaps most importantly, IMHO, is to make the interviewing process worthwhile for both parties. Both person should walk away learning something.

I realize my opinion doesn't align exact with Joel Spolsky's view on interviewing. I just think his views can be adjusted for different types of developers. And as Google admitted,  even their hiring process is flawed. And perhaps the technical interview is dead. One thing is certain, hiring and getting hired as a software developer is hard!

So godspeed to all who look for the right developer! and godspeed to those of us who strive to widen our knowledge and to sharpen our skills everyday. May we encounter good people and produce great product that enriches our society.

EDIT: I recently found an article that's similar to mine but he went much further to claim that Android development cost 2-3x than iOS. http://stevecheney.com/why-android-first-is-a-myth/

Builder pattern in Java

I've always liked how nice the StringBuilder API is. But I have not found the perfect opportunity to use it until today when I wanted to create a clean API for a Request object for searching OnDemand videos. The server API has been defined to accept a bunch of parameters. And depending on what you want to search for, you may supply one or more of these parameters.

What I wanted to create was a request object that's immutable once it's created. I have plans to use this request as a key to retrieve cached response, so it would be messy if someone was allowed to modify the attributes of the original request. So I've decided to have no setter methods.

I could create a constructor with all the parameters, but that would mean that most of the time the developer may have to create a SearchRequest object with lots of nulls. It's also very easy to misplace the arguments. If argument 1 is the rating and argument 2 is the offset, and they're both integers, I can imagine someone accidentally putting the value for offset in the ratings position and the value for ratings in the offset position.

The Builder pattern can be helpful in my situation. So I've prototyped the class here. Let's take a look at how I use this class first. Here's an example of a SearchRequest that query for high rating sports TV shows and episodes.


Running this code generates the following print:
03-01 20:00:59.849    1321-1321/com.example.app I/System.out﹕ http://my.server.com/search.json?offset=0&max_result=100&rating=4&categories=SPORTS&types=TV_EPISODE,TV_SERIES

I've restricted the creation of the SearchRequest object directly by making the constructor private. Instead the developer need to create a new SearchRequestBuilder. The builder then has small methods that are clearly named to add attributes. Once you have composed the request you want, you call the toSearchRequest method and you get the SearchRequest object.

And here's the source code for SearchRequest. I've seen variations of this pattern, but I've implemented it to satisfy my own requirements. I'd love to hear how you've used this pattern in the course of your career and how it differs from my interpretation.