Swift interview questions

What a strong answer covers

• Describe `if let` and `guard let` as conditional unwrapping methods, noting `guard let`'s early exit behavior.
• Explain `optional chaining` for safely accessing properties or calling methods on an optional.
• Detail the `nil-coalescing operator (??)` for providing a default value when an optional is `nil`.
• Mention `force unwrapping (!)` and emphasize its dangers and limited appropriate use cases.

Where people lose the point

• ×Failing to explain the 'why' behind each unwrapping method, beyond just 'how' it works.
• ×Over-relying on force unwrapping without acknowledging its risks or providing alternatives.
• ×Confusing the behavior of `if let` (creates a new scope) with `guard let` (ensures value for the rest of the current scope).

What a strong answer covers

• Define `let` as a constant, meaning its value cannot be changed after initialization.
• Define `var` as a variable, meaning its value can be changed after initialization.
• Explain that `let` promotes immutability, which can lead to safer and more predictable code.
• Provide clear examples for both, such as `let` for fixed IDs or configuration, and `var` for counters or mutable state.

Where people lose the point

• ×Simply stating 'let is constant, var is variable' without explaining the implications for code safety or mutability.
• ×Not providing concrete, distinct examples for when each keyword is appropriate.
• ×Incorrectly suggesting that `let` variables cannot be initialized later (e.g., in an `init` method for a class property).

What a strong answer covers

• Explain that structs are value types (copied on assignment/pass), while classes are reference types (shared reference).
• Discuss memory management: structs are typically stack-allocated (or inline in heap objects), classes are heap-allocated and managed by ARC.
• Highlight the implications of value semantics (immutability, no side effects) vs. reference semantics (shared state, inheritance).
• Suggest use cases for structs (small data models, immutability, no inheritance needed) and classes (shared mutable state, identity, inheritance, Objective-C interoperability).

Where people lose the point

• ×Failing to clearly articulate the 'value vs. reference' distinction and its practical consequences.
• ×Not mentioning ARC as a class-specific memory management mechanism.
• ×Providing a generic answer without specific scenarios where one is clearly superior to the other.

What a strong answer covers

• Define ARC as Swift's automatic memory management system that tracks and manages app memory usage.
• Explain how ARC works: it counts strong references to instances of classes, deallocating an instance when its strong reference count drops to zero.
• Describe strong reference cycles: when two or more class instances hold strong references to each other, preventing them from being deallocated even when no longer needed.
• Detail how to resolve strong reference cycles using `weak` and `unowned` references, explaining the difference between them.

Where people lose the point

• ×Confusing ARC with garbage collection or manual memory management.
• ×Failing to explain *why* strong reference cycles occur and *how* `weak` and `unowned` break them.
• ×Incorrectly stating that ARC applies to structs or enums (it only applies to class instances).

What a strong answer covers

• Explain that closures, like classes, are reference types and can capture variables from their surrounding context.
• Describe how a strong reference cycle occurs when a class instance holds a strong reference to a closure, and that closure, in turn, captures and holds a strong reference back to the same class instance.
• Detail the use of `capture lists` (`[weak self]`, `[unowned self]`) within a closure to break these cycles.
• Explain the difference between `weak` (optional, can become `nil`) and `unowned` (non-optional, must always have a value) in capture lists, and when to use each.

Where people lose the point

• ×Not clearly explaining *why* closures can cause strong reference cycles (their reference type nature and capture behavior).
• ×Confusing `weak` and `unowned` or misstating their safety implications (e.g., `unowned` can crash if the captured instance is deallocated).
• ×Forgetting to mention that `self` becomes an optional when captured `weakly` and requires unwrapping.

What a strong answer covers

• Define `associatedtype` as a placeholder name for a type that is used as part of a protocol's definition.
• Explain that the actual type to be used for the `associatedtype` is determined by the conforming type.
• Discuss how `associatedtype` allows protocols to be generic and work with different concrete types, making them more flexible.
• Provide a concrete example, such as a `Container` protocol with an `associatedtype Item` that specifies the type of elements it holds (e.g., `Int`, `String`, `CustomObject`).

Where people lose the point

• ×Failing to explain that `associatedtype` makes a protocol generic, not the conforming type itself.
• ×Providing an abstract or overly simplistic example that doesn't clearly demonstrate the utility of `associatedtype`.
• ×Confusing `associatedtype` with generic type parameters on functions or classes.

What a strong answer covers

