Herald.

In Swift, static and class both create type-level members, but only class supports overriding in subclasses. Use static when a behavior should be identical for every subclass; use class when you want to opt into dynamic dispatch. Getting this wrong can either lock down a method you meant to open or open a method you meant to seal.

- class members are dispatched dynamically, so a subclass can override and swap in new behavior when it is read through the base type.
- static members are dispatched directly, which means no runtime lookup, a tiny performance win, and no chance for a subclass to change the behavior.
- Protocol requirements declared with static can technically be satisfied by class in a conforming class, and that's the right call when you still want subclass overrides.
- In generic code, static is resolved at compile time, so two calls to T.self may end up invoking different methods than you expect if you mirror the API with class.

A common interview trap: a protocol declares static func make(), and the candidate writes class func make() in the type. That actually conforms — and it's the only way to allow overriding. The subtler problem is class properties: an overridden class var in a subclass must always be a *computed* property, not stored, or the compiler will reject you.

Swift's ARC deallocates an object when the last strong reference to it goes away. If two objects hold each other strongly, they create a retain cycle and leak forever. weak and unowned are the two ways to break that cycle, and each answers a different lifetime question: can this ever be nil, and who outlives whom?

- weak references are always optional and are automatically nil'd when the object deallocates. Use it for a delegate or a parent reference, because those can legitimately disappear while the child is alive.
- unowned references are non-optional and trap the moment you access them after deallocation. Use it when the referencing object is guaranteed to have the same lifetime — or a shorter lifetime — than the referenced object.
- In closures, the default capture is strong. Writing [weak self] moves the capture to an optional self?, and [unowned self] keeps the closure's self non-optional but never retains.
- The golden rule: if the captured object's lifetime is not obviously longer, use weak. If the only alternative is a guaranteed crash from a dangling unowned, use weak and early-exit.

Every iOS engineer knows weak is optional and unowned is not. The deeper question is *lifetime*: unowned promises that the referencing object cannot outlive the referenced one, so no optional is needed. If you get that promise wrong, the app crashes in release — not in tests, because timings differ. Also, weak requires a var, not let, because the reference slot must be updated when the object deallocates.

@MainActor is a global actor that serializes access to everything it annotates. In practice, it means any method or property marked with it runs on the main thread, and Swift's compiler enforces that before it gets to runtime. You get the safety of DispatchQueue.main.async without the manual bookkeeping, and a compile error instead of a race condition.

- Global actor isolation marks a type, method, or closure as isolated to MainActor.self; every synchronous access from a non-isolated context becomes a compile-time error, not a crash.
- Task { @MainActor in ... } runs its body on the main actor and is the cleanest replacement for DispatchQueue.main.async — but it's also a *suspension* point, so code after it may run after other work interleaves.
- nonisolated is the escape hatch for read-only pure functions; use it to keep expensive computation off the main thread instead of making the whole method hop.
- @MainActor on a property wrapper like @StateObject propagates isolation, which is why a SwiftUI view can call viewModel.foo() without manually dispatching to the main queue.

The deadliest mistake is using Task.detached and then assuming it runs off the main thread — Task.detached does not change the actor context unless you explicitly hop. If you call a @MainActor function from a plain Task {}, you're still hopping to the main actor, so a long synchronous loop in there will still freeze the UI. And a semaphore.wait() on the main thread deadlocks if the signal comes from a @MainActor task waiting for that very main thread.

Swift's Array, Dictionary, and Set are value types, but duplicating on every assignment would be catastrophically slow for large collections. Copy-on-write (CoW) shares the underlying storage between two copies — and only copies the moment one of them mutates. That gives you the mental model of value semantics with the performance of reference storage.

- isKnownUniquelyReferenced is the gatekeeper: if the refcount is 1, Swift mutates the shared buffer in place; if not, it allocates a fresh buffer and copies elements.
- Bridging to Objective-C can defeat CoW: an NSArray cast to [Any] may keep the entire Swift array alive for the duration of an autoreleasepool, destroying uniqueness checks.
- Custom CoW uses a reference-type Storage box plus a mutating accessor that calls ensureUnique() before writing — not a value type with direct field mutation.
- The optimizer can eliminate many copies entirely with -O and inlining, but only if the compiler can prove uniqueness at compile time.

A silent trap is using withUnsafeBufferPointer and holding onto the resulting pointer after the array is mutated — even if the array appears unique at the time, the next append can reallocate and invalidate the pointer. Also, a for loop that captures the array in a closure every iteration destroys uniqueness, turning every mutation into a full O(n) copy: the classic O(n²) performance bug. And isKnownUniquelyReferenced returns false for *any* additional reference, including one held by a surrounding autoreleasepool.

