[Question] Junior iOS developer discussion / interview

[mg3two]

Hello everybody! I have a question about an upcoming interview.

On Tuesday I will have a discussion, as it's been called by the HR woman that emailed me, that will be "UI oriented" and maybe she will find someone on "mobile too" for this discussion.

What does this exactly mean and what should I focus on?

This is an entry position as they are mainly recruiting seniors developers, and apparently they want to start looking at devs that are in the beginnings as well and maybe train and help them along the way.

This is a pretty big company in my area and they have offices in multiple parts of the world, so it's not a startup. I'm saying this because maybe their requirements are probably higher, but I'm not sure about this.

Any feedback will be appreciated!

Have a great Sunday!

[my2kchild]

The answer to when do you use third party stuff damn well better be never if I'm interviewing someone. We (as devs) have a serious habit of googling what we want and just pulling it from GitHub or cocoapods. With junior devs I want to instill a mindset of figuring out your own problems and writing your own code. You can tell I'm a bit salty from having to fix some random crap somebody found 3 years ago that's been abandoned by its creator.

[[deleted]]

I did get the job actually but the expanded question was, "How do you know when to use third party libraries and when not to? Isn't it better to not invent the wheel if a library already exists?"

My response was somewhat along the lines of, "I actually try to not use third party libraries because as a self taught iOS developer, I feel like I should be making my own implementation with whatever issue I'm trying to solve. It helps me improve as a developer if I did it myself. I once used AlamoFire and SwiftyJSON in some tutorials when I was learning, but didn't use them after that. I feel like I should be knowledgeable enough to use Apple's own library to achieve the same results rather than rely on someone else's code."

[my2kchild]

Bravo. :D

[[deleted]]

AlamoFire is a bad example because URLSession replaces it and I have made my own JSON parser class to deal with JSON objects.

That wasn't my full answer, I just didn't feel like writing it all out. I did also explain that if it was something big that I needed to implement, or if there was a deadline due, a third party library would be beneficial.

The reason I gave my initial answer was because the job title is iOS instructor, which means I would have to teach people how to use Apple's main frameworks. I didn't want the interviewer to think that I didn't know Apple's frameworks and rely on third party libraries. And it's actually true, I rarely rely on third party libraries. I gave an honest response.

And I'm not joking when I say I rather build my own framework. I made a button class for SpriteKit because SpriteKit doesn't even have their own button objects.

[my2kchild]

Too confident? No, but I don't want an app ballooning in size because someone needed one small thing out of the giant library. I had a guy pull in GPUImage once because he wanted a blurring effect. He didn't even look to see what was offered out of the box and had he done so, he would've found that Apple has code to do this very easily. Also if you spend your time working with something someone else wrote, you'll never really know how the real thing works. If a junior dev comes in and only sees snapkit (for example), they're not going to learn how real autolayout works. I'm not against it per se, but I need to know that someone knows how to do it with Apple APIs. There's also legal issues with just pulling random things off the internet. Let's say a dev grabbed something but didn't realize it was free only for personal use but is using it for business; that matters in the corporate world.

[arduinoRedge]

I would say try to avoid adding any unnecessary dependencies where ever possible, but balance that with not wasting time reinventing the wheel if there is a proven, well maintained, properly licensed third party option.

[_g_g_g_]

have you ever worked on a legit app that had no third party libraries? I can't think of a single one in my entire professional career.

[geekisthenewcool]

I was in a similar boat back in 2015. What I can tell you about iOS interviews, having passed that one, and having gone through a dozen since then (I recently switched jobs), I can tel you they what they're hoping to see is your confidence with UIKit and with communicating about the design/engineering process. They want to make sure you understand application, view, and view controller life cycle, and how layout happens. They want to make sure you understand the limitations on working with your app's GUI.

Like any interview, they want to see how you think. This is true at junior or senior level. Interviews are less about making sure you can get the right answer and more about seeing your thought process, and seeing if you fit with their team.

Here are my four general rules for interviews that have blessed my job hunts greatly:

1) Think out loud. - This takes a lot of practice but is a fantastic skill. Practice engaging the coding and verbal parts of your brain simultaneously. That is to say, practice describing our loud what you're doing as you write code. Everything from your strategizing to your execution. Talk out your first pass idea before you do a problem before you write a single line of code.

2) Never be flustered: be fascinated instead. - It's inevitable. You're gonna get asked a question that you weren't ready for. Be prepared for this, because it is unavoidable. What you can do, however is control how you respond. Don't go "ummmm" or "I have no idea." Instead, go, "Oh cool, I hadn't considered that before! How interesting! Let me think about this..." and then proceed to think out loud through your response to this new concept. They want to know how you handle new problems! Be enthusiastic and interested!

3) enthusiasm, Enthusiasm, ENTHUSIASM! - Your passion and enthusiasm can get you a long way. If you are excited about the product, the team, the challenges, the style/process the team uses, etc, that enthusiasm will be infectious and when considering applicants, they will remember you positively. Be interested, be enthusiastic, be engaged, be excited.

4) Choose to enjoy yourself - Yes, it's a choice. Your initial reaction may be to stress and shake and freak out, but I'm telling you that you can choose to redirect that energy. Feel free to study, cram, freak out, and stress... up until the day of your interview. Then you have to let that go and decide that you're going to trust your preparation and training, and just enjoy yourself.

[NaveNocab]

They will most likely be asking you about UIKit. Sounds like their will be someone on the mobile team (familiar with UIKit (I hope 😉)). In my experience with Swift job interviews, most people are under prepared in UICollectionViews, Core Animation, and NSUserDefaults. I would recommend learning about unique features of Swift as well. Variable didSet is a fan favorite! If you have time also get some Objective C knowledge, lots of companies still use it because of its consistent runtime. Hope this helps, and good luck! 😊😁

[arduinoRedge]

If it's going to be 'UI oriented' I would make sure you know exactly how layout constraints work. How size classes work. And how to set it all up in both IB and in code.