Functional requirements

In a design document, functional requirements are usually captured as use cases. Each use case describes one or more system behaviors:

When a customer does this, the system does that.

Use the same approach in an interview. Identify one, two, or perhaps three core functions, then focus the rest of the design on that small set.

An interviewer may give the functions directly: “Design video upload and video viewing for a YouTube-like system.”

Or the prompt may only say: “Design a YouTube-like system.” In that case, defining the functions is part of your task.

To find the functions, first determine who will use the system and how.

A customer can be:

• a person;
• a digital device;
• another software system.

This is easier for products you already use, such as YouTube, Facebook, a messenger, or Gmail.

It is harder for infrastructure systems that people do not interact with directly, such as rate limiters, fraud-prevention systems, or content delivery networks.

For an unfamiliar system, the central questions are often: What is the input? What is the output? Who sends the input, and who consumes the output?

Start with the customer and work backwards toward the system behavior.

The working-backwards approach was popularized by Amazon. Before developing a product, a team describes the problem, the intended customers, and the benefit those customers should receive.

In an interview, begin by clarifying the customers.

For a YouTube-like product, two obvious customer groups are:

• content creators who upload videos;
• viewers who watch videos.

For a rate-limiting system, the customers are other systems—for example, web services that need protection from overload.

After identifying customers, ask what they do.

For a rate limiter, a web service calls the rate-limiting system for an incoming request. The response tells the service whether that request should be allowed or throttled.

For a video platform, creators may:

• upload videos;
• create posts;
• inspect analytics.

Viewers may:

• search for videos;
• watch videos;
• leave comments.

Each function can become a large system on its own. Ask the interviewer which functions belong inside the scope of the current discussion.

An ambiguous prompt tests whether you can break a large, unclear problem into manageable pieces.

The expected ambiguity often depends on the role. Entry-level candidates may receive explicit functions, while senior candidates may need to discover and prioritize them.

Do not attempt to design every possible feature. Establish a small set of core use cases and confirm it with the interviewer before moving into architecture.

Sometimes the interviewer describes the use cases verbally and asks you to express them as an API.

The expected interface is commonly:

• an RPC API;
• a REST API.

The interview may focus almost entirely on identifying the key functions and translating them into a corresponding API.

This requires knowledge of RPC and REST conventions. The important sequence is still the same: customers → actions → use cases → API contract.