Interviewer Readme: iOS interview questions for advanced developers

When you're ready for a technical iOS interview, it's important to understand what topics you might be asking and what experienced iOS developers expect.
This is a series of questions that many Silicon Valley companies use to measure the level of seniority of iOS candidates.
These issues cover all aspects of iOS development and are designed to reach a broad understanding of the platform.
After all, advanced developers should be able to publish complete iOS products from beginning to end.
This is by no means an exhaustive list, but it can help you prepare for the upcoming technical iOS interview.

You need to let go of your subjective judgment and the most important thing.
– Listen carefully.

1. What is the latest version of iOS that you use? What do you like and why?
2. What is an iOS app and where does your code fit?
3. What Swift features do you like or dislike? Why?
4. How does memory management work on iOS?
5. What do you know about single people? Where would you use one, where you are not?
6. Can you explain the difference between delegate and KVO?
7. What design patterns are commonly used in iOS apps?
8. Do you know what design patterns are available in addition to the usual cocoa patterns?
9. Can you explain and show examples of solid principles?
10. What options do you have for storage and persistence on iOS?
11. What options do you have to implement network and HTTP on iOS?
12. How and when do I need to serialize and map data on iOS?
13. What are the options for laying out the UI on iOS?
14. How would you optimize the scrolling performance of a dynamically sized table or collection view?
15. How will you perform asynchronous tasks on iOS?
16. How do you manage dependencies?
17. How do you debug and configure files on iOS?
18. Do you have TDD experience? How do you do unit and UI testing on iOS?
19. Do you encode review and/or pairing plans?

In the following chapters, we will discuss each question, the reason behind it, the expected answer, and the answer that might pose a danger to the interviewer.

1. What is the latest version of iOS you are using? What do you like and why?
This question is often asked to learn how to connect using the latest iOS technology and development on the swift and iOS platforms.

The expected answer:
Hopefully, you are using at least the latest stable iOS version. But if you've already played or even updated your app, then you'll get an extra score. Talk about the exciting new features of iOS 11, and why you like them. It's good to have developers on the team passionate about the latest iOS technology. Often, curious people can use new features to propose interesting new features or come up with creative solutions.

Note:
This is usually a bad sign if the candidate does not have much work or interest in the current stable version of iOS. This means that this person is likely not to be aware of the latest technology, solutions, and features offered by iOS, which is likely to mean that the person misses the opportunity to take advantage of the iOS system, or, worse, that they do not know that there are new flaws in the latest system.

2. What is the iOS app and where does your code fit?
This is a big picture problem that can be queried in one form or another to assess your understanding of the iOS application and the overall situation where the code you write applies to the iOS system.

The expected answer:
You might think that the applications we build are special because they cover a unique use case. But your typical iOS app is just a huge, beautifying running loop. It waits for user input and is interrupted by external signals, such as phone calls, push notifications, home button presses, and other application life cycle events. The only difference is that it's not just a simple mail-looping function that starts every time a user clicks on an application icon, it has a higher level of abstraction, uiapplication and appdelegate is what our developers are doing.
The remainder of the code that you write to write the business logic of your application is placed in the "trigger point" of the application that is delegated to us by the main loop appdelegate. This is very much. Simple. However, code written for an application can be as simple as calling a method/function, or as complex as a viper architecture. What you do with it is your choice.

Note:
It is common for developers to see iOS applications as the code they write and the complex and complex details they implement, which are real. But if you take a step back and look at the big picture, you can see what the iOS app really is
A run cycle.

3. What swift features do you like or dislike? Why?
With the latest swift updates, it proves again and again that this language is the future of iOS development. The expectation of these days, especially experienced developers, is that you are very familiar with Swift and the features it offers.

