Implement Recipe Storage CRUD
Company: Circle
Role: Software Engineer
Category: Coding & Algorithms
Difficulty: hard
Interview Round: Technical Screen
Implement an in-memory `RecipeStore` that supports CRUD operations for recipes.
Each recipe contains:
- `id`: a string identifier in the form `recipe<n>`
- `name`: the recipe name
- `ingredients`: a list of strings
- `steps`: a list of strings
Implement these methods:
- `create(name, ingredients, steps) -> string`
- `get(recipeId) -> Recipe | null`
- `update(recipeId, updatedRecipe) -> bool`
- `delete(recipeId) -> bool`
Required behavior:
1. IDs are assigned sequentially starting from 1 and exposed as `recipe1`, `recipe2`, and so on.
2. `get`, `update`, and `delete` receive the id as a string such as `recipe2`. You must parse the numeric suffix to find the stored recipe. If the format is invalid, the operation fails.
3. Recipe names are unique in a case-insensitive way. For example, `Pasta` and `pAsTa` should be treated as the same logical name, so both cannot exist at the same time.
4. Preserve the stored casing of the name when returning a recipe. If a recipe was created as `PaSta`, `get` must return `PaSta`.
5. `update` succeeds only if `recipeId` matches `updatedRecipe.id`.
6. During `update`, the name may change only by letter case. For example, `PaSta` to `pasta` is allowed, but `PaSta` to `Noodles` is not.
7. If a case-only rename is accepted, future reads should return the new casing.
8. Updating or deleting a non-existent recipe should fail.
Design appropriate data structures and implement the methods so common operations are efficient.
Quick Answer: This question evaluates the ability to design and implement in-memory data structures and APIs for CRUD operations, covering skills such as ID generation and parsing, string handling for case-insensitive uniqueness constraints, data modeling, and preserving original value casing.