Juan Catalan, the Suncoast iOS Meetup organizer, gave a great presentation based on his own experiences. Six years ago, he began as a self-employed indie iOS developer. He landed a few short contracts, followed by a six-month contract, which in turn led to full-time work as an iOS developer. He continues in that line of work today, having interviewed at a few companies and interviewed a few iOS developer position candidates.
I took notes and photos, and the distilled result follows.
Requirements for iOS developers at different levels
Junior iOS developers should:
Have either:
At least one app in the App Store (and yes, sample projects count), or
A GitHub repo featuring iOS projects or sample code
No experience as an iOS developer necessary
Be comfortable with the basics of iOS development
Know Swift and maybe be willing to learn Objective-C
Intermediate iOS developers should:
Have at least one app in the App Store that isn’t a sample project
Have 2+ years experience
Know how to build an app from scratch and publish it to the App Store
Know both Swift and Objective-C, as there’s a good chance that they’ll be working with legacy libraries or even on legacy projects
Senior iOS developers should:
Have several apps in the App Store — Juan quantified this as “5 or more”
5+ years experience as an iOS developer, or 10+ years in software development
Deep knowledge of Objective-C and Swift, and how to interface between the two
Knowledge of complex subjects, such as:
Memory management
Concurrency
Unit testing
Automated builds
Version control
Before you apply for an iOS developer job
Have one (but preferably both) of the following:
An updated LinkedIn profile with links to your apps
A portfolio website
Have an updated resume in both Word and PDF format (some places, especially recruiters, insist that you submit your resume in Word format for a number of reasons)
Have apps or code that you have written yourself available in some publicly-available repository, such as GitHub, BitBucket, or Gitlab
Now you can apply and prepare yourself for the interviews!
Applying for an iOS developer job
The process generally has these five phases:
Initial screening interview with a recruiter or human resources person:
This is the first “filter” in the process
The recruiter or HR person looks at your “documentation”, usually your LinkedIn profile and resume, and matches that information with the position’s requirements
Remember, when dealing with recruiters, they make money when they successfully match a prospective employee with one of their clients
Technical screening interview, which could be in person or a call/chat:
A more in-depth look at your documentation by technical people
An interview with technical questions tailored to the required experience and company needs
Could include a post-interview real coding exercise
On-site technical interview:
Technical questions:
General software development questions
iOS-specific development questions
Whiteboard or paper coding exercises
Read coding/exercise or app
On-site team interview:
Resume questions
Technical questions
Behavioral questions
Closing conversation with a recruiter or HR person:
The company informs you of their decision
Offer negotiation and offer letter
Make sure that whatever you negotiated is in writing is in the offer letter
If it’s not in writing, it doesn’t exist, especially dollar amounts! The general rule is: “the more specific, the better”
The iOS technical interview: What you should review
From high-level to low-level, here are the categories of questions that you’ll be asked in an iOS technical interview:
Algorithms and data structures
Design patterns
Tool (Xcode, instruments, Git, and so on)
Frameworks (iOS SDK, 3rd-party libraries)
Programming languages (Objective-C and Swift)
You should review the following topics and sub-topics (and wow, are there a lot of them!)
You may be asked to do a coding exercise and build an simple sample app. The example Juan provided was one that displayed NASA’s “Image of the Day”, which would present a list showing the most recent images of the day in reverse chronological order (that is, the most recent one first). Each list item would feature a thumbnail of the image of the day, its title, and a brief excerpt of the image description. Tapping on an item would take you to the screen for that item, which would display a larger image, the title, and the full description:
You would need to know what controls to use:
And you’d have to handle a number of cases, as pictured below:
When the list is first populated
Downloading image thumbnails for the list
Simply displaying the list
What happens when the user pulls down the list to refresh it
Sample interview questions
What was the latest version of iOS you worked with? What did you like about it, and why?
Have you worked with Swift? What do you like about it? What don’t you like?
How is memory management handled in iOS?
What do you know about singletons? Where would you use one? Where would you not?
Explain the difference between using delegates and using KVO.
How do you usually persist data on iOS?
How do you typically do networking?
How do you serialize data on iOS, from getting JSON from the web, to memory, to persistent storage?
What design patterns do you know and use on iOS
What’s autolayout?
How do you handle asynchronous tasks?
How do you manage dependencies?
How do you debug and profile your iOS apps?
Do you do code review?
Do you test your code? What do you do to make your code testable?
Advice
Don’t waste your bullets. You have a limit amount of time and energy — use it where it will be most effective!
Be honest. You will get found out if you’re not!
Be precise. This is programming, after all.
Be respectful. How you conduct yourself is just as important as your coding skill.
Be friendly, not arrogant. You will be working with other people, some of whom will sign your paychecks.
Never give up.
The interviewer’s perspective
Juan then invited Igor Androsov to talk about iOS interviews from the interviewer’s point of view:
I’ve interviewed lots of people, and asked lots of the questions that Juan posted
I like to ask questions about actual hands-on work that people did
I often ask questions that lead to other questions
“I’m not here to tramp you down — I want to hire someone!” I’m buried in work, and need someone to take some of it off my hands.
Leading questions should be a sign. Chains of questions are an indication that you weren’t clear with answers, and they’re also a cue for deeper discussion
Be ready to say “I don’t know”. That’s okay; you can’t know everything. “I can prepare all day long, but I’ll never know all the answers”
With interview questions, tries to stay out of the details; tries to stay more general
Honesty is important; it’s a good indicator when someone stumbles — I want to see what they do next. Will you work through the problem? Will you ask questions?
More concerned about an attitude — Will they work with the team? Is there a cultural fit?
Solid development experience: By this I don’t mean “I developed, by myself, thirty one games and pushed them to the app store”. I mean you’ve been through a number of development cycles and encountered (and solved) problems enough times not to get thrown when something weird happens.
Ability to work solo if need be: Pair programming is the new hotness in some areas but sometimes you have to go it alone. You need to be self-sufficient enough to be given a problem and left alone to solve it.
Ability to work as part of a team: Along with the previous bullet point, you need to know when you’ve beaten your head on the desk enough to go ask for help or look on Stack Overflow or Cocoa Controls
Being able to DIY or adapt: It’s one thing to have some manager tell you you can build your app quickly by slapping together a bunch of components (React Native enthusiasts think this way); it’s another to do that, have one of them not play nicely with the others and you have to go dig into five or six components you didn’t write to fix the problem. You need to be able to take a look at someone else’s code (*cough*AFNetworking*cough*) and recreate just as much of it as you need. You avoid the consequences of the old saying “Marry in haste, repent at leisure.”
Hungry: Mobile is fast-moving. You have to be hungry to stay enough ahead of things to be able to bat aside the flavor of the month “write once run anywhere” hybrid app solution until you understand it and can give a reasoned opinion.
Comfortable Talking about Your Projects and Your Role In Them: Resumes, especially ones that come from recruiters, tend to have weasel-words in them that are red flags – “Involved with” or “Helped” or “Worked with” are an attempt to inflate minimal experience into something that might pass an interview if the interviewer isn’t technical or experienced. I ask people about what they worked on, what they did, what they encountered and how they solved problems. Sometimes I ask why they made a certain decision – not that I think they’re wrong, but how they thought it through.
Technical Proficiency: Where I work we give a four-hour timed task. You build an app from scratch to do something useful. You’re not recreating Paper or Facebook, but you’re not writing “Hello World” or “Flappy Swift” either. That, along with a standard technical interview designed to see where your experience is heavy and where it’s not, gives me a good picture of your skills and abilities.
What I don’t look for:
Dead-Enders: It’s one thing to be dedicated to solving a problem and shipping software. It’s another to think you have to grind yourself into dust to do it. Nobody really needs to make a habit of 80 hour weeks for months at a time.
Trivia Buffs: We need to write code, not argue over what CFString did eight years ago. I care that you know how to build an app.
One-Uppers, People with Something to Prove: People like this are never fun to work with and aren’t very often worth the trouble they bring.
BS Artists: There are red flags I mentioned earlier. Others are things like trying to take over the interview and direct it their way, evasive language, the “Gish Gallop” of acronyms and esoteric concepts designed to overwhelm the interviewer(s) and seem a lot smarter than they are. There are lots of other ones but this is a short post.
Perfection: Nobody is perfect. Everyone makes mistakes.
Antbleed is a newly-discovered vulnerability in the firmware of “Antminer” Bitcoin mining devices made by Bitmain, who make an estimated 70% of the world’s Bitcoin-mining ASICs. You can read about it on Antbleed.com, Bitcoin Magazine, and International Business Times UK, or you can get the 30-second explanation from the infographic below (share and enjoy it, please!):
How big is the mobile gaming market? About $46 billion, according to Newzoo, a market intelligence firm specializing in the global games and “esports” (I hate that word) industry. Their recent Global Games Market Report says that in 2017, 2.2 billion gamers worldwide will generate about $109 billion in game revenues, and mobile will account for 42% of that.
At this point, you’re probably asking yourself…
…and my answer would be:
Next Tuesday’s Tampa iOS Meetup will cover Apple’s SpriteKit framework, an excellent basis for building your own 2D iPhone and iPad games. We’re a group for people just getting started on their iOS programming journeys, so we’re going to keep it simple, but that doesn’t mean you won’t learn how to write a blockbuster smash hit game. That’s because I’ll show you how to write…
…and over a period of several days, turned it into Flappy Bird. He released it in May 2013, and it unexpectedly enjoyed a meteoric rise in popularity in 2014. The game is incredibly simple; it doesn’t increase in difficulty or vary at all throughout its gameplay. Despite (or perhaps because of) its simplicity, and even though he released the game as a free app, it still made lots of money — as much as $50,000 a day, thanks to in-game advertising.
You may be surprised to learn that Flappy Bird isn’t made up of much more than 4 or 5 screens’ worth of code. I’ll introduce you to the basics of SpriteKit and game development for iPhones and iPads, and walk you through the Flappy Bird code. By the end of the meetup, you’ll understand the mechanics underlying the Flappy Bird game, and you might have even made your first step towards getting a piece of the $46 billion mobile gaming market!
Applying to the State of Florida’s “Reemployment Assistance Program”. (I do like the positive-sounding name.)
The latter involves paying a visit to Connect, the Florida Department of Economic Opportunity’s benefits site. Among the benefits you can get from visiting that site is a grand tour of late 20th century/early 21 century governmental website design, in all its Kafkaesque glory.
I kept getting stuck at one part of the process: the one where you provide a list of the prospective employers you contacted in a given week (you need to contact 5 to be eligible for benefits). For each prospect, you need to provide the usual contact info, including the URL of their website. The problem is that Connect doesn’t think that an URL is real unless preceded by a subdomain — in other words, it won’t accept example.com, but will accept the functionally equivalent www.example.com:
I’ve got to hand it to this motherless, godforsaken site: I now have an additional incentive to land a job pronto.
Junior iOS developers should:
Intermediate iOS developers should:
Senior iOS developers should:
