Grammarly Software Engineer Interview Experience — An AI-Chat Spreadsheet Design Question and a Brutal 45-Minute Merge Problem

Overall people were pretty nice, and the recruiter was attentive — maybe the company just isn't that big yet and is still hiring. The bar for the questions didn't feel well calibrated, honestly a bit exaggerated. At this level, I think only people from the top, currently-hot AI star companies could really handle it. Why bother stressing over this one?

Here are the two rounds of technical interviews I went through:

Design: design an online multi-user collaborative spreadsheet system, similar to Google Sheets, but — besides supporting direct edits to the sheet — it also needs an interactive AI chat interface that implements the whole feature set, e.g.: sum the values in column K and write the result into cell (c, y); delete row K / column J; insert a row after row M with (....). They wanted it down to every API and every parameter.

This one problem basically splits into at least 3 separate design problems — 1. the online multi-user collaborative sheet, 2. LLM inference (with some prompt engineering, natural language to query/MCP), 3. an actual implementation of MCP. It really tests your prior experience — if you've never built MCP before, hacking it together on the spot is no small feat.

The prompt itself ran almost 2 pages of A4. Just reading it and fully understanding the requirements ate up a lot of time.

Coding: optimize correction suggestions — implement a function correctionMerge. Input is a List<Correction>, where a Correction object has these fields:

{
  start: integer,    // starting index of the correction
  end: integer,      // ending index of the correction
  priority: integer, // priority of the correction, higher value = higher priority
  changes: Enum      // the actual change to apply, e.g. Changes.DELETE, Changes.DEDUP, Changes.UPDATE, ...
}

Output is also a List<Correction>, and you need to guarantee there's no overlap between the corrections. If two corrections overlap, apply these rules:

• if the priorities differ, keep the higher-priority one
• if the priorities are the same, keep whichever one has the smaller (end - start)

Example: (1, 10, 1, Changes.UPPERCASE), (3, 6, 1, Changes.LOWERCASE) → expected output: (1, 2, 1, Changes.UPPERCASE), (3, 6, 1, Changes.LOWERCASE), (7, 10, 1, Changes.UPPERCASE)

Again, the prompt was two pages of A4 and a real slog to get through — there was a lot of extra context that didn't actually matter, and just getting from start to understanding what they wanted ate up a ton of time.

There were a ton of corner cases. Take the example above — after slicing it, the resulting piece (7, 10, 1, Changes.UPPERCASE), if it still needs to be merged with a later object (say still priority 1), has to have its priority computed off the original (1, 10) span, not the sliced (7, 10) span. Same example: if the queue still has other objects like (3, 6, 1) and (7, 10, 1) sitting in it, you can't pop them off right away either — you have to keep re-heapifying against the heap, because you don't know where a later object's start position is going to land (say a later object turns out to be (4, 8, 1)).

You had to fully understand the problem, come up with an approach, talk through every corner case, finish writing the code, and get it passing tests — all in 45 minutes, having never seen the problem before. Tough ask. Whether you can pull that off, I don't know — I sure couldn't.

Overall the experience was pretty mediocre. Moving on. Can't really say they did anything wrong — the one with the problem is always yourself, I guess. There's always someone out there who can clear the bar, so why would they need you otherwise.