I’m doing some contract work for a local mobile development shop who use Harvest as their time-tracking app (and it’s a nice one, too!). On days where you haven’t made any entries, Harvest fills the blank space with an aphorism or inspirational quote.
Currently, in honor of Chris Cornell, the quote is “One more time around might do it,” a lyric from one of Soundgarden’s best songs, The Day I Tried to Live:
This is cloud software’s way of pouring a 40 on the ground for fallen homies. Click the screenshot to see it at full size.
After taking in that poignant moment — at Crazy Go Nuts University, I was a DJ at the engineering pub and a keyboard player in an alt-rock band, and Soundgarden figured heavily in both — I did what I was supposed to do: click New Entry, put on some Soundgarden, and get to work on coding. This software isn’t going to write itself.
Texas Instruments should have simply issued this statement
to upstart online calculator vendor Desmos.
If you don’t get what “welcome to your tape” means, keep reading!
“Our products include only the features that students need in the classroom, without the many distractions or test security concerns that come with smartphones, tablets and internet access.”
Remember that quote. “We’re better because we do less and charge more for it” is often the battle cry of a slow-moving, complacent incumbent about to be trounced by an upstart that’s aware of changing technologies and markets.
been approved by the Smarter Balanced Assessment Consortium, a public agency that creates an online testing system used in middle schools and high schools in 15 states,
been backed by Pearson, the world’s largest education company,
won the College Board’s endorsement for use with its SpringBoard platform, and
With all this and the fact that physical calculator tech hasn’t changed much in power or price over the past 20 years while mobile tech has advanced in leaps and bounds, Desmos is on track to displacing Texas Instruments as the calculator of choice for high school and university.
Okay, please explain “Welcome to your tape”
It’s a new catchphrase that comes from the Netflix series 13 Reasons Why,which is about a high school student’s decision to commit suicide. Hannah Baker, the student in question, left behind a collection of cassette tapes explaining the thirteen reasons why she killed herself. Each tape addressed a specific student in her class and opened with “Welcome to your tape, [student’s name here]” — basically a message that says “You are one of the reasons why I chose suicide.”
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.
Junior iOS developers should:
Intermediate iOS developers should:
Senior iOS developers should:
