This Christmas, close to 90% of shopping will occur on a mobile device. Companies are scrambling to get in-house developers.

Imagine you’re hiring an in-house team. You’re tired of outsourcing with contractors. You want to be able to walk to someone’s desk and ask them, “Can we do that on Android?” And, in this fantasy, the engineer lights up, does a few keystrokes, and voilà! Your new Android app does the dishes or your taxes, or some awesome feature. No long protracted meetings and $100,000 later you get a feature that doesn’t remotely look like what you asked for, and doesn’t even work that well doing something else.

I know these companies, and I understand their situation. They don’t have someone in-house to interview mobile. If they did, they wouldn’t have to hire them, ha. So here’s my opinion as a senior mobile developer and lead engineer, on how to interview candidates for mobile, as well as leadership roles.

1. Get rid of the fantasy that quick deployment will happen. Be realistic- two out of three marketplaces require review. Old software rules apply, that with good planning, iteration, and testing, you will get a great product. You can setup a quick deployment environment, but it’s not about the developer, it’s about your engineering group and how quick you release in general.

2. Mobile engineering is not rocket science. Complicated, obscure, and varied, yes, but mostly about getting up to speed on different systems and SDKs and hands-on experience. Put away the Google Questions, engineering exercises, and hypotheticals. Good design means thin clients to a single code repository on the server where you have the hard core engineers. Look for architecture chops- that limit the development on the client. If a mobile developer wants to “do everything on the client” that is generally a bad design. There are interesting problems on the client, but mostly around UI, caching and responsiveness. Hard-core developers in mobile are very tight with the operating system, or moving out of native and into web- HTML5.

3. More and more (and this is a good thing) the user interface and user experience are key elements to good mobile apps. Quick feature development is nice, but good and elegant solutions, from people who have done many apps are better. As an experienced iOS developer, my most intensive code is around a gradient button that I subclassed from the usual UI toolkit from Apple. Yes, making a button. And, it’s a damned good button. Also, my highest points from StackOverflow come from the blog post I made sharing the love on how to make gradient buttons on Android and iOS. So ask them about buttons. Ask them what apps they like and why. Ask them what is slow responsiveness, what is fast, what users can expect. Propose a problem and see how they answer it. Like, “What’s the best way to do a login and facebook login on the same app?” Have them whiteboard some mock-ups and screens. That is probably what they’re going to be doing all day- mobile mock-ups to communicate functionality. If you have an amazing design team, have them meet and interview the mobile developer. This will be a significant portion of their job. The right answers to “what is your favorite app”- one that you like as well. If you have different opinions, it’s probably not a match (or it’s a battle you’ll keep fighting during their tenure, if you want that.)

4. Hire someone who knows how to setup A/B tests for product design and customer feedback, analytics, and testing frameworks. That raises engineers from hobbyists to professionals. If they’ve been in a large engineering group, more the better. Working side by side with your API developer is key, key, key, to a successful internal mobile team. Can they “speak” to the server developer about how to access the API, or how to build one? Setup an interview with server developers and have them focus on data calls, modeling the server side, see if communication is good and they can work together. This will be approximately 30% of their workload, working with server engineers.

5. The “front-end” and “back-end” engineering roles of most web sites does not apply to mobile. If it does, it would be all front-end, but you need to handle memory management and work with a computer language that is Java or C. So, it’s a combination of a serious back-end developer, with user interface and UX interests. Hiring someone internally who is “interested in mobile” – I wouldn’t recommend this as it will be the blind leading the blind. There’s a lot of catching up to do, and while folks may learn fast, you will be their guinea pig, and all deadlines will be pushed out, or products released poorly. Without mentorship, I have seen this go very wrong. So, if you do hire a senior iOS or Android developer, or a lead, do train someone from another department if they’re interested. But don’t saddle them with product and feature deadlines, in a high pressure situation, right out of the gate. It is an expertise, and your business is important.

6. Ask them if they’ve ever versioned an app, and how they did it, and what they recommend or lessons they’ve learned. This will prove that they were involved in the architecture and implementation of a released product. The right answer is that they’ve done it before and can easily explain it to you. There are different flavors, but mostly it’s just whether it’s been done.

7. For developers who point to a lot of iPhone apps in the store that don’t list them as the creator, ask what role they had in the team. Many folks claim apps that are in the store that aren’t theirs, and understanding how they worked with their teammates, and the roles they had, and if they can justify certain code or decisions. Ask them how it got started, what their invovlement was. Were there any changes along the way? Did feature get dropped, if so, why? Sniff out bullshit here, and ask if you can get a reference from another team member. Developers are pretty territorial and will make sure that their work is theirs.

8. Points if the candidate has done packaged/downloadable software (application developers) are good candidates for mobile- the versioning is similar (vs. web), as it’s released software to devices. The problem with web developers who want to do mobile… the movement to HTML5 and mobile web is a great transition in the mobile space, but not completely done at this moment (to be in the store you still have to do a native wrapper app). The modal style of development for applications is still more application (vs. web). Application developers have been solving similar problems as mobile, just with bigger monitors. Web developers have two dangerous tendencies: live updates (not on a release schedule), and easy to create interfaces. Mobile development has a structured, timed release, and the user interface elements are more complex (longer to build) than web.

9. If you happen to land yourself a very senior mobile developer that you’d like to lead your group, the key elements to interview for, in my opinion:
– Ability to code for Android *and* iOS, and gravy if they can do mobile web
– Experience in the server language, or, structural and architectural understanding of the rest of your site and/or product.

Having architecture expertise, and proven experience in developing for multiple platforms, will place them in a unique situation to understand what the clients need to have responsibility for, and what others systems the clients need to interact with. Then, you can start doing the fun work of lining up all those cool features you want to develop.