← Back to Directory

Grammarly interview notes, page 2 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

May 2026
System design round at Grammarly focused entirely on rate limiting, which sounds contained until they start asking you to implement five different algorithms and then defend your choices under concurrency and distributed systems pressure. Pretty intense for what I expected to be a mid-level screen.
  • Design and implement a rate limiter that supports token bucket, leaky bucket, fixed window, sliding window log, and sliding window counter algorithms, exposing an isAllowed(client_id) API with configurable per-client rate limits.
  • How do you ensure correctness of your rate limiter under concurrent requests from the same client?
  • What are the trade-offs between a centralized rate limiter using something like Redis versus a local in-process limiter on each node?
  • Where do accuracy and memory usage conflict in rate limiting algorithm design, and how do you reason about that trade-off?

“I started with token bucket because it's the one I actually understand well, then kind of fumbled through leaky bucket.”

View Post

Grammarly·Software Engineer·Recruiter / HR Screen

May 2026
Short Grammarly screen, basically just one question about motivation for applying.
  • Why are you interested in working at Grammarly?

“Pretty standard opener.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

May 2026
Phone screen at Grammarly for a software engineer role, three binary tree problems back to back. Nothing too wild but the third one had some teeth to it.
  • Given the root of a binary tree, write a function to return its maximum depth (the length of the longest path from root to leaf).
  • Given the root of a binary tree, return its level-order traversal as a list of lists, where each inner list contains the values at that depth.
  • In a binary tree where each node holds a value from 0 to 25 (representing 'a' to 'z'), find the lexicographically smallest string formed by reading from any leaf up to the root.

“Warmup question, basically.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

May 2026
Coding round at Grammarly for a Software Engineer position. Two algorithm problems, one with a follow-up variant that made things more interesting. Nothing too wild but the stack-based string problem had a tricky extension I had to think through carefully.
  • Given a string, repeatedly remove adjacent pairs of equal characters until none remain. Then, as a follow-up, generalize this to removing groups of k adjacent equal characters.
  • Design a time-based key-value store that supports set(key, value, timestamp) and get(key, timestamp), where get returns the value at the largest timestamp less than or equal to the queried one.

“The basic version I got pretty quickly, stack-based approach where you track characters and pop when there's a match.”

View Post

Grammarly·Product Manager·Onsite - Product Sense / Strategy

May 2026
Grammarly PM interview with two back-to-back product strategy questions that were basically one big case study on building for non-native speakers. Light on behavioral stuff, heavy on thinking out loud.
  • How would Grammarly design a fluency product specifically for non-native English speakers?
  • How would you position and bring this fluency product to market?

“This one opened the whole interview and I spent too long on user segmentation before getting to the actual product.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Grammarly for a software engineer role. The problem was a read-once messaging system where one sender fans out to multiple recipients, each getting their own isolated copy that disappears after being viewed. Pretty involved question with a lot of moving parts.
  • Design a messaging system where a sender can address the same message to multiple recipients at once, but each recipient gets an independent copy that is permanently deleted or made inaccessible after they read it once. How would you handle the APIs, data model, fan-out, read-once enforcement, deletion, scaling, and failure recovery?

“This one is deceptively wide.”

View Post

Grammarly·Software Engineer·Technical Phone Screen

May 2026
Grammarly coding screen, one algorithm question, pretty standard stuff. The problem itself wasn't brutal but I second-guessed my approach halfway through and it cost me some time.
  • Given a list of intervals, merge all overlapping ones and return the resulting non-overlapping set.

“I knew the sort-then-sweep approach but fumbled explaining why sorting by start is necessary before you can safely merge.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Grammarly for a software engineering role. The whole thing centered on one big design problem that kept branching into uncomfortable territory the longer it went on.
  • Design a messaging system where a sender can blast the same message to multiple recipients privately, each recipient sees it as a 1:1 thread, and the message self-destructs after the recipient reads it once. Walk through your data model, real-time delivery approach, deletion guarantees, and how you'd scale it.

“I started with the data model and immediately hit a fork: do you copy the message row per recipient or keep one shared record with per-recipient state?”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

May 2026
System design round at Grammarly for a software engineer role. The whole thing was basically one giant question about building a Figma-style collaborative editor, and they wanted you to go deep on every layer. Felt like a PhD defense at points.
  • Design a real-time collaborative design editor similar to Figma, covering the canvas rendering, document model, collaboration layer, backend infrastructure, and scale.
  • How would you handle concurrent edits to the same document from multiple users, and what conflict resolution strategy would you use?
  • How would you design the backend to maintain document state for many concurrent editors while ensuring no edits are lost across disconnects?
  • Walk me through how you'd handle image and font asset uploads, storage, and delivery at scale.
  • How would you design the permissions model, sharing links, and team or project hierarchy for this kind of product?

“This was the whole interview.”

View Post

Grammarly·Software Engineer·Onsite - System Design / Architecture

May 2026
Grammarly system design round for a software engineer role. The problem was building a transactional key-value store from scratch in memory, which sounds manageable until you start thinking about nested transactions and how count() is supposed to behave mid-transaction.
  • Design an in-memory key-value store that supports transactions, including set, get, count, begin, commit, and rollback operations. Transactions can be nested, and count must reflect the current visible state including uncommitted changes.

“My first instinct was a simple hashmap and I got maybe two minutes into explaining it before they asked about nesting.”

View Post