← Back to Directory

Grammarly interview notes, page 1 of 5

Mid-sized

Most of these Grammarly write-ups come from Software Engineers (39), then Product Managers (3). The most reported rounds are the technical phone screen (17), the system design round (16), the behavioral / leadership round (3) and the product sense round (2).

42 interview notes · updated Jul 2026

Grammarly·Software Engineer·Onsite - System Design / Architecture

Apr 2026
Grammarly system design round focused entirely on building a pub/sub system from scratch. The question kept expanding with follow-ups and I felt like I was playing whack-a-mole with requirements the whole time.
  • Design and implement a publish/subscribe system supporting subscribe(topic, handler), unsubscribe, and publish(topic, message). Then extend it to handle wildcard topic patterns, async delivery, durable subscriptions, and at-least-once vs. at-most-once delivery semantics. Also discuss thread safety, back-pressure, and scaling across many topics and subscribers.

“Started okay with the basic subscribe/publish interface, a map from topic to list of handlers, nothing fancy.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

Apr 2026
Grammarly coding screen, one question, stack-based string manipulation. Pretty clean problem once you see the pattern but I fumbled around for a bit before the approach clicked.
  • Given a string of lowercase letters, repeatedly remove pairs of adjacent identical characters until no more removals are possible. Return the final string. Solve it in O(n) using a stack.

“Took me a second to realize brute-forcing it with repeated passes would be too slow.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

Apr 2026
Did a system design round at Grammarly for a software engineer role. One thing worth flagging: they've moved away from Google Docs and are now using an Excalidraw-based tool for the design portion, which threw me a little since previous reports didn't mention that.
  • Design a read-once chat system, where messages can only be read a single time before they disappear.

“Seen this one floating around on forums so I wasn't totally blind going in, but the Excalidraw tool was new to me and I spent the first few minutes just figuring out how to draw boxes properly.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

Apr 2026
Grammarly coding interview with a string manipulation problem that looks deceptively simple but has a neat stack-based trick to it. Nothing too wild, just one focused algorithmic question.
  • Given a string and an integer k, repeatedly remove groups of k adjacent identical characters until no more removals are possible. Return the resulting string. Solve it efficiently.

“The naive approach of scanning and removing in a loop will get you killed on time complexity.”

View Post

Grammarly·Software Engineer·Onsite - Cross-functional / Panel

Apr 2026
Had a cross-functional chat with a PM at Grammarly as part of the software engineer interview loop. Pretty low-key, just product thinking stuff, nothing that felt too technical.
  • Describe a product you use and walk through how you would improve it.

“Picked something I actually use day to day which helped, but I rambled a bit before landing on a concrete improvement.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

Apr 2026
Grammarly system design round, one big question that sprawled into a bunch of sub-topics. The rate limiter prompt sounds deceptively contained but they really wanted to see how deep you could go on the tradeoffs.
  • Design a rate limiter that enforces per-key request quotas. Cover your choice of algorithm, the API design, data structures, time and space complexity, thread-safety, distributed operation with a shared cache, clock skew, burstiness versus smoothness, and edge cases like bursts at window boundaries.

“I went with token bucket pretty fast because I know it well, but then they started pulling on every thread.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

Apr 2026
System design round at Grammarly for a software engineer role. The question was a beast, basically three separate design problems rolled into one, and they wanted wire-level API specs across all of them.
  • Design a Google Sheets-style collaborative spreadsheet with an AI chat interface that can edit the sheet via natural language commands. Cover the real-time collaboration layer, the LLM inference and prompt engineering layer, and a tool-calling protocol layer. Define the wire-level APIs and all parameters across all three.

“This one is basically three system design interviews duct-taped together.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

Apr 2026
Grammarly SWE coding round, one question on string manipulation with a stack-based solution. Pretty clean problem once you see the pattern.
  • Given a string and an integer k, repeatedly remove k adjacent identical characters until no more removals are possible. Return the resulting string.

“The naive approach of scanning and rebuilding the string in a loop will time out, which I almost went down before catching myself.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

Apr 2026
Grammarly software engineer coding round, pretty sparse on details but the main question was the transactional store problem that's been floating around on 1point3acres.
  • Design and implement a transactional key-value store that supports basic transaction operations like begin, commit, and rollback.

“Seen this one referenced a few times on forums before going in, which helped a little.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

Apr 2026
System design round at Grammarly for a software engineer role. The whole thing was basically one big deep-dive into building a collaborative design tool from scratch, Figma-style. A lot of ground to cover in one session.
  • Design a real-time collaborative whiteboard tool similar to Figma that supports multiple users editing vector shapes simultaneously, with presence indicators, cursors, persistence, and version history.
  • How would you handle conflict resolution for simultaneous edits, and what are the trade-offs between CRDTs and operational transformation in this context?
  • How would your system handle transient network failures, including offline edits, replaying operations after reconnect, and reconciling state with the server?
  • How would you scale the system to support a large number of concurrent collaborators on a single document?

“This is a beast of a question and I did not scope it fast enough.”

View Post