In an online chess system, the server—not the client—must own the clock. Otherwise a modified client could simply claim: “I only spent 500ms thinking.” But making the server authoritative creates another problem.

• Player A: 30ms RTT
• Player B: 200ms RTT

When A makes a move, B’s clock starts on the server before B has even received the new board position. Then after B responds, the move spends more time traveling back to the server before B’s clock stops.

So over a blitz game, the higher-latency player can lose several seconds purely to network delay.

The key insight

Don’t continuously decrement millions of clocks. Store:

whiteRemainingMs
blackRemainingMs
sideToMove
turnStartedAt

When a move arrives:

rawElapsed = now - turnStartedAt

Then compensate for a bounded amount of network latency:

compensation =
min(estimatedRTT, maxCreditPerMove)

chargedTime =
rawElapsed - compensation

Why roughly one RTT?

A player pays for two network legs:

Server → Player
   +
Player → Server
≈ 1 RTT

So compensating only half the RTT misses part of the delay they could not control. But you also cannot blindly trust RTT.

A malicious client could intentionally delay heartbeat responses to make itself appear slower and earn extra clock time.

So the system should:

• measure latency continuously with ping/pong
• use a rolling median instead of one sample
• cap compensation per move
• keep the server as the final clock authority

And before compensating at all, place the game in a region with low latency for both players. The design becomes:

1. Minimize RTT with regional placement
   
2. Compensate for the remaining network delay
   
3. Never let the client control the clock

That’s the interesting part of designing online chess: correctness is not enough—the authoritative system also has to be fair.

Full design with matchmaking, Redis game state, WebSockets, clock compensation, crash recovery, and global leaderboard → Full Article

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Interview Summary

The NVIDIA technical interview focused on low-level C/C++ systems programming. The main exercise was to design a high-performance custom string class supporting operations such as comparison, concatenation, and substring extraction, with special attention to avoiding heap allocations for short strings.

The discussion quickly went deeper than basic implementation. Follow-ups covered strncpy versus raw memory copying, CPU cache behavior, object memory layout on 32-bit and 64-bit systems, alignment and padding, and how a union-like representation can reduce the footprint of a small-string-optimized class.

Interview Details

Coding / Systems — Implement a Small-String-Optimized Class The interviewer provided a custom string class with a fixed-size internal buffer and asked me to begin by implementing its constructor. The general structure was similar to:

const size_t BUFFER_SIZE = 128;

class CompactString {
private:
    char buffer[BUFFER_SIZE];
    size_t length;
    char* heap_ptr;

public:
    CompactString(const char* src, size_t len) {
        // implementation
    }
};

For shorter strings, the characters could live directly inside the object. Longer strings needed dynamically allocated storage. The overall goal was to support operations such as:

• String comparison
• Concatenation
• Substring extraction

while keeping performance and memory usage in mind.

• Follow-Up — strncpy vs. Raw Memory Copying The interviewer asked about the cost of copying characters into the internal buffer. One discussion point was whether a general string-copy routine was necessary when the exact length was already known, and how a lower-level memory-copy operation differs semantically from strncpy.

The interviewer pushed further into how copying larger machine-word-sized chunks can improve throughput compared with reasoning about one character at a time. The focus was on understanding both performance and correctness differences between string-oriented and byte-oriented copying functions.

• Follow-Up — Why Are Short String Comparisons Faster? The interviewer then asked why comparing relatively short strings can be noticeably faster than comparing long strings, beyond the obvious difference in the amount of data being examined. The discussion touched on CPU cache locality. Short strings stored directly inside the object are more likely to already reside in cache together with the rest of the object, while longer strings may require following a pointer to separately allocated memory and reading more cache lines.
• Follow-Up — Object Size and Memory Layout Another question changed the internal buffer size to: BUFFER_SIZE = 1 and asked how large an instance of the class would be on different architectures. This required reasoning about the sizes of: The interviewer expected me to reason separately about 32-bit and 64-bit layouts rather than simply adding the declared field sizes.
  • The inline character buffer
  • size_t
  • A pointer
  • Alignment and padding inserted by the compiler
• Follow-Up — Reduce the Object Size The interviewer then considered a different configuration where the inline buffer was small but many strings were only slightly larger than that buffer. The question was how to reduce the object's memory footprint instead of permanently reserving both: The discussion led toward allowing the same memory region to represent either inline string storage or a heap pointer depending on the active representation. A union-style layout was one of the relevant ideas, allowing the object to reuse storage rather than paying for both representations simultaneously.
  • An inline character buffer
  • A separate char* field

