Zycus Interview Questions and Answers

Name features by what they let you delete. By 17 (LTS) you have records, sealed classes, text blocks, switch expressions, instanceof patterns and Stream.toList(). Java 21 (LTS) adds pattern matching in switch with guards, record patterns, virtual threads and sequenced collections such as getFirst() and reversed().

Only claim what you have used, and know your project's runtime version. A useful migration note: Java 17 strongly encapsulates JDK internals, so old libraries that reflect into them may need upgrading or --add-opens.

import java.util.List;

public class Modern {
    sealed interface Event permits Borrowed, Returned, Reserved {}
    record Borrowed(String isbn, int days) implements Event {}
    record Returned(String isbn, boolean damaged) implements Event {}
    record Reserved(String isbn) implements Event {}

    static String describe(Event e) {
        return switch (e) {
            case Borrowed b when b.days() > 14 -> "long loan of " + b.isbn();
            case Borrowed b -> "loan of " + b.isbn();
            case Returned(String isbn, boolean damaged) -> damaged ? "damaged " + isbn : "back " + isbn;
            case Reserved r -> "hold on " + r.isbn();
        };
    }

    public static void main(String[] args) {
        for (Event e : List.of(new Borrowed("A1", 21), new Borrowed("B2", 7),
                               new Returned("C3", true), new Reserved("D4")))
            System.out.println(describe(e));
    }
}

long loan of A1
loan of B2
damaged C3
hold on D4

What the interviewer is checking: Whether you have real, current Java experience and can say what each feature simplifies.

Likely follow-up: Why does the switch above need no default branch?

A virtual thread is a Thread whose stack lives on the heap and is scheduled by the JVM rather than the OS. When it blocks on I/O it parks and its carrier thread runs something else, so you can keep the simple one-thread-per-request style and still serve tens of thousands of waiting tasks.

Use them for blocking I/O work: HTTP calls, JDBC, queues. They do not speed up CPU-bound code. Never pool them; create one per task. In Spring Boot 3.2 and later, spring.threads.virtual.enabled=true switches the web server over. Cap pressure on the database with a Semaphore, and avoid long blocking inside synchronized on Java 21. More depth: Java interview questions.

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

public class Vt {
    public static void main(String[] args) throws Exception {
        AtomicInteger done = new AtomicInteger();
        try (ExecutorService ex = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 10_000; i++) {
                ex.submit(() -> {
                    Thread.sleep(200);   // stands in for a blocking status call
                    done.incrementAndGet();
                    return null;
                });
            }
        }                                // close() waits for every task
        System.out.println("finished: " + done.get());
    }
}

finished: 10000

What the interviewer is checking: Whether you know what problem they solve and where they do not help.

Likely follow-up: Why should virtual threads not be pooled?

A stream is a pipeline description: a source (exposed as a Spliterator), a chain of intermediate stages and exactly one terminal operation. Calling filter or map only appends a stage. The terminal call wraps the stages into a chain of sinks and pushes each element through it.

Stateless stages (filter, map) handle one element at a time; stateful ones (sorted, distinct) must buffer, acting as barriers, which the output below shows: every element reaches sorted before anything leaves it. Short-circuit operations such as limit stop the pull early. A parallel stream uses trySplit and the common fork-join pool, and flags like SIZED and ORDERED let the framework skip work.

import java.util.*;

public class Lazy {
    public static void main(String[] args) {
        List.of(5, 3, 9, 1).stream()
            .peek(n -> System.out.println("filter sees " + n))
            .filter(n -> n > 2)
            .sorted()
            .limit(2)
            .forEach(n -> System.out.println("out " + n));
    }
}

filter sees 5
filter sees 3
filter sees 9
filter sees 1
out 3
out 5

What the interviewer is checking: Understanding of pipelines, sinks, barriers and short-circuiting beyond "streams are lazy".

Likely follow-up: Why is a stateful lambda inside a parallel stream dangerous?

A singleton guarantees one instance of a class (strictly, per class loader) and gives global access to it. Options: an eager static final field; a lazy holder class, where the instance lives in a nested class that loads on first use; a single-element enum; a synchronized accessor, simple but it locks every call; and double-checked locking with volatile.

I would pick the enum or the holder idiom. In a Spring application, the container's default singleton scope is better still, because it keeps the class testable. State the downside: a hidden global makes unit tests order-dependent and hard to isolate.

What the interviewer is checking: Breadth of implementations plus the judgement to prefer simple, safe ones.

Likely follow-up: Why is a hand-written singleton harder to unit test than a Spring-managed bean?

Reflection: setAccessible(true) on a private constructor lets anyone create a second instance. A guard in the constructor that throws if the instance already exists blocks it for an eager singleton. Serialization: reading the object back builds a new instance without your accessor; add readResolve() returning the real instance. Cloning is similar, so do not implement Cloneable.

A single-element enum avoids all three: the JVM refuses to construct enums reflectively and deserialises them by name. Also remember separate class loaders each get their own "singleton".

import java.lang.reflect.Constructor;

public class Ref2 {
    static class Registry {
        private static final Registry INSTANCE = new Registry();
        private Registry() { }
        static Registry get() { return INSTANCE; }
    }
    static class Guarded {
        private static final Guarded INSTANCE = new Guarded();
        private Guarded() {
            if (INSTANCE != null) throw new IllegalStateException("already created");
        }
    }
    enum Safe { ONLY }

    public static void main(String[] args) throws Exception {
        Constructor<Registry> c = Registry.class.getDeclaredConstructor();
        c.setAccessible(true);
        System.out.println("second instance: " + (c.newInstance() != Registry.get()));

        Constructor<Guarded> g = Guarded.class.getDeclaredConstructor();
        g.setAccessible(true);
        try { g.newInstance(); }
        catch (java.lang.reflect.InvocationTargetException e) {
            System.out.println("guard: " + e.getCause().getMessage());
        }

        Constructor<Safe> s = Safe.class.getDeclaredConstructor(String.class, int.class);
        s.setAccessible(true);
        try { s.newInstance("COPY", 1); }
        catch (IllegalArgumentException e) { System.out.println("enum: " + e.getMessage()); }
    }
}

second instance: true
guard: already created
enum: Cannot reflectively create enum objects

What the interviewer is checking: Whether you know the attack paths and the defences, not just the pattern.

Likely follow-up: Why does the constructor guard not work for a lazily created singleton?

Three details are worth stating. Why check twice: the first, unlocked check keeps the fast path lock-free once initialised; the second, inside the lock, stops two racing threads from both creating the object. Why volatile: without it, the reference can be published before the constructor's writes are visible, so another thread may see a half-built object. Why the local variable: it costs one volatile read on the fast path instead of two.

Then say you would rather avoid it. The holder idiom, shown below, is lazy and thread-safe because the JVM guarantees class initialisation happens once.

public class Dcl2 {
    static class Catalog {
        private static volatile Catalog instance;
        private Catalog() { }

        static Catalog get() {
            Catalog local = instance;          // one volatile read on the fast path
            if (local == null) {
                synchronized (Catalog.class) {
                    local = instance;
                    if (local == null) instance = local = new Catalog();
                }
            }
            return local;
        }
    }

    static class Lazy {
        private Lazy() { }
        private static class Holder { static final Lazy INSTANCE = new Lazy(); }
        static Lazy get() { return Holder.INSTANCE; }
    }

    public static void main(String[] args) {
        System.out.println(Catalog.get() == Catalog.get());
        System.out.println(Lazy.get() == Lazy.get());
    }
}

true
true

What the interviewer is checking: Memory-model awareness: safe publication, reordering and the simpler alternative.

Likely follow-up: What breaks if the field is not volatile?

Remember five numbers. The table is allocated on the first put with 16 buckets and doubles when entries exceed 0.75 times capacity. The bucket index is (n - 1) & (h ^ (h >>> 16)), where h is the key's hash code; spreading the high bits protects against poor hash codes. Collisions form a chain; at 8 nodes a chain becomes a red-black tree, but only if the table has at least 64 buckets, otherwise the map resizes instead. It reverts to a list at 6.

On resize, each bucket splits into a low and a high half without rehashing keys. If you know the size, presize it, for example with HashMap.newHashMap(n) (Java 19). It is not thread-safe, and its iteration order is unspecified.

What the interviewer is checking: Whether you can give precise mechanics: index calculation, resize and when treeification happens.

Likely follow-up: Why does a tree bin first compare hash codes, and what happens when keys are not Comparable?

HashMap has no synchronisation, so concurrent writers can lose updates, and its fail-fast iterators throw when the map is modified. ConcurrentHashMap (Java 8 and later) inserts into an empty bucket with a compare-and-swap and otherwise locks only the first node of that one bucket, so writers to different buckets do not contend; reads take no lock.

It rejects null keys and values, because a null from get would be ambiguous with absent. Iterators are weakly consistent and never throw. size() is an estimate under concurrent updates. Compound updates must use merge, compute or putIfAbsent; a separate get then put is still a race.

What the interviewer is checking: Understanding of fine-grained locking and the atomic compound operations, not just "it is thread-safe".

Likely follow-up: Why does ConcurrentHashMap forbid null values?

equals answers "are these two logically the same?"; hashCode answers "which bucket should I look in?". The contract: equal objects must have equal hash codes; the value must not change while the object is stored in a hash structure; unequal objects may share a hash code, at the cost of slower lookups.

Override both from the same fields, or use a record, which generates them. Keep the equals parameter as Object, and be careful with getClass() versus instanceof in inheritance hierarchies, since symmetry can break. Avoid mutable fields, and for database entities do not rely on a generated id that is null before saving. TreeMap uses compareTo, not these methods.

What the interviewer is checking: Whether you link the two methods to how hash collections work and know the practical pitfalls.

Likely follow-up: What happens if two equal objects return different hash codes?

String is immutable: every change creates a new object. StringBuilder is a mutable buffer with no synchronisation, fast and the right default. StringBuffer is the same API with synchronised methods, a legacy choice from Java 1.0; sharing one builder between threads is rarely a sound design anyway.

A + inside a loop builds a fresh string every iteration, copying the growing text each time, which makes it quadratic. The compiler handles a single expression well, but not across iterations. Use a StringBuilder, String.join or Collectors.joining when assembling pieces.

What the interviewer is checking: Mutability, thread-safety and the practical cost of concatenating in a loop.

Likely follow-up: Is the + operator on strings compiled to a StringBuilder?

Each thread has its own stack of frames, one per method call, holding local primitives and references. Frames vanish when the method returns, the size is set by -Xss, and running out gives StackOverflowError, usually from runaway recursion.

The heap is one region shared by all threads and holds every object and array, managed by the garbage collector and sized with -Xms and -Xmx; exhaustion gives OutOfMemoryError. In Parcel p = new Parcel(); the reference p is on the stack and the object is on the heap. The JIT can sometimes avoid heap allocation for objects that never escape a method.

What the interviewer is checking: A precise mental model of where data lives and the two different memory errors.