Unlike UIKit, SwiftUI doesn't give you a viewDidLoad equivalent; it decides when views are created, updated, and destroyed. The lifecycle is driven by state, not by view events, which is why onAppear, onDisappear, and scenePhase act more like checkpoints than strict callbacks. Knowing this model is the key to avoiding networking calls that fire five times and animations that reset your application state.

- onAppear fires when a view is inserted into the view tree — not necessarily when it's fully visible, and definitely not once per screen. Use it to kick off a lightweight task, like setting a default value or starting an animation.
- scenePhase is the app-level lifecycle: @Environment(\.scenePhase) gives you .active, .inactive, and .background, and you switch on it inside .onChange(of:) to pause or resume work.
- task modifier launches an async operation that SwiftUI automatically cancels when the view disappears — the modern replacement for manually guarding onDisappear.
- id(_:) is the nuclear reset button: changing the identity causes SwiftUI to treat the view as brand new, destroying local @State and firing onAppear again. Use it to force a reset, not to fix a lifecycle bug.

A List recycles rows, so a row's onAppear can fire repeatedly as it scrolls in and out of visibility — that's why people use .task on the row's data, not a network call. A deeper trap: onDisappear fires when a view is removed from the window, which also happens on every navigation push if the previous view is removed from the hierarchy. And if you use .onAppear to restore scroll position, you'll fight the framework every time SwiftUI decides to re-create the view.

Many greedy algorithms require ordering the input before making choices. Sorting lets you *grab the best candidate first* — whether it's the smallest, largest, or most urgent — and avoids re-scanning the entire data each time. That one sort() call often turns an O(n^2) mess into an O(n log n) solution.

- Sort by key – decide whether to sort by value, deadline, or profit. For example, to feed the most children with limited cookies, sort both the greedy kids and the cookie sizes.
- Take the immediate next – after sorting, a single pass makes the choice that seems best right now. This works because the ordering guarantees you never regret a smaller cookie later.
- Stop early – if you can discard the rest of the input once a condition is met, even better. The greedy choice property makes early termination safe.
- Code rhythm – sort one or both arrays, then a while or for loop advances pointers based on a comparison.

A common trap is sorting by the wrong key — for intervals, sorting by start time instead of end time breaks the entire strategy. Another trap is modifying the input unexpectedly; interviews often check if you realize you're allowed to sort the original array, but sometimes you need a copy. And beware of numeric vs lexicographic sorting — Python's default handles numbers fine, but for tuples you must be explicit with key=.

When you need to pack items into fixed-capacity containers, a greedy two-pointer strategy often works. Sort the items; pair the lightest with the heaviest, and if they fit together, ship them together; otherwise the heavy one goes alone. This balancing act directly minimizes the count of containers.

- Sort ascending – order by weight so the extremes become easy to compare.
- Pair lightest+heaviest – if their sum fits in the limit, ship them together and move both pointers inward.
- Heavy goes solo – if not, the heaviest exceeds any remaining capacity, so it must ship alone; move the right pointer only.
- Count and repeat – each iteration consumes at least one item, so the loop runs exactly once per item.
- Think of proof – the greedy choice is safe because if the heaviest can't pair with the lightest, it can't pair with anyone.

Forgetting that the left pointer also advances depends on whether they pair. Another trap is assuming everyone can be paired: when weights are large, the heavy item may solo. And always verify you didn't accidentally use a 0-index vs 1-index mismatch in your pointer loop.

In some greedy problems, you may later find a better set of tasks after an earlier pick. Instead of backtracking, keep a max-heap of chosen items and, when total duration exceeds a deadline, drop the longest task so far. This is why Course Schedule III can be solved in O(n log n).

- Sort by deadline – process courses in increasing deadline so constraints feel local.
- Greedily pick – always take the current course, add its duration to the running total, and push its duration onto a max-heap.
- Check current total – if the total duration exceeds the current deadline, you must drop one course. The best candidate to drop is the one with the longest duration — it frees the most time with the least sacrifice.
- Pop and move on – pop from the heap, subtract from total, and continue. The heap size at the end is the maximum number of courses you can finish.
- Why safe? – dropping the longest course minimizes total time while preserving the course count, and because we process by deadline, any completed prefix is always feasible.

