How to Hire an iOS Developer

Market Your Job

A Job Description

Write your job descriptions for developers, not your business. The critical facts for an iOS job include the hiring business’s name, the job title, a salary range, the benefits, the location, and the experience desired. Put that information as close to the top of your job description as possible.

If you insist on describing your company before selling the job, keep your writing tight and as brief as possible. Explaining your business and your culture will help candidates decide to apply. Save your three page essay on your business values for after the critical facts.

Post Widely

Finding an iOS developer means making it easy for them to find you. Job boards like those on Stack Overflow or we work remotely make a lot of sense. You’ll probably want to expand your horizons beyond the job sites: use your social media accounts, ask your current employees to spread the word, and send our an email to your friends working on iOS apps outside of your company. If you mention the @hireanappdev account on twitter, and meet my posting criteria, I will probably retweet you.

The key to any of these posts is to include the actual job information and a way to apply (or a link to the same). One reason many outside recruiters fail to find quality candidates is a reluctance to share the name of the employer. Skilled app developers care about who they work for.

Screening Candidates

Once you start getting job applications, you need to filter out the best candidates. As much as possible, this process should focus on skills and experience. Intelligence, Computer Science trivia, and “culture fit” might seem important, but the number one qualifier for an app developer is building apps.

Looking at Resumes

To start, only look to resumes to confirm that the candidates appear to match your hiring criteria from the job description. If you find yourself tossing out resumes that meet your job description, you’ve either written a misleading job description, or you’re applying some sort of bias to the process. If that’s the case, you need to go back to your job description.

I suggest resisting any bias, or “pattern matching”, often a synonym for prejudice. Sometimes the most unlikely candidates looking have the best skills. Likewise, candidates listing fancy schools or big tech names on their resumes sometimes prove disappointing. Hiring a great app developer requires focus on app development skills.

The first review of resumes should only eliminate obvious mismatches. If you’re looking for a Senior iOS developer, and someone with only Java experience applies, you can safely eliminate their resume. I wouldn’t eliminate someone for something like not having worked at a famous company, or for having an unusual educational background.

At the end of your screening process, feel free to rank your candidates. However, if you have less than 20 candidates it’s probably not worth your effort to sort. Depending on the quality of your applicants, you will probably need to contact 10-40 candidates anyhow.

Making Contact

Your next step involves contacting each candidate who meets the expectations of your job description. I suggest personalizing each email at least somewhat. A simple template for contacting your candidates might read:

Hi Pat,

Thanks for applying to our Senior iOS Position! Based on your resume, it looks like you have the skills we need! As a reminder, here is a link to the job description along with the salary and benefit information: ...

We hope you’re still interested in moving forward in our interview process. From this point the interview process includes: a coding challenge, a phone interview where we discuss your coding challenge, an on-site interview (travel and expenses covered), and finally if the other steps go well, a job offer.

The details of the coding challenge and how we score it are linked here ... The challenge should take no more than two hours for most developers, and we hope it will be fun.

John

The Take-Home Coding Challenge

The key to a hiring a great app developer lines in the coding challenge. While many developer interviews focus on brain teasers or memorized computer science facts, the secret to hiring a skilled app developer is making sure they can develop apps!

In other words, a good coding challenge asks your candidates to build an app using the same skills they will need in your business. Makes sense, right?

If you’re building an app that connects with a web api and lets the user search for results, make your app challenge reflect those skills. If the challenging bits of your app involve concurrency, make sure to include concurrency in your app challenge. Explicitly tell your candidates your criteria: “we expect your solution to keep computation off the main thread where possible”.

Calibrating the difficulty of a coding challenge is a balancing act for your business. On one hand, it should be challenging and unique enough that it isn’t boring or trivial to implement. On the other hand, it shouldn’t require more than an hour or two of your applicant’s time. Companies that expect a candidate to spend hours of their free time completing a challenge will look inconsiderate.

When constructing your challenge, I suggest keeping it focused, fun, and obviously not usable in your product. Keep it focused so the candidate knows when they’ve solved your challenge. Keep it fun so the candidate doesn’t think you’re a soulless, life-crushing employer. Make sure that it doesn’t seem like work usable in your product so that you don’t look like you’re getting free labor from the candidate’s hard work.

Keep your requirements for the challenge focused on the position you’re trying to fill. Asking a candidate to write code that isn’t in an app is a waste. Asking app developers to struggle through your standard “fizz-buzz” command line program challenge makes no sense.

