If you've sat through enough interviews, you'll notice the same topics keep coming up. I've gathered 38 questions I've actually been asked in Java/Spring backend interviews and grouped them by theme. Let's walk through how to answer each one. Java Fundamentals Features of Java Three OOP pillars are the safe answer. Encapsulation — Bundle data and behavior together, expose only what's needed. Inheritance — Child classes inherit attributes and behavior from parent classes. Polymorphism — The same interface can call different implementations. Some include abstraction to make it four. It also helps to mention that Java runs on the JVM (Write Once, Run Anywhere) and uses garbage collection for automatic memory management. Interviewers also ask about modern Java features these days. Knowing the highlights from Java 21 (LTS) onward goes a long way. Record (Java 16+) — Declare immutable data classes in one line Sealed Class (Java 17+) — Explicitly restrict which classes can extend a parent Pattern Matching (Java 21+) — Pattern matching for switch and instanceof Virtual Threads (Java 21+) — The result of Project Loom; lightweight threads for concurrency Class vs. Object Class — A blueprint for creating objects. Defines attributes (fields) and behavior (methods). Object — An actual instance in memory, created from a class. If a fish-shaped bread mold is the class, each bread that comes out of it is an object. Data Types (Primitive vs. Reference) Primitive — The value itself sits on the stack. The eight types: byte, short, int, long, float, double, char, boolean. Reference — Holds the address of an object on the heap. Classes, arrays, and interfaces are all reference types. int a = 10; // Primitive: stores the value 10 directly String s = "hello"; // Reference: stores the heap address Instantiation The act of creating an object in memory from a class blueprint. You use the new keyword. User user = new User(); // Instantiating the User class The resulting user is called an instance of the class. It's nearly synonymous with "object," but you use "instance" when you want to emphasize which class it came from. Interface vs. Abstract Class Aspect Interface Abstract Class Purpose Enforce contract Shared logic + partial enforcement Multiple inheritance Yes No (single inheritance) Fields Only public static final Any kind Methods abstract + default + static abstract + concrete When to use "What it can do" "What it is (is-a)" An interface is a contract — "this class can do these things." An abstract class lets you share common implementation while forcing subclasses to implement specific methods. Why Use Generics? The one-line answer: type safety + code reuse. // Without generics List list = new ArrayList(); list.add("hello"); String s = (String) list.get(0); // Cast required, runtime risk // With generics List&x3C;String> list = new ArrayList&x3C;>(); list.add("hello"); String s = list.get(0); // No cast, type-checked at compile time The biggest win is catching ClassCastException at compile time instead of letting it explode at runtime. Collections Framework The Big Picture Three main interfaces to know. List — Ordered, allows duplicates (ArrayList, LinkedList) Set — Unordered, no duplicates (HashSet, TreeSet, LinkedHashSet) Map — Key-value pairs (HashMap, TreeMap, LinkedHashMap) Map doesn't extend Collection, but it's still part of the framework. Java 21 added Sequenced Collections. The SequencedCollection, SequencedSet, and SequencedMap interfaces give you a consistent API for the first/last element (getFirst(), getLast(), addFirst(), addLast(), reversed()). Before this, every LinkedList, LinkedHashSet, and LinkedHashMap had its own way to access the ends. Array vs. ArrayList Item Array ArrayList Size Fixed Dynamic Type Both primitive and reference Reference only (generics) Performance Fast (lightweight) Slight overhead Features Minimal Rich (add, remove, contains, ...) Internally, ArrayList is also backed by an array. When capacity runs out, it creates a larger array and copies everything over to fake dynamic sizing. Key-Value / Deduplication Key-value: Map family → HashMap, TreeMap, LinkedHashMap Deduplication: Set family → HashSet, TreeSet, LinkedHashSet What Works in for-each Anything that implements the Iterable interface, plus arrays. public interface Iterable&x3C;T> { Iterator&x3C;T> iterator(); } Collection extends Iterable, so List and Set work directly. Map doesn't work directly — you need to convert it via entrySet(), keySet(), or values(). Spring &x26; DI/IoC DI and IoC IoC (Inversion of Control) — Object creation and lifecycle are managed by the framework (container), not the developer. DI (Dependency Injection) — Objects don't create their dependencies themselves; they receive them from outside. DI is one way to implement IoC. // Without DI public class OrderService { private UserRepository repo = new UserRepository(); // Tight coupling } // With DI public class OrderService { private final UserRepository repo; public OrderService(UserRepository repo) { // Injected from outside this.repo = repo; } } The benefits: lower coupling, easier testing, better reusability. Spring Bean Scope singleton (default) — One instance per container prototype — A new instance per request request — One per HTTP request (web only) session — One per HTTP session (web only) application — One per ServletContext (web only) Most service beans are stateless, so singleton is enough. Spring Version As of 2026, the practical standard is Spring Boot 3.x / Spring Framework 6.x. The key changes: Java 17+ required (Spring Boot 3.2 added official Java 21 support, enabling Virtual Threads) javax.* → jakarta.* package migration (Jakarta EE 9 transition). The biggest migration headache. GraalVM Native Image officially supported Observability standardized (Micrometer + OpenTelemetry) Projects still on Spring Boot 2.x face this migration, which is why interviewers love asking about it. REST Standard Annotations (HATEOAS / OpenAPI) When an interviewer asks "Spring's API annotations don't conform to the standard — which library makes them standard-compliant?", they're usually pointing at one of two things: HATEOAS (Hypermedia As The Engine Of Application State) — The final stage of true REST as defined by Roy Fielding. Spring offers the Spring HATEOAS library. OpenAPI 3 / Swagger — The standard for API specs. In Spring, springdoc-openapi is the de facto choice (the older SpringFox is deprecated). HATEOAS embeds links (href) to next actions in responses, getting closer to true REST. { "id": 1, "name": "User", "_links": { "self": { "href": "/users/1" }, "orders": { "href": "/users/1/orders" } } } Full HATEOAS adoption is rare in practice — standardizing API specs with OpenAPI is far more common. HTTP &x26; REST HTTP HyperText Transfer Protocol — The protocol clients and servers use on the web Stateless — Each request is independent; the server doesn't remember prior requests Request-response structure: method, URL, headers, body Default port 80, HTTPS uses 443 It also helps to know the version differences. Version Features Transport HTTP/1.1 Text-based, Keep-Alive TCP HTTP/2 Binary, multiplexing, header compression (HPACK), server push TCP + TLS HTTP/3 Runs on QUIC, 0-RTT, solves TCP head-of-line blocking UDP + TLS 1.3 As of 2026, most major CDNs and large services have HTTP/3 enabled. HTTP Methods: Safety and Idempotency Method Safe Idempotent Use GET Yes Yes Read HEAD Yes Yes Headers only OPTIONS Yes Yes Check supported methods PUT No Yes Full update/create DELETE No Yes Delete POST No No Create PATCH No No Partial update Safe — Doesn't change server state (read-only) Idempotent — Multiple identical requests produce the same result HTTPS HTTP plus TLS/SSL encryption. The three guarantees to remember: Confidentiality — Encrypts data in transit Integrity — Ensures data isn't tampered with along the way Authentication — Verifies the server is who it claims to be, via certificates The handshake works like this: exchange a session key safely with asymmetric crypto, then switch to fast symmetric crypto for the rest. TLS 1.3 is the standard now. Faster 1-RTT handshake, and weak algorithms (RSA key exchange, CBC, SHA-1) are gone. TLS 1.0/1.1 have been deprecated for years, and TLS 1.2 is being phased out as well. RESTful API REST stands for REpresentational State Transfer. Core principles: Identify resources by URL — /users/1 Express actions with HTTP methods — GET, POST, PUT, DELETE Stateless — The server doesn't store client state Representation — Resource state is conveyed via JSON, XML, etc. URLs hold nouns; actions go in HTTP methods. Bad: GET /getUser/1 Good: GET /users/1 Bad: POST /deleteUser/1 Good: DELETE /users/1 OSI Layers and HTTP Layer Name Examples 7 Application HTTP, FTP, SMTP, DNS 6 Presentation SSL/TLS, JPEG, ASCII 5 Session NetBIOS, RPC 4 Transport TCP, UDP 3 Network IP, ICMP 2 Data Link Ethernet, MAC 1 Physical Cables, signals HTTP lives at layer 7 (Application), TCP at layer 4, IP at layer 3. TLS in HTTPS is usually classified at layer 6 (Presentation). Web Server &x26; Servlet Web Server vs. WAS Web Server — Serves static content (HTML, CSS, images). Nginx, Apache HTTPD. WAS (Web Application Server) — Handles dynamic content and business logic. Tomcat, Jetty. A common production setup is Nginx in front + Tomcat behind. The web server handles static assets, the WAS handles dynamic processing — splitting the load. How a Servlet Works A client request arrives The servlet container (Tomcat etc.) receives it URL mapping locates the right servlet (instantiating it if needed) A thread is allocated to call service() → doGet() / doPost() The response goes back to the client A servlet is a singleton, so multiple requests share the same instance. That means storing state in instance variables is dangerous. Since Jakarta EE 9, the package is javax.servlet → jakarta.servlet, and Spring Boot 3.x follows. From Spring Boot 3.2 onward, enabling Virtual Threads drastically lowers the cost of the thread-per-request model. If you need non-blocking, Spring WebFlux (reactive) is also an option. Servlet Filter A component that intercepts requests and responses in front of the servlet. Useful for authentication, logging, encoding conversion, CORS, and more. Client → Filter 1 → Filter 2 → Servlet → Filter 2 → Filter 1 → Client Spring's Interceptor is similar but kicks in at a different point. Filter runs before DispatcherServlet, Interceptor runs after DispatcherServlet but before the controller. Cookie vs. Session Item Cookie Session Stored at Client (browser) Server Security Relatively weak Stronger Size 4KB limit Server memory Expiry Set duration Browser close (or timeout) Common rule of thumb: sensitive data goes in the session, simple identifiers and remember-me tokens go in cookies. Remember-me lives in cookies because it must survive a browser restart — sessions disappear on close or timeout. It's worth knowing the cookie security flags: HttpOnly — Inaccessible from JavaScript (XSS defense) Secure — Sent only over HTTPS SameSite — Strict / Lax / None. CSRF defense. Chrome's default is Lax now. Partitioned (CHIPS) — Isolates third-party cookies, prevents cross-site tracking These days, stateless token authentication with JWT (JSON Web Token) is also widespread. It avoids server memory and scales horizontally well, but token revocation is hard. The usual workaround: short access tokens + longer refresh tokens. Security Defending Against SQL Injection The most reliable defense is PreparedStatement (parameter binding). // Dangerous: string concatenation String sql = "SELECT * FROM users WHERE id = '" + userId + "'"; // Safe: parameter binding String sql = "SELECT * FROM users WHERE id = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, userId); "Doesn't MyBatis or JPA block this automatically?" — Partly, but not entirely. MyBatis {} becomes a PreparedStatement and is safe; ${} is string substitution and unsafe JPA's JPQL is safe, but concatenating strings into a Native Query is just as risky Bottom line: even with an ORM, be careful whenever you build SQL fragments dynamically from strings. Proxy vs. Gateway Proxy — A middleman between client and server. Forwards requests within the same protocol. Forward Proxy — Client-side (corporate network → external) Reverse Proxy — Server-side (external → distributed internal servers, e.g., Nginx) Gateway — Adds protocol translation, routing, auth, logging, and other value-add features. API Gateway is the canonical example. In short: proxy = simple forwarding, gateway = entry point that applies policies. In the MSA era, Service Mesh (Istio, Linkerd) often comes up. A sidecar proxy (like Envoy) handles service-to-service communication at the infrastructure layer — pulling cross-cutting concerns like mTLS, traffic shaping, and observability out of application code. Message Queues &x26; Caches RabbitMQ Features Built on AMQP (Advanced Message Queuing Protocol) Producer → Exchange → Queue → Consumer flow Supports message persistence (disk-backed) Flexible routing via Exchange types Wide language client support RabbitMQ Exchange Types (Beyond Just Queueing) You don't push directly into a queue — the Exchange routes messages to queues based on rules. Exchange Type Behavior Direct To the queue whose routing key matches exactly Topic Routing key pattern matching (*, ) Fanout Broadcast to all bound queues Headers Routing based on message headers The Topic Exchange is what people mean by "publishing to a topic." It's great for patterns like order.created, order.cancelled. For reference, RabbitMQ 4.x added Streams, a new persistent log structure for Kafka-like replay and long retention scenarios. Heavy event streaming is still Kafka territory, while RabbitMQ shines as a reliable work queue. Caches Other Than Redis (In-Memory) If they ask about "RAM caches," they mean local in-memory caches. Caffeine — The most popular high-performance in-memory cache for Java Ehcache — A Java-world veteran; supports distributed caching too Guava Cache — Predecessor of Caffeine; Caffeine is now recommended Memcached — Distributed in-memory cache (simpler than Redis) Redis is a separate server over the network; Caffeine runs inside the JVM. For fast in-process caching, go Caffeine. For sharing across servers, go Redis. JavaScript Why Minify? Smaller files → faster downloads Lower bandwidth costs Faster parsing Minifiers strip whitespace, line breaks, and comments, and shorten variable names. It's not about security (obfuscation is a different thing). These days, builds are mostly handled by Go/Rust-based tools like esbuild, swc, Rolldown. They're tens of times faster than Webpack/Babel, which is why they power next-gen bundlers like Vite and Turbopack. Inline vs. External Item Inline (&x3C;script>...&x3C;/script>) External (&x3C;script src="...">) HTTP requests None extra Extra request Caching Not cacheable Browser-cacheable Reuse Duplicated per page Shared across pages Maintainability Hard Easy Initial render Can be faster First request is slower In the HTTP/1.1 era, the cost of an extra external request was painful. With HTTP/2 multiplexing, fetching multiple external files no longer hurts much. The recommended approach is to split modules into external files, and inline only the critical CSS/JS needed for the first paint. Where to Place Inline Scripts In &x3C;head> — Runs before the page renders, can't access the DOM At the end of &x3C;body> — Runs after DOM load; the common recommendation In &x3C;head> with defer/async — Parallel download with controlled execution timing If your code touches the DOM, just before &x3C;/body> is safe. Or use the DOMContentLoaded event. The modern best practice is to put scripts in &x3C;head> with defer or type="module". Both don't block HTML parsing and execute in order after the DOM is ready. &x3C;!-- Modern recommended pattern --> &x3C;script type="module" src="/app.js">&x3C;/script> &x3C;script defer src="/legacy.js">&x3C;/script> Collaboration &x26; Communication How Do You Handle Disagreements? This question is really about attitude and reasoning process. The model answer follows this flow: Hear them out fully — Understand their intent and reasoning Confirm a shared goal — "We both want X, right?" Argue from data and evidence — Objective grounds, not emotion Disagree and Commit — Once a decision is made, support it 100% The core mindset: "It's not about winning; it's about reaching a better outcome." Wrapping Up Each interview question is really a tool to gauge how solidly you grasp the fundamentals. Don't just rattle off keywords — practice articulating why something works the way it does and how it's used in practice. When you don't know an answer, it's better to say "I'm not sure exactly, but I've encountered this in such-and-such context." Pretending to know is the most dangerous move. People take different roads seeking fulfilment and happiness. Just because theyre not on your road doesn't mean they've gotten lost.— Dalai Lama