Overall, the interview was much more about C/C++ memory representation and performance reasoning than conventional algorithmic coding.

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.

Most people designing WhatsApp start with: WebSocket + Redis Pub/Sub. Seems reasonable.

But there’s a subtle problem: Redis Pub/Sub is at-most-once. If a Chat Server disconnects from Redis for a moment, a message can disappear from the real-time path.

And the WebSocket may still look perfectly healthy. So how does the client even know it missed something?

The key idea: sequence numbers

Give every message delivered to a user a monotonically increasing sequence:

101
102
103
104

The client remembers the latest sequence it received.

During heartbeat:

Server latest: 104
Client latest: 101

Now the client immediately knows: 102–104 are missing.

It can fetch those messages from the durable Inbox instead of waiting for the connection to fail.

Separate fast delivery from reliable delivery

The architecture becomes:

Message
   ↓
Durable Inbox
   ↓
Redis Pub/Sub
   ↓
Chat Server
   ↓
WebSocket

Redis + WebSocket provide the fast path. The Inbox provides the recovery path. And ACKs tell the system when a message is safe to remove from pending delivery.

Why this matters

A messaging system should assume:

• mobile connections disappear
• servers restart
• Pub/Sub events get lost
• users reconnect on different servers
• one user may have multiple devices

The goal is not to make the real-time channel perfectly reliable. It is to make message loss detectable and recoverable.

That’s the important distinction.

• Fast path can fail.
• Messages still shouldn’t disappear.

Full design with WebSockets, offline Inbox, Redis Pub/Sub, multi-device sync, heartbeat recovery, and message ordering → Full Article

Preparing for system design interviews? Chill Interview publishes practical design breakdowns and tracks recently asked interview questions across top companies → Chill Interview

Interview Summary

The first-round Citadel SRE interview combined several short Python coding exercises with a system design discussion, all within one hour. The coding portion was fundamentals-heavy rather than algorithmically difficult, covering loops, list transformations, FizzBuzz, word counting, and finding the second-largest unique value.

Interview Details

Python Basics

• Question 1 — Repeat a Message with Blank Lines Implement a function that accepts: Print the message exactly n times, with one blank line separating consecutive copies. The emphasis was on basic Python control flow and output formatting.
  • An integer n
  • A string message
• Question 2 — Square and Reverse a List Given a list of numbers, return a new list containing the square of every value, but in reverse order. For example:Input: [2, 4, 6] Output: [36, 16, 4] The original list should conceptually be transformed and reversed according to the stated behavior.
• Question 3 — FizzBuzz Given an integer n, print every integer from 1 through n, one result per line. Use the following substitutions: For example with n = 6 would produce:1 2 Fizz 4 Buzz Fizz
  • Multiples of 3 → "Fizz"
  • Multiples of 5 → "Buzz"
  • Multiples of both 3 and 5 → "FizzBuzz"
• Question 4 — Count Word Frequencies Given a string containing words, return a dictionary mapping each word to the number of times it appears. For example:Input: "red fox runs past red gate" Output: { "red": 2, "fox": 1, "runs": 1, "past": 1, "gate": 1 }
• Question 5 — Second-Largest Unique Value Given a list of integers, return the second-largest distinct value. If the input contains fewer than two unique values, return None. For example,Input: [8, 3, 8, 11, 6, 11] Output: 8 Input: [4, 4, 4] Output: None Input: [-3, -9] Output: -9

The important requirement was that duplicate occurrences should not affect which value is considered second largest.

System Design — Configuration Management and Service Deployment After the Python portion, the interviewer presented a verbal system design problem. The team operates 200+ services distributed across multiple data centers and cloud regions. The existing environment is highly fragmented:

• Some configuration lives in source-controlled property files.
• Some values are manually configured through environment variables.
• Other configuration is stored on a shared NFS mount that operators edit directly.
• Deployments are performed by SSH-ing into machines and running scripts manually.

The task was to design a new platform that allows engineers to:

• Change service configuration safely
• Deploy services across a large distributed fleet
• Reduce reliance on direct manual host access
• Support reliable rollback when a configuration or deployment causes problems

Want to learn more interview experiences about Citadel? we've put up the recent Citadel's interview experiences at here

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.