The max-heap is implemented in Python by pushing negative durations; forgetting the negative sign turns it into a min-heap. Also, the drop decision must happen after pushing the new course — otherwise you might drop the same course you just added. Sorting by deadline is crucial; if you sort by duration, the whole argument collapses.

Some greedy problems require respecting constraints from both sides of a sequence. The classic example is assigning candies to children: each child with a higher rating than a neighbor must get more candies than that neighbor. A single pass can only satisfy one side; a two-pass greedy (left-to-right then right-to-left) handles both.

- Initialize all to 1 – every child starts with one candy, satisfying the baseline.
- Left to right – whenever the current rating > previous, set candies[i] = candies[i-1] + 1. This satisfies all left-side constraints.
- Right to left – whenever the current rating > next, set candies[i] = max(candies[i], candies[i+1] + 1). This now satisfies right-side constraints without violating the left side.
- Sum and return – the sum of candies is minimal because each local increase is forced by the constraints.
- Why minimal? – each child's candy count is exactly the maximum chain of increasing ratings to the left or right, so no less is possible.

Skipping the second pass is tempting, but then the order between children of equal rating with a peak on the right is wrong. The second pass must use max, and you should handle the boundary indices carefully to avoid out-of-range. Also, this greedy only works when the constraints are simple inequalities between adjacent elements.

When asked to schedule the maximum number of non-overlapping intervals, always pick the interval that ends *earliest*. This simple rule leaves the most room for the rest of the intervals. It's the foundation of interval scheduling and proves the greedy choice property beautifully.

- Sort by finish time – ignoring start time for the initial sort is counterintuitive but crucial.
- Take the first interval – the earliest finish is guaranteed to be part of some optimal solution, so you can safely select it.
- Skip conflicts – after selecting an interval, skip all intervals that start before the current finish time.
- Repeat – the next interval to select is the earliest-finishing one that starts after the current end.
- Visualize – think of releasing a throwaway anchor at the current end; every future interval must start after it.

The >= operator matters: if one interval ends exactly when another starts, they are considered non-overlapping. Another trap is mutating the input list by sorting a list of tuples incorrectly (default sorts by start). And beware of negative time or floating-point timestamps; sort with key=lambda x: x[1] explicitly.

Dockerfile instructions produce layers, each one a delta on top of the last. When you rebuild, Docker reviews each layer and reuses cached layers if the instruction and any files haven't changed. This is why your apt-get install step only runs once, unless a line above it changes. Understanding layers is the difference between bloated builds and CI-ready pipelines.

- Order matters: each Dockerfile command creates a layer, and if a command hasn't changed since the last build, Docker reuses it. A single change near the top invalidates every later layer.
- COPY invalidates based on file checksums: Docker checks file contents and metadata for all files in the context for that COPY, not just the path list.
- RUN commands are cached blindly: unless you provide a --mount=type=cache, Docker won't know if remote package repos changed—cached apt lists are a classic cause of stale installs.
- Squash or multi-stage can merge layers, but ordinary builds keep them visible to the layer cache.

The top mistake is copying the entire app (COPY . .) before installing dependencies, which forces a full reinstall on every code change. The other trap is assuming RUN apt-get update && apt-get install -y python3 is stable—it can reuse outdated package indexes, or miss security fixes. Interviewers love asking why a build is slow; the answer is almost always layer ordering and cache busting.

When a container listens on port 8080, it's on the container's network namespace, not your host. Docker's default bridge network gives each container an IP on an internal subnet, and you publish ports with -p to create NAT rules. With overlay networks, containers on different hosts communicate without publishing ports at all. This matters because "it connects locally" is a lie the moment you add a second container.

- Bridge: Docker creates a virtual bridge (docker0), and each container gets a veth pair on a private subnet. Outbound traffic gets NATed, inbound only via published ports.
- Host: the container shares the host network namespace, so no NAT and no IP forwarding. Great for low-latency daemons, but every port conflict is yours to manage.
- Overlay: used by Swarm or Kubernetes; a VXLAN tunnel encrypts and routes traffic between hosts, and containers resolve each other via DNS.
- User-defined bridges (not the default bridge) give automatic DNS resolution between containers, so redis resolves to the redis container's IP.
- Publishing with -p binds on the host IP and forwards to the container, but localhost:* only works on the host itself, not inside another container.

The classic bug is a frontend container trying to talk to localhost:3000 for the API, but localhost inside the frontend container is itself. Another is relying on a container's IP, which changes on every recreate; Docker's embedded DNS is the stable option. Conversely, when using network_mode: host, containers lose DNS aliasing and -p port publishing becomes meaningless—interviewers often check if you understand that Host mode bypasses Docker's NAT.