Likely follow-up: Which error would an infinite recursion produce, and which a growing static list?

The phrase covers two ideas, so give both. Runtime areas: the heap (young generation with eden and survivor spaces, plus old generation), a stack per thread, the program counter, metaspace (class metadata in native memory, replacing PermGen in Java 8), the JIT code cache, and direct or native memory.

The Java Memory Model is a different thing: the rules for when one thread's write must be visible to another. A write is only guaranteed visible across an happens-before edge: unlock then later lock of the same monitor, volatile write then later read, Thread.start and join, and safe publication of final fields. Without such an edge, the compiler and CPU may reorder or cache. See Advanced Java.

What the interviewer is checking: Whether you separate memory layout from visibility rules and can name concrete happens-before edges.

Likely follow-up: What does volatile guarantee, and what does it not?

The collector keeps anything reachable from GC roots (thread stacks, static fields, native references) and reclaims the rest. Most objects die young, so the heap is split: young collections are frequent and cheap, survivors are promoted to the old generation, which is collected less often.

Choose by goal. Serial suits tiny heaps; Parallel favours throughput; G1, the usual default on server machines, balances throughput against a pause-time target; ZGC aims for very short pauses on large heaps, with a generational mode available in Java 21. Before touching flags, read GC logs (-Xlog:gc) and set the heap size. Leaks are objects that stay reachable but are no longer needed.

What the interviewer is checking: Reachability thinking and a goal-driven, log-first approach to choosing and tuning collectors.

Likely follow-up: What would you look at first if a service shows long GC pauses?

A final class cannot be extended: String, the wrapper types and records are examples. A final method can be inherited but not overridden; the class itself can still have subclasses. Making a class final therefore makes all its methods effectively non-overridable. Private and static methods cannot be overridden anyway.

Use final methods to protect an invariant, such as the fixed sequence in a template method. Today it is not a performance trick, since the JIT inlines most calls regardless. One practical catch: Spring's proxies for features like @Transactional work by subclassing, so a final class cannot be proxied and a final method is not intercepted.

What the interviewer is checking: Whether you know where each applies and the real design and framework consequences.

Likely follow-up: How does the sealed keyword differ from final?

No. Constructors are not inherited, so they can never be overridden, which makes final meaningless, and the compiler rejects it. The same applies to static, abstract and synchronized. A constructor may carry only an access modifier.

If the goal is to stop subclassing, mark the class final, use sealed, or make the constructor private and expose a static factory method. If the goal is fixed state, declare the fields final and assign them in the constructor.

public class Fin {
    final Fin() { }
}

Fin.java:2: error: modifier final not allowed here
    final Fin() { }
          ^
1 error

What the interviewer is checking: Basic language rules and the correct alternatives for the underlying goal.

Likely follow-up: How do you stop a class being subclassed without marking it final?

Abstraction is about the outside view: expose what a caller needs and hide how it is done, through interfaces and abstract types. Encapsulation is about the inside: keep state private and change it only through methods that enforce the rules, so the object cannot be put into an invalid state.

Example: a parcel locker. LockerBank.reserve(size) is the abstraction; callers never learn how a free compartment is found. Inside, the compartment list is private and reserve refuses to book an occupied slot, which is encapsulation. Generating a getter and setter for every field is not encapsulation; it just exposes the state indirectly.

What the interviewer is checking: A clear, distinct definition of each with a concrete example rather than swapped terms.

Likely follow-up: Can you have encapsulation without abstraction, or the reverse?

A class states what it needs, usually as constructor parameters, and the container supplies those objects instead of the class building them with new. The class depends on an interface, and the wiring decision lives in one place.

The payoff is easy substitution. A ReminderService that needs a MessageSender can get an SMS sender in production and a recording fake in a unit test, without any change to its own code. It also keeps object creation, configuration and lifetime out of business logic.

In the interview, give that one concrete swap rather than a definition. Fuller treatment: Spring Boot course.

@Service
class ReminderService {
    private final MessageSender sender;      // an interface

    ReminderService(MessageSender sender) {  // Spring supplies it
        this.sender = sender;
    }
}

What the interviewer is checking: Whether you explain DI through a testability and decoupling benefit, not only by quoting a definition.

Likely follow-up: What is the difference between dependency injection and inversion of control?

Startup is two phases. First the container collects BeanDefinition objects, which are recipes (class, scope, constructor arguments, init method) gathered from component scanning, @Bean methods and imports, and stores them in a registry inside a BeanFactory. Special post-processors such as ConfigurationClassPostProcessor and BeanFactoryPostProcessor implementations can add or alter definitions at this point, before any application bean exists.

Second, the container instantiates the non-lazy singletons, resolving dependencies in order, and runs BeanPostProcessors around initialisation. ApplicationContext is the richer layer on top of BeanFactory: events, environment and properties, message resources.

Key sentence: definitions first, objects second.

What the interviewer is checking: Whether you can separate bean definitions from bean instances and name where customisation hooks in.

Likely follow-up: What is the difference between a BeanFactoryPostProcessor and a BeanPostProcessor?

Order of events for a singleton: instantiate (constructor or factory method), inject dependencies, run Aware callbacks such as BeanNameAware, call BeanPostProcessor before-initialisation hooks (this is where @PostConstruct runs), then InitializingBean.afterPropertiesSet and any custom init method, then after-initialisation hooks, where proxies are usually created. The bean is now ready.

On context shutdown: @PreDestroy, DisposableBean.destroy, then a custom destroy method. Remember that Spring does not call destroy callbacks for prototype beans, because it hands them over and stops tracking them.

Practical rule: do not use injected collaborators in the constructor body of a field-injected bean; do the setup in @PostConstruct.

@Component
class KioskCatalogue {
    @PostConstruct void warmUp() { /* load titles */ }
    @PreDestroy   void flush()   { /* persist counters */ }
}

What the interviewer is checking: That you know the order, where post-processors and proxies fit, and the prototype exception.

Likely follow-up: At which step is the AOP proxy created, and what does injection into other beans receive?

singleton is the default: one instance per container. prototype creates a new instance on every lookup. In a web application there are also request, session, application and websocket scopes, each tied to that lifetime.

Choose singleton for stateless services and let mutable per-user data travel in method arguments, a request-scoped bean, or the database. A singleton shared by threads must be thread-safe, which usually means no mutable fields.

If a singleton needs a request-scoped collaborator, declare the narrower bean with a scoped proxy so the singleton holds a stand-in that resolves the real instance per call.

What the interviewer is checking: Whether you tie scope choice to thread safety and know the scoped-proxy answer for mixed lifetimes.

Likely follow-up: What breaks if you keep a customer's basket in a field of a singleton service?

Take "renew a library book". The DispatcherServlet maps the URL to a controller method. The controller binds and validates input, then calls the service. It does no business logic and returns a DTO.

The service holds the rules (is the loan overdue, is there a hold on the title) and defines the transaction boundary. It calls the repository, which is a Spring Data interface that talks to the database. On the way back, message converters write the DTO as JSON.

Failures travel up as exceptions, and one @RestControllerAdvice turns them into consistent error responses. Say why the layers exist: each can be tested and changed independently.

What the interviewer is checking: A clear mental model of responsibilities per layer, including where transactions and error handling live.

Likely follow-up: Why should the transaction boundary usually sit on the service rather than the controller?

With a constructor, dependencies are mandatory and visible in the signature, fields can be final, and the object is never half-built. A unit test just calls new ReminderService(fakeSender) with no Spring and no reflection.

Field injection hides how many collaborators a class has, so a class quietly grows to eight of them. It also needs reflection to test and permits an object in a state with null fields. Constructor cycles fail immediately at startup, which is a feature.

Since Spring 4.3 a class with a single constructor needs no @Autowired. Use setter injection only for optional dependencies. Related set: Spring Boot interview questions.

What the interviewer is checking: Whether your reasons go beyond "it is best practice": immutability, testability and fail-fast behaviour.

Likely follow-up: How do you handle a dependency that is genuinely optional?

A call to getBean (or startup pre-instantiation) finds the merged BeanDefinition in DefaultListableBeanFactory, and the factory's create logic (AbstractAutowireCapableBeanFactory) takes over. It picks a constructor or a @Bean factory method, resolves each argument by type and qualifier (recursively creating other beans first), and instantiates through reflection.

Then it populates properties, where @Autowired fields and setters are filled by a BeanPostProcessor. Then initialisation: Aware callbacks, init hooks, and the after-initialisation post-processors, which may swap the object for a proxy. Finished singletons are kept in a cache, so later lookups return the same instance.

Do not claim more detail than you remember; the order above is the part to get right.

What the interviewer is checking: Whether you can narrate definition lookup, instantiation, population and post-processing in the right order.

Likely follow-up: Why can the object another bean receives be a proxy rather than your own class instance?

Boot ships many configuration classes inside its jars and the starters you add. @EnableAutoConfiguration imports the candidates named in an AutoConfiguration.imports file under META-INF/spring. Every candidate is guarded by conditions such as @ConditionalOnClass, @ConditionalOnProperty and @ConditionalOnMissingBean, so only the relevant ones apply.

The design rule is that auto-configuration yields to you: declare your own DataSource bean and the default one backs off.

To debug, start with --debug (or debug=true) to print the conditions report, which lists what matched and why not. Writing your own starter uses the same pieces. Full walk-through: Spring Boot course.

@AutoConfiguration
@ConditionalOnClass(KioskClient.class)
class KioskAutoConfiguration {
    @Bean @ConditionalOnMissingBean
    KioskClient kioskClient() { return new KioskClient(); }
}

What the interviewer is checking: Whether you know the conditional mechanism and the debugging report, not just "it configures things automatically".

Likely follow-up: How would you exclude one auto-configuration class for a single deployment?

All three are meta-annotated with @Component, so component scanning registers each one as a bean. For @Service that is the whole story: it carries intent only, and it is a handy target for a pointcut or an architecture test.

@Repository has real behaviour. Spring registers a post-processor that translates persistence exceptions, such as a JPA or JDBC error, into its DataAccessException hierarchy, so the service layer does not depend on a vendor exception type. Spring Data interfaces already get this.

Web-layer stereotypes (@Controller, @RestController) add request mapping support. Pick by role, because a reader learns the layering from the annotations.

What the interviewer is checking: Whether you know that only @Repository changes behaviour and can name what it does.

Likely follow-up: Could you annotate every class with @Component? What would you lose?

Boot enables transaction management, which registers an advisor holding a TransactionInterceptor. An auto-proxy BeanPostProcessor finds beans with matching methods and, after initialisation, replaces them with a proxy (CGLIB by default in Boot). A call through the proxy asks the PlatformTransactionManager to start or join a transaction, binds the connection or EntityManager to the current thread, runs your method, then commits or rolls back.

Consequences follow directly. A call inside the same class uses this, skipping the proxy. Private or final methods are not advised. A new thread has no bound transaction. Fix self-invocation by moving the method to another bean or using TransactionTemplate.

