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.
Process a sequence of operations against an in-memory `RecipeStore`. Each recipe has four fields: `id`, `name`, `ingredients`, and `steps`. A recipe id is exposed as strings like `recipe1`, `recipe2`, and so on. Return the result of every operation in order. Operation forms are: `('create', name, ingredients, steps)`, `('get', recipeId)`, `('update', recipeId, updatedRecipe)`, and `('delete', recipeId)`. Rules: (1) successful creates receive sequential ids starting at `recipe1`; failed creates do not consume an id, (2) `get`, `update`, and `delete` must parse the numeric suffix from the id and fail if the format is invalid, (3) recipe names are unique case-insensitively, so `Pasta` and `pAsTa` cannot both exist, (4) preserve the stored casing of the name when returning a recipe, (5) `update` succeeds only if `recipeId == updatedRecipe['id']`, (6) during `update`, the name may change only by letter case, such as `PaSta` to `pasta`, but not to a different logical name, (7) if a case-only rename succeeds, future reads must return the new casing, and (8) updating or deleting a non-existent recipe fails. For `create`, return the new id on success or `None` on failure. For `get`, return the recipe dictionary or `None`. For `update` and `delete`, return `True` or `False`.