Front-End Design of an Emoji Picker with a Search Field

Quick Overview

A candidate-driven front-end system design discussion about an emoji picker with a search field. It tests how a candidate scopes the component, models and loads the emoji catalog, ranks search results, keeps a grid of thousands of emoji fast, and supports keyboard and screen-reader users.

Front-End Design of an Emoji Picker with a Search Field

Company: Atlassian

Role: Frontend Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

Design the front end of an emoji picker: the familiar panel that opens from a message box or a reaction button, shows emoji grouped by category in a scrollable grid, and has a search field at the top that filters the emoji as the user types. Selecting an emoji hands it back to whatever opened the picker. This is a short front-end system design discussion (about 15 minutes) in which the interviewer asks few questions, so you are expected to drive: set the scope, propose the architecture, and choose where to go deep. ```hint Size the data first Estimate how many emoji and search keywords the picker has to handle before deciding where search runs and how the data reaches the browser. ``` ```hint Find the expensive part Ask which part of the panel costs the most to render and to update on every keystroke, and design around that part. ``` ### Clarifying Questions - Is the picker a reusable component used by several surfaces (message composer, reactions, status), or a single screen? - Which features are in scope: categories, recently used emoji, skin-tone variants, custom emoji uploaded by users or organizations? - Which browsers and devices must be supported, and must emoji look identical everywhere, or may the operating system's own glyphs be used? - Must search work in several languages? - What keyboard and screen-reader support is required? ### What a Strong Answer Covers - Scope stated up front and a time plan that leaves room for depth, since the candidate drives the discussion. - A component breakdown (search field, category navigation, grid, preview, skin-tone control) with a clear state model and a small API for the host that opens the picker. - The emoji data model and a loading strategy that does not slow down the host page. - Search: matching against names and keywords, result ranking, and responsiveness while typing. - Rendering performance for a grid of thousands of items, and how emoji glyphs are drawn. - Keyboard navigation, focus management and screen-reader announcements. - Persistence of recent emoji and preferences, and behavior when the data fails to load. ### Follow-up Questions - How would the design change if an organization can upload thousands of custom emoji that change daily? - Emoji render differently, or not at all, across operating systems. What are the trade-offs between system glyphs and an image sprite? - How would you measure and protect the time from keystroke to updated results on low-end phones? - How would you test this component, including its accessibility?

Overview: A candidate-driven front-end system design discussion about an emoji picker with a search field. It tests how a candidate scopes the component, models and loads the emoji catalog, ranks search results, keeps a grid of thousands of emoji fast, and supports keyboard and screen-reader users.

|Home/System Design/Atlassian
Atlassian logo
Atlassian
Sep 12, 2026
mediumFrontend EngineerTechnical ScreenSystem Design
0
0

Design the front end of an emoji picker: the familiar panel that opens from a message box or a reaction button, shows emoji grouped by category in a scrollable grid, and has a search field at the top that filters the emoji as the user types. Selecting an emoji hands it back to whatever opened the picker.

This is a short front-end system design discussion (about 15 minutes) in which the interviewer asks few questions, so you are expected to drive: set the scope, propose the architecture, and choose where to go deep.

Clarifying Questions Guidance

  • Is the picker a reusable component used by several surfaces (message composer, reactions, status), or a single screen?
  • Which features are in scope: categories, recently used emoji, skin-tone variants, custom emoji uploaded by users or organizations?
  • Which browsers and devices must be supported, and must emoji look identical everywhere, or may the operating system's own glyphs be used?
  • Must search work in several languages?
  • What keyboard and screen-reader support is required?

What a Strong Answer Covers Guidance

  • Scope stated up front and a time plan that leaves room for depth, since the candidate drives the discussion.
  • A component breakdown (search field, category navigation, grid, preview, skin-tone control) with a clear state model and a small API for the host that opens the picker.
  • The emoji data model and a loading strategy that does not slow down the host page.
  • Search: matching against names and keywords, result ranking, and responsiveness while typing.
  • Rendering performance for a grid of thousands of items, and how emoji glyphs are drawn.
  • Keyboard navigation, focus management and screen-reader announcements.
  • Persistence of recent emoji and preferences, and behavior when the data fails to load.

Follow-up Questions Guidance

  • How would the design change if an organization can upload thousands of custom emoji that change daily?
  • Emoji render differently, or not at all, across operating systems. What are the trade-offs between system glyphs and an image sprite?
  • How would you measure and protect the time from keystroke to updated results on low-end phones?
  • How would you test this component, including its accessibility?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...