What the interviewer is checking: Whether you can connect the annotation to a BeanPostProcessor-created proxy and thread-bound resources.

Likely follow-up: What happens to the transaction when the method runs on an @Async thread?

A transaction begins, runs several statements as one unit, then ends in commit (changes become durable and visible) or rollback (all discarded). Locks or row versions are held until it ends, so keep it short and never include slow remote calls.

ACID: atomic (all or nothing), consistent (constraints still hold), isolated (concurrent work does not corrupt each other, to the degree the isolation level allows), durable (committed data survives a crash).

In Spring the proxy does the begin and commit for you; the mental model is the same. The conditional update below shows a safe borrow: the last copy cannot be taken twice. I ran it against SQLite.

db.execute("BEGIN")
n = db.execute("UPDATE copies SET available = available - 1 "
               "WHERE book_id = 7 AND available > 0").rowcount
if n == 0:
    db.execute("ROLLBACK")          # nothing left, undo
else:
    db.execute("INSERT INTO loans VALUES (7, ?)", (member,))
    db.execute("COMMIT")

borrowed
none left
[(7, 'asha')] [(7, 0)]

What the interviewer is checking: That you know the begin/commit/rollback flow and the practical cost of long transactions.

Likely follow-up: Which ACID property does a crash right after COMMIT test?

Propagation answers "what if a transaction already exists?": REQUIRED joins or creates one, REQUIRES_NEW suspends and starts a fresh one, NESTED uses a savepoint, SUPPORTS and NOT_SUPPORTED are tolerant, MANDATORY insists one exists, NEVER forbids it.

Isolation answers "what may I see from concurrent transactions?". Levels from weakest to strongest: read uncommitted, read committed, repeatable read, serializable. Stronger levels prevent more anomalies (dirty reads, non-repeatable reads, phantoms) at a cost in locking or retries.

DEFAULT uses the database's own level, for example read committed on PostgreSQL and repeatable read on InnoDB, so state which database you mean.

What the interviewer is checking: Whether you can keep propagation (joining behaviour) and isolation (visibility) as separate ideas.

Likely follow-up: Which anomaly does read committed still allow?

REQUIRED means the callee shares the caller's fate: one commit, one rollback. Choose REQUIRES_NEW when a piece of work must survive the caller's rollback, the classic case being an audit or failed-attempt record: the booking fails, but the log row that says so must persist.

It only takes effect when called through another bean, because of the proxy. It also holds a second database connection while the first is suspended, so heavy use can exhaust a small pool, and it cannot see the caller's uncommitted rows.

Do not use it to dodge rollback-only errors; that hides a design problem.

@Service
class AuditWriter {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    void record(String event) { auditRepo.save(new AuditRow(event)); }
}

What the interviewer is checking: Whether you can give a justified use case and name the pool and visibility risks.

Likely follow-up: What happens if the outer transaction needs a row the inner one also locks?

Only work done through the transaction-bound resource: SQL changes on the enlisted connection. Not rolled back: in-memory object state, a file you wrote, an HTTP call, an email, a message already sent to a broker. That gap is the reason for outbox and saga patterns.

By default Spring rolls back on RuntimeException and Error, and commits on checked exceptions unless rollbackFor says otherwise. If you catch and swallow the exception, the proxy sees a normal return and commits. If a joined inner method already marked the transaction rollback-only, the outer commit fails with an UnexpectedRollbackException.

What the interviewer is checking: Whether you understand the boundary of rollback, including side effects it cannot undo.

Likely follow-up: How would you send a confirmation email only if the transaction really commits?

The problem is the dual write: saving to the database and publishing an event are two systems, so a crash between them loses the event or publishes one for data that never committed. The fix: write the business row and an outbox row in the same local transaction. A separate relay (a poller, or change-data-capture) reads unsent rows, publishes them, then marks them sent.

A crash after publishing but before marking means a repeat, so delivery is at-least-once and consumers must deduplicate on an event id. The sketch below ran in Python with SQLite.

Full background: microservices course.

with db:   # one local transaction
    db.execute("insert into parcel values (1, 'DISPATCHED')")
    db.execute("insert into outbox(payload) values ('parcel 1 dispatched')")
relay(crash=True); relay()      # publish, crash before marking, retry
# consumer: skip ids already seen

[(1, 'parcel 1 dispatched'), (1, 'parcel 1 dispatched')]
handle 1
skip 1

What the interviewer is checking: Whether you can explain the dual-write failure and accept the duplicate-delivery consequence.

Likely follow-up: Polling relay or change-data-capture: how do you choose?

A saga splits a business operation across services into a chain of local transactions. If a later step fails, earlier steps are undone by compensating actions run in reverse order. No global lock is held, so services stay available, but the system is eventually consistent.

Trade-off to state: no isolation. Other requests can see the intermediate state, for example a held slot that is later released, so model it explicitly with statuses like PENDING and CONFIRMED.

Illustrative clinic booking: hold slot, charge card, send confirmation. When the charge fails, the hold is released. I ran a small simulation of that flow.

run_saga([("hold slot", hold, release),
          ("charge card", charge, refund),
          ("send confirmation", notify, noop)])

ok   hold slot
FAIL charge card - card declined
undo hold slot
ABORTED

What the interviewer is checking: Whether you can describe local steps, compensations, and the isolation trade-off.

Likely follow-up: What if the compensation itself fails?

In orchestration one coordinator tells each service what to do next and tracks the state. In choreography there is no coordinator; each service reacts to events and emits its own.

Choreography is lightweight for short, linear flows of two or three services, but the overall process becomes invisible, and cyclic event dependencies can creep in. Orchestration gives a single place to see state, handle timeouts and branches, and test the flow, at the cost of a central component that must stay thin and not absorb business rules.

Rule of thumb: few steps and few branches, choreography; many steps, deadlines or approvals, orchestration. Either way, steps need to be idempotent.

What the interviewer is checking: Whether you decide from complexity and observability needs instead of fashion.

Likely follow-up: How would you find out where a stuck saga instance is?

A compensating transaction is a new action that semantically reverses an earlier committed step. It is not a rollback: the original row stays, and a refund or release record is added. Releasing a held clinic slot or issuing a refund are examples.

A good compensation is idempotent (safe to run twice), retryable until it succeeds because it must not be abandoned halfway, and works from stored data, not memory. Some actions cannot be undone, such as an email already sent, so put those last, after the point of no return, or make the compensation a follow-up message.

Business rules may also require a fee or a partial refund, so compensation is domain logic, not a generic undo.

What the interviewer is checking: Whether you treat compensation as idempotent domain logic and know about non-reversible steps.

Likely follow-up: How do you order steps so the irreversible one comes last?

Command Query Responsibility Segregation separates the model that changes state (commands) from the model that answers questions (queries). The read side is usually a denormalised view built for one screen, updated from events or change feeds, while the write side stays normalised and enforces rules.

Worth it when read and write shapes or load differ a lot, such as a parcel-tracking timeline read thousands of times per update. The price is eventual consistency between the two sides and more moving parts.

It is not the same as event sourcing; you can do CQRS with ordinary tables. For plain CRUD it is overkill, and saying so shows judgement.

What the interviewer is checking: Whether you can justify CQRS by a concrete read/write mismatch and name its consistency cost.

Likely follow-up: How does a user see their own write if the read model lags?

Two-phase commit (2PC, as in XA) has a coordinator ask every participant to prepare, and if all vote yes, tell all to commit. It gives atomicity across databases, but participants hold locks while waiting. If the coordinator dies after prepare, they are stuck until it recovers, so availability and latency suffer, and not every broker or SaaS API supports it.

Microservice systems therefore usually avoid it: they combine local transactions with the outbox, a saga for coordination, and idempotent consumers, and accept eventual consistency.

Mention the exception honestly: if two writes truly must be atomic, keep them in one service and one database.

What the interviewer is checking: That you understand 2PC's mechanism and its blocking cost, and know the usual alternatives.

Likely follow-up: Does a Kafka transaction give you atomicity with your own database?

An idempotent operation has the same effect when repeated. Setting a status to SHIPPED is naturally idempotent; "add 500 to the balance" is not. Retries, timeouts and at-least-once messaging make duplicates unavoidable, so non-idempotent actions need protection.

Implementation: the caller sends a unique key; the server inserts it into a table with a unique constraint in the same transaction as the effect. A repeat hits the constraint and returns the stored result. Reject the same key arriving with a different body, and expire old keys. The sketch ran against SQLite.

Related: System design interview questions.

try:
    with db:   # key and effect commit together
        db.execute("insert into idem(key) values (?)", (key,))
        rid = db.execute("insert into refunds(amount) values (?)", (amount,)).lastrowid
except sqlite3.IntegrityError:
    pass       # seen before: return the stored answer

refund 1 refund 1 refund 2
2 refund rows

What the interviewer is checking: Whether you can make idempotency race-safe with a constraint, not a check-then-insert.

Likely follow-up: How long should you keep idempotency keys, and what happens after they expire?

First challenge the requirement: does it truly need atomicity, or just a consistent end state? If two things must change together, the cleanest answer may be that they belong in one service and one database.

Otherwise, accept that each service is atomic only locally and design for convergence. Use the outbox so each service reliably publishes its change, a saga with compensations for the multi-step flow, and idempotent handlers so retries are safe. Add visible intermediate states, timeouts and a dead-letter path for steps that keep failing.

In the interview, name the trade-off: you give up instant global consistency for availability and independence. Starting point: Microservices interview and course material.

What the interviewer is checking: Whether you question the requirement first and then combine outbox, saga and idempotency coherently.

Likely follow-up: Which orders or payments would you refuse to split across services?

Kafka is a cluster of brokers that store topics as append-only logs. Each topic is split into partitions, and each partition is replicated: one replica is the leader that handles reads and writes, the others follow. Records stay for a retention period, not until consumed, so many readers can replay them.

Producers append records; consumers pull them and track their own position, the offset. Cluster metadata and leader election are handled by controllers; newer versions use the built-in KRaft mode instead of a separate ZooKeeper ensemble.

Say the design idea: a durable, partitioned, replayable log. Fuller treatment: Apache Kafka course.

What the interviewer is checking: Whether you can describe the log, partition and replication model without drifting into product marketing.

Likely follow-up: What happens to a partition when its leader broker dies?

The producer serialises the record, picks a partition (hash of the key if there is one, otherwise spread across partitions), batches records and sends them to that partition's leader. The leader appends and, depending on acks, waits for followers before acknowledging.

The consumer in a group polls, receives records from its assigned partitions, processes them, and then commits the offset so it can resume after a restart. When you commit relative to processing decides your delivery guarantee.

In Spring that is KafkaTemplate to send and @KafkaListener to receive.

kafka.send("parcel-scans", parcelId, event);   // key = parcelId

@KafkaListener(topics = "parcel-scans", groupId = "tracking")
void onScan(ScanEvent e) { /* update the timeline */ }

