Interview Questions

Swift: Automatic Reference Counting (ARC). The compiler inserts retain and release calls. Every class instance counts its strong references, and when the count reaches zero it is freed right away. Memory use is predictable and there are no collection pauses.

The weak spot is retain cycles: if two objects reference each other strongly, neither count reaches zero. You break the cycle with weak (becomes nil when the object is freed) or unowned (assumed to always exist), most often as [weak self] in closures.

Kotlin and Java: garbage collection. The JVM (or Android’s ART) periodically starts from roots such as threads and static fields and frees everything it can’t reach. Cycles are not a problem, because unreachable cycles are collected too. The cost is that collection runs when the runtime decides, which can mean short pauses and more memory headroom.

	ARC (Swift)	GC (JVM, ART)
When memory is freed	Immediately at zero references	When the collector runs
Reference cycles	Leak unless broken with weak	Collected automatically
Runtime cost	Small, spread across every assignment	Periodic, can cause pauses

A good closing line: “Both are automatic, but with ARC I still have to think about ownership; with a GC I think more about allocation pressure and pause times.”

With a value type, the variable holds the data itself. Assigning it or passing it to a function makes a copy, and changing the copy never affects the original. With a reference type, the variable holds a reference to an object; assignment copies the reference, so both variables point to the same object.

struct Point { var x = 0 }        // value type
final class Counter { var n = 0 } // reference type

var a = Point(); var b = a; b.x = 5      // a.x is still 0
let c = Counter(); let d = c; d.n = 5    // c.n is now 5

Per language:

• Swift: struct, enum, tuples, String and the collections are values (collections use copy-on-write, so copies are cheap until changed). class and actor are references.
• Kotlin and Java: only primitives (Int, int, Boolean…) behave as values. Everything else, including Kotlin data class and Java record, is a reference type. They get value-like behavior when they’re immutable.

Why it matters: shared mutable objects cause “action at a distance” bugs, where code in one place changes data another place is using. Values (or immutable objects) make that impossible and are safe to share between threads.

Java splits exceptions in two:

• Checked (extend Exception): the compiler forces callers to catch them or declare throws. Meant for recoverable situations the caller should plan for, like IOException.
• Unchecked (extend RuntimeException): no enforcement. Meant for programming errors, like NullPointerException or IllegalArgumentException.

The idea is good, but in practice checked exceptions don’t work with lambdas (stream().map(this::load) can’t throw IOException), they leak implementation details up through layers, and they encourage empty catch blocks. Modern code often wraps them at the edges (UncheckedIOException), always keeping the original as the cause.

Kotlin has no checked exceptions at all. For expected failures, Kotlin code often returns null or a sealed result type instead, and uses @Throws so Java callers can catch exceptions.

Swift takes a middle path: throws in the signature and try at every call site make failure visible, but the error type is any Error unless you use typed throws (throws(ParseError), Swift 6). Swift errors are ordinary return values under the hood, so throwing is cheap.

In all three, cancellation (CancellationError, CancellationException, InterruptedException) travels through the error path and must be propagated, not handled as a failure.

Type erasure: Java and Kotlin check generic types at compile time and drop the type arguments in the bytecode. At runtime ArrayList<String> and ArrayList<Integer> are the same class, so you can’t write x instanceof List<String>, new T(), T.class, or two overloads that differ only by type argument, and JSON libraries need a TypeToken/TypeReference to learn that a list holds Users. Kotlin’s inline fun <reified T> keeps T at the call site. Swift keeps generic types at runtime and can specialize generic code per type.

Variance: if Cat is an Animal, may a container of cats be used as a container of animals?

• Reading only (producer): yes, that’s covariance. Kotlin: List<out E>. Java: List<? extends Animal>.
• Writing only (consumer): the other way round, contravariance. Kotlin: Comparator<in T>. Java: List<? super Cat>.
• Both: neither; invariant. MutableList<Cat> isn’t a MutableList<Animal>, or you could add a Dog to a list of cats.

