In this article
Before you start
For how this round fits a full loop, see the interview process and its stages. The term "functional round" has no single standard definition, so this page defines it below and reports only what candidates describe.
Why interviewers ask this
A functional round checks whether you can do the daily work of engineering, not only solve a puzzle. Reported examples show the range: a Microsoft candidate reported being asked to explain object-oriented programming (OOP) and the SOLID principles and then design a chess board; a Stripe candidate reported an API design round where the expectation was to parse JavaScript Object Notation (JSON); an xAI candidate reported implementing a data fetch behind a prompt-history screen; a Google candidate reported a small conversion problem followed by a repo-wide migration scenario. These are reports by candidates, not company statements.
A weak answer starts typing or drawing at once. A strong answer first narrows the problem, then names a model, applies a principle, and says what it costs. The four kinds differ in what you produce: class design produces classes and methods, API design produces endpoints and JSON shapes, user interface (UI) wiring produces working fetch code, and tool trivia produces short spoken answers.
Text description of the diagram
- Class design produces classes and methods.
- Tool trivia produces short spoken answers.
Non-leetcode functional rounds from first principles
- Functional round
- A functional round is a technical interview that asks you to produce or explain working engineering, such as a class model, an API, a screen that calls a service, or the behavior of a tool, and that is judged on design reasoning and clarity more than on an algorithm's speed.
- Class
- A class is a template in object-oriented code that defines the state and behavior its objects will have, so many similar objects can be created from one description.
- SOLID principles
- The SOLID principles are five design guidelines for object-oriented code: single responsibility, open/closed, Liskov substitution, interface segregation and dependency inversion, each meant to keep code easy to change without breaking its users.
In plain words
Think of a restaurant kitchen. Each station has one job, the stations pass plates through a window, and the menu can change without rebuilding the kitchen. A functional round asks you to build that kind of structure, in code or in words, while someone watches. The analogy breaks at one point. A real kitchen can be rearranged by hand. Code has callers that depend on its current shape, and that is why design principles exist.
In one precise sentence, a functional round asks you to turn a loosely stated need into a small, correct, changeable design and to justify its trade-offs aloud.
Step 1: Clarify the ask before you design anything
The answer starts with clarifying questions. Input: a one-line prompt such as "design a chess board". Output: a short list of agreed scope and assumptions. Ask who uses the code, what must work now and what can wait, what the inputs look like, and what failures matter. For a chess board, ask whether you are modeling only the board and pieces or also the rules, turns and a game history.
For an API round, ask what the caller sends and what shape comes back. For a fetch task, ask what happens while the request is pending and when it fails. Saying your assumptions out loud shows judgment and lets the interviewer correct you early, which is cheap. You now have a scope; the next step turns it into a model.
Step 2: Model state and behavior
The model names state and behavior before any principle. Input: the agreed scope. Output: a list of objects, what each one knows, and what each one does. Oracle's Java tutorial describes real-world objects as having state and behavior, and that pairing is the quickest way to find the classes in a prompt.
Name the nouns first (board, square, piece, move), then give each noun its data and its actions. Keep the first version small; extra features come after the core works. Say why each class exists in one sentence. Prefer four classes you can justify over ten you cannot: every class you name invites a "why does this exist?" follow-up. With a model on the table, you can test it against principles.
Step 3: Apply principles to the model
Apply a principle only where it solves a visible problem in your model. The single responsibility idea says a class has one reason to change: a piece should know how it moves, not how a board is drawn. The open/closed idea says you add a new kind of piece by adding a class, not by editing a long conditional. Liskov substitution says any piece can stand where a generic piece is expected without surprising the caller. Interface segregation keeps contracts small, and dependency inversion makes the board depend on a general piece contract instead of each concrete piece.
The same method works for an API (keep each endpoint to one job) and for a screen (keep fetching apart from drawing). Name the principle, point at the line of your design it shaped, and move on. Reciting all five without pointing at the design earns little.
Step 4: Say the trade-off and a test
The answer ends with a trade-off and a test. Input: your finished design. Output: one cost you accepted and one way you would check the design works. A separate class per piece type makes new pieces easy but adds files; a table of move rules is shorter but harder to extend. State which you chose and why.
Then name a test: a short case that proves the design, such as moving a knight past other pieces, or an automated check that a repo-wide rename does not touch names owned by outside code. For a migration scenario, the same shape applies: find candidates, protect external contracts, and validate changes automatically. Ending on a named cost and a test is what the strong and Staff columns of the rubric below share.
Step-by-step description
- Ask about scope, inputs and failures first.
- Name objects, their state and their behavior.
- Apply a principle where it fixes a problem.
- End with one cost accepted and one test.
- The answer starts with clarifying questions.
- The model names state and behavior before any principle.
- The answer ends with a trade-off and a test.
Worked example: sizing the chess board model
A standard chess game has 64 squares and starts with 16 pieces per side, 32 in total, drawn from six kinds of piece.2 Those counts size the model. Six kinds of piece means six move rules, so six small classes or one table of rules, and 64 squares means a fixed grid you can store as a simple two-dimensional array.2 One rule per kind is a simplification: castling, en passant and pawn promotion cross kinds, and a strong candidate names them as edge cases. Whose turn it is and the move history are state that would live on a game object that owns the board, not on the pieces.
| Part of the model | Count or fact | Design consequence |
|---|---|---|
| Squares | 64 | fixed grid, no need for a dynamic structure |
| Pieces at the start | 32 | pieces can be stored on the board or as a list per side |
| Kinds of piece | 6 | six move rules, one per kind |
| Move rules shared by all pieces | one contract | a generic piece contract lets the board treat every piece alike |
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
How would you approach a design round with no algorithm puzzle in it?
I start by asking what is in scope and what the inputs and failures are, because the prompt is usually loose. Then I name the objects and give each one state and behavior, keeping the first version small. I apply a principle only where my design needs it, for example a shared piece contract so new piece types need no edits to the board. I finish by naming the cost I accepted, such as more classes for easier extension, and one test that would catch a mistake. If I am unsure of a fact, I say so and reason from what I know.
What makes it Staff-level is the order and the ending: questions first, a reasoned cost last, and honesty about gaps in between.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Scope | Starts building at once | Asks two or three clarifying questions | States assumptions and what is deferred |
| Model | Long list of classes, no reasons | Few classes, each with a reason | Parts shaped around what will change |
| Principles | Recites names | Applies one to a visible problem | Shows where a principle would over-complicate |
| Trade-offs | None mentioned | Names one cost | Compares two designs and picks with a reason |
| Communication | Silent, then a finished answer | Talks while working | Checks the interviewer's reaction and adjusts |
Three variants of this question
What's OOP and what are the SOLID principles?
Object-oriented programming (OOP) is a way of organizing code as objects that bundle state and behavior, usually created from classes. The SOLID principles are five guidelines for keeping such code changeable: single responsibility, open/closed, Liskov substitution, interface segregation and dependency inversion. Define the first in a sentence, name each of the five in a clause, then give one example from the design you are building.
Design a chess board
Ask whether rules and turns are in scope, model board, square, piece and move, and give the piece a shared contract with one move rule per kind. Say what you would test first. The counts that size this design are in the worked example above.
What is the default isolation level in Postgres?
An isolation level is a setting that decides which changes from other concurrent transactions a transaction can see. According to the PostgreSQL manual, Read Committed is the default isolation level, and the manual lists four levels: Read Uncommitted, Read Committed, Repeatable Read and Serializable. In PostgreSQL, Read Uncommitted behaves like Read Committed, so only three distinct levels are implemented. Add one sentence of consequence: in Read Committed each query sees only data committed before that query began. Candidates report that some screens are run by non-technical recruiters against a keyword list, so say the exact term, for example "Read Committed", before you explain it.
Common mistakes
- "Let me start coding the board." (wrong) It skips scope and shows no judgment. (right) "Before I design, should the model include game rules and turns, or just the board and pieces?"
- "I'll use all five SOLID principles." (wrong) Listing principles without a problem they solve sounds recited. (right) "A shared piece contract lets me add a piece without editing the board."
- "Non-leetcode means I need no code." (wrong) Candidates report coding in these rounds. (right) "I will expect to write small, working code and explain it."
- "I have never seen that, so I can't answer." (wrong) It ends the conversation. (right) "I don't know that detail, but systems of this kind usually store the following, and here is how I would find out."
Follow-up questions
Does non-leetcode mean there is no coding?
No. Candidates report writing code in these rounds; the difference is that the task is applied rather than a puzzle. Expect to write and explain working code, as the AI-assisted coding interview page also discusses.
What if the interviewer asks trivia I do not know?
Say so briefly, then reason from related knowledge. A Google candidate reported being asked about the structure of an inode in an old Unix version and answered generally about what Unix-like systems keep in inodes; that approach shows honesty and range. The staff follow-up covers how to handle a question that goes past what you prepared.
How is a functional round different from system design?
A functional round usually asks for a smaller artifact, such as one class model, one endpoint or one screen, while system design spans many services and capacity. A loop can contain both kinds of round.
How do you answer a repo-wide migration scenario?
Find candidates for the change with search, exclude names owned by outside code, and validate with automated tests before merging. The refactor take-home shows a related exercise, and the project deep dive is where you would discuss a real migration you led.
- A functional round tests applied engineering, such as class design, API design or tool knowledge, not algorithm speed.
- Start with clarifying questions, then model state and behavior, then apply principles where they solve a problem.
- End every answer with one trade-off you accepted and one test.
- Say what you do not know and reason from related facts.
- Company examples here are reported by candidates, not stated by the companies.
Sources
- PostgreSQL documentation: 13.2 Transaction Isolation — PostgreSQL Global Development Group, 13 Aug 2026
- The Java Tutorials (Java SE 8): What Is an Object? — Oracle, 26 Oct 2026