What the interviewer is checking: That you can follow a record end to end, including partition choice and offset commit.

Likely follow-up: What does acks=all change in that flow?

A broker is one Kafka server. A topic is a named stream, say the parcel-scan feed. A partition is one ordered lane of that topic: a topic with six partitions is six independent logs, spread over the brokers, each with its own offsets.

Partitions are the unit of both ordering and parallelism: order holds only inside a lane, and at most one consumer of a group reads a lane at a time. The replication factor says how many brokers hold a copy of each lane.

Partition count can be increased later but not reduced, and increasing it changes which partition a key maps to, so plan it with expected throughput in mind.

What the interviewer is checking: Whether you tie partitions to ordering and parallelism, not just storage.

Likely follow-up: How would you choose the number of partitions for a new topic?

Consumers sharing a group.id form a group, and Kafka divides the topic's partitions among them so each partition goes to exactly one member. This is how you scale reading: add consumers, up to the partition count. Extra consumers sit idle. A different group gets its own full copy of the stream, with its own offsets.

A rebalance reassigns partitions when members join, leave, crash or time out. During it, processing can pause, and uncommitted work may be redelivered to another member, so handlers should be idempotent. Cooperative assignment and static membership reduce the disruption.

What the interviewer is checking: Whether you know the one-partition-one-consumer rule and the cost of rebalances.

Likely follow-up: You have 12 consumers and 8 partitions. What do you observe and what do you change?

Order is guaranteed within a partition only, not across a topic. Records with the same key go to the same partition (while the partition count is unchanged), so use the entity id, for example the parcel id, as the key: all scans of one parcel stay in order, while different parcels run in parallel.

Two ways to lose order: producer retries can reorder in-flight batches unless the idempotent producer is enabled (the default in recent clients), and a consumer that hands records to a thread pool may finish them out of order. Process one partition's records sequentially, or partition work by key inside the app.

What the interviewer is checking: Whether you can say "per partition, keyed by entity" and name two real ways ordering gets broken.

Likely follow-up: What happens to per-key ordering if you add partitions to a live topic?

Durability on the producer side: replication factor 3, acks=all, a sensible min.insync.replicas, retries on, idempotent producer on. Consumer side: commit offsets only after processing succeeds.

At-most-once: commit before processing, so a crash loses work. At-least-once: process then commit, so a crash repeats work; this is the practical default, paired with idempotent handlers. Exactly-once: Kafka transactions plus idempotent producers give it for read-process-write inside Kafka, but an outside side effect such as a database write or email needs its own deduplication.

Send poison messages to a dead-letter topic after bounded retries.

What the interviewer is checking: Whether you tie the three semantics to commit timing and know exactly-once stops at Kafka's boundary.

Likely follow-up: How would you handle one message that fails every time?

Add @EnableAsync, then annotate a method with @Async. Like @Transactional, it works through a proxy, so the call must come from another bean, and the body runs on a TaskExecutor thread. Return void or a CompletableFuture so the caller does not block.

Gotchas: an exception from a void method vanishes unless you configure an AsyncUncaughtExceptionHandler; the transaction and the security context do not follow to the new thread; and an unbounded or default pool can hide overload, so define a bounded executor with a queue. Boot 3.2 and later can run on virtual threads through a property.

If the work must survive a restart, use a queue instead.

@Async
public CompletableFuture<Void> sendReceipt(long loanId) {
    mailer.send(loanId);
    return CompletableFuture.completedFuture(null);
}

What the interviewer is checking: Whether you know @Async is proxy-based, loses thread-bound context, and is not durable.

Likely follow-up: When would you use Kafka instead of @Async for a background job?

Set a TTL with SET key value EX 600 or EXPIRE. Redis removes expired keys lazily on access and with a background sampler. Choose TTL from how stale the data may be, and add random jitter so many keys written together do not expire together and stampede the database.

Usual strategy is cache-aside: read the cache, on a miss load from the database and store it; on a write, update the database and delete the cached key. Also consider caching "not found" briefly, and set maxmemory with an eviction policy so memory is bounded.

In Spring, @Cacheable with a cache manager configured with entryTtl does this declaratively. More: Redis course.

RedisCacheConfiguration cfg = RedisCacheConfiguration.defaultCacheConfig()
    .entryTtl(Duration.ofMinutes(10));

What the interviewer is checking: Whether you pair TTL with invalidation and name stampede and eviction as real production concerns.

Likely follow-up: One hot key expires and a thousand requests miss at once. What do you do?

Two properties organise the answer. Safe means the call does not change server state: GET (and HEAD) qualify. Idempotent means repeating it leaves the same final state: GET, PUT and DELETE qualify, POST does not, and PATCH is not guaranteed to be.

Use GET to read a library loan, POST to create one (the server picks the ID, so a retry can create a duplicate), PUT to replace the whole record with the body you send, and PATCH to change a few fields, such as only the due date. The trap: a PATCH like "extend by 7 days" is not idempotent, while "set due date to 3 March" is.

What the interviewer is checking: Whether you reason from safety and idempotency, not from memorised one-line definitions.

Likely follow-up: A client times out on a POST that creates an order. How do you make the retry safe?

Group by first digit. 2xx: 200 for a normal read or update, 201 with a Location header after creating something, 204 when there is nothing to return. 4xx means the caller must change something: 400 malformed input, 401 not authenticated, 403 authenticated but not allowed, 404 unknown resource, 409 conflicts with current state, 422 well-formed but semantically invalid, 429 too many requests.

5xx means the fault is ours: 500 unexpected failure, 502/504 a bad or slow upstream, 503 temporarily unavailable. Never send 200 with an error inside the body; clients, caches and monitoring all rely on the code. Full discussion: REST API course.

What the interviewer is checking: Accurate, purposeful use of codes, especially 401 versus 403 and 400 versus 422.

Likely follow-up: A user tries to book a slot someone else just took. Which code, and what body?

Validate at the edge: constraint annotations on the request type, @Valid on the parameter, so bad input is rejected before business code runs. Rules that need data (is the slot still free?) belong in the service and throw a domain exception.

One @RestControllerAdvice maps each exception type to a status and a uniform error body (a problem-details style document with a message and a field map). Log server faults with a correlation ID, but never return stack traces or SQL text to callers.

public record BookSlot(@NotBlank String patronId, @Future Instant start) {}

@PostMapping("/slots")
ResponseEntity<Void> book(@Valid @RequestBody BookSlot req) { /* ... */ }

@RestControllerAdvice
class ApiErrors {
  @ExceptionHandler(MethodArgumentNotValidException.class)
  ProblemDetail invalid(MethodArgumentNotValidException ex) {
    ProblemDetail p = ProblemDetail.forStatusAndDetail(HttpStatus.BAD_REQUEST, "Validation failed");
    p.setProperty("fields", ex.getBindingResult().getFieldErrors().stream()
        .collect(Collectors.toMap(FieldError::getField, FieldError::getDefaultMessage, (a, b) -> a)));
    return p;
  }
}

What the interviewer is checking: Layered validation, one central error handler, and not leaking internals.

Likely follow-up: Where do you validate a rule that needs a database lookup, and what status does it map to?

Offset (?page=40&size=20) is simple and supports jumping to a page, but the database still walks past every skipped row, and rows inserted meanwhile shift pages so items repeat or vanish. Keyset (cursor) pagination asks for rows after the last seen sort key; it stays fast on deep pages and is stable under inserts, but cannot jump to page 40.

Return the cursor opaquely, cap size, define a stable order with a unique tiebreaker (such as id), and include a next link. Choose offset for small admin tables, keyset for feeds and large datasets.

# db: a sqlite3 connection holding a loans(id, title) table
def page(after_id, size=3):
    return db.execute(
        "SELECT id, title FROM loans WHERE id > ? ORDER BY id LIMIT ?",
        (after_id, size)).fetchall()

cursor = 0
while rows := page(cursor):
    print([r[0] for r in rows], "next cursor =", rows[-1][0])
    cursor = rows[-1][0]

[1, 2, 3] next cursor = 3
[4, 5, 6] next cursor = 6
[7] next cursor = 7

What the interviewer is checking: Understanding the cost of OFFSET and the stability argument for cursors.

Likely follow-up: How do you keyset-paginate when the sort column, such as price, is not unique?

Common options: a path segment (/v2/loans), a header or media type (Accept: application/vnd.library.v2+json), or a query parameter. Path versions are the most visible and easiest to route, cache and debug; header versions keep URLs stable but are harder to test from a browser.

The better question is how rarely you need a new version at all. Additive changes (new optional fields, new endpoints) are backward compatible, so clients must ignore unknown fields. Cut a new version only for breaking changes, run old and new side by side, publish a deprecation date, and measure remaining traffic on the old one before removal.

What the interviewer is checking: Judgement: prefer compatible evolution, and treat versioning as a retirement plan too.

Likely follow-up: Which changes are breaking: renaming a field, adding a required field, adding an optional one?

Authentication establishes identity ("this is patron 17") using a password, one-time code or token. Authorization decides what that identity may do to a specific resource. Say in the first sentence that the order is authenticate, then authorize.

Both are enforced on the server for every request: a gateway or filter handles authentication, while authorization is closest to the data, checking roles for the action and ownership for the object. The classic failure is logged-in user A reading user B's record by changing an ID. Return 401 when identity is missing or invalid, 403 when it is known but not permitted. More: Security interview questions.

What the interviewer is checking: Clear separation, server-side enforcement, and awareness of object-level checks.

Likely follow-up: Where in a Spring app would you put role checks versus ownership checks?

The client posts credentials to a login endpoint; the server verifies them and returns a signed token carrying claims such as sub, iss, aud and exp. The client sends it as Authorization: Bearer <token> on later calls. Each service checks the signature with a fixed expected algorithm and key, then the expiry, issuer and audience, and only then trusts the claims.

The payload is encoded, not encrypted, so keep secrets out of it. The run below signs a token with HMAC, then shows expiry and a tampered payload both being rejected. Deeper: JWT course.

import base64, hashlib, hmac, json

def b64(b): return base64.urlsafe_b64encode(b).rstrip(b"=").decode()
def unb64(s): return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))
KEY = b"demo-only-secret"

def sig(head, body):
    return b64(hmac.new(KEY, f"{head}.{body}".encode(), hashlib.sha256).digest())

def sign(claims):
    head = b64(json.dumps({"alg": "HS256"}).encode())
    body = b64(json.dumps(claims).encode())
    return f"{head}.{body}.{sig(head, body)}"

def verify(token, now):
    head, body, s = token.split(".")
    if not hmac.compare_digest(s, sig(head, body)):
        return "reject: bad signature"
    claims = json.loads(unb64(body))
    return "reject: expired" if claims["exp"] <= now else "ok: " + claims["sub"]