Java’s rule of thumb is PECS, producer extends, consumer super. Swift generics are invariant, with the standard collections special-cased ([Cat] converts to [Animal] safely because arrays are values).

Senior bonus: Swift’s some P is one hidden concrete type checked statically, while any P is an existential box with dynamic dispatch and possible heap allocation, so prefer generics and some in hot code.

Inheritance gives you code reuse and a subtype in one step, and that’s its problem: the subclass depends on how the parent is implemented. Change the parent (which methods call which) and subclasses can break without being touched. It also scales badly: notifications by channel × urgency × timing become ScheduledUrgentPushNotification and a dozen siblings.

Composition gives an object the parts it needs: a notification has a channel, an urgency and a timing. Each part varies on its own, is replaceable in tests, and adding a channel is one new type.

Inheritance is still right for a genuine, stable is-a relationship, or when a framework requires it (subclassing a view or an Activity). Even then, mark classes final (Kotlin’s default) unless they’re designed to be extended, and avoid calling overridable methods from constructors.

A closure (or lambda) is a function value that can use variables from the scope where it was created:

fun makeCounter(): () -> Int {
    var count = 0
    return { ++count }      // captures count; it lives on after makeCounter returns
}

What is captured differs by language. Swift, Kotlin and JavaScript/TypeScript capture the variable: if it changes later, the closure sees the new value, and the closure can change it. Swift’s capture list ([x]) takes a snapshot instead. Java lambdas may only use effectively final locals, captured by value, so changing state has to live in an object.

Why it matters: a closure keeps everything it captures alive. In Swift, a closure stored on self that uses self is a retain cycle (fix: [weak self]). On the JVM and in JavaScript, a callback registered with something long-lived (a singleton, a timer, a global event) keeps the whole screen alive until it’s removed.

A good unit test:

• Checks one behavior and is named after it, so a failure says what broke.
• Arranges input, acts once, asserts against an expected value worked out from the requirement, never recomputed with the code’s own formula.
• Covers the cases that find bugs: a normal case, boundaries on both sides (7 and 8 characters for an 8-character minimum), empty and invalid input, and error paths. Parameterized tests make that cheap.
• Is isolated and deterministic: slow or random dependencies (network, database, clock, randomness) are replaced with fakes passed in through the constructor, and no state is shared between tests, so it passes alone, together, in any order and at any time.
• Can fail: break the code once and watch it go red. Async tests must await their work, or they pass no matter what.

It tests behavior through the public API rather than private methods, so refactoring doesn’t break it.

Actors prevent data races: only one piece of actor-isolated code runs at a time. But they’re reentrant: when an actor method suspends at an await, the actor is free to run other calls, and when the method resumes, the state may be different.

actor ImageCache {
    private var images: [URL: Data] = [:]

    func image(for url: URL) async throws -> Data {
        if let cached = images[url] { return cached }
        let data = try await download(url)      // other calls run here
        images[url] = data                      // two callers can both reach this
        return data
    }
}

Ten rows asking for the same avatar all miss the cache before the first download finishes, so the same file is downloaded ten times. A read-modify-write across an await (let v = count; await …; count = v + 1) loses updates the same way.

Fixes:

• Don’t hold state across await: do the read-modify-write synchronously, or re-read after resuming.
• Record intent before suspending: store the in-flight Task in the dictionary before awaiting it, so later callers join it.
• Keep critical sections synchronous: if a change must be atomic, do it without suspension points.

Swift made actors reentrant on purpose: non-reentrant actors waiting on each other would deadlock. The trade-off is that you reason about each await as a place where the world can change.

When the scene goes to the background, the app gets a few seconds and is then suspended; later it may be terminated without notice. So first: save user data at .background.

Then pick the tool for the job:

• Finish something you started: beginBackgroundTask gives a short extra window (about 30 seconds, not guaranteed). Always end it, including in the expiration handler.
• Transfers: a background URLSession with file-based upload/download tasks. The system continues them while the app is suspended or terminated and relaunches the app when they finish.
• Periodic refresh: BGAppRefreshTask via BGTaskScheduler (or SwiftUI’s .backgroundTask(.appRefresh)): short, scheduled by the system based on usage, battery and network. Reschedule on every run.
• Heavy maintenance: BGProcessingTask, usually while charging and idle.
• Continuous features: background modes for audio playback, navigation/location, VoIP.

