The API

In one line: five calls, and the most interesting thing about the surface is what is deliberately missing from it.

The surface, grouped by path

Post a question

POST postQuestion(user_id, question, description, topic_label, video, image)

Parameter	Description
`user_id`	The user posting the question
`question`	The question text
`description`	Longer description — optional
`topic_label`	The domains the question relates to
`video`	A video file embedded in the question — optional
`image`	An image that is part of the question — optional

video and image are optional and set to NULL when unused; if provided, the media uploads with the question.

Post an answer

POST postAnswer(user_id, question_id, answer_text, video, image)

Parameter	Description
`question_id`	The question this answers
`answer_text`	The answer text

Vote and comment

upvote(user_id, question_id, answer_id)
comment(user_id, answer_id, comment_text)

Parameter	Description
`answer_id`	The answer being voted on, within `question_id`
`comment_text`	The comment posted against `answer_id`

downvote functions identically to upvote.

That shape is weaker than it could be, and it is worth saying so. The YouTube chapter used one endpoint with a three-valued field, so setting a reaction was an absolute assignment and therefore naturally idempotent. Here they are separate calls, which leaves two questions the API does not answer:

What happens if a user calls upvote twice? Does the count go up twice?
How does a user remove a vote, or switch from up to down?

Both are handled internally, but the API shape does not make the answer obvious. Relative operations repeat unsafely; absolute assignment repeats safely. Prefer the call that expresses the resulting state.

Note also that an upvote does two things: it increments a visible count, and it feeds the ranking model.

Search

searchQuestion(user_id, search_terms)

Matching is on term overlap after tokenization, which is why reordered queries return the same results — see Lesson 4 for what that trades away.

What has no endpoint

Ranking and recommendations are internal system processes, not user requests.

Lesson 2 listed feed and recommendation and ranking as functional requirements. Neither appears in the API, and that is correct: the user never asks for them. Nobody calls rankAnswers(). A user requests a question page, and ranking is something the system already did.

Not every requirement becomes an endpoint. Some are properties of how existing endpoints behave.

It also explains why those two are the hard requirements. An endpoint has a clear contract you can implement and test. A property like "answers are ordered by usefulness" has no contract — it is a quality judgment, which is why it needs a model and an evaluation loop rather than an implementation.

Key takeaway

Five calls, with topic_label mandatory because routing questions to potential answerers is the product. Separate upvote and downvote is weaker than a single absolute-assignment call, because relative operations repeat unsafely. And two of the five functional requirements have no endpoint at all — ranking and recommendations are properties of how other endpoints behave, which is exactly why they are the hard ones.

Interview signal by level

Level	What a strong answer sounds like
L4	"Endpoints to post a question, post an answer, vote, comment, and search."
L5	Notices the idempotency issue: "I'd make voting a single call that sets the reaction rather than separate upvote and downvote, so a repeated call is safe."
Staff+	Points at the absence: "two of the functional requirements — ranking and recommendations — have no endpoint, and that's right: the user never asks for them, they're properties of how the question-page read behaves. That's also why they're the hard ones, because a property has no contract to test against the way an endpoint does. And topic_label is the field that looks optional and isn't — it's the input to feed, notifications, and routing questions to people who can answer them."

Next: where this design breaks.