When you revisit interview questions, even concepts you thought you knew well need another pass. Let me walk through traffic handling, concurrency, caching, indexing, and data structures in one go. Traffic and Performance How much traffic have you handled? It depends on the service, but it helps to anchor your answer somewhere between hundreds of thousands of daily requests and a few hundred peak RPS. What matters more than the absolute numbers is what bottlenecks you hit at that scale and how you solved them. Interviewers don't want to hear "we increased the DB connection pool." They want to hear something layered: "I checked the slow query log, added an index, and when that wasn't enough, introduced a cache." Articles or topics you've studied for handling large-scale traffic Here are some go-to resources. Woowahan Brothers tech blog for large-traffic case studies (a Korean food-delivery company with rich content on Java/Spring scaling) Netflix Tech Blog on resilience patterns (Hystrix, Circuit Breaker) Martin Fowler on CQRS and Event Sourcing High Scalability for architecture case studies The key themes boil down to horizontal scaling, asynchronous processing, layered caching, and the tradeoffs between pessimistic and optimistic locking. Concurrency and Parallel Processing WebFlux vs. ExecutorService WebFlux is a non-blocking model based on reactive streams. A small number of event-loop threads handle many requests. ExecutorService, on the other hand, is a thread-pool-based explicit task runner. You hand a unit of work directly to the pool. Aspect WebFlux ExecutorService Model Non-blocking / event loop Blocking / thread pool Best for I/O-bound, long waits CPU-bound, explicit async Learning curve Steep Gentle Debugging Hard to follow stack traces Straightforward WebFlux only pays off when the entire path is non-blocking. One blocking line in the middle can make performance worse. Where does Virtual Thread fit in? Virtual Threads (Project Loom), GA since Java 21 LTS, changed this picture significantly. The point is that you can write plain synchronous code and still get non-blocking-level throughput. try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(() -> userClient.findById(id)); } A virtual thread isn't pinned 1:1 to an OS thread. When it makes a blocking call, it parks off the carrier thread and resumes later. So OS threads aren't held during I/O waits. Aspect WebFlux Virtual Thread Code style Reactive chains (Mono/Flux) Plain synchronous code Learning curve Steep Almost none Debugging Hard Normal stack traces Maturity Long-standing Maturing fast across 21–25 LTS Virtual threads aren't a silver bullet either. If you call blocking I/O inside a synchronized block, the carrier thread gets pinned, and you lose the benefit. Java 24 relaxed most of these pinning issues, but you still need to audit library compatibility and ThreadLocal usage. The question "Do I really need WebFlux for a new project?" has a different answer now. If your goal is just multiplexing I/O, virtual threads are often the simpler choice. Couldn't you just tweak the parallelStream thread setting? parallelStream() uses the shared ForkJoinPool (commonPool) by default. You can adjust parallelism via a system property. System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "8"); The catch is that the common pool is shared across the entire JVM. Heavy work in one place affects others. For isolation, it's safer to create your own ForkJoinPool and run inside it. ForkJoinPool customPool = new ForkJoinPool(4); customPool.submit(() -> list.parallelStream().map(...).toList()).get(); parallelStream vs. ExecutorService — when is each more efficient? Different jobs. parallelStream: best for CPU-bound transformations over a collection. Works well when tasks are short and uniform. ExecutorService: best when the unit of work is well-defined and you want explicit control over scheduling, results, and cancellation. Suits I/O work or workloads where task durations vary. In short: data processing pipelines lean toward parallelStream; independent async tasks lean toward ExecutorService. parallelStream vs. plain stream — which wins? Plain streams are single-threaded, so they're faster when data is small, computation is light, or order matters. There's no parallelization overhead (splitting work, merging results). parallelStream wins only when all of these line up: Data set is large enough (typically tens of thousands or more) Computation is heavy (CPU-bound) No shared state or order dependencies Splittable data structure (ArrayList, IntStream.range — LinkedList is inefficient) Throwing parallelStream at a small collection just makes it slower. Non-Blocking I/O Is non-blocking I/O always better? No. It depends on the workload. It clearly wins when you have many concurrent connections and long I/O waits. For CPU-bound work, the difference is negligible — sometimes worse. Performance downsides of non-blocking I/O Less context switching, but more code complexity. You have to manage callbacks, reactive chains, and error propagation. One blocking line can ruin the whole thing. If an event-loop thread blocks, every request stalls. Debugging and stack traces are painful. Async boundaries break the call stack. No win for CPU-bound work. More threads can't beat the core count. Caching Cache experience Common tools: Redis, Caffeine, Ehcache. Typical use cases: Caching responses for read-heavy query APIs Caching external API call results Session/auth token stores Distributed locks When does the cache get refreshed? Depends on the strategy. TTL expiration: simplest — invalidate after a time window. Write-Through: write to DB and cache simultaneously. Write-Behind: write to cache first, flush to DB asynchronously. Cache-Aside (Lazy Loading): on a cache miss, read from DB and populate. On update, invalidate or refresh. Event-driven invalidation: refresh from DB change events (Kafka, CDC). How can cache–DB consistency break? It can. Common scenarios: In the brief gap between DB update and cache invalidation, another request reads the old value and refills the cache. In a multi-instance setup, one node refreshes while another reads stale data. A transaction rolls back, but the cache was already updated. During TTL, the DB changes, and stale data stays visible. Mitigations: invalidate the cache after the DB transaction commits, use a distributed lock to serialize updates, or use a version key to ignore stale entries. JVM and Monitoring How to prevent OOM in a Java application For prevention: Tune heap size and GC algorithm for your workload (-Xmx, -Xms, -XX:+UseG1GC, etc.) Avoid memory leaks: don't pile into static collections forever, clean up ThreadLocals, cap cache sizes Stream large data: don't load entire files or DB results into memory Avoid resource leaks: use try-with-resources GC choice also depends on workload. G1GC: solid default for most server workloads. Balanced throughput/latency. ZGC: production-ready since Java 15. Targets sub-millisecond pauses even on tens of GB to TB heaps. Java 21 introduced Generational ZGC (-XX:+UseZGC -XX:+ZGenerational), closing the throughput gap. Shenandoah: another low-latency OpenJDK GC with similar goals. Parallel GC: for batch jobs where throughput matters more than latency. For latency-sensitive, high-traffic services, more teams are moving from G1 to Generational ZGC. When OOM does happen: Use -XX:+HeapDumpOnOutOfMemoryError to auto-save a heap dump. Analyze leaks with MAT (Memory Analyzer Tool). Read GC logs for patterns (steady growth → leak; sudden spike → traffic pattern). Bump the heap as a stopgap, but fix the leak as the real solution. How did you monitor servers? These days OpenTelemetry (OTel) is effectively the standard. You emit metrics, logs, and traces through one SDK/protocol (OTLP), and pick the backend separately. By layer: Collection (SDK / agent): OpenTelemetry Java Agent, Micrometer Tracing Metrics backend: Prometheus + Grafana, CloudWatch Logs backend: Loki, Elasticsearch, OpenSearch Traces backend: Grafana Tempo, Jaeger Commercial APM: DataDog, New Relic, Grafana Cloud (all support OTLP ingest) Korean tools: Pinpoint and Scouter are still around, but new systems trend toward OTel Alerting: Grafana Alert, PagerDuty, Slack integrations The real goal is to see traffic, error rate, latency, and resource use (USE/RED metrics) on one dashboard, with traceId stitching logs, metrics, and traces together. synchronized and Atomic Operations Explain synchronized synchronized is Java's monitor-lock-based synchronization keyword. Apply it to a method or block, and only the thread holding the same monitor can enter. public synchronized void increment() { count++; } Internally, lock state is recorded in the object header's Mark Word, and the JVM escalates from biased lock → lightweight lock → heavyweight lock based on contention. Problems with synchronized Performance overhead: under heavy contention it escalates to OS-level (heavyweight) locks, increasing context switches. Deadlock risk: tangle the lock acquisition order and you're stuck. Reentrant but not interruptible: Lock offers lockInterruptibly(); synchronized doesn't. No fairness control: no guarantee about which thread gets the lock next. No timeout: it can wait forever. Alternatives like ReentrantLock, ReadWriteLock, and StampedLock give you finer control. Do you know AtomicInteger? AtomicInteger is a lock-free integer class built on CAS (Compare-And-Swap). Internally it calls Unsafe.compareAndSwapInt (or VarHandle on newer versions). AtomicInteger counter = new AtomicInteger(0); counter.incrementAndGet(); It uses an atomic CPU instruction instead of taking a lock, which makes it ideal for lightweight counters. How would you implement AtomicInteger yourself? The core idea is a CAS loop. public class MyAtomicInteger { private volatile int value; private static final VarHandle VALUE; static { try { VALUE = MethodHandles.lookup() .findVarHandle(MyAtomicInteger.class, "value", int.class); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public int incrementAndGet() { int prev, next; do { prev = value; next = prev + 1; } while (!VALUE.compareAndSet(this, prev, next)); return next; } } The recipe: volatile for visibility + CAS for atomicity + retry on failure. When to use AtomicInteger and when not to Good fits: Counting or flags on a single variable Low-contention environments Avoid in these cases: Heavy contention: CAS retries explode and performance tanks. Reach for LongAdder, which spreads work across cells. Internally, the JDK marks those cells with @jdk.internal.vm.annotation.Contended to prevent false sharing (performance loss from sharing cache lines). Multi-variable consistency: locks or transactions are a better fit. Data Structures: HashMap and HashSet When to use HashSet and HashMap When you need average O(1) lookup/insert. HashMap is a key-value map; HashSet is a duplicate-free set. Internally, HashSet wraps HashMap. When they don't fit: Need ordering: LinkedHashMap, LinkedHashSet Need sorting: TreeMap, TreeSet (O(log n)) Need concurrency: ConcurrentHashMap No-null requirement: Hashtable and ConcurrentHashMap reject nulls When HashSet doesn't perform as expected hashCode() is poorly distributed — collisions push you toward O(n). equals() and hashCode() are inconsistent — you can't find what you put in. Mutable keys with mutated fields — the hash drifts, lookups fail. Initial capacity is too low — frequent resizing (rehash). Load factor is too high — more collisions. Since Java 8, when a bucket's collisions exceed a threshold, it converts to a Red-Black Tree for O(log n). But fundamentally, a good hashCode() matters most. ThreadLocal Have you used ThreadLocal in Java? Yes — typical uses: Per-request context: auth info, transaction IDs, MDC (log context) Reusing non-thread-safe objects like SimpleDateFormat Spring's RequestContextHolder and TransactionSynchronizationManager rely on ThreadLocal internally The catch: always call remove() to clean up. In thread-pool environments, threads are reused, so a leftover ThreadLocal can carry into the next request — leading to security bugs or memory leaks. MySQL Indexes What is a MySQL index and when should you use one? An index is a separate data structure that speeds up access to table data. Like a book's table of contents, it helps you find the right rows fast. Good places to add an index: Columns frequently used in WHERE JOIN keys ORDER BY / GROUP BY columns High-cardinality columns (many distinct values) MySQL 8.0 added more index options: Descending Index: handle descending sort at the index level Invisible Index: hide from the optimizer to safely test impact Functional Index: index expressions like JSON_EXTRACT(...) or LOWER(col) Multi-Valued Index (JSON arrays): index values inside a JSON array Are more indexes always better? No. Indexes raise write costs. Every INSERT, UPDATE, and DELETE has to update every index. They also use disk space, and the optimizer might pick the wrong one. The rule: only the minimum needed for actual query patterns. B+ Tree as the index data structure InnoDB uses a B+ Tree. Key properties: Actual data (or PK) lives only in leaf nodes Leaf nodes form a doubly-linked list, making range scans fast Balanced tree — every leaf is at the same depth Optimized for disk I/O page size — one I/O reads many keys InnoDB's PK index is a clustered index, so the leaves store the actual rows. Secondary indexes store PK values in their leaves and then do a second lookup against the clustered index (called a back-to-base or lookup). charAt Type Issues Cases where charAt's return type vs. receiving type can cause bugs String.charAt(int) returns a char. But Java treats char as an unsigned 16-bit integer, so it auto-promotes to int and you can get unexpected results. String s = "1"; int x = s.charAt(0); // 49 (ASCII for '1') int y = s.charAt(0) - '0'; // 1 If you just add s.charAt(0), you get 49, not 1. Comparisons trip people up too. char c = '1'; if (c == 1) { ... } // false (49 != 1) if (c == '1') { ... } // true Another big trap: Unicode supplementary characters (surrogate pairs). Emojis and some CJK characters are encoded as two chars, so a single charAt(i) won't return the full character. String s = "𝕏"; // U+1D54F s.length(); // 2 s.charAt(0); // returns half a surrogate s.codePointAt(0); // 119887, the full code point For character-level work, use codePointAt, String.codePoints(), or Character.toChars(). Wrap-up Interview questions aren't about memorizing answers — they're about explaining the tradeoffs in real situations. The same question gets a much deeper answer when you can cover both "why does it work this way?" and "when would I pick something else?" If any of these 25 questions felt fuzzy, run a small example in code to lock it in. Difficulties increase the nearer we get to the goal.— Johann Wolfgang von Goethe