The system decides: earliestBeginDate is only a minimum, force-quit apps don’t get background time, silent pushes are throttled. So refresh on launch too and keep a persistent queue of pending work.

Tie the work to an owner whose lifetime matches the work:

• Android: viewModelScope (cancelled in onCleared()), lifecycleScope with repeatOnLifecycle(STARTED) for collecting flows only while visible, and collectAsStateWithLifecycle() in Compose.
• iOS: SwiftUI’s .task and .task(id:) (cancelled when the view disappears), structured async let and task groups, and stored Task handles cancelled in deinit or onDisappear for anything unstructured.

Cancellation is cooperative in both: it sets a flag and throws CancellationException / CancellationError at the next suspension point that checks. Networking and delay/Task.sleep check for you; long CPU loops need ensureActive() or Task.checkCancellation(). And it travels through the error path, so broad catch blocks (and Kotlin’s runCatching) must rethrow it, or the work keeps running and may show an error for a screen that’s gone.

Work that should outlive the screen (an upload the user already sent, a sync) belongs to an application-level scope, or better, to WorkManager on Android and a background URLSession or BGTaskScheduler on iOS, which also survive the process being killed.

Configuration change: rotation, dark mode, locale, font size or window size change. The Activity (and its composition) is destroyed and recreated in the same process. Fields and remember are lost; the ViewModel survives; rememberSaveable/onSaveInstanceState values are restored.

Process death: the app is in the background and Android kills the process to free memory, with no callback. When the user returns, Android recreates the last Activity and restores its saved instance state: SavedStateHandle, rememberSaveable, the navigation back stack. The ViewModel, singletons and caches are new and empty.

	Rotation	Process death
Fields, remember	Lost	Lost
ViewModel	Kept	Lost
SavedStateHandle, rememberSaveable	Kept	Restored
Database, DataStore	Kept	Kept

Design: keep data and in-flight work in the ViewModel, user input and ids in saved state, and important drafts on disk; reload data from saved ids. Test process death with adb shell am kill <package> while the app is in the background, or “Don’t keep activities”.

N+1 happens when code loads N entities with one query and then touches a lazy association on each, so Hibernate runs one extra query per entity:

List<Author> authors = authorRepository.findAll();          // 1 query
for (Author a : authors) {
    System.out.println(a.getBooks().size());                 // + 1 query per author
}

With 10 test rows nobody notices; with 5,000 authors it’s 5,001 round trips.

Fixes, depending on the use case:

• Fetch join or @EntityGraph: load the association in the same query (select a from Author a left join fetch a.books). Don’t combine a collection fetch join with paging: Hibernate then pages in memory.
• Batch fetching (hibernate.default_batch_fetch_size=50): lazy loads are grouped into where author_id in (…) queries, turning N+1 into N/50+1 without changing code.
• DTO projections: for read-only endpoints, select exactly the columns you need, often with aggregation (count(b)), and no entities at all.

Detection: set spring.jpa.open-in-view=false so lazy loading in the web layer fails loudly, enable Hibernate statistics or a datasource proxy in integration tests, and assert a maximum number of statements per request.

@SpringBootApplication includes @EnableAutoConfiguration, which loads the auto-configuration classes listed by every jar on the classpath. Each one is guarded by conditions:

• @ConditionalOnClass: only if a library is present (Jackson, a JDBC driver, Redis).
• @ConditionalOnMissingBean: only if you haven’t defined that bean yourself.
• @ConditionalOnProperty: only if a setting is on.

So adding spring-boot-starter-web gives you Tomcat, Spring MVC and a configured JSON mapper without any code.

Changing it, from lightest to heaviest:

1. Properties in application.yml (server.port, spring.jackson.*).
2. Customizers, beans that adjust what Boot builds (Jackson2ObjectMapperBuilderCustomizer, RestClientCustomizer).
3. Your own bean of the same type. The auto-configured one backs off completely, and its properties stop applying, which is a common surprise.
4. Excluding an auto-configuration (@SpringBootApplication(exclude = …)), rarely needed.

To see what happened and why, run with --debug for the conditions evaluation report, or call /actuator/conditions.

Authentication answers who is calling. The app opens the login page of an identity provider in the system browser (authorization code flow with PKCE), gets an authorization code, and exchanges it for a short-lived access token (a JWT, minutes) and a refresh token (stored in the Keychain or Keystore). Every API call sends Authorization: Bearer <token>.

The backend is an OAuth2 resource server: Spring Security verifies the signature with the issuer’s public keys and checks expiry, issuer and audience. No valid token means 401.

Authorization answers what they may do, at two levels:

• Per endpoint: scopes or roles (hasAuthority("SCOPE_orders:write")). A known user without permission gets 403.
• Per object: a valid token for customer A must not read customer B’s order. Scope every query to the caller, findByIdAndCustomerId(id, jwt.getSubject()), and return 404 for objects that aren’t theirs. Skipping this is IDOR, the most common API vulnerability.

Trade-offs worth mentioning: a JWT can’t be revoked before it expires, so keep access tokens short, revoke refresh tokens on logout, and rotate them on use.

What 137 means: 128 + 9, the process got SIGKILL. In Kubernetes the pod status shows OOMKilled: total process memory crossed the container’s memory limit and the kernel killed it instantly, so there’s no Java stack trace.

Why it happens: the JVM uses more than its heap. Metaspace (100–200 MB for a Spring app), the code cache, about 1 MB per platform thread stack, direct buffers for Netty and HTTP clients, and GC structures all live outside -Xmx. A config like -Xmx2g in a 2 GiB container is guaranteed to get killed once the heap fills up.

How to investigate:

1. Confirm OOMKilled in kubectl describe pod and look at the memory graph: a slow climb (leak or growing cache) or a spike (a large request, a burst of threads)?
2. Check the JVM flags actually in effect (jcmd <pid> VM.flags) and the heap size the JVM picked.
3. Enable -XX:NativeMemoryTracking=summary and compare jcmd <pid> VM.native_memory summary with the container’s memory usage to see which area grows.
4. If the heap itself grows, take a heap dump (-XX:+HeapDumpOnOutOfMemoryError, or jcmd GC.heap_dump) and look for the leak.

Fix: size the heap as a percentage, -XX:MaxRAMPercentage=75, so a quarter of the limit is left for everything else; add -XX:+ExitOnOutOfMemoryError for clean restarts; cap thread pools and off-heap caches. Only raise the limit once you know what the memory is for.

1. Is the time in this JVM? Open traces of slow requests. If the time is in a database query or a downstream call, the JVM isn’t the problem.

2. What happens at the same moment? Put p99 latency next to:

• GC pause times (jvm.gc.pause, GC logs). A periodic multi-second Pause Full on G1 means concurrent marking fell behind, often because of humongous allocations.
• CPU usage and CPU throttling in the container.
• Connection pool and thread pool waits (HikariCP pending threads, Tomcat busy threads).

3. Profile. Record with Java Flight Recorder (around 1% overhead, can run continuously) or async-profiler during a spike. Read the CPU and allocation flame graphs by width; check lock contention and thread states for time spent waiting.

4. Fix in order of payoff:

1. Fix the workload: hot allocations, needless work, N+1 queries, oversized responses.
2. Size the heap and container correctly.
3. Choose the collector: G1 by default, ZGC for strict latency or very large heaps.
4. Change single flags, measuring before and after each one.

What a strong answer adds: allocation rate drives GC frequency, so reducing allocation often helps more than GC tuning. JIT warm-up explains slow first requests after a deploy, and readiness gating hides it from users.

A class depends on other objects to do its job: a repository, an API client, a clock. With dependency injection, it doesn’t create them; it receives them, usually through the constructor.

