Ajith's blog

I occasionally blog here.Checkout my website.

As an agency developer, I’ve had a chance to be part of the recruiting team that recruits new members for the iOS team. Here, I’d like to take you through my thoughts and through the process of conducting interviews for an iOS developer role.

Candidate’s Resume

A resume generally has one to two pages and recruiter takes 10-15 sec to scan them. In India? No; Here in India resume and CV are one and the same for most people (including recruiters) and recruiters over here expect CV, I think.

I’m going through the resume to fill out my bow quiver with the arrows of the different concepts listed in the candidates’ resume. I’d like to know, of course, what he / she has known. It helps to realize that the candidate doesn’t make up the resume.

I’d vote for a resume like this one.

Go Easy

A candidate is the best to perform when he is comfortable. He’s expected to find it convenient to talk about his recent work or something interesting he’s been working on lately. So, I would always like to start with a question like, “What have you been working on lately?”

I expect the answer to explain the technical side after a short overview on the project/work. When interviewee does not clarify the technical aspect, I’m going to ask them to do so. And, I’m going to keep my questions around it for this session.

Fire The Arrows

It’s about time to ask questions about some of the things the candidate claimed to have learned. I often start my interviews with questions related to basic concepts such as “What is MVC and how its components communicate with each other in iOS development?”

Surprisingly, for the latter part of the question, I don’t get a convincing answer from a developer who’s been playing with MVC all that time.

I’m going to shuffle my questions a little here on the basis of the candidate’s way of answering; simple questions will be followed by difficult questions, and vice versa. Because back-to-back unanswered questions could make interviewee feel bad, and I might rush to judge the candidate’s abilities.

Nervous candidates, huh? Well, that’s normal. If they feel nervous, I try to make them feel comfortable.

Domain Specific

I don’t usually ask the basic questions listed on the first page of the google search result for an interview of iOS developer position. Because everyone comes prepared with answers to the basic questions (I believe so). Of course, there are some important basic questions that I’m sure I’ll ask them.

Here are a few concepts that I’m asking questions about with a typical iOS developer:
Initializers, app life cycle, appDelegate, view life cycle, memory management, categories & subclasses, concurrent execution, web services & REST, code signing, provisioning profile and sandboxing, LLDB, crash tracking, zombie concept, design patterns, etc.

I’ve also had a couple of interviews with candidates who are more experienced than me. I ask them some difficult questions like, “They say that singleton is evil; why?” IMO, Junior developers are more likely to come to senior developers with similar questions.

Whiteboard Coding

First of all, it’s not fair to expect to write a hundred percent executable code. I look at the analytical thinking of the candidate, the way in which the candidate approaches the problem and, most importantly, the logic behind the implementation.

The question could be as simple as “Implement accessor methods for a property (non ARC)”. Can’t imagine that some beginner minds have completely ignored this since they’ve had ARC. Nothing here is magic, it’s built for you and it’s hidden from you. I would be happy to know that the candidate has made an attempt to understand how it works.

One Last Question

Before winding up, I always ask the following question. It helps me to improve myself, too.

“Are you happy with the way we interviewed you? Do you feel that you haven’t been able to present your skills since we didn’t ask about it?”

Kyle Richter, thank you for this tip.

Feedback

At the end of each interview, I do share my observations from the interview with the candidate, both positive and negative. For example, I often meet with candidates who have excellent practical skills but are theoretically poor. They may find it difficult to put their understanding into words.

When I share my opinion of the interview, I see how the candidate accepts feedback and his desire to know what could have been better.

That’s all of it. I hope to improve myself as I make progress in my career.

P.S. I’ve only taken the technical round of the interview so far.

Thanks for reading!
If you found my work helpful, buy me a cup of coffee! I will appreciate it a lot.

Buy Me A Coffee