Also be careful to not require the use of tools or technology a candidate probably won’t know. For instance, I’ve worked on coding challenges that required use of a buggy and poorly-documented internal UI toolkit. The experience wasn’t fun, and I had doubts about wanting to work somewhere that built and requires the use of such obnoxious technology.

An example coding challenge might be:

Acme Coding Challenge - The Boot Hunt Using this API ..., build an app to allow users to search for boots for sale. The UI doesn’t haven to be fancy, but should provide a place to enter search terms, and show a scrolling list of results. You should use the RESTful API documented later to fetch the data your app needs.

Your app should be written in Objective-C or Swift. Feel free to use any open-source libraries to make your life easier. Make sure the app compiles on the latest version of Xcode, works on the latest iOS version, is resistant to crashes, and is well documented. Send us the complete source code. Your efforts will be judged for reliability, readability, and performance. We don’t expect a fancy custom user interface, although it should basically comply with Apple’s HIG.

To score each coding challenge, you need a senior iOS developer to evaluate each submission. They should look for obvious sources of crashes (e.g. force-unwrapped variables), readable coding style, error handling, proper concurrency, and so on.

Perfection in the coding challenge isn’t expected, but proficiency should be demonstrated.

The Interview

Interviews can be held in person or over the phone. The interview has several goals:

• To confirm that the candidate wrote their coding challenge
• To evaluate communication skills
• To evaluate knowledge of more complex app development skills
• To sell the candidate on the job

The first step in the interview after the introduction is to confirm that the candidate actually solved the coding challenge themself. I suggest asking questions about the app, and then requesting that the candidate make some minor change to their app. This should be somewhat trivial, and not intimidating. It could be as simple as asking them to change a color or a layout. You should let the candidate use their preferred tool on an actual computer to do the work (i.e. AppCode or Xcode).

Once you’re comfortable that the candidate understands their own code, the next step is to discuss some relevant technical topics around app development.

• How auto-layout works
• How ARC works
• Concurrency and race conditions on iOS
• Patterns (MVC, Notifications, etc.)
• Swift Optionals (if relevant)

And so on. This is also an opportunity to test their verbal communication and collaboration skills.

Finally, you should be prepared to explain how your organization works, how you manage source code, your QA process, how people are promoted, and so on. The candidate should have ample opportunity to interview you and your team.

Checking References

Once you’ve narrowed down your candidates though screening resumes, coding challenges, and an in person interview, you should ask for references. For a senior or junior developer, you should ask for at least one reference that has worked with them in an app-development capacity.

Like every other aspect of the screening process, communications with the references should focus on the exact job skills. For example:

Dear Jesse,

Pat listed you as a reference for a senior iOS developer role at Acme (link to job). Can you comment on Pat’s abilities concerning:

• verbal and written communications
• collaborating with other developers, managers, and QA engineers
• developing iOS apps in Swift
• debugging and technical analysis skills

Thanks,

John

Making an Offer

The final step in the hiring process is making an offer to your top candidate. Remember when making any job offer that negotiation is expected. Offering at the top of your range may seem generous, but it can lead to resentment from candidates who have a strong expectation of negotiation.

Even if you have an mind-blowing offer, experienced negotiators will believe that your first offer isn’t your best offer. Regardless of their negotiation experience, your candidate may also have different priorities for their compensation. While you might crave equity, they might crave health insurance, vacation time, or a salary at the high end of market rates (which in my experience varies by quite a bit).

You should consult with an expert in local employment law before making an offer. The basic information to include in a job offer is:

• Salary
• Equity (e.g. stock options or Restricted Stock Units)
• Bonus structure (e.g. performance bonus, profit sharing, etc)
• Retirement benefits (e.g. 401k and matching)
• Health insurance
• Long and short term disability insurance
• Life insurance
• Vacation time
• Other benefits or perks

After giving the verbal offer, be prepared for the candidate to request a better offer, accept, reject the offer entirely (which may be the same as requesting a better offer), or ask for time to contemplate the offer. If you’re an skilled negotiator, you probably know how to react to these. If you’re not an experience negotiator, treat your candidate respectfully and in an understanding fashion no matter how they react.

If the candidate accepts your offer, great news! If the candidate asks for time, set a time to follow up and look for follow up questions. You probably will negotiate the offer in a few days.

If the candidate rejects the offer or asks for a better offer, you’re negotiating! Asking for a better offer is obviously better news than a rejection, but in either case you should ask for details so you can decide what to do next in your negotiations.

Comments? Questions? You can reach me at @HireAnAppDev