Skip to content
Sign in
Artwork for Software Engineer Interview Prep Podcast
EducationCourses

Software Engineer Interview Prep Podcast

Prabuddha Ganegoda

Ace your Software Engineer interviews with confidence.
This podcast helps you organize your thinking, strengthen problem-solving skills, and prepare effectively for real technical interviews.

Topics covered include:

Programming (Java & Python)

Data Structures & Algorithms

System Design

AI for Software Engineers

Interview strategies & mindset

Whether you're targeting Big Tech, startups, or senior engineering roles, each episode helps you think clearly, solve better, and perform at your best.

Play
Open in
  • 26 episodes
  • Avg 33 min
  • English

Episodes 26

NewestOldestLongest
All20Unplayed20In progress0Played0
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • Saturday · 1 hr 10 min

    Mastering REST API Design & Best Practices

    "Design the backend for Twitter." Reciting HTTP verbs won't get you through that whiteboard session. In this deep dive we build a complete, staff-level blueprint for REST API design: the reasoning behind every rule, the trade-offs interviewers probe, and the patterns that keep large systems evolving safely. You'll learn: - Fielding's six REST constraints, and why statelessness unlocks horizontal scaling - The Richardson Maturity Model, from the "swamp of POX" to HATEOAS - URI design: stable identifiers, shallow nesting, filtering and sparse fieldsets - Safety and idempotency, PUT vs PATCH, and JSON Merge Patch vs JSON Patch - Status codes that show polish: 201 + Location, 409 Conflict, 410 Gone, 422 - Offset vs cursor pagination - Versioning, breaking changes, tolerant readers and the expand-contract pattern - Deprecation headers, RFC 7807 problem details and trace IDs - OAuth 2.0, API keys, JWTs and mutual TLS - Rate limiting: fixed window, sliding log, token bucket and leaky bucket - ETags, Cache-Control, and 202 Accepted for long-running jobs - OpenAPI and consumer-driven contract testing with Pact Chapters 00:00 The whiteboard challenge 01:35 An API as a city 02:20 Fielding's six constraints 03:28 Code on demand 04:38 Statelessness and scaling 07:44 The layered system 09:21 The Richardson Maturity Model 12:29 HATEOAS and server-driven state 15:13 Pragmatic hypermedia 15:59 URI design rules 17:30 Stable identifiers 18:38 Nesting vs flattening 20:12 Query parameters 20:59 Safety and idempotency 22:54 PUT vs PATCH 25:39 JSON Merge Patch vs JSON Patch 27:39 201, 202 and 204 28:25 409 Conflict and optimistic locking 30:19 410 Gone 31:07 400 vs 422 31:54 Response envelopes 32:41 Offset pagination 34:39 Cursor pagination 36:11 API versioning 38:55 Breaking vs non-breaking changes 40:30 Tolerant readers 41:40 The expand-contract pattern 44:46 Deprecation and Sunset headers 45:52 RFC 7807 problem details 46:41 Trace IDs 47:27 Never leak internals 48:14 Returning all validation errors 49:24 OAuth 2.0 and API keys 51:25 JWTs and mutual TLS 52:57 Rate-limiting algorithms 56:29 429 and Retry-After 57:15 ETags and Cache-Control 1:01:11 Async jobs with 202 Accepted 1:03:58 OpenAPI 1:05:30 Consumer-driven contracts with Pact 1:08:39 Recap: API design is empathy #RESTAPI #APIDesign #SystemDesign #BackendEngineering #SoftwareArchitecture #InterviewPrep Interview Prep Podcast

  • Friday · 27 min

    The Architecture of Professional REST APIs

    Your connection drops mid-checkout on a $1,000 ticket. Do you hit refresh and risk paying twice? The answer lives in the invisible architecture of REST APIs. In this deep dive we go from the basic grammar of the web to the patterns that keep global platforms fast, safe and reliable. You'll learn: - What REST really is, and why verbs never belong in your URLs - Resource naming, the two-level nesting rule, and when to flatten - Honest HTTP status codes and error responses with trace IDs - API versioning: URI vs headers vs content negotiation - Why offset pagination breaks at scale, and how cursors fix it - Safe vs idempotent methods, and how idempotency keys prevent double charges - Authentication vs authorization, OAuth 2.0, and the trade-offs of JWTs - ETags, sparse fieldsets, compression and 202 Accepted for long-running jobs - Rate-limit headers and the token bucket algorithm - The Richardson Maturity Model, HATEOAS, and API governance with OpenAPI Chapters 00:00 The $1,000 refresh dilemma 00:45 "It works" vs "it's designed well" 01:31 What REST really is 02:17 Resources: nouns and verbs 03:04 REST vs RPC 03:52 Nesting and flattening resources 05:28 Honest status codes 06:16 The status code vocabulary 08:36 Error responses that help you fix things 10:10 API versioning strategies 11:44 Why offset pagination breaks 12:53 Cursor-based pagination 14:03 Securing filters 14:38 Safe and idempotent methods 16:02 Idempotency keys 16:50 Authentication vs authorization 17:37 JWT trade-offs 19:11 Caching with ETags 20:22 Sparse fieldsets and compression 21:08 Long-running jobs with 202 Accepted 21:31 Rate-limit headers 22:16 Rate-limiting algorithms 23:28 The Richardson Maturity Model 24:14 HATEOAS in theory and practice 25:24 API governance 26:35 Three golden rules 27:22 Final thought #RESTAPI #APIDesign #BackendEngineering #SoftwareArchitecture #SystemDesign #InterviewPrep Interview Prep Podcast

  • Friday · 31 min

    Kubernetes Deep Dive: Pod Startup and Failure Modes

    "Walk me through what happens from kubectl apply to the first request hitting your container." It sounds like a warm-up question, but how you answer it can decide whether you land a senior or staff role. In this deep dive we trace a pod from creation to production and unpack the failure modes interviewers expect you to anticipate. You'll learn: - The full startup chain: API server, etcd, controllers, scheduler, kubelet and container runtime - Why init containers can't run in parallel, and why migrations belong in one for security - Startup, liveness and readiness probes, and the liveness trap that turns a 10-second database blip into an outage - Native sidecars in Kubernetes 1.29 (KEP-753) and the startup and shutdown races they fix - HashiCorp Vault: mutating webhook injection, TokenReview and system:auth-delegator, and dynamic database credentials - Zero trust with mTLS, SPIFFE identities and JWTs, plus the alg: none attack and audience checks - Service DNS, ndots:5, ClusterIP "phantom" IPs, iptables vs IPVS, and headless services for gRPC - Istio traps: DestinationRule ordering, empty AuthorizationPolicies and a stray YAML hyphen - Helm secrets, migration hooks, and a five-phase rollout for breaking API changes - A layered runbook for debugging intermittent 503s Chapters 00:00 Introduction 00:22 What interviewers are really listening for 01:31 From kubectl apply to "success" 03:06 The scheduler and the kubelet 04:18 Init containers 05:26 Why migrations belong in an init container 06:34 Startup, liveness and readiness probes 08:09 The liveness probe thundering herd trap 10:04 What a liveness probe should check 10:53 Startup probes for slow-booting apps 11:40 The sidecar startup and shutdown race 12:52 Native sidecars in Kubernetes 1.29 13:39 Vault injection with a mutating webhook 14:48 Vault's init and sidecar agents 15:34 Vault authentication and TokenReview 16:43 Dynamic database credentials 17:55 A Postgres quoting trap 18:44 Zero trust and mutual TLS 19:52 SPIFFE identities in Istio policies 20:17 mTLS vs JWT 20:39 Istio policy traps 21:46 The alg: none attack and audience checks 23:20 Service DNS and the phantom ClusterIP 24:31 iptables vs IPVS and headless services 25:41 Istio routing and deployment order 26:29 The YAML hyphen trap 26:53 Helm versions and secrets 27:41 Helm migration hooks 28:04 Five phases for a breaking API change 29:14 Debugging 503s step by step 30:00 Matching symptoms to causes 30:47 Final thought: abstractions leak #Kubernetes #DevOps #SRE #CloudNative #Istio #SystemDesign #InterviewPrep Interview Prep Podcast

  • October 3 · 50 min

    Cracking the Senior System Design Interview: RADIO, NFRs, Scale and CAP

    Senior system design interviews don't test whether you know what a load balancer is. They test how you think under pressure: how you handle ambiguity, weigh brutal trade-offs and defend every box you draw. In this deep dive we unpack the framework used to evaluate senior engineers, architects and principal candidates. You'll learn: - The RADIO framework (Requirements, API, Data model, Infrastructure, Optimize) and how to split your 45 minutes - The one question that instantly signals seniority - REST vs gRPC, API versioning, and why offset pagination breaks at scale - Choosing a database by access pattern, and justifying every component with the NFRs - Why skipping non-functional requirements is the number one reason senior candidates fail - Peak vs average TPS, P99 tail latency, latency budgets, RPO and RTO, and compliance - Sticky sessions, sharding, hot shards, read replicas, CQRS and event streaming - The math of the nines, active-active vs active-passive, circuit breakers, bulkheads and graceful degradation - Exponential backoff with jitter to survive the thundering herd - The CAP theorem, the consistency spectrum, and why banks must choose CP to prevent double spending Chapters 00:00 Introduction 00:49 They test judgement, not definitions 02:22 The roadmap 03:36 The RADIO framework 04:47 Requirements in five minutes 06:00 The seniority signal 06:47 API design and versioning 08:20 Offset vs cursor pagination 09:05 Choosing the data model 10:18 Justifying infrastructure with NFRs 11:28 Network boundaries 11:50 Attacking your own design 12:39 Observability and cost 14:37 The URL shortener trap 15:23 The NFR cheat sheet 15:46 Peak vs average traffic 16:33 Tail latency and fan-out 17:44 Latency budgets 19:16 RPO and RTO 20:02 Compliance: GDPR, PCI DSS, SOX 21:37 Scaling out and sticky sessions 23:13 Sharding and the hot shard 24:49 Cross-shard query trade-offs 25:58 Read replicas and replication lag 27:08 CQRS 28:41 Event streaming and idempotency 31:02 The nines of availability 33:04 Active-active vs active-passive 34:37 Circuit breakers 36:09 Bulkheads 37:18 Graceful degradation 38:26 Thundering herd, backoff and jitter 40:25 The CAP theorem 43:09 The consistency spectrum 45:32 The FinTech exception: double spending 47:05 Why a rejected transaction beats a duplicate 48:13 Recap: every design is a trade-off 49:23 Final thought #SystemDesign #SoftwareEngineering #DistributedSystems #InterviewPrep #TechInterviews #SoftwareArchitecture Interview Prep Podcast

  • October 3 · 1 hr

    Kafka in Production: Failure Scenarios for Staff-Level Interviews

    A single misconfigured setting in Kafka doesn't just slow a page down. It can silently vaporize financial transactions. In this deep dive we walk through real production failure scenarios and the exact reasoning interviewers look for in staff-level system design interviews. You'll learn: - Why acks=1 loses data, and the four configuration layers for zero data loss - Consistency vs availability: why a healthy cluster refuses writes on purpose - Pushing from 400,000 to 2 million events/s with batching, linger.ms and compression - How retries reorder a debit and a credit, and how idempotent producers fix it - Rebalance storms, cooperative sticky assignment and static membership - Hot partitions and the irreducible trade-off between ordering and scale - How deleting and recreating a topic silently skips hours of data - A 3 AM role-play: 85 under-replicated partitions, a disk at 96%, and why you never restart the broker - Exactly-once with Kafka transactions, and exactly-once into PostgreSQL - Tiered retry topics and dead letter queues - Split brain, KRaft quorums and vanishing tombstones - System design at scale: multi-tenant topics, quotas, event-driven sagas and change data capture with Debezium Ideal for backend and platform engineers preparing for senior and staff-level interviews. Chapters 00:00 Distributed systems have no X-ray 01:08 Why Kafka interviews matter 02:19 acks=1 and the 200 missing payments 03:27 Four layers of zero data loss 05:21 The CAP theorem trade-off 06:31 Throughput: taxis vs buses 07:42 batch.size, linger.ms and compression 09:38 When retries reorder messages 11:38 Idempotent producers 12:48 Message keys and partition ordering 13:12 Flash sale: buffer exhausted 14:22 Decoupling with a local buffer and circuit breaker 16:18 Rebalance storms 18:13 Eager vs cooperative sticky rebalancing 19:25 Static group membership 20:12 Hot partitions and the hot key problem 23:18 Silent data loss after recreating a topic 25:20 auto.offset.reset and topic versioning 26:08 3 AM: 85 under-replicated partitions 28:54 Why you never restart the broker 29:42 Disk at 96%: the 15-minute response 31:36 Throttled reassignment, Cruise Control, tiered storage 33:36 Duplicates in consume-transform-produce 34:47 Kafka transactions 37:11 Exactly-once into PostgreSQL 39:56 Head-of-line blocking from retries 41:08 Tiered retry topics and DLQs 42:42 Split brain 44:38 KRaft and quorum math 45:27 Log compaction tombstones 48:33 Multi-tenant topic design 50:07 Tenant tiers and client quotas 51:40 Event-driven sagas 53:15 Compensating transactions 54:51 Change data capture with Debezium 57:13 Recap 58:46 Will offsets still matter in five years? #Kafka #SystemDesign #DistributedSystems #SoftwareEngineering #InterviewPrep #BackendEngineering Interview Prep Podcast

  • October 3 · 27 min

    How WebSockets Power the Real-Time Web

    Why does a chat message arrive instantly, but the web was never built for it? In this deep dive we unpack WebSockets: how engineers turned a request/response web into an open, two-way line, and what that costs at scale. You'll learn: - Why short polling, long polling and Server-Sent Events fall short (and the math behind 200,000 empty requests per second) - How the WebSocket handshake hides inside a normal HTTP request, and the "cryptographic high-five" that proves the server understood - Why clients mask every frame but servers never do, and the cache-poisoning attack it prevents - Half-open connections, idle timeouts and why heartbeats every 20–30 seconds keep sockets alive - Close code 1006, the "ghost code" every system design candidate should know - The real cost of state: 1 million connections × 20 KB = 20 GB of RAM before a single message - Gateways, pub/sub buses, the thundering herd, and exponential backoff with full jitter - Cross-site WebSocket hijacking, and why tokens never belong in the URL - When NOT to use WebSockets: SSE vs WebSockets vs gRPC - Head-of-line blocking and why QUIC and WebTransport may be next Perfect for software engineers preparing for system design interviews. Chapters 00:00 Intro: the web wasn't built for real time 02:19 Short polling and the 200,000 requests/second problem 03:54 Long polling 04:42 Server-Sent Events 05:31 WebSockets and full-duplex communication 06:19 The handshake: disguised as HTTP 07:55 Sec-WebSocket-Accept: the cryptographic high-five 09:05 Why clients mask frames 09:53 Cache poisoning explained 11:50 Half-open connections 12:38 Idle timeouts at every network hop 13:47 Heartbeats: Ping and Pong 14:36 Close code 1006 15:23 The cost of state 16:57 Scaling with gateways and pub/sub 18:34 The thundering herd 19:46 Exponential backoff with full jitter 20:58 Cross-site WebSocket hijacking 22:32 Ticket-based authentication 23:45 When not to use WebSockets 24:55 The big trade-off: latency vs statefulness 25:43 Head-of-line blocking 26:55 What's next: QUIC and WebTransport #SystemDesign #WebSockets #SoftwareEngineering #InterviewPrep #BackendEngineering Interview Prep Podcast

  • June 8 · 21 min

    Agentic coding Session 3 - Live Problem-Solving Under Pressure

    The mental model and the toolkit come together here. We cover managing a session in real time — when to course-correct, when to clear and restart — the five failure patterns that quietly tank your work and how to fix each, and a complete worked problem run end to end: explore, plan, implement in a fresh session, verify with tests, and review with an adversarial subagent. Plus scaling techniques and exactly how to demonstrate competence when someone is watching you code.

  • June 8 · 19 min

    Agentic coding Session 2 — Configuration & Extension Mastery

    This is where the deep technical interview questions live. Claude Code has five extension points — CLAUDE.md, skills, hooks, subagents, and MCP — and knowing which to reach for is a core competency. We break down each one: why CLAUDE.md is always-on context you must keep lean, how skills load knowledge on demand and why the description field decides everything, when hooks give you deterministic guarantees, how subagents isolate heavy work in their own context, and how MCP and CLI tools connect the outside world. Ends with the decision framework that ties them all together.

  • S1 · E1
    June 8 · 23 min

    Agentic coding Session 1 — The Agentic Mental Model

    The Agentic Mental Model: what "agentic" means and the loop, the context window as the governing constraint, explore→plan→implement→commit, verification, and precise prompting. Most engineers meet AI coding tools as a smarter autocomplete. Claude Code is something else: an agent that explores, plans, and writes code on its own while you direct and review. This opening episode rewires how you think about the tool. We unpack what "agentic" actually means, why the context window is the one constraint that explains every best practice, the explore-plan-implement-commit workflow, and the discipline of verification — giving the agent a check it can run so it self-corrects. The foundation for everything that follows, and for any interview that asks how you think with an AI agent.

  • May 22 · 46 min

    The Behavioral Round - STAR/CARL

    The behavioral round quietly decides more FAANG loops than coding or system design — and most engineers spend 300 hours on LeetCode and 45 minutes preparing for it. In this deep dive, we unpack: – Why FAANG weights behavioral signal so heavily (leveling, risk, culture fit)– The STAR framework, dissected letter by letter, with the failure modes at each step– CARL and why the Learning layer is the punchline, not an afterthought– How to choose between STAR and CARL in real time based on the verb in the question– Building a 12-story bank that covers 14 behavioral dimensions– Company-specific calibration: Amazon's Leadership Principles, Google's Googleyness, Meta's core values, Apple's craft focus, Netflix's candor culture– The five anti-patterns that quietly tank candidates who think they did well– Walkthroughs of ten of the most common behavioral questions with model approaches– The five shifts that separate an L5 answer from an L6 answer Whether you're prepping for your first FAANG loop or trying to figure out why your last one downleveled you, this episode gives you the structure, the frameworks, and the homework to fix it.

  • May 17 · 1 hr

    Kafka Architecture and Triage Production Scenarios

    Every scenario includes: Real-world context setting the stage The interview question as it would be asked A structured model answer Exact configuration parameters with values and reasoning

  • May 17 · 9 min

    System Design Interview: Payment Settlement Batch Processing

    Design a batch processing system for end-of-day payment settlement at a payments company that processes 50 million transactions per day. The system must net merchant positions, calculate fees, and initiate fund transfers to merchant bank accounts within a strict bank cutoff window. Walk me through your design, covering reliability, scalability, and how you'd handle failures. Key Takeaways The outbox pattern is the canonical solution to the dual-write problem. Know it cold. Partition keys define ordering and parallelism — choose with intention, usually around the natural aggregation boundary (here, merchant ID). Throttling must be distributed when you have multiple workers — Redis-backed buckets or a sidecar. Idempotency is non-negotiable in payments. Design for at-least-once and dedupe. Retries are tiered: in-process for transient, delay-queue for slower-resolving, DLQ for terminal. Backpressure beats dropping — use Kafka lag as your buffer when downstream is slow. Reconciliation closes the loop — you don't know it worked until ground truth confirms. Corrections are new events — never rewrite history in a financial system.

  • April 24 · 7 min

    Anatomy of `kubectl apply` - Inside the Kubernetes Control Plane

    When I run kubectl apply, the request is sent to the Kubernetes API Server, which acts as the entry point to the cluster. The API Server processes the request through several stages: Authentication – validates the client (certificates, tokens, etc.) Authorization – checks permissions using RBAC Admission Controllers Mutating (e.g., inject defaults, sidecars) Validating (ensure request is compliant) Once validated, the object is persisted. The API Server stores the Deployment object in etcd, which is the cluster’s consistent key-value store. At this point, the desired state is recorded—but nothing is running yet. The Kubernetes Controller Manager detects the new Deployment via the API Server’s watch mechanism. Deployment Controller creates a ReplicaSet ReplicaSet Controller creates the required Pods This is all driven by control loops comparing: Desired state (in etcd) Current state (actual cluster) The Pods are created without a node assigned. The kube-scheduler: Filters nodes (resource constraints, taints, node selectors) Scores remaining nodes (resource availability, affinity rules) Assigns the best node Once scheduled, the kubelet on the node pulls the image and starts the container. "The important thing is Kubernetes is entirely declarative and event-driven. Nothing is executed immediately—instead, components continuously reconcile actual state toward desired state."

  • April 18 · 31 min

    Deep Dive Kubernetes Pod Start and Failure Modes

    What We Cover in This Episode: The Probe Trap, Why telling an interviewer that a "liveness probe failure removes traffic" is an instant red flag (it actually kills and restarts the container!), and why you should never check external databases in your liveness probes. The JWT Myth: Why saying "JWTs are encrypted" will cost you points. We explain how to articulate that standard JWTs are signed, and how to defend against the notorious alg: none attack. Silent Istio YAML Bugs: We expose the most common structural bug candidates write on the whiteboard: putting fault, retries, and route as separate list items in an Istio VirtualService, which silently fails to route traffic. Zero-Trust Security Illusions: Did you know that Istio's RequestAuthentication alone does not reject unauthenticated requests? We explain why you absolutely need an AuthorizationPolicy to actually block traffic. The Sidecar Evolution: How to elevate your answer from a mid-level to a Staff-level by explaining the new Kubernetes 1.29 native sidecars (restartPolicy: Always), effectively solving the old startup race conditions

  • April 17 · 27 min

    The Architecture of Professional REST APIs

    HTTP Contracts & Status Codes: The podcast will cover why returning a 200 OK for an error is a massive anti-pattern. Jenny explains the exact contract of 2xx, 4xx, and 5xx status codes, and emphasizes the use of trace IDs and machine-readable error envelopes so clients know exactly what went wrong and how to fix it. Versioning & Pagination: They will discuss the trade-offs of URI, Header, and Query Parameter versioning, with Jenny recommending URI versioning (/v1/users) for public APIs. For pagination, the episode will strongly contrast Offset Pagination (which can skip records or show duplicates during mutations) with Cursor-Based Pagination (which uses an opaque token for stable, high-performance data fetching). Idempotency & Safe Operations: You will learn how to design systems for network failures. The hosts clarify the difference between a safe operation (like GET) and an idempotent one (like PUT or DELETE), and how to implement client-supplied Idempotency-Key headers for POST requests so you never accidentally double-charge a user. Performance Levers: Jenny walks through using Cache-Control and ETag headers for conditional requests, sparse fieldsets to save bandwidth, and standardizing rate limits using algorithms like the Token Bucket or Leaky Bucket. Expert Territory (HATEOAS & Governance): To close out, they will discuss the Richardson Maturity Model, defining Level 3 (HATEOAS) where the server dictates the next possible actions via hypermedia links. The episode ends with the philosophy that API documentation (via OpenAPI) and contract testing are first-class engineering concerns, because breaking an API is a "social contract violation".

  • March 27 · 59 min

    Mastering OAuth 2.0 & Microservice Security for Senior Interviews

    Are you preparing for a senior security or backend engineering interview and struggling to articulate how to secure microservices in a zero-trust environment? In this deep dive, we break down the definitive guide to OAuth 2.0, OpenID Connect, and advanced token security to help you move beyond textbook definitions and start designing banking-grade architectures.Whether you are designing a Backend-For-Frontend (BFF) or securing a massive microservice mesh, this episode is your ultimate cheat sheet! What We Cover in This Episode: The "Hotel Keycard" Analogy (AuthN vs. AuthZ): We clarify the critical difference between OpenID Connect (verifying your identity at the front desk) and OAuth 2.0 (the keycard that tells the lock what you can access). The "Secret Handshake" (PKCE): Discover why the Proof Key for Code Exchange (PKCE) is now mandatory for public clients to prevent authorisation code interception attacks. The "Clear Backpack" Trap: We reveal why storing tokens in browser localStorage is a major interview red flag, and how the Backend-For-Frontend (BFF) pattern keeps tokens securely on the server. Defeating the "Forged Badge" (JWT Vulnerabilities): We unpack the notorious alg:none vulnerability and exactly what steps a Resource Server must take to validate a JWT signature safely. Zero-Trust Microservices & Token Exchange: Learn how to move past weak shared secrets. We explain how to use private_key_jwt (RFC 7523) for strong service identity, and why you should use Token Exchange (RFC 8693) to maintain a secure chain of custody across microservices. Banking-Grade Security (DPoP & Token Rotation): We dive into the ultimate defenses against token theft: Refresh Token Rotation, which acts as a tripwire to invalidate compromised token families, and DPoP (Sender-Constrained Tokens, RFC 9449), which mathematically binds a token to the client's private key.

  • March 25 · 1 hr 5 min

    JVM Internals Deep Dive 8-25 LTS

    JVM Architecture Overview — runtime data areas, memory model, flag reference table Class Loading Subsystem — delegation model, loading phases, JPMS/Jigsaw module system Execution Engine & JIT — tiered compilation levels (0→4), inlining, escape analysis, loop vectorisation, SIMD intrinsics, speculative optimisation and deoptimisation Garbage Collection Algorithms — deep dives on G1, ZGC (coloured pointers, load barriers, concurrent relocation), and Shenandoah; full comparison table across all collectors LTS-by-LTS Optimisation History: GC Configuration & Tuning — selection guide, essential flags, unified GC logging Monitoring & Profiling — JFR, jcmd/jstack/async-profiler, key production metrics Virtual Threads & Modern Concurrency — VT vs platform threads, migration checklist, StructuredTaskScope pattern Performance Tuning Playbook — symptom→root cause table, AppCDS, CRaC, GraalVM Native Evolution Timeline — Java 8→25 at a glance

Showing 1–20 of 26 episodes