How I Interview an iOS App Developer

Hey All! Thanks for popping by, and reading my article.

Please don't hesitate to leave a comment, and let me know if I'm full of Doo Doo.

Or, on the flip side, please also leave a comment, if I'm full of Goo Goo ... as in ... Goo Goo Goodness! ??

I've been working as a software developer for the last 20 years, and as an iOS / Mac app developer, for the last 10 of those years.

During my last gig, I was a team lead for a very large Fortune 100 company's iOS apps. These apps provided critical services for millions of global users.

During my career, I've had the pleasure of participating in many interviews, as both the interviewer, and the interviewee. For most of the interviews, I was the interviewer, but lately, I've had the pleasure of being the interviewee.

Or, maybe I should say "displeasure".

I just thought I would share my thoughts on what has worked for me, when interviewing a candidate, to fill a "mid-to-senior level" iOS app developer position. Of course, for a junior level, or "beyond senior" level position, this method may have to be tweaked. But, for a typical mid-level iOS app developer position, I've had great success with this method.

I'm going to go out on a limb here, and say, of the few interviews that I've attended lately, as an interviewee ( the one being interviewed ), it was a rather, shall we say, unpleasant experience. I came away from the interview thinking "The people who just interviewed me, to fill an iOS app developer position, really don't know how to conduct an interview, IMHO. I would rather have had a root canal, without the numbing juice, rather than repeat that experience!".

Ok, maybe that's an exagerration, but I just don't understand why a software dev interview, at least one for an iOS app developer, has to be so unpleasant. Maybe it goes back to the early days of M$, and other big tech firms, when the interview process would involve two, ( or even three! ), days of very stressful grilling, by 10 different managers and tech leads.

Yes. I kid you not! Three long days of white boarding! Can you say "overkill"? And, just to add minced liver to the top of the soggy cake, chances are, the candidate would be passed by for the position. That is, if the candidate was lucky enough to even hear back. If even one of the interviewers gave a thumbs down, that candidate was canned. ( "Hey, thanks for wasting three days of my time!" ).

Call me obnoxious, egotistical, full of hubris, or whatever other negative adjective you can think of, but I felt, if nobody speaks up about the crappy software dev interview process, it will always stay the same.

With that being said, I'm going to be brave, step in, and attempt to pull in some fresh air.

Okay, so how do I, " Mr. Brilliant Know-It-All", conduct an iOS app developer interview?

First off, just let me just say, I try to make the interview a pleasant, and interesting, experience for both, myself, and the candidate. My intent is not to "sweat" the candidate, and run the candidate through a torturous and stressful process. Nor, is it my intent to show the candidate how brilliant I am, and what a dummie she is.

No. My intent is, numero uno, to find out if the candidate can:

(A) - Complete the types of REAL tasks that will be encountered while on the job. Or, if the candidate is lacking in some technical areas, does the person have the passion, and desire, to learn new technologies. I would even go so far as to say, I'm more interested in the latter, than the former.

(B) - Find out if myself, and my fellow team mates, can "jive" with this candidate. That is, can we be highly productive, while working together, and deliver on an excellent product. A highly productive team, working together, will almost always blow away a single "rock star" developer, any day of the week. I know, I've seen it happen many times.

So, in the words of "The Ahnold" ... LET'S ROCK!

Here is how I conduct my iOS app dev interviews:

Step 1: A casual, short 15 to 30 minute phone conversation. I ask the candidate if she is currently working on any of her own apps. We chat about what iOS dev-related web sites, books, Meetup groups, etc. that the candidate reads, or attends. Nothing too intense here. I'm just trying to build some rapport with the candidate and look for genuine interest in deving for iOS.

If there is great rapport, this first chat may go longer than 30 minutes. This is a good thing, and will be positively noted.

Provided I felt this chat went well, and if the candidate feels the same ( Remember, she is interviewing the company, also. ), I ask the candidate if she would be interested to meet for a more in-depth chat. If so, it's on to Step 2.