// Without DI: the ViewModel builds its own repository and can't be tested with a fake
class ProfileViewModel : ViewModel() {
    private val repository = ProfileRepository(RetrofitClient.api)
}

// With DI: the repository is passed in
class ProfileViewModel(private val repository: ProfileRepository) : ViewModel()

Why it helps:

• Testing. In a unit test you pass a fake repository that returns fixed data, with no network.
• Flexibility. You can switch from Retrofit to Ktor, or from a real clock to a fixed one, without touching the class.
• Clear dependencies. The constructor shows exactly what the class needs.

Frameworks like Hilt, Koin or Spring create and wire the objects for you, which helps in big apps. But passing a parameter to a constructor is already dependency injection.

A constructor with eight parameters, half of them optional and two of them booleans, is unreadable and easy to call wrong. A builder gives every setting a name, lets you skip what you don’t need, and creates the object in one build() call that can validate the whole combination:

HttpRequest request = HttpRequest.newBuilder(URI.create(url))
    .timeout(Duration.ofSeconds(10))
    .header("Accept", "application/json")
    .build();

In Kotlin and Swift, named arguments with default values solve most of this directly:

val notification = AppNotification(title = "Shipped", body = "Arriving Tuesday", priority = Priority.HIGH)

Builders are still the right tool when:

• Java code calls your Kotlin API (Java doesn’t see default arguments).
• The object is assembled step by step over time (a parser, a multi-screen form).
• You want a DSL: Kotlin type-safe builders, Swift result builders.
• You publish a library and need to add options later without breaking binary compatibility (adding a parameter to a public constructor or data class does).

Whatever the form, keep the result immutable: validate in build(), and copy collections instead of handing over the builder’s own list.

Inheritance adds behavior at compile time, one combination per class: CachedRepository, LoggingCachedRepository, RetryingLoggingCachedRepository… A decorator implements the same interface as the object it wraps, adds one behavior, and delegates to the inner object, so behaviors compose at runtime:

val repo: ProductRepository = Logging(Caching(Retrying(ApiProductRepository(api))))

Use decorators when:

• several cross-cutting behaviors should combine freely (cache, log, retry, metrics, auth),
• you can’t or shouldn’t modify the original (third-party, final, shared),
• you want each behavior testable alone with a fake inner object.

Things to get right:

• Order is semantics: a cache outside a logger hides hits from the log; a retry outside a timeout gives each attempt its own timeout.
• Every method is wrapped: a generic retry around an interface that includes charge() can double-charge on timeouts.
• Composition over inheritance: subclassing a concrete class to “decorate” it breaks when the base class calls its own overridable methods (HashSet.addAll calling add), the fragile base class problem. Kotlin’s by delegation avoids it but forwards un-overridden methods straight to the inner object.

SOLID is five rules of thumb for keeping code changeable:

	Principle	In one line
S	Single responsibility	A class has one reason to change: one group of people asks for its changes.
O	Open/closed	Add new behavior by adding code (a new rule, a new class), not by editing code that works.
L	Liskov substitution	A subtype must work everywhere its parent is expected, with no surprises.
I	Interface segregation	Small interfaces shaped by what each client needs.
D	Dependency inversion	Business code defines the interfaces it needs; databases and vendors implement them.

An example worth giving: a checkout class created its own payment client, so tests hit the real provider. Introducing a PaymentGateway interface owned by checkout, passed in through the constructor, fixed testing (D) and later made adding a second provider a new class instead of an edit (O).

Close with judgment: the principles pay off where code actually changes. Abstracting a closed, stable set of cases (three order states) adds indirection without benefit.

Both patterns put behavior behind an interface and let a context delegate to the current implementation. The difference is who switches it, and why:

• Strategy: the client picks an algorithm (standard vs express shipping, a sorting rule) and passes it in. The strategies don’t know about each other, and the choice usually doesn’t change during the object’s life.
• State: the context’s behavior depends on its current state, and the states themselves decide the next one as events arrive (a document goes Draft → In review → Published; a player goes loading → playing → paused). Each state object handles every event, and actions not allowed in a state are refused there.

