Cohere · Primly Community

Cohere frontend engineer interview: what they actually tested (it wasn't just React)

quietquit_quincy · 7 replies

Wrapped up a Cohere frontend engineer interview loop in April 2026. Wanted to share because most of what I found online was ML-focused and the frontend process is pretty different.

Background on me: 4 years React, worked mostly on design systems and data visualization. Applied for a senior frontend role on their platform team.

The short version: it's a real engineering bar, not a trivia quiz. They care about TypeScript, performance thinking, and how you build interfaces that surface complex ML output in a way users can understand. That last part is unique to an AI company frontend role.

The loop (3 rounds after recruiter screen):

Round 1: Coding (60 min) We worked in a shared TypeScript environment. I got two problems. First was implement a debounce function with a configurable delay (classic, but they cared about edge cases with immediate invocation). Second was a React rendering problem: given a recursive tree structure, render it as an expandable/collapsible component. State management, clean event handling, no external libraries. The interviewer was hands-on and collaborative, not watching silently.

Round 2: System design / architecture (45 min) Design a document annotation UI for reviewing model outputs. Think highlighting spans of text, adding labels, persisting state, handling conflicting labels from multiple reviewers. They care a lot about conflict resolution and optimistic UI patterns. I talked through selection range APIs, local state vs. server sync, optimistic updates with Zustand. They pushed on performance for documents with thousands of tokens.

Round 3: Behavioral + team fit (30 min) Standard impact questions but with an angle toward cross-functional work with ML researchers and product. They asked: how do you approach building a UI when the underlying model behavior is still changing?

What to prepare:

TypeScript solid. Not just types but generics, type guards, utility types. The coding round tests whether you actually write TS or just sprinkle it on JS.

DOM and browser APIs: the annotation UI question required knowledge of the Selection API and Range objects. Worth brushing up on things that don't come up in typical React tutorials.

Accessibility: they asked me unprompted about ARIA roles in the tree component. Have a real answer.

Performance: virtualization for long lists/documents came up in both rounds. Know why and when to use it.

Overall the frontend interview felt more senior-calibrated than I expected from a company whose main product is a language model API. Good sign that they take frontend seriously.

7 replies

returner_ren

the annotation UI design question is really interesting. that's a core UX problem for AI tooling and I've never seen it come up as a system design prompt before. sounds like they're actually thinking about their real product surface.

intl_isla

did they care about your experience in any particular tech stack or was it framework-agnostic? I mostly do Vue and I'm wondering if React-heavy background is expected.

frontend_fran

the coding env was React but they said framework knowledge wasn't the point, they care about the underlying concepts. I'd frame it as 'I know React well but my solutions here would translate to Vue or any component model' and you should be fine. the TS and DOM stuff matters more.

numbers_only

what level did you get leveled at and roughly what was the comp range for senior frontend in this loop? toronto-based or us remote?

frontend_fran

remote US. offer came in around $180-195k TC all-in for senior. I don't know their exact bands but there was some room to negotiate. toronto would be different obviously.

sam_recovering

love that they asked about building UIs when the model behavior is still changing. that's such a real challenge at AI companies right now and the answer tells you a lot about someone's engineering maturity. did you have a pre-prepared answer for that or did you think through it in the room?

frontend_fran

mostly in the room. I talked about designing for graceful degradation, exposing confidence signals to users, and making model-output components easy to update in isolation. not a perfect answer but they seemed to want to hear how you think more than a rehearsed response.