A multi-stage Dockerfile contains several FROM statements, and each one creates a separate build stage. You can copy artifacts from earlier stages into the final stage without any of their intermediate files. This solves the old either-build-the-app-or-keep-it-small dilemma, and it's the standard way to produce production images under 100MB for compiled languages.

- Start with a heavy build image (maven:3.9 or golang:1.22) in the first stage; it can contain compilers, headers, and package caches.
- Compile or assemble the application there, producing a binary, jar, or bundled asset directory.
- Start a fresh, slim runtime stage with FROM eclipse-temurin:17-jre or FROM alpine:latest.
- Use COPY --from=0 to grab the built artifact and any needed config files, then define CMD or ENTRYPOINT.
- Platform-specific packages like glibc requirements on Alpine can bite; you may need -static or a distroless base.

People often copy the compiled binary but forget the shared libraries it needs, leading to a No such file or directory error when the binary starts. Another trap is using COPY --from=build /src/target but the path doesn't exist because the build produced a different artifact name; stage paths are relative to that stage's filesystem, not the build context. Interviewers look for whether you know that multi-stage does not automatically discard earlier layers—you still need to make the final stage lean by not copying caches.

In Linux, PID 1 has two extra responsibilities: it must reap orphaned child processes (zombies) and handle the container's signals, because the kernel applies special signal semantics to PID 1. In a normal init system (systemd, runit), that's handled for you; inside a container, if your main process is your app or a shell, it often doesn't. This becomes a real production issue with processes spawned by your app or scripts.

- Zombie reaping: when a child process exits, it remains in the process table until its parent calls wait(). If your app isn't the parent—say it runs bash -c as a subprocess—nobody calls wait(), so zombies accumulate and exhaust the PID table.
- Signal handling: PID 1 is special; Docker sends SIGTERM directly to PID 1, but other processes don't get it. Your app may ignore or not trap SIGTERM, so docker stop ends with SIGKILL after the timeout.
- Shell-based CMD: CMD ["/start.sh"] makes the shell PID 1, and shells typically do not forward signals or reap children. Using exec inside the script is crucial.
- The fix: run something like tini or the built-in --init flag (which launches tini) as PID 1, with your app as a child. Kubernetes does this via shareProcessNamespace or an init container.
- Node's included --init and Go with tini are common; in production, let your orchestrator manage PID 1.

Many applications don't fork children at all, so this feels like an academic concern—until you add a backup script, an exporter, or a job queue that spawns processes. The subtle bug is that zombie processes don't appear in CPU/memory metrics, so the system behaves fine until the PID table is exhausted and suddenly nothing can fork. Interviewers check if you know the difference between a normal process's signal handling and PID 1's—particularly that PID 1 doesn't get default SIGTERM behavior unless it explicitly handles it.

Docker Compose reads a compose.yaml file to build, connect, and run multiple containers together as one project. You declare services—web, db, redis—with build contexts, ports, volumes, and env vars, and Compose handles the networking and volumes automatically. It's the fastest way to make local development match production without writing a swarm setup.

- Declarative: all services, networks, volumes, and environment config live in one YAML file, so onboarding is docker compose up.
- Networking is free: Compose auto-creates a network and registers service names in DNS; web can reach db via db:5432.
- Hot reload: mount your source as a volume and let nodemon/webpack-dev-server restart the container process; no container rebuilds.
- Compose vs Kubernetes: Compose is a single-host orchestrator; it doesn't scale or provide HA, but it's the perfect local staging ground before moving to orchestrators.
- Extendable: compose overrides let you swap in prod-like services, like a managed Postgres vs local Postgres.

A common pain is that a host-mounted volume can have ownership 1000:1000, while the container runs as root; SQLite and cache files get permission errors, and you can't write to them. Also, services start in parallel by default, and a database that isn't ready will cause your app to crash—unless you add a depends_on with condition: service_healthy. Interviewers love asking why the app can't connect to the DB once at the beginning; it's usually a healthcheck gap.

Anti-monotonicity means that if an itemset is infrequent, every superset must also be infrequent. Apriori uses this to prune candidate itemsets before counting them, turning an exponential search into a level-by-level sweep. This matters because naively testing all combinations on real transaction data is computationally impossible.

