← Back to Directory

Decagon interview notes, page 3 of 4

Small

Most of these Decagon write-ups come from Software Engineers (30), then AI Engineers (1). The most reported rounds are the technical phone screen (22), the system design round (8) and the behavioral / leadership round (1).

31 interview notes · updated Jul 2026

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon SWE interview focused on extending a rolling-window CSAT tracker with an update operation. Pretty design-heavy for a coding round, less about grinding algorithms and more about thinking through data structure tradeoffs.
  • You have a rolling-window CSAT tracker that supports record and get_average. Add an update method that modifies a conversation's score in place if it's still within the active window, and does nothing if the record has already been evicted. Walk through how you'd implement this efficiently.

“The baseline tracker was already given so you're not building from scratch, which I appreciated.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon SWE interview hit me with a pretty gnarly combinatorics/backtracking problem on a 4x4 board variant of tic-tac-toe. The question had a lot of moving parts and the follow-ups kept coming, so it felt more like a 45-minute deep dive into one problem than a typical coding round.
  • Given a 4x4 board where two players alternate placing marks (X goes first) and a player wins by getting three consecutive marks in a row, column, or diagonal, write a recursive backtracking solution to enumerate all valid game sequences from the empty board to a terminal state.
  • How would you efficiently detect a win after each move on this 4x4 board, given that the win condition is three consecutive marks rather than four?
  • What is the worst-case time complexity of your backtracking enumeration, and how does the 'stop immediately on win' rule affect the actual search space?
  • Are you counting distinct ordered game sequences (different move orders to the same final board count separately) or distinct terminal board positions? How does that choice affect the result?
  • How would you validate your enumeration result against a known baseline, and what sanity checks would you apply?
  • If the full enumeration is too slow in an interpreted language, what strategies would you use to make it tractable?

“This took me way longer to set up than I expected.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon software engineer interview, got a classic grid DP problem. Nothing unexpected, pretty standard coding round.
  • A robot starts at the top-left of an m x n grid and can only move right or down. How many unique paths exist to reach the bottom-right corner?

“Classic DP, I've seen this a dozen times.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon software engineer interview had me implementing a Tic Tac Toe evaluator from scratch, starting brute-force and then optimizing. Pretty focused session, all algorithmic, no fluff.
  • Implement a Tic Tac Toe game-state evaluator: given a 3x3 board with X, O, and empty cells, determine the optimal outcome assuming both players play perfectly. Start with brute-force minimax, then optimize with memoization, and discuss state-space size and how board symmetries could reduce the search further.

“I got the basic minimax down without too much trouble but fumbled a bit explaining the memoization step.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Interviewed for a software engineering role at Decagon and got hit with a meaty design-plus-implementation question about a sliding window CSAT tracker. More involved than I expected for what I thought would be a straightforward coding round.
  • Design and implement a class that tracks customer satisfaction scores over a sliding time window, supporting record, update, get_average, and get_percentile operations with efficient expiration of old entries.

“The basic record and get_average parts came pretty naturally.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon SWE interview focused on a sliding window data structure problem with a tricky follow-up. The design angle made it harder than a typical LeetCode question since you had to think about eviction semantics and what 'current time' even means for an update call.
  • Design and implement a sliding window data structure that supports insert(timestamp, value) and get_avg(timestamp), where get_avg returns the average of all samples within the last W seconds. Every operation should evict samples that fall outside the current window before doing anything else.
  • Follow-up: add an update(id, new_value) operation that changes the value of a previously inserted sample. Note that update takes no timestamp, so you have to decide what 'current time' means for the eviction step.

“I went straight to a deque and felt good about it for the basic case.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon coding screen, one question about a sliding window data structure. Pretty straightforward on the surface but the eviction logic tripped me up a bit.
  • Design a class that accepts a window size on initialization and supports inserting timestamped score records and returning the average score of all records currently within the active window. Both methods should evict stale records on every call.

“The insert and average parts were fine, I had a deque in mind pretty quickly.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jun 2026
Decagon software engineer interview that basically boils down to one big question: pick a project and be ready to defend every technical decision you made. They go deep, so if you exaggerate anything on your resume you will feel it.
  • Pick a project from your background and walk through it completely: why it existed, what you personally built, the technical decisions and trade-offs you made, the hardest problem you hit and how you solved it, what failed or had to be redone, the measurable impact, and what you'd change looking back.

“This is the whole interview basically.”

View Post

Decagon·Software Engineer·Onsite - System Design / Architecture

Jun 2026
System design round at Decagon for a software engineer role, focused entirely on designing an AI gateway service. The problem was meaty and covered a lot of ground, probably more than I expected for a single session.
  • Design an AI Gateway service that sits between application clients and multiple upstream LLM providers, exposing a single unified API.
  • How would you handle provider failover, circuit breaking, and retry logic when an upstream LLM provider starts returning errors or timing out?
  • What strategies would you use to minimize response latency, including request hedging, caching, and parallel calls to multiple providers?
  • How would you implement per-request token accounting, cost attribution per tenant or API key, and budget enforcement across multiple LLM providers?
  • How do you validate LLM responses for accuracy, enforce structured output schemas, and detect when a provider's quality has degraded?
  • Walk through the rate limiting, quota management, and observability design for the gateway, including audit logging.

“This is one of those problems that sounds manageable until you realize the scope.”

View Post

Decagon·Software Engineer·Technical Phone Screen

Jul 2026
Decagon SWE interview had a sliding window design problem that looked deceptively clean on the surface but had a bunch of decisions baked in that you had to call out explicitly.
  • Design a class that takes a window length at initialization and supports two operations: recording a conversation event with an ID, timestamp, and score (1 to 5), and returning the average score of all conversations whose timestamp falls within the active window relative to the latest seen timestamp.

“The core question wasn't that hard but the part that tripped me up was when they asked me to state my time semantics upfront.”

View Post