What are the most common interview questions for Swift jobs?

Recorded May 2nd 2020 – watch the full episode on YouTube.

What would you say are the most common kinds of questions that get asked around Swift? What are the most common questions you see again and again?

Sean Allen: There are definitely some questions you're almost 100% going to get. ARC, automatic reference counting, how to fix the retain cycle, the whole weak self thing. If you don't know that and you're going into an iOS interview, that's probably not a good idea.

That's probably the number one thing I would recommend you not only just regurgitate the buzzwords, but actually put it into practice and do some print() statements in your deinit so you can see when it's not there anymore.

“There are definitely some questions you're almost 100% going to get. ARC, automatic reference counting, how to fix the retain cycle, the whole weak cell thing.”

But a quick disclaimer too, these are for I guess junior positions, right? You're trying to get that first job, because the more senior you get, the more nuanced the interview becomes. It's kind of hard to give blanket advice for senior positions, but for junior position, trying to get that first job, communication patterns is another big one.

Again, the whole delegate one-to-one notifications observers, one to many, all that stuff. People talk about KVO but, I've never used KVO and that's kind of like a relic of the past from what I understand, but I've never really been asked about KVO. It's been just those two typical reference, diverse value types, right. Classes versus structs, why they're different. If it's Swift-specific, you're going to get the optionals questions. And they're going to ask, “tell me all the ways you can unwrap optionals, and when you would use each one.”

“And then finally, basic threading is another very, very common one.”

And then finally, basic threading is another very, very common one. When I say basic, I'm not saying you need to know the details of all this multi-threaded code, but just knowing that UI needs to be on the main thread, and you need to know how to bounce back and forth in the UI, with the main thread and background threads.

But for beginner positions, of course, if you know more, that's great. But if you don't know the whole UI on the main thread thing, it's going to be a knock against you.

Paul Hudson: In your opinion, is it right to interview the interviewers? When they say, “do you have any questions for us?” What would you recommend?

Sean Allen: And it's always hilarious too. I’ve got to give the typical situation when this happens, because it always happens. If you were doing a Skype coding thing, or if you're out doing the whiteboard, usually you take all the time. So you'll be one minute over your time, and they'll be like, "Oh, well, I got to stop you there. We're out of time. Do you have any questions for me?" You're already three minutes over. So it's like, no, you're not going to have a conversation. Which sucks because anyway, that's usually how it goes.

“But, the first piece of advice is to just be genuine. It's very obvious when they say, ‘What questions do you have for me?’ And that candidate is just reading some random question they found on the internet that they were supposed to ask.”

But, the first piece of advice is to just be genuine. It's very obvious when they say, “What questions do you have for me?” And that candidate is just reading some random question they found on the internet that they were supposed to ask. That's very obvious. You can read, like you don't care about that, come on. So, that would be my first thing is, ask genuine questions that you really want to know.

And typical stuff that I want to know is, I want to know what my working environment is going to be like. Is it Swift, is it Objective-C? Is it all storyboard, is it code? Are you using MVC or MVVM? Like what architecture are you using? What's your philosophy on third-party libraries, or object-oriented, reactive, functional? I want to know what I'm going to be working in.

“I start asking you about the team. What is the workflow to get new code in? Of course usually there are PR reviews, but what is the actual flow? How does that go down? What are the dynamics of the team? Is everybody a senior developer and you're the only junior developer, or is there a nice mix, or is it mostly junior, one senior?”

So I would definitely ask all those questions. Then I start asking you about the team. What is the workflow to get new code in? Of course usually there are PR reviews, but what is the actual flow? How does that go down? What are the dynamics of the team? Is everybody a senior developer and you're the only junior developer, or is there a nice mix, or is it mostly junior, one senior? I like to know those dynamics. Also, like I mentioned earlier, this is personal to me, because I'm more interested in creating the products than I am the code, so to speak, so I want to know how much influence I'm going to have on the product.

Like I mentioned earlier, a lot of companies, if you're big enough, you've got product managers, designers, all the programmer does is type in the code and create what they've already got. I like to have influence on the products, so I want to know if that's a thing.

So yeah, at the end of the day, I'm just really trying to get a feel for the environment I'm going to be working at, and then like I said, just be genuine, don't ask blanket questions that you're like supposed to ask. Because they can see right through that.

Sponsor Hacking with Swift and reach the world's largest Swift community!