t = sign({"sub": "patron-17", "exp": 1000})
print(verify(t, 900))
print(verify(t, 1001))
h, _, s = t.split(".")
print(verify(f"{h}.{b64(json.dumps({'sub': 'admin', 'exp': 9999}).encode())}.{s}", 900))

ok: patron-17
reject: expired
reject: bad signature

What the interviewer is checking: That you can narrate issue, send and verify, including which checks happen on every request.

Likely follow-up: Why must the server pin the expected algorithm rather than read it from the token header?

A session stores state on the server and gives the browser an opaque ID. Logout and revocation are instant, but every instance needs the shared store. A JWT carries its own claims and is verified without a lookup, which suits many independent services or third-party clients, but it is valid until it expires.

My default for a single browser app with one backend: sessions in a cookie. For service-to-service or mobile APIs: short-lived JWTs. If you need instant revocation with JWTs you reintroduce state (a deny-list or token version), so say that cost out loud. Compare: Security interview questions.

What the interviewer is checking: A reasoned default and an honest account of revocation, rather than "JWT is stateless so it is better".

Likely follow-up: An employee is dismissed; how fast does access end under each approach?

The access token is short-lived (minutes) and sent with every API call, so a leak has a small window. The refresh token is long-lived, used only against the authorisation endpoint to obtain a new access token, so it travels rarely.

That split gives revocability without a lookup on every request: the server can refuse to refresh. Good practice: store refresh tokens hashed server-side, bind them to a device or session, rotate on each use, and treat a reused old refresh token as theft, revoking that whole session family. Keep the refresh token out of script-readable storage, for example an HttpOnly, Secure cookie scoped to the refresh path.

What the interviewer is checking: Understanding the lifetime trade-off plus rotation and reuse detection.

Likely follow-up: How do you log a user out of all devices if access tokens are stateless?

CORS is a browser mechanism by which a server says which other origins may read its responses from script. It relaxes the same-origin rule, and it is not authentication: curl ignores it. CSRF is an attack where another site makes the victim's browser send a state-changing request that carries the victim's cookies automatically.

Defences differ. For CORS: an explicit allow-list of origins, never reflecting the incoming Origin, and no wildcard with credentials. For CSRF: SameSite cookies, anti-forgery tokens on state-changing requests, no state changes on GET, and an Origin check. APIs authenticated with an Authorization header are largely immune to classic CSRF.

What the interviewer is checking: Whether you keep the two apart: one is a read relaxation, the other a request-forgery attack.

Likely follow-up: Does enabling CORS for one origin make CSRF easier?

Work outside in. Transport: TLS only. Identity: strong authentication (OAuth 2.0/OIDC or sessions), MFA for people, short-lived tokens, per-client credentials for services. Authorisation: deny by default, object-level checks on every endpoint.

Input and output: schema validation, parameterised queries, size and type limits, and no internal details in errors. Abuse control: rate limits per client and stricter ones on login. Data: least-privilege database users, secrets in a manager, sensitive fields masked in logs. Operations: audit logs, dependency scanning, security headers, tested key rotation. Mention a threat-modelling pass for each new endpoint. More: OWASP Top 10 course.

What the interviewer is checking: A structured, layered view, with object-level authorisation named explicitly.

Likely follow-up: Which two items from your list would you implement first on a new API, and why?

The gains: independent deployment, scaling a hot part separately, team ownership aligned to business domains, and fault isolation. The costs are real: network latency and partial failure replace method calls, data is split so cross-service transactions disappear, and you now need contract versioning, tracing, and mature deployment automation.

Frame it as a trigger, not a fashion: many teams blocked on one release, or one component with very different load. Without that, a modular monolith is faster and cheaper. If you do split, cut along business boundaries and give each service its own data. Full discussion: microservices course.

What the interviewer is checking: Balanced reasoning with named costs, not enthusiasm for the pattern.

Likely follow-up: Which part of a clinic appointment system would you extract first, and why that one?

Instances start, stop and move, so callers cannot hard-code addresses. A registry keeps the live list: each instance registers (or the platform does it) and is removed when health checks fail.

Client-side discovery means the caller fetches the list and picks an instance, which saves a hop but puts logic in every client. Server-side discovery sends the call to a load balancer or proxy that does the lookup. In Kubernetes the platform covers this: a Service name resolves through DNS to healthy pods only. Mention health checks, caching of results with a short TTL, and what happens when the registry is unreachable (keep using the last known list).

What the interviewer is checking: That you know why it exists and can compare client-side with server-side models.

Likely follow-up: What happens to in-flight requests when an instance is deregistered?

It is the single entry point for outside clients: routing to services, authentication and token validation, rate limiting, TLS termination, request logging, and sometimes response aggregation or protocol translation. It hides internal topology so services can be reshuffled without breaking clients.

What it should not hold is business logic, because it becomes a shared bottleneck that every team must edit. It is also a single point of failure, so run it redundantly and keep it thin. Distinguish it from a service mesh, which manages service-to-service traffic inside the cluster.

What the interviewer is checking: Knowing the legitimate cross-cutting jobs and the risk of a bloated gateway.

Likely follow-up: Would you put authorisation rules in the gateway, in each service, or both?

A timeout bounds one call. A retry repeats a failed call. A circuit breaker tracks recent outcomes across calls: when the failure rate passes a threshold it opens and fails immediately for a cooling period, half-opens to allow a few probe calls, then closes again on success.

The point is protecting both sides: the caller stops tying up threads on a doomed dependency, and the struggling service gets quiet time to recover. Pair it with a fallback (cached value, reduced feature, clear error) and keep retries behind the breaker, otherwise retries make an outage worse. Libraries such as Resilience4j provide it.

What the interviewer is checking: Correct states and the interplay of the three patterns.

Likely follow-up: What fallback would you show when the price-lookup service is open-circuited?

Decide the key (API key, user, IP), the limits, and the rejection response (429 with a retry hint). A token bucket is my default: a bucket of capacity C refills at R tokens per second, each request spends one, so short bursts pass but the long-run rate stays at R. A fixed window is simpler but lets a double burst straddle the boundary.

With several servers the state lives in a shared store such as Redis and the check-and-update must be atomic. Decide whether the limiter fails open or closed when that store is down. Fuller treatment: rate limiting course.

class Bucket:
    def __init__(self, cap, rate):
        self.cap, self.rate, self.tokens, self.t = cap, rate, cap, 0.0

    def allow(self, now):
        self.tokens = min(self.cap, self.tokens + (now - self.t) * self.rate)
        self.t = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

b = Bucket(cap=5, rate=2)
print("burst of 8 at t=0:", [b.allow(0.0) for _ in range(8)])
print("one second later: ", [b.allow(1.0) for _ in range(3)])

burst of 8 at t=0: [True, True, True, True, True, False, False, False]
one second later:  [True, True, False]

What the interviewer is checking: Algorithm choice with the reason, plus the distributed and failure-mode concerns.

Likely follow-up: How do you apply different limits per customer plan without redeploying?

Find the bottleneck first, then pick the cheapest fix. Typical order: tune queries and add indexes; cache read-heavy data; scale the stateless tier horizontally behind a load balancer; add read replicas; move slow work behind a queue so requests return fast; and only then partition (shard) the data.

Each step has a price: caches go stale, replicas lag, queues make results asynchronous, shards complicate joins. State the metric that triggers the next step (CPU saturation, p99 latency, replica lag, queue depth) and load-test before and after. Scaling also means degrading gracefully, for example shedding low-priority work under overload.

What the interviewer is checking: A measured, ordered approach instead of listing buzzwords.

Likely follow-up: Your database CPU is at its limit but the app tier is idle. What do you try, in order?

Requirements: multiple channels, user preferences and opt-outs, priorities (a security code beats a promotion), no duplicates, delivery status. Components: a notification API, a preferences and template service, one queue per channel (so a slow SMS vendor cannot delay email), channel workers calling providers, and a status store.

Flow: accept the request and persist it, check preferences, render, enqueue with an idempotency key; a worker sends and records the outcome. Failure: retry with backoff, dead-letter after a limit, fail over to a backup provider. Trade-offs: at-least-once plus deduplication rather than exactly-once; asynchronous, so senders get "accepted", not "delivered". See system design interview questions.

What the interviewer is checking: A structured outline covering requirements, flow, failure handling and trade-offs within a few minutes.

Likely follow-up: What do you change if a marketing campaign targets 5 million users at once?

Share the pipeline, isolate the channel adapters. Each adapter hides one provider behind a common interface, owns its rate limits and error mapping, and has its own queue and concurrency cap.

Channel differences matter: email is cheap and slow, needs bounce and complaint handling, and reputation depends on suppressing bad addresses. SMS is costly, length- and region-regulated, and often needs quiet hours. Push needs device tokens that expire, so a "token invalid" response must delete the token. Template per channel, honour per-channel opt-in, and fall back (push, then SMS) only for critical messages. Providers throttle, so respect their limits instead of retrying blindly.

What the interviewer is checking: Awareness of real channel differences and a clean adapter boundary.

Likely follow-up: How do you stop one broken provider from consuming all worker capacity?

Give every notification an ID and a state machine: queued, sending, sent, delivered, failed, dead-lettered. Providers report asynchronously through callbacks (webhooks), so accept those idempotently, verify their signatures, and update by ID; "sent" and "delivered" are different facts.

Retry only transient failures, with exponential backoff and random jitter, a maximum attempt count, then a dead-letter queue with an alert and a replay tool. Reuse one idempotency key for all attempts so a retry after a timeout cannot double-send. Show only a status summary to users, and keep raw attempts for support.

import random
random.seed(7)

def jittered(attempt, base=1.0, cap=30.0):
    return round(random.uniform(0, min(cap, base * 2 ** attempt)), 2)

print("ceilings:", [min(30.0, 1.0 * 2 ** i) for i in range(7)])
print("waits:   ", [jittered(i) for i in range(7)])

ceilings: [1.0, 2.0, 4.0, 8.0, 16.0, 30.0, 30.0]
waits:    [0.32, 0.3, 2.6, 0.58, 8.57, 10.97, 1.74]

What the interviewer is checking: State tracking, idempotent callbacks, and bounded retries ending in a dead-letter path.

Likely follow-up: A provider webhook arrives twice, out of order. How does your status update stay correct?

Do the arithmetic first: a day has 86,400 seconds, so 1,000,000 requests is about 12 per second on average. That is small; one modest instance can often handle it. The design is driven by peaks, not the average: traffic clusters (a 4-hour working window, a campaign, a retry storm), so plan for several times the mean, then check the numbers below.

What matters is per-request cost and dependencies: slow queries, the database connection pool, downstream limits, and the tail latency. Run at least two instances for availability, set timeouts and rate limits, and load-test to the measured peak with headroom. Do not shard or add Kafka for 12 requests a second.

per_day = 1_000_000
avg = per_day / 86_400
print(f"average: {avg:.1f} req/s")
print(f"x10 peak: {avg * 10:.0f} req/s")
print(f"60% of traffic in a 4h window: {0.6 * per_day / (4 * 3600):.1f} req/s")
print(f"in flight at x10 peak, 200 ms each: {avg * 10 * 0.2:.0f}")