A quick test: if your “strategies” start returning or installing the next strategy, you’ve built a state machine. In modern code, many state machines are an enum or sealed type with one transition function (state, event) → next state, which is the State pattern without a class per state.

MVVM: the ViewModel exposes observable state (often several properties, or one UI state object) and methods the view calls (onEmailChange, logIn). It has no reference to the view, so it survives screen recreation and is testable with fakes. Changes can happen in any method.

MVI: the screen has one immutable state. The view sends intents; a pure reducer computes (state, intent) → state; side effects (network, storage) run outside the reducer and report back as new intents. Every change goes through one function, in one direction, which makes bugs traceable (log the intents) and transitions trivially testable.

Choosing: MVVM for small and medium apps where speed of development matters; MVI (or TCA, Redux) when many people work on many screens, when you need consistent conventions and traceability, or when state transitions are complex. Either way, keep observable state immutable, and treat one-off events (navigation, toasts) separately from state, consumed by id or delivered as a non-replayed stream.

A reliable way to do it, out loud:

1. Name the inputs. “n is the number of orders, m is the number of products.” Different inputs get different letters.
2. Cost of each step, including library calls: contains on a list is O(n), sort is O(n log n), a hash map lookup is O(1) on average, removing from the front of an array list is O(n).
3. Combine. Nested loops multiply, steps that follow each other add.
4. Simplify. Drop constants and keep the dominant term: O(2n + n log n) is O(n log n).
5. Space. Count extra memory: sets, maps, copies, and the recursion depth.

Then say it as one sentence with the trade-off: “This is O(n) time and O(n) space because of the hash set; the sort-based version would be O(n log n) time with less extra memory.”

If the interviewer pushes, distinguish worst case (a hash map degrading with collisions), average case, and amortized cost (dynamic-array appends are O(1) amortized because resizes are rare).

• A stack is LIFO, last in, first out: push and pop at the top, like a pile of plates. Used for undo, the back button, matching brackets, evaluating expressions, and depth-first search. Function calls themselves live on the call stack, which is why very deep recursion can overflow.
• A queue is FIFO, first in, first out: add at the back, remove from the front, like a line at a shop. Used for tasks in arrival order, message processing, rate-limited work, and breadth-first search, which finds shortest paths in unweighted graphs.

Both have O(1) operations at their ends, but only with the right type:

	Stack	Queue
Swift	Array (append, popLast)	Deque from swift-collections
Kotlin	ArrayDeque (addLast, removeLast)	ArrayDeque (addLast, removeFirst)
Java	ArrayDeque (push, pop)	ArrayDeque (offer, poll)

A strong answer also mentions the monotonic stack for “next greater element” problems, and bounded queues for backpressure between producers and consumers.

The trick is to not stop when you find the target. Search for the boundary instead: the first index whose element is >= target.

fun firstOccurrence(nums: IntArray, target: Int): Int {
    var low = 0
    var high = nums.size                  // half-open: the answer is in [low, high]
    while (low < high) {
        val mid = low + (high - low) / 2
        if (nums[mid] < target) low = mid + 1 else high = mid
    }
    return if (low < nums.size && nums[low] == target) low else -1
}

Why it works: everything before low is smaller than the target, everything from high on is >= the target, and every branch shrinks the range, so the loop ends with low == high at the boundary. Then one check tells you whether the target exists.

The last occurrence is the first index with an element > target, minus one, and the count of the target is the difference between the two boundaries, both in O(log n).

Worth mentioning: Java’s Arrays.binarySearch and Kotlin’s binarySearch return any matching index when there are duplicates, and Swift’s standard library has no binary search, so in an interview you write the lower bound yourself.

BFS (a queue) explores by distance from the start: everything one step away, then two, and so on. Use it for:

• the shortest path in an unweighted graph or grid (fewest moves),
• anything per level (level order, the minimum depth of a tree),
• multi-source spreading (the nearest exit from every cell, rotting oranges).

