Redis interview questions

Data structures, beyond get and set

• Strings, hashes, lists, sets, sorted sets - and a use case for each. Sorted sets for leaderboards and rate limiting is the canonical pair.
• Why a hash rather than many string keys? Memory efficiency and atomic field updates.
• Sets for uniqueness and intersection; lists as queues, with the blocking variants.
• HyperLogLog for approximate cardinality, and the accuracy trade-off.
• Streams, if the role uses Redis for messaging.

Persistence and eviction

• RDB versus AOF - snapshotting against an append-only log, and the durability-versus-performance trade-off. Many setups use both.
• Is Redis durable? The honest answer is: configurably, and never as durable as a database you should treat as a system of record.
• Eviction policies - `allkeys-lru`, `volatile-ttl`, `noeviction` - and what happens when memory fills with `noeviction` set.
• What is the difference between a key expiring and a key being evicted?
• Why is `KEYS` dangerous in production, and what do you use instead? `SCAN`.

Caching patterns

• Cache-aside - the default. Read from cache, fall back to the database, populate. Name the race condition it has.
• Write-through and write-behind, and what each costs.
• Cache stampede - many requests missing simultaneously and hammering the database. Mitigations: locking, staggered TTLs, serving stale while refreshing.
• Invalidation - TTL versus explicit invalidation, and why the second is hard in a distributed system.
• What do you do when the cache goes down entirely? If the answer is that the system falls over, that is a design problem worth naming.

Operations and scale

Replication and Sentinel for failover, Redis Cluster and hash slots, and why a multi-key operation across slots is a problem. Then the distributed-lock question - how you would implement one, and the honest caveat that distributed locking in Redis has well-known correctness limits under failure. The broader architecture context is in the system design cheat sheet.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a cache you have designed and operated. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: cache invalidation strategy at scale, and an incident where the cache made things worse. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a Redis interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Redis interview questions?

Which data structure to use for a given problem, RDB versus AOF persistence, eviction policies and what happens when memory fills, the cache-aside pattern and its race conditions, and how you handle a cache stampede.

Is Redis durable?

Configurably, but never to the standard of a primary database. RDB snapshots can lose everything since the last snapshot, and AOF durability depends on the fsync policy. Treating Redis as a system of record rather than a cache is the mistake the question probes for.

What is a cache stampede and how do you prevent it?

Many requests missing the same key at once and all hitting the database together, usually after a popular key expires. Mitigations include a lock so only one request repopulates, staggered or jittered TTLs, and serving stale data while refreshing in the background.

Why is the KEYS command dangerous in production?

Redis executes commands on a single thread, and `KEYS` scans the entire keyspace, blocking every other client until it finishes. `SCAN` iterates incrementally with a cursor instead, which is why it is the production-safe alternative.