average: 11.6 req/s
x10 peak: 116 req/s
60% of traffic in a 4h window: 41.7 req/s
in flight at x10 peak, 200 ms each: 23

What the interviewer is checking: Honest back-of-envelope maths, the average-versus-peak insight, and resisting over-engineering.

Likely follow-up: What if the same 1 million requests arrive in a single minute after an email campaign?

Requirements: files up to many GB, resumable on flaky networks, integrity guaranteed, processing must not block uploads. Flow: the client asks the API for an upload session; it uploads in chunks, directly to object storage via short-lived signed URLs so the API servers never proxy gigabytes. A chunk can be retried independently; the client resumes from the last confirmed chunk.

On completion the service verifies a checksum, stores metadata, and puts a job on a queue; workers stream-process the file in a staging area. Failure handling: idempotent jobs, retries, a dead-letter queue, expiry of abandoned sessions. Trade-offs: chunk size (more overhead versus cheaper retries) and virus scanning delay. Scan before exposing results.

What the interviewer is checking: Direct-to-storage upload, resumability, integrity checks, and decoupled processing.

Likely follow-up: How do you stop one customer's huge uploads from starving everyone else?

Separate doing the work from making it visible. Write everything to a staging location under a temporary name, verify the checksum, then publish with one atomic step: a same-filesystem rename, or a commit marker/manifest row that readers require. Readers never see a half-written file.

For the processing, stream in bounded chunks instead of loading the file, and make each unit idempotent (keyed by file ID plus chunk or row range) so a crash resumes instead of duplicating. Apply backpressure: bounded queues and worker pools, so a slow sink slows intake instead of exhausting memory. Clean up orphaned staging data on a schedule. Object stores lack cheap rename, so a manifest is the usual commit.

import hashlib, os, tempfile

def stage(data, chunk, part_path):
    h = hashlib.sha256()
    with open(part_path, "wb") as f:
        for i in range(0, len(data), chunk):
            piece = data[i:i + chunk]
            h.update(piece)
            f.write(piece)
        f.flush()
        os.fsync(f.fileno())
    return h.hexdigest()

def publish(part_path, got, expected, final_path):
    if got != expected:
        os.remove(part_path)
        return "rejected: checksum mismatch, nothing published"
    os.replace(part_path, final_path)   # atomic on one filesystem
    return "published"

data = os.urandom(10_000)
want = hashlib.sha256(data).hexdigest()
with tempfile.TemporaryDirectory() as d:
    part, final = os.path.join(d, "a.part"), os.path.join(d, "a.csv")
    got = stage(data, 4096, part)
    print("before publish, final exists:", os.path.exists(final))
    print(publish(part, got, want, final))
    print("after publish, final exists:", os.path.exists(final), "| leftover .part:", os.path.exists(part))
    got = stage(data, 4096, part)
    print(publish(part, got, "0" * 64, final + ".bad"))

before publish, final exists: False
published
after publish, final exists: True | leftover .part: False
rejected: checksum mismatch, nothing published

What the interviewer is checking: Staging then atomic publish, idempotent chunk processing, and backpressure.

Likely follow-up: The worker crashes at 80 percent. What state is the system in, and how does it recover?

Ask for numbers: peak load and growth, p95/p99 latency, availability target, durability (can we lose data?), consistency needs, recovery targets (RPO/RTO), security and compliance, cost ceiling. A vague "fast and reliable" cannot be tested.

Then walk failures, each with a planned response: an instance dies (health checks, redundancy), a dependency is slow (timeouts, circuit breaker, fallback), a retry storm (jitter, budgets), a poison message (dead-letter queue), a bad deploy (rollback), a zone or database failure (replication, failover, restore drill), duplicate delivery (idempotency). End with monitoring and an alert for each. Method: system design prep guide.

What the interviewer is checking: Quantified requirements and a systematic failure walk-through, not a list of technologies.

Likely follow-up: Choose one failure above and describe exactly what the user sees while it happens.

EC2 gives you virtual machines: you choose size, OS and patching, which suits custom or legacy workloads. EKS is managed Kubernetes: AWS runs the control plane, while you still design workloads and node capacity, which suits many containerised services. RDS is a managed relational database: backups, patching, replicas and failover are handled, but you do not get OS access. S3 stores objects (files) by key, durable and cheap per GB, but it is not a file system or a database.

A typical stack: services in containers on EKS or EC2, relational data in RDS, uploads and exports in S3. Details: AWS interview questions.

What the interviewer is checking: One-sentence clarity on each service and its boundary.

Likely follow-up: Why would you store uploads in S3 rather than on the application server's disk?

It presents one address and spreads requests across several instances, so no instance is a single point of failure and capacity can grow by adding more. Health checks remove an instance from rotation when it stops answering, which is why the check endpoint should test real readiness, not just "process is up".

A layer 4 balancer routes by IP and port; layer 7 understands HTTP, so it can route by path or host and terminate TLS. Algorithms: round robin for even requests, least connections for uneven ones. Keep the app stateless, otherwise you need sticky sessions, which unbalance the load.

What the interviewer is checking: Basics plus the health-check subtlety and the statelessness link.

Likely follow-up: An instance passes its health check but returns errors. What do you change?

A group of identical instances grows or shrinks between a minimum and maximum, driven by a metric (CPU, request count per instance, queue depth) or a schedule. New instances come from a template or image, join the load balancer once healthy, and surplus ones are drained and removed.

It only helps if instances are stateless and quick to start: no local sessions or files, configuration injected, and a startup time shorter than the load spike. Set a sensible minimum for availability, a maximum to cap cost, a cooldown to avoid flapping, and prefer a metric that predicts load (queue depth) over one that lags. Scaling a service cannot help if the database is the bottleneck.

What the interviewer is checking: Prerequisites for effective scaling and awareness of downstream bottlenecks.

Likely follow-up: Traffic spikes in 30 seconds but new instances need 3 minutes. What are your options?

Docker packages an application with its dependencies into an image: a read-only, layered template built from a Dockerfile. A container is a running instance of an image, isolated by operating-system features, sharing the host kernel, so it starts in moments and is lighter than a virtual machine.

The benefit is the same artefact running identically on a laptop, in CI and in production. Habits worth stating: small base images, copy the dependency file before the source so layer caching works, run as a non-root user, one main process per container, keep data in volumes, never bake secrets into an image. More: Docker course.

What the interviewer is checking: Accurate image/container distinction and practical Dockerfile hygiene.

Likely follow-up: Why does the order of lines in a Dockerfile change build time?

It keeps containers running as declared: you state the desired state, and controllers continually reconcile reality towards it, restarting failed containers, rescheduling when nodes die, and scaling replicas.

Core objects: a Pod runs one or more containers; a Deployment keeps N replicas of a Pod template and performs rolling updates; a Service gives them a stable name and load-balances across ready pods; ConfigMaps and Secrets inject configuration; an Ingress routes external HTTP traffic. Add readiness probes so traffic only reaches pods that can serve, and resource requests so the scheduler places pods sensibly. Course: Kubernetes.

What the interviewer is checking: The declarative model and correct roles of the basic objects.

Likely follow-up: What is the difference between a liveness probe and a readiness probe?

Rolling replaces instances gradually: cheap and the default, but old and new versions run together briefly, so they must be compatible. Blue-green keeps a full second environment and switches traffic at once: instant rollback, at the cost of duplicate capacity. Canary sends a small share of traffic to the new version, watches error and latency metrics, then widens: lowest risk, needs good observability.

Rollback means keeping the previous artefact and switching back, but the database is the catch: use backward-compatible changes (add the column first, remove the old one in a later release) so both versions work against the same schema. Feature flags separate deploying from releasing.

What the interviewer is checking: Choosing a strategy from risk and cost, and handling schema changes during rollback.

Likely follow-up: A release adds a non-null column. How do you ship it without breaking the old version?

Products in this space change every few months, so I would not argue from a feature list or declare a winner. I would run a small trial: pick two or three real tasks from the backlog (a bug fix, a test-writing chore, a multi-file refactor), give each tool to the same developers, and record time to a reviewed pull request, review comments caused by the tool's output, and how often suggestions were rejected.

Alongside that, compare the constraints that are not features: where code and prompts are sent and kept, admin and audit controls, language and editor fit, cost per seat against measured time saved, and how well the tool follows repository conventions. Decide on your own data, and repeat the trial when either product changes materially.

What the interviewer is checking: Whether you judge tools with evidence and team constraints rather than brand preference.

Likely follow-up: What would make you reject a tool outright, even if developers liked it?

I would not name a winner, because models and plans are revised often and the right choice depends on the task. I would build a small evaluation set from work we really do: summarise a design doc, explain a stack trace, draft a SQL query, write a unit test, answer a question from a pasted specification. Run both assistants on identical prompts, hide which is which, and have two engineers score correctness, completeness and tone against a short rubric.

Then weigh the practical side: context size needed, response speed, how each behaves when unsure, data-handling terms, API availability if we will integrate it, and cost at our volume. A result from today is a snapshot, so re-test every few months.

What the interviewer is checking: A repeatable, blind evaluation method and awareness that vendor comparisons go stale.

Likely follow-up: How would you stop evaluators from favouring the longer answer?

Treat the assistant as a fast junior pair, not the author. Start by writing the intent yourself: the behaviour, the interfaces and the tests that should pass. Give tight context (the relevant files, the conventions, the constraint), ask for one small change, and read the whole diff before accepting it.

Then loop: run tests, lint and type checks, fix or re-prompt, and commit in small steps. Keep design decisions, security-sensitive code and anything you cannot explain in your own hands. You stay accountable at review time, so the pull request description should say what you verified rather than that a tool wrote it.

What the interviewer is checking: That you use AI to speed up work you still own, with checkpoints instead of blind acceptance.

Likely follow-up: Which tasks would you never delegate to an assistant, and why?

Assume it is wrong until shown otherwise. First read for intent: does it solve the stated problem, and does every package, method and flag it mentions actually exist? Compile and run it, then use tests you wrote before seeing its output, including empty input, nulls, large values and concurrent access.

Then check what models tend to miss: error handling, resource cleanup, SQL built by string concatenation, secrets in code, new dependencies of unknown origin, and speed on realistic data volumes. Run static analysis and a dependency scan. If you cannot explain a line, rewrite it or ask the tool to justify it and verify that justification independently.

What the interviewer is checking: A concrete verification checklist, not trust in confident-sounding output.

Likely follow-up: The tests the tool wrote all pass. Why is that not enough?

Four limits matter in practice. Plausible but wrong output: a model can invent functions, options or citations with full confidence. Limited context: it only sees what you supply, so it can miss conventions or code in other modules. Stale knowledge: training stops at a cutoff, so newer library behaviour may be unknown. Variability: the same prompt can give different answers on different runs.