DFS (recursion or an explicit stack) goes as deep as possible first. Use it for:

• exploring and counting connected components (islands),
• cycle detection and topological sort (with three states in directed graphs),
• tree problems where a node combines its children’s results (height, diameter, lowest common ancestor), and backtracking.

Space: BFS holds a frontier, O(width); DFS holds a path, O(depth). A balanced tree of a million nodes is about 20 deep but 500,000 wide at the bottom, so DFS is far lighter there; a long chain is the opposite, and a recursive DFS can overflow the stack, so use an explicit stack for big or untrusted inputs.

On graphs, both need a visited set; in BFS, mark nodes when they’re added to the queue. And BFS’s shortest path only counts edges: with weights, use Dijkstra.

A recipe that works for most interview DP problems:

1. Recognize it: the brute force is recursive and solves the same subproblems repeatedly (count paths, minimum cost, maximum value, number of ways).
2. State: the smallest description of a subproblem the rest depends on, like “the fewest coins for amount a” or “the edit distance between the first i and j characters”.
3. Transition: ask what the last decision was. “The last coin was c” gives fewest(a) = 1 + min over c of fewest(a − c).
4. Base cases: the trivially known states (amount 0, empty strings).
5. Order and answer: compute states after their dependencies; say which state is the answer.

Then implement it top-down (the recursion plus a shared memo, natural to write, visits only reachable states) or bottom-up (a table filled in order, no recursion depth issues, easy to space-optimize). Complexity is the number of states times the work per transition.

Say the trade-offs: rolling arrays reduce space (often O(n·m) to O(m)) but make reconstructing the actual choices harder; sentinels like Int.MAX_VALUE overflow when you add to them; and greedy is tempting but needs a proof, while DP doesn’t.

A greedy algorithm makes the best-looking choice at each step and never revisits it. It’s correct when two things hold:

• Greedy-choice property: some optimal solution starts with the greedy choice.
• Optimal substructure: after that choice, the rest is the same kind of problem, solved by the same rule.

You justify it with an exchange argument: take any optimal solution, swap its first choice for the greedy one, and show it doesn’t get worse. Interval scheduling (keep the meeting that ends earliest) is the classic example.

Greedy fails when an early choice can block a better combination. Coins [1, 3, 4] and amount 6: biggest-first takes 4 + 1 + 1 (3 coins), but 3 + 3 uses 2. 0/1 knapsack fails the same way. Those problems need dynamic programming, which considers every choice and reuses the answers to smaller subproblems.

In practice: state the greedy rule, try two or three tiny counterexamples, and only commit to greedy if you can explain why swapping never helps.

1. Sort by start. After that, an interval can only overlap the last one you’ve merged.
2. Walk once. If the current interval starts at or before the last merged end, they overlap: set the end to max(last end, current end). Otherwise, append it as a new interval.

fun merge(intervals: Array<IntArray>): List<IntArray> {
    val merged = mutableListOf<IntArray>()
    for (cur in intervals.sortedBy { it[0] }) {
        val last = merged.lastOrNull()
        if (last != null && cur[0] <= last[1]) last[1] = maxOf(last[1], cur[1])
        else merged.add(cur.copyOf())
    }
    return merged
}

Edge cases worth naming: nested intervals ([1, 10] and [2, 3], the reason for max), touching intervals ([1, 4] and [4, 5]: merged if closed, separate if half-open; ask), an empty input, and comparator overflow on the JVM if you sort with a[0] - b[0]. Sorting is O(n log n), the walk O(n).

1. Clarify: who is limited (user, API key, IP, tenant), which endpoints, the limits, whether bursts are OK, the scale, and the latency budget.
2. Algorithm: a token bucket (bursts up to the bucket size, then a steady rate) or a sliding window counter (two counters per key, close to exact). Mention the fixed window’s 2× burst at boundaries and the sliding log’s memory cost.
3. Where: in the API gateway, before traffic reaches services, with shared counters in Redis so limits hold across all instances. Update them atomically with a Lua script, with expiry in the same step.
4. Response: 429 Too Many Requests with Retry-After and RateLimit-* headers; clients back off with jitter.
5. Failure: short timeouts to Redis; fail open for most endpoints, fail closed for abuse-sensitive ones like login.