- Generate candidates: Join frequent (k-1)-itemsets to create k-itemsets, e.g., {milk, bread} + {milk, eggs} → {milk, bread, eggs}.
- Prune with Apriori: Before scanning the DB, delete any candidate with an infrequent subset — this is the anti-monotonicity shortcut.
- Count supports: Scan the transaction list once and keep only candidates that pass min_support.
- Repeat: Move to k+1 until no new candidates survive.

The classic trap is thinking Apriori scales to long itemsets. It doesn't — if you have thousands of frequent 1-items, the pair candidate set explodes, and the repeated DB scans kill you. Interviewers want you to notice that the minimum support threshold is the real lever; lower support makes the lattice drastically wider.

- SMOTE fills the minority class with synthetic examples instead of duplicated rows.
- It helps models draw smoother decision boundaries and avoid overfitting to exact copies.
- It's a preprocessing step, not a classifier — use it before fitting any algorithm.

- Pick a seed: For each minority sample, find its k nearest minority neighbors (usually k=5).
- Choose a neighbor: Randomly select one of those neighbors.
- Interpolate: Generate a new point at a random point on the line segment between the seed and the neighbor: new = seed + λ(neighbor − seed), with λ ∈ [0,1].
- Repeat until balanced: Generate as many synthetic samples as needed to match the majority class.

The usual failure is running SMOTE before splitting into train/test. If you synthesize samples on the full dataset, then split, you get optimistic accuracy because the same synthetic points appear in both sets. Also, if the minority class has internal clusters, SMOTE's random neighbor choice can fill in empty space with unrealistic points.

In high-dimensional data, Euclidean distance concentrates around a single value, making nearest-neighbor queries almost random. The volume of space grows exponentially, so points become sparse and distances become uninformative. This is the curse of dimensionality, and it breaks clustering, outlier detection, and similarity joins unless you reduce dimensions or use specialized metrics.

- The unit cube: In 10 dimensions, 99% of the volume is near the boundary — the 'middle' is empty.
- Distance ratio: For random points, the ratio of max to min distance approaches 1 as dimensions grow, so nearest neighbor ≈ farthest neighbor.
- Sample required: To maintain the same density, the number of points needed grows exponentially — doubling dimensions requires squaring the data.
- Practical impact: k-means clusters become spherical shells, and LOF outlier scores become unstable.

The standard trap is assuming 'more features = better model.' Many people run PCA or t-SNE and call it a day, but t-SNE is for visualization, not feature extraction — it doesn't preserve distances. Interviewers will ask you to compare feature selection vs dimensionality reduction: one removes noise, the other transforms signal, and they are not interchangeable.

FP-Growth mines frequent itemsets by compressing the database into an FP-tree, then recursively mining the tree without generating candidate itemsets. It avoids the Apriori bottleneck of repeated full scans, and for most real-world transaction data it runs orders of magnitude faster. This matters when you have millions of transactions and thousands of items; candidate-based mining simply won't finish.

- First pass: Scan the database, count support for each item, discard infrequent ones, and sort items by descending support frequency.
- Second pass: Read transactions in that sorted order and insert them into a prefix tree. Each node increments a counter, and nodes with the same item are linked via header pointers.
- Recursive mine: For each item in the header table, take its conditional pattern base (the paths ending at that item), build a conditional FP-tree, and recursively extract frequent combinations.
- No candidate generation: You never create {a,b,c} just to count it; every pattern emerges from suffix propagation on the tree.

People think FP-Growth is a drop-in replacement, but it's memory-hungry because the tree and the conditional pattern bases can blow up if the data has long highly-overlapping transactions. Another subtle trap: if you change the minimum support, the header table changes and the tree structure changes — you can't reuse an old tree for a new threshold.

Data leakage happens when information from the future or from the test set leaks into training features. It can show up as a timestamp accidentally used in training, a categorical encoding fit on the full dataset, or a target-derived feature that sneaks into the feature matrix. The result: perfect offline metrics and a model that fails the moment it sees truly unseen data.

- Preprocessing before split: Fitting a scaler, imputer, or PCA on all data before train_test_split transfers statistics across the boundary.
- Temporal leakage: Using a future label column as a feature — e.g., a 'did_churn' flag in a row for a customer who later churned.
- Group duplication: Randomly splitting records instead of by user/patient/store, so the same entity appears in both folds and the model memorizes identity.

The biggest trap is thinking 'I'll just do cross-validation' automatically fixes leakage. It doesn't if preprocessing is nested outside the folds. Interviewers love giving you a pipeline where StandardScaler fits on the whole dataset before a train/test split and asking what AUC really means — the answer is optimistic bias, not 'good feature engineering.'