Add weak spots in exact arithmetic, long multi-step reasoning without checks, and having no accountability or business context of its own. I plan around them with tests, current documentation supplied in the prompt, small tasks, human review and clear rules on what data may be pasted.

What the interviewer is checking: Realistic awareness of failure modes and the habits that contain them.

Likely follow-up: How would you handle a library released after the model's training cutoff?

An agentic workflow lets a model choose its next step: it plans, calls tools such as search or a database query, reads the result, and decides whether to continue. In a fixed pipeline the steps are decided in advance by code. Prefer the pipeline when the path is known, since it is cheaper, faster and easier to test; use an agent when the route depends on what is found along the way, for example tracing a lost parcel across several systems.

Guard an agent with a tool allow-list, step and spend limits, a log of every action, and human approval before anything irreversible. Full course: AI agents.

What the interviewer is checking: Judgement about when autonomy is worth its cost, and the controls that make it safe.

Likely follow-up: How would you test an agent whose route differs on every run?

Draw two lanes on the board. The ingestion lane runs ahead of time: parser, cleaner, chunker, embedding model, then a vector store holding each vector plus its source, access group and date. The query lane runs per request: embed the question, fetch the closest chunks with the caller's permission filter applied, rerank if needed, assemble a prompt from those chunks alone, call the model, and return the reply with source ids.

Three design points to name: chunk quality caps retrieval quality, the prompt must say what to do when the context is silent, and retrieval and generation get scored separately. More in the RAG course.

def build_prompt(question, passages):
    ctx = "\n".join(f"[{p['id']}] {p['text']}" for p in passages)
    return (
        "Answer using ONLY the numbered context. Cite ids like [d2]. "
        "If the context lacks the answer, say you do not know.\n\n"
        f"Context:\n{ctx}\n\nQuestion: {question}"
    )

passages = [
    {"id": "d1", "text": "Library cards expire after 2 years."},
    {"id": "d2", "text": "Renewals can be done at the kiosk or online."},
]
print(build_prompt("How do I renew my card?", passages))

Answer using ONLY the numbered context. Cite ids like [d2]. If the context lacks the answer, say you do not know.

Context:
[d1] Library cards expire after 2 years.
[d2] Renewals can be done at the kiosk or online.

Question: How do I renew my card?

What the interviewer is checking: That you can describe both the ingestion and query paths and where permissions and refusal fit.

Likely follow-up: Where would you enforce per-user document permissions, and why there?

An embedding model maps text to a fixed-length vector so that texts with similar meaning land close together. "Reset my kiosk pin" and "forgot my locker code" share almost no words yet end up near each other. Closeness is usually measured with cosine similarity or a dot product.

Rules to remember: embed documents and queries with the same model, store the model name beside every vector because vectors from different models are not comparable, and re-embed everything when you switch. Embeddings capture topic well but can blur exact identifiers and negation.

What the interviewer is checking: A correct mental model plus the operational rules that cause real bugs.

Likely follow-up: You upgrade the embedding model. What happens to your existing index?

Keyword search matches the words typed, usually ranked with a scheme such as BM25, so it misses synonyms and rephrasings. Semantic search converts the query and the documents to embeddings and ranks by closeness of meaning, so "cheap flights" can find a page titled "budget airfares".

It is weaker on exact strings such as part numbers, error codes and names, which is why many systems run both and merge the lists. Judge quality with a set of real queries and the page that should come first for each, not by eyeballing a handful of examples.

What the interviewer is checking: Understanding the strengths and blind spots of each approach and how to measure them.

Likely follow-up: A user searches for the error code E-4021 and gets unrelated pages. What happened?

Vector search returns the stored vectors nearest to a query vector. The exact method compares the query with every vector, which is accurate but slow across millions of items. Approximate methods build an index, graph-based or cluster-based, so only a small slice of the data is visited, trading a little recall for a large speed gain.

Two practical points: measure recall against exact results on your own data, and be deliberate about metadata filters such as language or tenant, because filtering before or after the nearest-neighbour step can change both results and latency. The snippet is a brute-force version with a filter, and it was run.

import math
def unit(v):
    n = math.sqrt(sum(x * x for x in v))
    return [x / n for x in v]

docs = [
    {"id": "a", "vec": unit([0.9, 0.1, 0.2]), "lang": "en", "year": 2024},
    {"id": "b", "vec": unit([0.8, 0.3, 0.1]), "lang": "de", "year": 2024},
    {"id": "c", "vec": unit([0.1, 0.9, 0.3]), "lang": "en", "year": 2022},
]
def search(q, k, where):
    q = unit(q)
    pool = [d for d in docs if all(d[key] == val for key, val in where.items())]
    scored = sorted(((sum(a * b for a, b in zip(q, d["vec"])), d["id"]) for d in pool), reverse=True)
    return [(i, round(s, 3)) for s, i in scored[:k]]

print(search([1, 0.2, 0.1], 2, {}))
print(search([1, 0.2, 0.1], 2, {"lang": "en"}))

[('a', 0.989), ('b', 0.987)]
[('a', 0.989), ('c', 0.317)]

What the interviewer is checking: Knowing exact versus approximate search and that filters interact with the index.

Likely follow-up: How would you measure the recall your approximate index gives up?

ChromaDB is an open-source vector database. You create a collection, add documents together with their embeddings (produced by an embedding function you configure, or supplied by you) and optional metadata, then query with text or a vector to get the nearest items. Metadata filters narrow results, for example by source or tenant, and data can be kept in memory for experiments or persisted so it survives restarts.

It suits prototypes and small to medium workloads. For production I would still check scaling, backup, access control and operational fit against alternatives rather than assume it is enough.

What the interviewer is checking: A general, accurate picture of a vector store's role and a sober view of production readiness.

Likely follow-up: What goes wrong if the embedding function changes after data is already loaded?

It means specifying a task precisely enough that the output can be relied on, then testing it like code. A solid prompt states the context, the exact task, the input, the constraints and the output format; it adds one or two examples for tricky cases and says what to do when information is missing.

The engineering part is iteration with evidence: keep a set of test inputs, change one thing at a time, version the prompt, and compare results before shipping. Prefer structured outputs you can validate. Full course: prompt engineering.

What the interviewer is checking: Treating prompts as versioned, tested artefacts rather than folklore.

Likely follow-up: Your new prompt fixes three failing cases. How do you know it did not break others?

Fine-tuning continues training a pre-trained model on your own examples so its weights shift towards a behaviour: a house writing style, a strict output schema, domain vocabulary, or a narrow classification skill. It needs a clean set of input and output pairs, an evaluation set kept apart from the training data, and a plan to retrain when requirements shift.

It is not a dependable way to store facts, and small or noisy data can leave the model worse or narrower. Try prompting and retrieval first; tune when you have measured a gap they cannot close. Budget for data preparation, training, hosting and re-testing.

What the interviewer is checking: Knowing fine-tuning targets behaviour, needs good data, and is not the first tool to reach for.

Likely follow-up: How would you prove the tuned model beats the prompted base model?

QLoRA fine-tunes a model whose base weights are held in a quantised, low-precision form (commonly 4-bit) and kept frozen. Instead of updating every weight, it trains small low-rank adapter matrices attached to chosen layers, with gradients flowing through the quantised base into those adapters.

Memory drops sharply because the large base is stored compactly and only the small adapters carry gradients and optimiser state, so a model too big for full training can be tuned on far less hardware. The adapter can be saved and swapped separately. Quality is often reported to be close to ordinary LoRA, but you must still evaluate on your own task.

What the interviewer is checking: Precise understanding of quantised frozen base plus trainable low-rank adapters.

Likely follow-up: What do you lose compared with full fine-tuning?

No single switch removes them, so layer the defences. Ground the answer: retrieve source text and instruct the model to use only that. Give it an exit: a retrieval-score floor and an explicit "not found" path. Require citations that you can check against the retrieved passages. Constrain output with schemas or fixed options, and use low sampling randomness for factual tasks.

Then verify and measure: automatic checks that quoted ids exist, human review of samples, and a test set with unanswerable questions so you can track how often it correctly refuses. Add a human step for high-stakes answers.

def answer(question, hits, floor=0.75):
    # hits: list of (score, passage_id) from retrieval, best first
    if not hits or hits[0][0] < floor:
        return "I could not find this in the documents."
    return f"Answer drawn from {hits[0][1]}"

print(answer("late fee?", [(0.88, "fees-3")]))
print(answer("parking rules?", [(0.41, "fees-3")]))

Answer drawn from fees-3
I could not find this in the documents.

What the interviewer is checking: A layered mitigation plan with measurement, not a single trick.

Likely follow-up: How would you choose the score floor without guessing?

I ask three questions. Is the gap about knowledge or behaviour? Changing, private or citable facts point to RAG; style, format or a narrow skill point to tuning. How often does the data change, and who may see what? Retrieval handles updates and per-user filters at query time, while tuned weights cannot hide content from some users. What is the cost shape? RAG adds retrieval and longer prompts to every request; tuning adds upfront training and upkeep.

I start with prompting plus RAG and an evaluation set, and add tuning only for a measured behaviour gap. They can be combined. Deeper comparison: generative AI interview questions.

What the interviewer is checking: A decision framework built on the type of gap, data churn, access control and cost.

Likely follow-up: Give an example where you would use both together.

Use "I" for what you personally did and "we" for the team's result. Structure it as one line of context (the system and its goal), your specific responsibility, the two or three actions that were yours (a design you proposed, a module you built, a defect you traced), and the outcome.

Be ready to go one level deeper on anything you mention, because interviewers probe details. Avoid listing everyone's work, and avoid vague verbs such as "helped with". If the result is not measurable, say what changed, such as fewer manual steps, without inventing numbers. See the STAR method guide.

What the interviewer is checking: Clear ownership, honest scope and the ability to defend details.

Likely follow-up: Which part of that project was hardest, and what exactly did you do about it?

Pick a real, modest setback and tell it in four beats: what happened, which part was yours, what you changed afterwards, and where you have applied that change since. The last beat turns a confession into a lesson.

Good lessons are concrete and behavioural: "I now write the rollback plan before the deployment" beats "communication is important". Do not blame others, do not choose a failure caused by carelessness you would repeat, and do not offer a lesson with no later evidence. Keep it near two minutes.

What the interviewer is checking: Self-awareness, accountability and evidence that you changed your behaviour.

Likely follow-up: How would a teammate describe the same setback?

Answer in a decision-record shape: the problem and its constraints (deadline, team skills, data volume), the two or three options you genuinely considered, the criteria you weighted, why the chosen one won, and what you gave up. Mention how you validated it, such as a small spike or a benchmark.

"It is the industry standard" or "I knew it best" are inputs, not a full justification. Show that you would revisit the choice if a stated assumption changed, for example if traffic grew tenfold. Honest, constraint-driven reasoning beats a polished-sounding story.

What the interviewer is checking: Structured reasoning about alternatives and the willingness to revisit a decision.