The expected answer:
You can talk about powerful language input and feature features, and why you like or dislike them. There is no right or wrong answer, but the expectation is that you are familiar with the language and the features it provides (generics, protocols, options, etc.). Also, you should be able to explain and argue if you like or dislike something in this language (I don't like the optional link because it breaks the Demeter law, for example).

Note:
Swift is becoming the main stable language for the iOS platform, so it makes no sense to ignore it now.

4. How do I handle memory management in iOS?
Memory management is important in any application, especially in iOS applications that have memory and other hardware and system limitations. Therefore, this is one of the problems raised in some form. It involves ARC,MRC, reference types, and value types.

The expected answer:
Swift uses automatic reference counting (ARC). This is the same concept in Swift as in Objective-c. Arc keeps track of strong references to class instances and increments or decreases the reference count when assigning or unassign class (reference type) instances for constants, properties, and variables. It frees the memory used by objects whose reference count is reduced to zero. ARC does not increase or decrease the reference count for value types because these values are copied on assignment. By default, if you do not specify otherwise, all references will be strong references.

Note:
This is what every iOS developer must know! Memory leaks and application crashes are too common because of poor management of iOS application memory.

5. What do you know about singletons? Where would you use one, where you are not?
Singleton is a common design pattern in many OOP languages, and cocoa considers it one of the "core competencies of cocoa". This problem is sometimes seen in interviews, to measure your experience with singletons, or to see if you have a background, not just iOS.

The expected answer:
Singletons is a class that returns only one and the same instance, no matter how many times you request it.
Sometimes it is considered an anti-pattern. There are many drawbacks when using. The two main factors are the global state/State and object life cycle, as well as dependency injection. When you have only one instance of something, it is tempting to refer and use it directly anywhere, rather than injecting it into an object. This results in unnecessary coupling of the specific implementation in the code, not the interface abstraction.??? " Convenient "Another malicious side effect is the global state. Many times, you can implement global state sharing and act as a "common package" role that each object uses to store a state. This leads to unpredictable results and errors and crashes when this uncontrolled state is overwritten or deleted by someone.

Note:
Although singletons are considered good in some languages/platforms, they are in fact an anti-pattern that should be avoided at all costs.

6. Can you explain the difference between a representative and a KVO?
Faced with this problem, the interviewer is evaluating your knowledge of the various message patterns used in iOS.

The expected answer:
Both are methods of establishing relationships between objects. A delegate is a one-to-one relationship, an object implements a delegate protocol, another uses it and sends a message to it, assuming these methods are implemented because the recipient commits to abide by the protocol. KVO is a many-to-many relationship where an object can play a message and one or more other objects can hear it and react. KVO does not rely on protocols. KVO is the first and basic module of responsive programming (RXSWIFT,REACTIVECOCOA, etc.)

Note:
An experienced developer should know the difference between the two, and which one should be used on top of the other.
**

7. What design patterns are commonly used in iOS apps?
   This issue is a common problem for job interviews at all levels, perhaps in addition to junior positions. Basically the idea is that when using the iOS platform, as a developer you should familiarize yourself with the technology, architecture, and design patterns commonly used on iOS.
   
   The expected answer:
   Typical common patterns when building iOS apps are the patterns that Apple advocates in Cocoa,cocoa touch,objective-c and swift documents. These are the patterns that each iOS developer learns. They include mvc,singleton,delegate and observer.
   
   Attention:
   When the interviewer raises the question (in one form or another), the interviewer is looking for something other than MVC. Because MVC is a forward-looking design pattern, it is expected that every iOS developer knows what it is. However, what they want to hear from you is a common and available out-of-the-box feature.
   
   8. In addition to the common cocoa patterns, what are the design patterns you know?
   The interviewer will ask this advanced question when interviewing senior or architect positions. Hopefully, in addition to the basic types described in the previous question, you can also learn more about the more practical design patterns used in iOS apps. Get ready to recall a bunch of gang of four and other similar patterns.
   Unfortunately, the design patterns themselves are a huge topic (they are also better introduced in my book), so here I'll just give some of the overviews I've seen in the iOS code base.
   
   The expected answer: * *
   In addition to the common mvc,singleton,delegate and observer patterns, there are many other applications that are fully applicable to iOS applications: Factory Method,adapter,decorator,command, Template and so on.
   Factory method is used to replace a class constructor, abstract and hidden object initialization, so that the type can be determined at run time, and the statement that SWITCH/IF uses to determine the type of object to instantiate is hidden and contained.
   An adapter is a design pattern that helps you (as the name implies) to adapt an object's interface to another object's interface. This pattern is typically used when you try to modify third-party code that cannot be changed to code, or if you need to use content that has an inconvenient or incompatible API.
   The decorator is another wrapper for the class that enhances its functionality. It wraps what you want to decorate, implements its interface, and delegates the message sent to it to the underlying object, or either enhances it or provides its own implementation.
   command is a design pattern in which you can implement an object that represents the action you want to perform. The operation can have its own state and logic to perform the tasks it does. The main advantage of this design pattern is that you can hide the internal implementation of the user's actions, you can add undo/redo functionality to it, and you can perform actions at a later point in time (or not at all), rather than creating an action right away.
   A template is a design pattern in which the main concept is to have a base class that outlines the algorithms that need to be completed. The base class has several abstract methods that need to be implemented by its specific subclasses. These methods are called hook methods. The user of the template method class interacts only with the base class that implements the algorithm step; The specific implementation of these steps is provided by the subclass.

Note:
While you're just starting out with the iOS platform, it's good to stick with the mvc,singleton,delegate and observer patterns, but they're very useful for advanced things that need to go deep into something more abstract and advanced like the gang of four oop design patterns, Make your code base more flexible and maintainable.

9. Can you explain and show examples of solid principles?
The solid principle is relatively obsolete, but is well suited for any OOP code base in any language. Watch some of Uncle Bob's conversations about this topic to fully understand the history behind them.
On YouTube: The Bob Martin Solid principle for object-oriented and agile design.
Unfortunately, the solid principles themselves are a huge topic (they are also better in my book), so I'll just give them an overview here.

The expected answer:
Solid represents single responsibility principle, open/close principle, Liskov substitution principle, interface isolation principle and dependency inversion principle. These principles are mutually supportive and are one of the best common design methods you can use for your code. Let's take a look at each one of them.
The single Responsibility principle (SRP) is the most important principle of the organization. It points out that each module should have only one responsibility and reason to change. The SRP starts from a specific and specific situation, such as a class and/or object that has only one purpose, and is used only for a single thing.
The Open/Close principle (OCP) stipulates that your module should be open for expansion, but closed for modification. It's one of the easiest things to hear, but it's hard to get your head around when you start thinking about its meaning. In fact, this means that when writing code, you should be able to implement an object's behavior through inheritance, polymorphism, and composition using interfaces, abstractions, and dependency injection.
The Liskov substitution principle (LSP) states that an object in a program should be able to replace an instance of its subtype without altering the correctness of the program. This means that when you inherit from or implement an interface (protocol) from a class or an abstract class, your object should be replaceable and can be injected, regardless of which interface or class you use. This principle is often referred to as contract design, or is referred to as protocol-oriented programming in the SWIFT community. The main message of this principle is that you should not violate the contract, that is, the interface commitment that your commitments follow, and through inheritance, these subclasses can be used anywhere the superclass was previously used.
The principle of interface isolation (ISP) says that many customer-specific interfaces are better than a common interface. It also stipulates that no client should be compelled to rely on and implement methods that are not used. This means that when you create an interface (protocol) for your class implementation, you should strive for and rely on abstract features, but until it becomes a waste, you must implement a bunch of methods that your new class will not even use.
The dependency inversion principle (DIP) states that "depends on abstraction rather than tuberculosis". The best example of this principle is the dependency injection (DI) technique. With dependency injection technology, when you create an object, you can provide and inject all of its dependencies when it is initialized or configured, rather than having the object create or get its dependencies for itself.

Note:
Solid principle is the foundation of good object-oriented design. Applying these principles will help you build better, easier-to-maintain software. If you are applying for an advanced iOS position, it is recommended that you familiarize yourself with these tips.

10. What options do you have to achieve storage and persistence on iOS?
Visitors ask this question to learn about the tools and ways you can store and save data on iOS.

The expected answer:
In general, there are several ways to store data: from simple to complex:
Memory arrays, dictionaries, collections, and other data structures
Nsuserdefaults/Key Chain
File/disk storage
Core Data, Field
SQLite's
Memory arrays, dictionaries, collections, and other data structures are good for storing data or not having to be persisted.
Nsuserdefaults/keychain is a simple key-value store. One is unsafe and the other is safe, respectively.
File/disk storage is actually a way to write data fragments (serialized or nonexistent) to disk using Nsfilemanager.
Core data and areas are the framework for simplifying database work.
SQLite is a relational database, and when you need to implement complex query mechanisms, core data or realm does not cut it.

Note:
You should understand the different ways that you can store data on iOS and its pros and cons. Do not limit yourself to a solution (such as core Data) that you are accustomed to. Know when more preferable than the other.

11. What options do you have to implement network and HTTP on iOS?
Almost every application is now using some kind of network to get data from APIs and other external resources. Many applications are useless when they are not connected to the Internet. Every iOS developer should know that they can build the service/network layer of their application.

The expected answer:
There are several options in iOS to implement the HTTP network. You can use the old nsurlsession, but unless you abstract it out, it can be daunting to use. Another option is to use a wrapper library around it. The most popular solution on iOS is alamofire/afnetworking.
Advanced developers should keep in mind that building a network layer in an iOS application means not only processing HTTP requests. It also means implementing a complete set of tasks related to your code: HTTP networking, data serialization, and data mapping.

Note:
Now, afnetworking and Alamofire are the de facto standards for HTTP networks on iOS, and each developer should know how to use them. At the same time, they are based on the Apple framework and know that Nsurlsession's internal details are also useful.

12. How and when do I need to serialize and map data on iOS?
Data serialization is a common task that needs to be performed when building an iOS application. The visitor asks this question to see if you recognize it as appropriate and know that you need to perform the task of data processing, whether it is a network or storing data.

The expected answer:
There are two most common scenarios in which you need to serialize and map data in an iOS application: Receive or send data (such as JSON or XML or other content) in the network layer, and persist or retrieve models in the storage layer (nsdata,nsmanagedobject, etc.).
Whenever you receive JSON or XML or any other type of response from the backend API, you are most likely to get it in JSON or binary or other "inconvenient" formats. The first thing you need to do to be able to process the data that you receive is to serialize it into what the application understands. On the simplest and most basic level, it will be a dictionary or an array of objects containing other dictionaries, arrays, and primitives from that response. Nsjsonserialization is responsible for dealing with this (and soon codable protocol). The next step is to map the data to the application's domain model. Those are the model objects that will be used by the rest of your application. You can do it manually, or you can use libraries such as mantle or Swiftyjson. The data flow and serialization/mapping are as follows: Binary data->?json-;? nsdictionary/nsarray->?your domain model objects.
Similarly, in the storage tier, you need to serialize the data and map the data to the custom domain model object and the storage-understanding format. The "map" chain used to read the data is as follows: db->?raw data format->?custom domain models, and is used to write this: custom domain models->?raw data format-& gt;? Db. You can do this here using the Nsmanagedobject or nscoding protocol.

Note:
The main note here is not aware of the need for these data operations when using the network and storage tiers of the iOS application. Things do not happen "automatically" and are not appropriate and maintainable to the original nsdictionaries.

13. What are the options for laying out the UI on iOS?
When you need to solve different UI problems on iOS, it's important to know your options for on-screen layouts. This question helps measure your knowledge of how to place and align views on the screen. In answering this question, you should at least mention the CGRect framework and the AutoLayout, but it would be nice to mention other options such as Componentkit and other flexbox and react implementations on iOS.

The expected answer:
The go options for arranging views on the screen are good old cgrect frames and AutoLayout. Frames and auto-sizing masks have been used before iOS 6 and are not preferred today. Because it is difficult to calculate exact coordinates and view sizes for various devices, frames are too error-prone and difficult to use.
Starting with iOS 6, we've launched AutoLayout, the most popular solution yet, and Apple's favorite solution. AutoLayout is a technique that declaratively defines the relationship between views, called constraints, and allows the framework to calculate the precise frame and position of UI elements.
There are other options for layout views, such as ASDK (Texture), Componentkit and Layoutkit, which are more or less inspired by react. For example, these workarounds are good in some cases when you need to build highly dynamic and fast tabular views and collection views. AutoLayout is not always perfect, and knowing that there are other options is always good.

Note:
At least the hard-to-get facts of Autolayout,frames's notoriety will surely be a red flag for the interviewer. Now no sane person will do cgrect framework calculations unless it is absolutely necessary (for example, when you do some crazy painting).

14. How can I optimize the scrolling performance of a dynamically sized table or collection view?
One of the most important questions to ask in an interview with the UITableView problem is the scrolling performance of the table view.

The expected answer:
Scrolling performance is a major problem in uitableviews, and it is often difficult to get the right results. The main difficulty is cell height calculation. When the user scrolls, each next cell needs to calculate its contents before the height can be displayed. If you do a manual frame view layout, then it's more performant, but the challenge is to make the height and size calculations just right. If you use AutoLayout, then the challenge is to set all constraints. But even though the AutoLayout itself may take some time to calculate the unit height, and your scrolling performance will be affected.
Potential solutions to rolling performance problems may be
Calculate the cell height yourself
Preserves a prototype cell, fills the content, and calculates the cell height
Or, you can take a completely radical approach, even with different techniques, such as ASDK (textures). The ASDK (texture) is designed for a list view with dynamic content size and is optimized to calculate the cell height in a background thread, making it ultra-high performance.

15. How will you perform asynchronous tasks on iOS?
Now, multithreading is an important part of any client-facing user-oriented application. This problem can be raised in a networked environment or as an independent problem with GCD or asynchronous development.

The expected answer:
Now, the solution for asynchronous tasks on iOS is nsoperations and GCD blocks. The Grand Central Dispatch is a technology that can handle multiple background queues, and the background queue can also determine the background thread processing work. The most important thing is that it's abstracted from you, so you don't have to worry about it. Nsoperation is an object-oriented abstraction above GCD that allows you to perform more complex asynchronous operations, but you can use all the content that gcd performed by Nsoperations. Many cocoa frameworks use GCD and/or nsoperations (such as nsurlsession).
Help with third-party libraries there are other ways to handle asynchronous work. The most notable are promises (Promisekit), Rxswift and Reactivecocoa. Rxswift and Reactivecocoa are particularly adept at modeling time and the asynchronous nature of work that needs to be done in the background and coordinated between threads.

Note:
The basic knowledge that every iOS developer should know about asynchronous work is GCD and nsoperations. Rxswift and promises are high-level concepts, but advanced developers should also be aware of them.

16. How do you manage dependencies?
Dependency management is an important task for every iOS project. This question is asked to measure your understanding of the problem and how to solve it.

The expected answer:
A few years ago, we had no dependency manager on iOS, we had to copy and paste third-party code into our project or use a git submodule. As our code base and dependencies grow, all of these methods are quickly proven to be out of control.
Now we have other dependent managers to choose from: Cocoapods,carthage and Swift Package Manager (SPM). So far, the strongest and most powerful is the cocoapods. It is built on the spirit of Ruby Bundler gems and is a ruby gem itself. It works by installing gems, creating podfile at the root of the project, declaring the Pods (library) to be used, and running pod install. Only.

Note:
Each iOS developer should understand why copying and pasting multiple third-party libraries into a code base can cause maintenance nightmares, because multiple libraries may depend on two different versions of another library, resulting in mismatches, compile and runtime issues, and so on.

17. How do you debug and configure files on iOS?
No one writes the perfect code, and occasionally developers need to debug their code and profile applications to look for issues such as performance and memory leaks.

The expected answer:
We can do this in iOS apps and always have a good nslog print. There are also breakpoints that you can set using Xcode. In order to execute a single code fragment, you can use Xctest's measureblock.
You can use the instrument for more advanced debugging and analysis. Instruments is an analysis tool that helps you analyze your application and discover memory leaks and performance issues at run time.

18. Do you have TDD experience? How do you do unit and UI testing on iOS?
While the iOS community has historically not been a big part of TDD, the improvements in tools and influence from other communities, such as Ruby, are now becoming more popular, and other communities such as Ruby have long embraced TDD.

The expected answer:
TDD is a technology and discipline, and before you write the product code that passes it, you write the failed test first. These tests will drive the implementation and design of your product code to help you write only the code necessary to pass the test implementation, not much more. This discipline can be daunting at first, and you don't immediately see the benefits of this approach, but if you persist, it can help you accelerate in the long run. It is particularly effective in helping you refactor and modify your code, because at any time you have a safety net that tells you if something is broken or that everything is still normal when you change it.
Recently, Apple has made improvements to the XCTEST framework to make testing easier. They also made a lot of improvements in Xcode's UI tests, and now we have a good programming interface to interact with our app and query what we see on the screen. Or, you can use a framework like kif.
There are several options for unit testing, but the two most popular options are xctest and quick and nimble.
Xctest is a Xunit test framework built by Apple. This is what they recommend, and it's the highest level of integration with Xcode.
Quick is a rspec-like BDD framework that helps you describe your specifications/tests based on behavior rather than "testing." RSpec's fans like it.
Nimble is a matching library that can be used with xctest or quick to declare expectations in your tests/specifications.

Note:
More and more teams and companies are accepting TDD, which has become an important part of the iOS development process. If you don't want to be left behind, try it and learn how to test your code.

19. Do you encode a review and/or pairing plan?
While many applications are built by independent developers, the complexity of applications is increasing, requiring development teams to work on them. Working in a team presents different challenges in code maintenance, collaboration, and knowledge sharing.

The expected answer:
Pair programming is the practice of two developers doing the same task together on the same machine (hopefully not sharing the same screen and keyboard and having two sets of their own). The goal is to facilitate collaboration, discussion, code review, and QA in the place where code is generated. This process makes knowledge transfer and architectural discussion a common daily matter, preventing people from having an island hazard and becoming an "expert" in one part of the code (what happens when that person leaves or gets sick). It also improves code quality because the two groups of eyes are looking at the code as they write code. This process occurs simultaneously between two developers, sometimes referred to as synchronization.
Pair programming is not for everyone, and if the character doesn't match, it could be an exhausting process. But it is one of the most effective collaborative technologies in software development.
Code review is a similar process of collaboration and knowledge transfer, but unlike pairing programming, it does not happen at the same time, so it is asynchronous. With code review, after a developer has written a piece of code or a feature, other people on the team can view it. The reviewer checks to see if the code makes sense and suggests changes and refactoring to improve it. This opens the online or offline discussion of the code, which is great. Pass knowledge about the code to other teammates and help identify errors and design odors as early as possible.
Code review is a less involved type of collaboration that is roughly the same as the results obtained for programming. It is also a kind of sympathetic exercise that you give others feedback on the work of other people.

Conclusion
The issues covered in this article cover a wide range of topics that iOS developers should be aware of. This is by no means a complete list. These questions are based on the research I've done for this book, the "iOS Interview Guide" I published. This book is close to the interview preparation as a comprehensive overview of the iOS theme and focuses on each iOS app. It breaks down the problem into the following groups: UI-related issues (uiview,autolayout, etc.), storage issues (persistence, user defaults, core data, etc.), networks (Http,nsurlsession,alamofire, etc.), and design patterns and architectural issues (MVC, Mvvm,solid, etc.).

Interviewer Readme: iOS interview questions for advanced developers