I recently had a system design interview with Applied Intuition, lasting about 50 minutes. The setup was framed around a hypothetical Lakehouse platform (think a Databricks competitor), and I was placed in the Admin Experience team. The interviewer walked me through three connected problems, each targeting a different skill: database schema modeling, API design, and real-world cloud infra challenges. Below I’ve written down the exact English prompts I was given, along with how I approached them and how CSOAHelp’s real-time assistance helped me stay on track.

Question 1 (Original Wording)

“Please write up a Database Schema that can properly model the relationships above.”

The relationships were described as follows:

• A Customer can have multiple Users.
• A Customer can have multiple Repos.
• Each Repo must be bound to a ComputeEnvironment.
• A ComputeEnvironment can be shared by multiple Repos, but belongs only to a single Customer.

At first I hesitated, wondering if I should jump straight into writing DDL. The CSOAHelp instructor quickly reminded me: don’t dive into syntax immediately, start with the conceptual model. I described the ER diagram verbally — Customer–User (1:N), Customer–Repo (1:N), Repo–ComputeEnvironment (N:1), ComputeEnvironment–Customer (1:1). From there, writing down tables became straightforward:

• Customer(id, name)
• User(id, customerId, name)
• Repo(id, customerId, computeEnvId, name)
• ComputeEnvironment(id, customerId, config)

The interviewer asked whether multiple Customers could share the same ComputeEnvironment. With a quick prompt from the instructor, I clarified that ComputeEnvironments are scoped per Customer, and cross-customer sharing is not supported. That boundary condition made the schema feel complete and realistic.

Question 2 (Original Wording)

“You are in charge of the APIs to manage (e.g. Create / Read / Delete) ComputeEnvironments. Let’s go ahead and design the APIs for ComputeEnvironments below.”

Here the focus was on resource management APIs. The instructor suggested I frame everything RESTfully and emphasize Customer isolation. So I proposed:

• POST /customers/{id}/computeEnvironments → create a new environment
• GET /customers/{id}/computeEnvironments/{envId} → fetch details
• DELETE /customers/{id}/computeEnvironments/{envId} → delete an environment

I also added a paginated list endpoint for large-scale usage. The interviewer followed up: what if a ComputeEnvironment is still referenced by multiple Repos when someone tries to delete it? Guided by the instructor, I stressed dependency checks: the system should reject the deletion with a conflict error instead of blindly removing it. That gave the answer a more engineering-minded touch, not just surface-level API design.

Question 3 (Original Wording)

“You realize that CreateComputeEnv takes >10 minutes. Creating cloud infra is slow. How do you update your system?”

This was the open-ended scenario. If creating infra takes 10+ minutes, a blocking API call would time out and make users think the system is broken. Initially I froze a bit, but the CSOAHelp instructor immediately dropped the keywords: asynchronous, state machine, operationId. That gave me the structure:

• POST /customers/{id}/computeEnvironments should return immediately with an operationId.
• A background job handles the actual infra creation asynchronously.
• Status gets persisted as CREATING / RUNNING / FAILED.
• Clients can call GET /operations/{operationId} to poll progress.
• To build user confidence, stream logs or progress updates could be exposed.
• All operations must be idempotent to prevent duplicate resources.

The interviewer pressed on failure handling. With another hint, I added retry policies with exponential backoff, ensuring the system tolerates cloud API flakiness. That satisfied the robustness angle they were looking for.

Final Takeaway

Applied Intuition’s interview didn’t throw tricky algorithms. Instead, it emphasized modeling relationships, designing clean APIs, and adapting to real-world cloud infra latency. The challenge wasn’t in knowing the textbook answers but in delivering them coherently under pressure.

That’s where CSOAHelp made the difference: the instructor anchored my opening frameworks, fed me the right keywords when follow-ups came, and reminded me of engineering details like idempotency and dependency checks. Without that guidance, I might have stumbled; with it, I presented structured, confident answers.

If you’re preparing for Applied Intuition or similar system design-heavy interviews (Databricks, Stripe, OpenAI often ask in the same style), I’d highly recommend looking into csoahelp.com. With targeted prep and live assistance, you can showcase your real ability instead of getting derailed by nerves.