Circle·Software Engineer·Online Assessment (OA)·Intermediate

Intermediate

Apr 2026

Summary

Circle OA for a Software Engineer role, one question, basically a CRUD system design with some tricky case-sensitivity rules baked in. The kind of problem that looks straightforward until you actually read the constraints.

Questions Asked (1)

Design a Recipe Storage system that supports Create, Read, Update, and Delete operations. Each recipe has a name, ingredients list, and steps list. Add() should return an auto-incrementing string ID like 'recipe1', 'recipe2', etc. Name matching on Add is case-insensitive (reject duplicates but keep original casing). Update only allows changing casing of the name, not renaming to something different. Get and Delete work by string ID.

System DesignData ModelingAlgorithms & Data Structures

Author's notes

Spent the first few minutes thinking this was a simple hashmap problem and almost missed the name-matching rules entirely.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a data model with a hash map for ID-to-recipe mapping and a case-insensitive index for name uniqueness. Walk through each operation (Add, Get, Update, Delete) with time complexity, and discuss edge cases like duplicate names and ID generation.

Pro tip: Emphasize that the case-insensitive name index must store the original casing to preserve it, and that the auto-incrementing ID should be a simple counter to avoid collisions. Also, mention that Update only changes casing, so you can reuse the same name index entry.

1. Clarify Requirements and Constraints

Ask about expected scale, concurrency needs, persistence requirements, and whether IDs should be globally unique or per-user. Confirm that name matching is case-insensitive but original casing is preserved.

2. Design Data Model

Propose a Recipe class with id, name, ingredients, and steps. Use a hash map (e.g., HashMap<String, Recipe>) for ID-to-recipe lookup, and a separate case-insensitive index (e.g., HashMap<String, String> mapping lowercased name to ID) to enforce uniqueness.

3. Implement Core Operations

For Add: check name uniqueness via lowercased key, generate ID with a counter, store recipe, and add to both maps. For Get/Delete: use ID map. For Update: only allow changing casing of the name, so update the stored name and the name index key (lowercased name remains same).

4. Analyze Complexity and Edge Cases

Discuss O(1) average time for all operations. Handle edge cases: duplicate name on Add (reject), non-existent ID on Get/Update/Delete, and Update attempting to change name to a different string (reject).

5. Discuss Scalability and Extensions

Mention how to scale with sharding, caching, or a database. Consider concurrency (locks or concurrent maps) and persistence (write-ahead log or database).

Key Points to Mention

Use of two hash maps: one for ID-to-recipe, one for lowercased name to ID to enforce case-insensitive uniqueness.
Auto-incrementing ID generation using a simple counter (e.g., AtomicInteger for thread safety).
Update operation only changes casing: validate that the new name lowercased equals the old name lowercased, then update the stored name and the name index key (which remains the same lowercased string).
Time complexity: O(1) average for all operations due to hash map lookups.
Edge cases: duplicate name on Add, non-existent ID on Get/Update/Delete, and invalid rename attempt on Update.
Concurrency considerations: use ConcurrentHashMap or synchronized methods for thread safety.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.