Step 2: Either in-person, or through remote video, we meet for a 1 hour to 2 hours chat. Possibly, 3 hours, but that would be pushing it. ( If you can't determine a candidates fit within 3 hours, your interview process is broken. If you have to interview for 3 days, then you must be looking to fill the position of CEO. You should stop reading this article now. ).

During this meeting, for the first 30 minutes, we casually chat about fundamental iOS dev topics. "Tell me a bit about how the iOS app event lifecycle works.". "What are your thoughts on GCD, threads, Operation queues.". "What's the differences between a 'class' and a 'struct' in Swift.

My questions will often start off easy. If the candidate seems to be breezing through them, I will step up the difficulty.

One of my desires here is to learn something, myself. As an interviewer, I take the opportunity to pick the candidates brain, and perhaps learn something new. Even the most experienced iOS app dev does not know everything about this huge, and magnificent, platform. My time is expensive. I would like to feel that the organization that I'm working for, even if the candidate is not hired, is getting something of value out of this time, too.

Good devs never stop learning.

In addition, this is where I attempt to de-stress the candidate, and make the interview interesting, and perhaps, even fun. I want the candidate to leave, feeling that regardless of the outcome, that the time spent was not a waste.

For the next 30 minutes, if the candidate has her own app, or code, and is able to walk me through some of the code, that is great. This is where a remote-video interview is great, because then the candidate can just do a screen share. ( Yes, the corporate lawyers may block this, but if it's possible, I feel it's good to see some of the candidates actual, real-world code. ). We talk about design approaches, challenges encountered, parts of the code that could possibly be improved. I'm also looking to see how clean and structured the code is. In addition, I'm paying attention to how much of the code is originally authored, how much is cut-and-pasted from Stack Overflow, and how many third-party components are used. If the candidate tells me that she cut-and-pasted the entirety of method "HelloWorld", I will positively note that. The candidate was honest. On the flip-side, if the candidate tells me that she designed, and authored, so-and-so method, but cannot tell me why she used a Set collection type, rather than an Array type, that will also be noted.

If the candidate does not have her own code, then that will be noted, and we will instead create a simple app in Xcode, that requires the candidate to write some code. Nothing hard here, just something quick and simple. Remember, I want the candidate to be relaxed and confident. You may be wondering why I would note her not having her own code. Most iOS app developers, the ones who genuinely have a passion for the platform, will have some of their own code available. Even if it's just simple, little apps used for experimentation. I have gobs of little apps on my drive, that do nothing but show a funky view transition, or that demonstrates a design pattern, like Chain, or MVVM. I even have an app that will control a DJI drone, using voice commands. ( I should swing it by DJI. ).

Step 3: At this point, we should be about an hour into it. If everything is going swell, then we get into the fun stuff. And, I'm serious, when I use the word 'fun'. This should be fun, or at least, interesting.

What I'm going to do now is pair program with the candidate, on a programming task that is very similar to the type of task that the candidate would be given during a typical day on the actual job.

I'm not interested in testing the candidate to solve some sort of sorting / searching programming puzzle, or path finding algorithm, or any other such silly nonsense. Unless, of course, the product that my team works, on involves a lot of custom sorting / searching / or pathfinding, which I will tell you now, is not the case. Perhaps, if you are interviewing for a position on the Apple Maps team, or Facebook Photos team, this would be the case. But, not for my team. And, I would hazard to guess, not for most teams, out there.

I know the previous paragraph is probably the one that is going to garner the most comments. Ah well, so be it. As I said, my method of interviewing has brought me success. The proof is in the pudding. Now, with that being said, I'm not saying that grilling the candidate on algorithm puzzles should be avoided. It just depends on what type of software product your team is producing. I would much rather hire a candidate who knows how the iOS Autolayout engine works, rather than one who knows how to write an algorithm to find the longest range of red bowling balls, out of 5000, that are being used by 2 bowlers, one of which throws a gutter ball on every 3rd try ... blah, blah, blah.

The users of the app won't give a rip if the background data is sorted in sub-O(n) time. The users will care a great deal if the UI looks funky on his brand new iPhone XS, in landscape mode! Your company will care a lot, if the user is unable to get to the "purchase" button, because the broken layout has placed it out of view.

I have to honestly tell you, in 20 years of deving software, I've never had to write an algorithm that finds the longest range of red bowling balls, out of 5000. Maybe that means I'm not a real software dev. Ah well, life goes on.

What is a typical programming task? One might be to create a custom Alert view that allows a user to do such and such. Or, to display a little thumbnail image that appears in the upper, right corner. The user should be able to use a gesture, to flick away the thumbnail. Or, perhaps, fix a bug, where old values are popping up in a scrollable list view of items. Or, perhaps to fix a layout bug, where the purchase button is placed out of view. Whatever it is, it will be interesting, and complex enough, so that I get a good feel for what the candidate can do. Depending on the experience level that I'm interviewing for, the task will vary. For a more experienced dev, we might design the API for an internal reusable framework component. It just depends.

I often will use something that I call "My Interview App". This is a simple app that I use just for interviewing. Before the interview, I will tweak the app to allow for the implementation of the new feature that I have in mind, or it will contain the bug that I would like to see fixed.

Working together, we will attempt to deliver on the task. Of course, I will be letting the candidate take the lead. I will only step in when needed.

After completing the task(s), we will chat a bit more. I will answer any questions the candidate may have. Something I will often take note of here is, if the candidate has any interests, outside of coding, that might demonstrate the candidates intellectual curiosity. For instance, learning a language, playing an instrument, or how to brew beer. I'm serious, on the last one. By the way, "red bowling ball" sorting algorithms, don't count.

I've found, through the years, that working with broad-minded, left brain - right brain people, with diverse backgrounds, are often a joy to work with, and make for great software developers.

In addition, the "soft skills" are becoming more and more important, with each passing year.

The ability to communicate, both verbally and via the written word is becoming so critical. As is, the ability to work with others. Even better is, the ability to have a multiplying effect on your team mates productivity. A developer with that skill is worth his / her weight in gold.

Hacker Dude, sitting in a dark corner, while wearing a hoodie, may be able to quickly write up a "red bowling ball" algorithm, but that's not the skill most teams need, in order to achieve maximum execution. There are plenty of companies that would love to have Hacker Dude. My company is not one of them. Sorry, Hacker Dude.

And finally, a mixture of genders, ethnic and cultural backgrounds, and just plain diversity, usually results in outstanding software development teams.

If it's an in-person interview, I will introduce the candidate to a few other team members. If it's a remote video interview, I may have some team members join the call.

Speaking of, it's not unusual for there to be one, or two, other team members present, during this "implement a task" part of the interview. This allows other team members to get to know the candidate.

That's it! After 2 hours, perhaps 3 ( Definitely, not 3 days! ), myself, and some fellow team mates, will have a fairly good idea on if we can be productive with this person, and if the person can handle the typical, realistic tasks that the team works on.

It's not rocket science folks. This is how most other professions interview. It's only the software development profession that runs candidates through a miserable, meat grinder of an interview process, that feels not unlike a day of university final exams, or root canals ( with no numbing juice ).

I hope this article was helpful. Cheers.

Greg M. Thompson - iOS App Developer, Blogger, and Deliverer of Good Vibes