• Explain that errors in Swift are represented by types conforming to the `Error` protocol (often enums).
• Describe how functions that can throw errors are marked with the `throws` keyword in their signature.
• Detail the `throw` keyword for signaling an error within a `throws` function.
• Explain the `do-catch` statement for handling errors, including specific `catch` blocks for different error types.
• Discuss `try`, `try?`, and `try!` for calling throwing functions, highlighting their different behaviors and safety implications.

Where people lose the point

• ×Not clearly distinguishing between `Error` protocol conformance and the `throws` keyword.
• ×Failing to explain the purpose of `try` when calling a throwing function.
• ×Misrepresenting the safety of `try!` or `try?`.

What a strong answer covers

• Define generics as code that works with any type, providing flexibility and type safety.
• Explain that generics solve the problem of code duplication (writing the same logic for different types) and type casting (avoiding `Any` or `AnyObject` and subsequent downcasting).
• Discuss how generics allow you to write flexible functions, classes, structs, and enums that can operate on any type, while still enforcing type constraints.
• Provide a simple example, such as a generic `swapTwoValues<T>(a: inout T, b: inout T)` function or a generic `Stack<Element>` struct.

Where people lose the point

• ×Simply stating 'generics work with any type' without explaining the benefits of type safety and code reuse.
• ×Providing an example that is not truly generic or doesn't clearly illustrate the problem generics solve.
• ×Confusing generics with `Any` or `AnyObject` and not emphasizing the type safety aspect.

What a strong answer covers

• Define `serial queues` as queues that execute tasks one at a time, in the order they are added, ensuring mutual exclusion for shared resources.
• Define `concurrent queues` as queues that can execute multiple tasks simultaneously, leveraging available system resources.
• Explain the `main queue` as a special serial queue for UI updates, and `global concurrent queues` for background tasks.
• Provide use cases: serial queues for protecting shared mutable state or ensuring task order; concurrent queues for parallelizing independent, long-running operations.

Where people lose the point

• ×Failing to mention the `main queue` as a critical serial queue for UI operations.
• ×Not explaining *why* you would choose one over the other (e.g., thread safety for serial, performance for concurrent).
• ×Confusing the concept of a queue being serial/concurrent with the number of threads it uses (GCD manages threads internally).

What a strong answer covers

• Define `willSet` as an observer called just before a property's value is stored, providing access to the new value (`newValue`).
• Define `didSet` as an observer called immediately after a property's new value has been stored, providing access to the old value (`oldValue`).
• Explain that property observers are useful for reacting to changes in a property's value, such as updating UI, logging, or performing validation.
• Note that property observers are not called during initialization and cannot be added to lazy stored properties or computed properties.

Where people lose the point