At scale, trade exactness for latency: gateways lease tokens in batches for hot keys, and regions enforce shares of a global limit instead of coordinating on every request.

• Reads and writes go to the local database (Room, SwiftData). The UI observes it, so it works offline and updates instantly.
• Writes are also recorded in an outbox in the same local transaction. A sync worker pushes it when there’s a network, in order, with client-generated UUIDs and idempotent requests (PUT /items/{id} or an Idempotency-Key), so retries after lost responses don’t duplicate.
• Pulls use a server-issued, commit-ordered cursor: GET /changes?cursor=… returns created, updated and deleted items (tombstones), and the new cursor is saved in the same transaction as the applied changes.
• Conflicts are detected with versions (each write carries the version it was based on) and resolved per field: last write wins by server order for low-stakes fields, merges for independent fields, domain rules where they exist, CRDTs for collaborative text. Make outcomes visible to the user.
• Platform: WorkManager with network constraints and backoff on Android; sync on foreground plus BGAppRefreshTask on iOS; real-time channels (WebSocket, silent push) only trigger the normal pull.

Senior follow-ups: tombstone retention and full resyncs, migrating unsynced outbox entries across app versions, partial sync for large datasets, and monitoring outbox size and sync failures per app version.

I use the same six steps for any question, and say them out loud so the interviewer can follow:

1. Requirements (about 5 minutes). Functional: the two or three main features. Non-functional: scale, latency, availability, how fresh data must be. I write them down and agree on what’s out of scope.
2. Estimates (about 5 minutes). Requests per second (per day ÷ 100,000, times 2 to 5 for peak), storage per year, read/write ratio, and what the numbers mean: read-heavy, so cache; terabytes of files, so object storage.
3. API and data model. The main endpoints and records.
4. High-level design. Load balancer, stateless servers, cache, database, queues where work can be delayed. I trace each main use case through it.
5. Deep dives. The one to three parts that are hard for this problem, explained as trade-offs: what I gain, what I give up, and why it fits the requirements.
6. Wrap-up. Bottlenecks at 10× scale, failure cases, what I’d monitor.

If the interviewer steers me somewhere, I follow; they’re showing me what they want to evaluate.

Scale in response to bottlenecks, roughly in this order:

1. Separate the database from the app server, and add the obvious indexes.
2. Stateless app servers behind a load balancer: sessions in Redis or tokens, files in object storage, scheduled jobs run once. Health checks (readiness) and graceful shutdown make deploys and failures invisible.
3. Caching: a CDN for static and public content, Redis for hot reads (cache-aside with TTLs), HTTP caching headers for clients.
4. Read replicas for read-heavy load, with read-your-writes handling for users who just changed something.
5. Queues for slow or unreliable work (emails, images, third-party calls), with idempotent consumers.
6. Partitioning (sharding) when writes or data size outgrow one primary, with a shard key that spreads load and keeps hot queries on one shard.

At every step, watch the next bottleneck: database connections (pool size × servers), write throughput, hot keys. Many products never need step 6.

Queues are effectively at least once: a consumer can finish the work and crash before acknowledging, a Kafka rebalance can resume from an older offset, or a retry can race with a slow first attempt. So the consumer must make a second delivery harmless:

• Ack after the work, never before (acking first loses messages).
• Record processed ids: insert the message id (or a business key like paymentId) into a processed_messages table with a unique constraint, in the same transaction as the side effect. A duplicate fails the insert or finds the row and does nothing.
• Prefer naturally idempotent operations where possible: “set status to paid” or an upsert by key instead of “add 10 EUR”.
• Publish reliably: the producer writes events to an outbox table in the same transaction as its own change, and a relay publishes them, so events are never lost and duplicates are handled by the idempotent consumer.

Kafka’s exactly-once semantics cover Kafka-to-Kafka processing; side effects in your own database still need this.