Problem and Scope
Design a Trello-like task management application. The app should allow users to create, organize, and track tasks using cards and lists, similar to Trello. The application should support a single user with multiple devices, and changes made on one device should sync to other devices in real-time.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to create and edit notes/cards with text content
- Users should be able to add image attachments to cards
- Users should be able to add checklists to cards
- Users should be able to change the status of cards (e.g., move from one state to another)
- The application should support synchronization of cards across multiple devices for the same user
Non-functional requirements:
- Support for offline mode - users should be able to create/edit cards while offline
- Real-time updates - changes made on one device should be immediately visible on other devices
- Data consistency across devices
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- Single user with multiple devices
- Potentially hundreds of cards per user
- Support for image attachments (potentially large files)
- Real-time synchronization between devices
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- UI components (cards, lists, editors)
- Data model for cards, checklists, and other entities
- Local storage for offline support
- Synchronization mechanism between devices
- Backend services for data persistence
- Media handling for image attachments
- Conflict resolution mechanism for handling simultaneous edits
- Handling offline mode and synchronization
- Managing conflict resolution when changes are made on multiple devices
- Efficient handling of image attachments
- Real-time updates across devices
- Data consistency across devices
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your system handle conflicts when a user edits the same card on two different devices while offline?
- Focus: Assess the candidate's answer to "How would your system handle conflicts when a user edits the same card on two different devices while offline" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What approach would you take for efficiently uploading large image attachments?
- Focus: Assess the candidate's answer to "What approach would you take for efficiently uploading large image attachments" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would you implement real-time synchronization between devices?
- Focus: Assess the candidate's answer to "How would you implement real-time synchronization between devices" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What data model would you use to represent cards, lists, and their relationships?
- Focus: Assess the candidate's answer to "What data model would you use to represent cards, lists, and their relationships" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your architecture handle offline mode and later synchronization?
- Focus: Assess the candidate's answer to "How would your architecture handle offline mode and later synchronization" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs did you consider when selecting your storage approach?
- Focus: Assess the candidate's answer to "What trade-offs did you consider when selecting your storage approach" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to create and edit notes/cards with text content; Users should be able to add image attachments to cards; Users should be able to add checklists to cards. Establishes the constraints that materially affect Design Task Management System, including Support for offline mode - users should be able to create/edit cards while offline; Real-time updates - changes made on one device should be immediately visible on other devices. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering UI components (cards, lists, editors); Data model for cards, checklists, and other entities; Local storage for offline support; Synchronization mechanism between devices. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as Single user with multiple devices; Potentially hundreds of cards per user to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Data model for cards, checklists, and other entities; Local storage for offline support; Backend services for data persistence. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Data consistency across devices; Data consistency across devices. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Efficient handling of image attachments; Real-time updates across devices; Data consistency across devices. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.