• ×Confusing `newValue` and `oldValue` or their availability in `willSet` vs. `didSet`.
• ×Suggesting property observers are suitable for computed properties (they are not, as computed properties don't store values).
• ×Failing to provide clear, practical examples of when to use them (e.g., updating a UI label when a model property changes).

What a strong answer covers

• List and explain the five access control levels: `open`, `public`, `internal`, `fileprivate`, and `private`.
• Differentiate between `open` and `public` (subclassing and overriding outside the defining module).
• Explain `internal` as the default level, accessible within the defining module.
• Describe `fileprivate` (accessible only within the defining source file) and `private` (accessible only within the defining declaration).
• Discuss the importance of access control for encapsulation, modularity, and preventing unintended external modification of internal implementation details.

Where people lose the point

• ×Confusing `open` and `public` or `fileprivate` and `private`.
• ×Not explaining the concept of a 'module' in the context of access control.
• ×Failing to articulate the software design principles (encapsulation, API stability) that access control supports.

What a strong answer covers

• Define `map` as a function that transforms each element in a collection into a new value, returning a new collection of the same size.
• Define `filter` as a function that returns a new collection containing only the elements that satisfy a given condition.
• Define `reduce` as a function that combines all elements in a collection into a single value, using an initial value and a combining closure.
• Provide a clear, distinct code example for `map` (e.g., squaring numbers), `filter` (e.g., even numbers), and `reduce` (e.g., summing numbers).

Where people lose the point

• ×Confusing the output type or size of the collection for `map` vs. `filter`.
• ×Not explaining the role of the initial value in `reduce`.
• ×Providing examples that are too complex or don't clearly demonstrate the core functionality of each function.

What a strong answer covers

• Define `defer` as a statement used to execute a block of code just before the current scope exits.
• Explain that `defer` blocks are executed regardless of how the scope exits (e.g., normal return, `break`, `throw` error).
• Discuss its primary use case for cleanup tasks, such as closing files, releasing locks, or deallocating resources, ensuring they are always performed.
• Provide an example demonstrating resource cleanup, like opening and then ensuring a file handle is closed.

Where people lose the point

• ×Incorrectly stating that `defer` executes *after* the function returns or *only* on error.
• ×Failing to emphasize its guarantee of execution regardless of exit path.
• ×Not providing a practical example that clearly shows its utility for cleanup.

What a strong answer covers

• Define `is` as a type check operator that returns `true` if an instance is of a certain type or a subtype, and `false` otherwise.
• Define `as?` as the optional downcasting operator, which attempts to downcast an instance to a more specific type and returns an optional of that type (`nil` if casting fails).
• Define `as!` as the forced downcasting operator, which attempts to downcast and force-unwraps the result. It will cause a runtime error if the cast fails.
• Explain when to use each: `is` for checking type, `as?` for safe conditional downcasting, and `as!` only when you are absolutely certain the cast will succeed.

Where people lose the point

• ×Confusing the return types of `is` (Bool), `as?` (Optional), and `as!` (forced type).
• ×Understating the danger of `as!` and not providing scenarios where it's appropriate (e.g., when you know the type from context).
• ×Not explaining that type casting applies to class instances and protocol conformance, not value types directly.

What a strong answer covers

• Define extensions as a way to add new functionality to an existing class, struct, enum, or protocol type, even without access to the original source code.
• List the types of functionality that can be added: computed properties, instance and type methods, initializers, subscripts, and protocol conformance.
• Explain the benefits: improving code organization, adopting protocol conformance for existing types, and extending types from frameworks or libraries.
• Provide examples like adding a computed property to `String` or making `Int` conform to a custom protocol.

Where people lose the point

• ×Incorrectly stating that extensions can add stored properties or override existing functionality.
• ×Failing to explain how extensions improve code organization and modularity.
• ×Not providing concrete examples that demonstrate the practical utility of extensions.

What a strong answer covers

• Define a `lazy` stored property as a property whose initial value is not calculated until the first time it is accessed.
• Explain that `lazy` properties must always be declared with `var` because their value can change (from uninitialized to initialized).
• Discuss the primary use cases: when the initial value is computationally expensive, when the property is not always needed, or when the property depends on other parts of the instance that are not fully initialized until later.
• Note that `lazy` properties are not thread-safe by default in a multi-threaded environment.

Where people lose the point

• ×Incorrectly stating that `lazy` properties can be `let` constants.
• ×Failing to mention the performance benefits or the 'only when needed' aspect.
• ×Not addressing the thread-safety concern in a concurrent context.

What a strong answer covers

• Define protocol composition as the ability to combine multiple protocols into a single requirement, using the `&` operator (e.g., `ProtocolA & ProtocolB`).
• Explain that a type conforming to a protocol composition must conform to *all* the protocols listed in the composition.
• Differentiate from class inheritance: composition allows combining behaviors from multiple sources without the limitations of single inheritance, promoting flexibility and avoiding the 'fragile base class' problem.
• Discuss its utility for creating highly specific type requirements, enabling more flexible and modular designs, and adhering to Protocol-Oriented Programming principles.

Where people lose the point

• ×Confusing protocol composition with multiple inheritance (which Swift does not support for classes).
• ×Failing to explain the `&` syntax or how it creates a new, combined type requirement.
• ×Not clearly articulating the benefits over class inheritance in terms of flexibility and avoiding tight coupling.

What a strong answer covers

• Define memory safety as ensuring that memory is accessed in a controlled and predictable manner, preventing issues like dangling pointers or buffer overflows.
• Explain data races: when multiple threads or concurrent tasks access the same memory location without synchronization, and at least one of the accesses is a write.
• Discuss Swift's features that contribute to memory safety: value types (structs, enums) by default prevent shared mutable state, and ARC manages memory automatically.
• Detail how Swift's strict access rules for `inout` parameters and `self` in mutating methods help prevent simultaneous access to mutable state within a single thread, and how concurrency tools like GCD and Actors (for Swift Concurrency) provide mechanisms for safe shared state management across threads.

Where people lose the point

• ×Focusing only on ARC and not on other aspects like value types or strict access rules.
• ×Failing to clearly define what a data race is and why it's problematic.
• ×Not mentioning Swift's explicit concurrency features (GCD, Actors) as tools for managing shared mutable state safely.