When you're preparing to launch a startup, it's tempting to think, "If I just land one government grant, I'll be set." But in reality, plenty of companies fail even after receiving one. Here's what I learned from a talk by Harrison Choi, CEO of ExitUp (a Korean accelerator). Common Misconceptions About Government Grants Government grants aren't a "nice-to-have, no big deal if I miss out" kind of thing. You should prepare as if you'll definitely be selected — that's the mindset. But here's an important counterpoint. Don't become dependent on grants. Some founders stay in the black and skip fundraising, only to shut down when external shocks (like COVID) hit. And one more thing worth knowing. Investors tend to avoid items that failed to win a government grant. "Never applying" and "applying and getting rejected" are two very different stories. Funding by Growth Stage The kind of investors you'll meet changes as your startup grows. Stage Main Investors Seed ~ Pre-A Angel investors, FFF, accelerators Series A ~ B Accelerators, venture capital Series C ~ Pre-IPO Venture capital, specialized finance firms, asset management firms FFF stands for Family, Friends, and Fools — the close circle who often fund you in the earliest days. MVP and MBP: How Long to Prepare Two deliverables matter most when you're seeking investment. MVP (Minimum Viable Product): The minimum functional product. Expect 3 to 6 months. MBP (Minimum Business Plan): The minimum business plan. Expect 3 days to 1 week. MBPs can be drafted quickly, but an MVP needs real time to build. How to Do Market Research Market research doesn't need to start with anything grand. Two steps are enough to get going. Use Google search to gauge market size Define your customer segment Choosing the Right Market Matters One of the hardest parts of writing a business plan is answering, "What market am I actually in?" Take a calendar app as an example. Online calendar market? Most people use it for free — how do you monetize? Calendar app market? Productivity app market? Online advertising market? Look at how services like KakaoTalk, Danggeun Market (a Korean neighborhood marketplace, similar to Nextdoor), or Toss define their business models and target markets. You'll find useful hints. User Acquisition Market vs. Revenue Market The market where you acquire users and the market where you generate revenue can be totally different. KakaoTalk is a classic example — they gather users through messaging and monetize through ads and commerce. You need to explain this well during pitches. Better yet, write the plan so clearly that readers instantly see how you'll acquire users and how you'll make money — without needing verbal explanation. Tips for Writing a Grant Proposal If you only write what the template asks for, you might get rejected. You need to add something beyond the minimum to score extra points. The approach also differs by program stage. Early-stage Startup Package: You need revenue-based market validation Pre-launch Startup Package: Customer surveys alone can get you through Among the evaluation criteria, feasibility and growth strategy carry the heaviest weight. Reviewers don't always fully understand your product. So write in a way that anyone can follow — no insider context required. What Government Agencies Measure After issuing grant money, agencies track your performance on three fronts. Revenue Hiring Investment raised Keep these metrics in mind as you operate — they'll help you in follow-on funding and reviews. Watch Out During Investment Negotiations When signing with investors, watch out for toxic clauses. Terms that look good now can strangle your company later. Always review contracts with a legal expert. One resource worth checking out is Angel Lounge — a Korean platform that connects founders with angel investors. Wrapping Up Government grants and investment rounds are valuable resources, but they shouldn't become crutches. What really matters is proving your product's value on your own. Prepare for grants assuming you'll be selected Separate your user acquisition market from your revenue market Write plans so your BM is visible without explanation Track revenue, hiring, and investment consistently Instead of waiting for the perfect plan, start by drafting an MBP with what you have today. The way to get started is to quit talking and begin doing.— Walt Disney