Likely follow-up: What new fact would make you reverse that decision?

Name each tension as a pair: consistency against availability, delivery speed against test depth, one deployable against several services, cost against latency. For each, say what you picked, what it cost, and what would make you revisit it.

Illustrative: a parcel-tracking service might cache status for 30 seconds, accepting slightly stale data to relieve the database; the trigger to revisit would be customers needing live scan results. Tie every choice to a requirement and state the downside plainly. Claiming there were no trade-offs signals shallow analysis.

What the interviewer is checking: Whether you can articulate costs and revisit triggers, not only the benefits of your choice.

Likely follow-up: Which trade-off turned out wrong, and how did you find out?

Go through it in order. Know the numbers: requests per second, peak against average, payload sizes. Find the bottleneck by measuring: database queries and indexes, connection and thread pools, downstream calls. Then protect the service with timeouts, retries with backoff, rate limits, caching, back-pressure and a degraded mode.

Prove it with a load test at a multiple of expected peak, and make it operable: dashboards for latency percentiles and error rates, alerts, spare capacity or autoscaling, and safe rollout with rollback. Say what you would measure first rather than reciting tools, and if you have not done this at scale, describe the test you would run.

What the interviewer is checking: A measure-first, protect-then-operate approach to scale.

Likely follow-up: Latency doubles at peak but CPU is low. Where do you look first?

For design questions, list what can fail (a dependency down, slow responses, duplicate messages, partial writes, a bad deploy) and state the behaviour you want for each: timeout, retry, fallback, idempotent handling, alert. For a real incident, follow this order: impact and detection, mitigation first, root cause, permanent fix, then the process or monitoring change.

Keep it blameless and be specific about your own role. Do not invent an outage; if you have none, describe a failure from testing or a near miss. Strong answers end with a prevention that is now in place, such as a runbook or an alert.

What the interviewer is checking: Systematic failure thinking and an honest, blameless incident narrative.

Likely follow-up: How did you decide to mitigate before finding the root cause?

Spend the first five minutes on scope, not code. Confirm the entities (Book, Member, Loan), the must-have operations (create, read, update and delete books; borrow and return), the storage (in memory or a database) and the language. Say the endpoints aloud: POST /books, GET /books/{id}, PUT /books/{id}, DELETE /books/{id}, then POST /loans and POST /loans/{id}/return.

Build one vertical slice first: model, service, endpoint, one test, running. Then add validation, 404 and 409 (no copies left) handling, and the loan rules. In Spring Boot 3.x that is an entity, a JpaRepository and a @RestController (a sketch, not run here); the Python service below, which was run, shows the shape.

from dataclasses import dataclass
from itertools import count

@dataclass
class Book:
    id: int
    title: str
    copies: int = 1

class LibraryService:
    def __init__(self):
        self._books, self._ids = {}, count(1)

    def create(self, title, copies=1):
        if not title.strip() or copies < 1:
            raise ValueError("title required, copies >= 1")
        b = Book(next(self._ids), title.strip(), copies)
        self._books[b.id] = b
        return b

    def get(self, book_id):
        try:
            return self._books[book_id]
        except KeyError:
            raise LookupError(f"book {book_id} not found") from None

    def update(self, book_id, **changes):
        b = self.get(book_id)
        for k, v in changes.items():
            setattr(b, k, v)
        return b

    def delete(self, book_id):
        self.get(book_id)
        del self._books[book_id]

svc = LibraryService()
b = svc.create("Dune", 2)
svc.update(b.id, copies=3)
print(svc.get(b.id))
svc.delete(b.id)
try:
    svc.get(b.id)
except LookupError as e:
    print("404:", e)

Book(id=1, title='Dune', copies=3)
404: book 1 not found

What the interviewer is checking: Scoping, ordering of work, and a working slice early rather than a big-bang build.

Likely follow-up: Where would you put the rule that stops a book being borrowed when no copies remain?

Read the whole thing silently first and state its purpose in one sentence. Then walk top-down in blocks: inputs, main flow, branches, outputs and side effects. Spend your time on lines that carry decisions: conditions, loops, error handling and library calls.

If you meet something unfamiliar, say so and reason from names and types, or settle it with a tiny experiment; do not bluff. Point out anything wrong, risky or missing, such as an unchecked null or an unbounded query, because spotting issues shows ownership. Finish by saying how you would test it.

What the interviewer is checking: Genuine comprehension, honesty about gaps and a reviewer's eye.

Likely follow-up: You spot a bug halfway through your explanation. What do you do?

Read before you write: find the entry point, follow one request through the code, note the naming and error-handling conventions, and run the existing tests. Restate the new requirement and ask about edge cases before touching anything.

Make the smallest change that fits the existing structure: add a method or a field rather than reshaping the design, write a failing test first, make it pass, then re-run the old tests. Narrate trade-offs as you go, for example "I will extend rather than refactor because time is short", and mention cleanup you would do later but are not doing now.

What the interviewer is checking: Respect for existing code, test-first habits and communicated trade-offs.

Likely follow-up: The existing code has no tests. How does that change your plan?

Treat it as a normal requirement change, not a failure. Pause, restate the new contract in your own words and confirm what is affected: request shape, response shape, status codes or behaviour. Ask whether existing callers must keep working, because that decides between changing in place, versioning (/v2) or adding an optional field.

Then change it in layers, from the contract and tests outward to the handler and the service, rather than patching everywhere. Keep the old tests as a safety net and update only those that encode the old contract. Say aloud what the change costs and what you would document.

What the interviewer is checking: Composure, clarifying questions and a layered, test-backed response to change.

Likely follow-up: How would you roll out that change if real clients already use the old endpoint?

The trap is expecting a fresh object on every use. The singleton is built once and its dependencies are injected once, so it keeps that single prototype instance for its whole life. Prototype scope only produces a new object when the container is asked, and injection asks exactly once.

Fixes: inject an ObjectProvider and call getObject() per use, use @Lookup method injection, or give the prototype a scoped proxy so each call is delegated to a new instance. If state is per-call, pass it as arguments instead. Spring also does not run destroy callbacks on prototype beans. More in the Spring Boot course.

// Sketch only (Spring Boot 3.x), not run here
@Component
@Scope("prototype")
class Ticket {
    final String id = UUID.randomUUID().toString();
}

@Service
class Desk {
    private final ObjectProvider<Ticket> tickets;
    Desk(ObjectProvider<Ticket> tickets) { this.tickets = tickets; }

    String issue() { return tickets.getObject().id; } // new Ticket each call
}

What the interviewer is checking: Knowing that scope applies at creation and injection time, plus the standard remedies.

Likely follow-up: What is the difference between ObjectProvider and a scoped proxy here?

No. The compiler rejects it with "modifier final not allowed here". The final modifier stops overriding, and constructors are never inherited or overridden, so it would mean nothing. The same applies to static, abstract and synchronized.

The trap is mixing it up with the goal you probably have. To forbid subclassing, make the class final. To stop a subclass changing one method, make that method final. For immutable state, mark the fields final and assign them inside the constructor. A private constructor blocks instantiation from outside the class.

public class Bad {
    final Bad() { }
}

Bad.java:2: error: modifier final not allowed here
    final Bad() { }
          ^
1 error

What the interviewer is checking: Precision about modifiers and knowing the right tool for each intent.

Likely follow-up: Can a constructor be private, and what does that allow?

No. A transaction undoes only what the database controls. An email is an external side effect: once the mail call returns, nothing can unsend it. The reverse also bites: if the mail goes out and the commit then fails, the customer holds a confirmation for an order that does not exist.

Fix: send only after a successful commit, with @TransactionalEventListener(phase = AFTER_COMMIT). For reliability use a transactional outbox: write a pending-message row in the same transaction, and let a separate worker send it, mark it done and retry. Delivery then becomes at-least-once, so keep the send idempotent.

// Sketch only (Spring Boot 3.x), not run here
@Transactional
public void place(Order o) {
    orders.save(o);
    events.publishEvent(new OrderPlaced(o.id())); // not an email yet
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
void onPlaced(OrderPlaced e) {
    mailer.sendConfirmation(e.orderId());
}

What the interviewer is checking: Understanding transaction boundaries versus external side effects, and the after-commit and outbox fixes.

Likely follow-up: The after-commit mail call itself fails. What guarantees do you have, and what do you add?

The trap is answering "it calls new". First the container reads definitions from component scanning, @Bean methods and configuration classes into metadata called bean definitions; nothing is built yet. When a bean is needed (singletons are normally created at startup), it resolves constructor arguments, instantiates through the constructor or a factory method, then injects remaining dependencies.

After that come Aware callbacks, BeanPostProcessors and initialisation hooks such as @PostConstruct. A post-processor may replace the object with a proxy, which is how @Transactional and AOP work, so the object you receive can be a wrapper rather than your own class. Singletons are cached by name.

What the interviewer is checking: Knowing the definition-then-instantiation lifecycle and where proxies appear.

Likely follow-up: Why can @Transactional fail when a method calls another method on the same object?

A hand-written singleton can be broken by anything that creates instances behind its back: reflection calling the private constructor, deserialization building a fresh object, cloning when the class is Cloneable, several class loaders each holding their own copy, and unsafe lazy initialisation racing on first use. In Spring, "singleton" means one per container, so two contexts give two.

Defences: a single-element enum, which resists both reflection and serialization; readResolve on a serializable class; a constructor that throws if an instance exists; and a holder class for thread-safe lazy loading. The snippet, which was run, shows the first two attacks succeeding.

import java.io.*;
import java.lang.reflect.Constructor;

public class Registry implements Serializable {
    private static final Registry INSTANCE = new Registry();
    private Registry() {}

    public static void main(String[] args) throws Exception {
        Constructor<Registry> c = Registry.class.getDeclaredConstructor();
        c.setAccessible(true);
        System.out.println("reflection: " + (c.newInstance() != INSTANCE ? "second instance" : "same"));

        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        try (ObjectOutputStream out = new ObjectOutputStream(bos)) { out.writeObject(INSTANCE); }
        Object copy = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray())).readObject();
        System.out.println("deserialization: " + (copy != INSTANCE ? "second instance" : "same"));
    }
}

reflection: second instance
deserialization: second instance

What the interviewer is checking: A complete list of singleton-breaking paths and a matching defence for each.

Likely follow-up: Why does a single-element enum resist reflection?

No, and the trap is equating speed with understanding. A model produces plausible code; it cannot know your system's constraints, and you cannot review what you do not understand. Without the concepts you will not notice that a generated singleton is not thread-safe, that a transaction does not cover an email, or that an index is missing.

The fix is to use AI to accelerate work you could explain and to explain things back to you, then verify with tests and primary documentation. Practise by predicting what code will do before running it. In a live round, be ready to justify every line you accepted.

What the interviewer is checking: Whether you see AI as an accelerator that still depends on your own judgement.

Likely follow-up: Give an example where a fluent AI answer would have misled someone lacking the basics.