The problem statement is usually 1 to 2 pages long and describes a real-world system: a parking lot, a meeting room scheduler, a food delivery app, a stock exchange. You will see a list of features the system should support, sometimes with explicit constraints ("support multiple floors," "handle concurrent bookings") and sometimes deliberately vague to test whether you ask clarifying questions.

This is fundamentally different from an OOD interview. In OOD, you spend most of your time on designing classes and discussion. In machine coding, your design phase should be 15-20% of the total time at most. The rest is implementation, testing, and bug fixing. You are evaluated on what you deliver, not what you describe.

You are expected to produce a runnable codebase with clean class design, working logic, and a demo (usually a Main class) that exercises the core workflows.

This chapter covers a 5-phase framework for machine coding interviews, using Stack Overflow as the running example.

Here are the 5 phases:

Phase 1: Understand and Clarify (3-5 minutes)

Read the problem statement carefully. Then read it again. Underline or note every action the system must support. Separate what is explicitly required from what is implied or ambiguous.

What to Look For

If you are allowed to ask the interviewer questions, this is the time.

Good clarifying questions include:

Take Quick Notes

Write down your requirements in a MUST HAVE / NICE TO HAVE format. This keeps you focused on what matters and gives you a clear list to work through.

Example for Stack Overflow

MUST HAVE:

NICE TO HAVE:

Phase 2: Quick Design (5-10 minutes)

You are not required to sketch out a detailed UML diagrams. You need just enough structure to start coding without second-guessing every class and method.

What to Identify

Identifying Classes Quickly

There is a simple trick that works surprisingly well: read the problem statement and highlight the nouns, verbs, and adjectives.

For the Stack Overflow example, the problem statement says: "Users can ask questions with tags, post answers, add comments, and upvote or downvote content." That single sentence gives you six classes and five methods.

One more class that does not appear in the problem statement but you always need: a manager or service class that ties everything together. This is the entry point for all operations. Call it StackOverflow, StackOverflowService, or StackOverflowManager. It holds collections of users and questions, and every public operation goes through it.

Choosing Data Structures

Your choice of data structures during the design phase directly affects how much code you write later. Get this right and implementation flows naturally.

When to use a Map vs a List:

Rule of thumb: If you will ever ask "does this collection contain X?" or "give me the item with ID Y," use a Map. If you just iterate through items or care about order, use a List.

Enums vs booleans vs string constants:

Quick Sketch

Write this on paper or in a comment block:

Classes: User, Question, Answer, Comment, Tag, Vote, StackOverflow (manager)

Relationships:

Key methods on StackOverflow:

Anti-Pattern: Over-Designing

Do not do this in a machine coding interview:

You will discover design issues while coding. That is fine. Refactor as you go.

Phase 3: Project Structure and Setup (10-15 minutes)

Before writing any business logic, set up your project skeleton. This takes 3-5 minutes but saves much more than that.

Why does skeleton-first work so well?

First, it compiles immediately. You have a project that builds and runs from minute 10. Every change you make from this point is incremental. You never face the dreaded "I have 500 lines of code and none of it compiles" situation at minute 50.

Second, it gives you navigation. When you are deep in the implementation phase and need to add a method to Question, you know exactly where to find it. Under time pressure, hunting through a single 400-line file for the right class wastes minutes you cannot afford.

Third, it provides psychological momentum. You have created files, written constructors, and your project runs. You are no longer staring at a blank screen. The hardest part of any timed exercise is getting started, and a skeleton removes that friction.

Naming Conventions

Stick to whatever convention your language uses. Do not invent your own style.

For the model vs service distinction: model classes hold data and behavior related to a single entity (Question knows how to add an answer to itself). The service class coordinates operations across multiple entities (StackOverflow knows how to connect a user's answer to a question). If you are unsure where a method goes, ask: "Does this operation need to know about more than one entity?" If yes, it belongs in the service class.

Example Folder Structure

Create Skeleton Classes

Start by creating all your classes with just the fields and constructor. Do not write any logic yet. This gives you a complete skeleton to fill in.

Now create the two content classes. Both Question and Answer need comments and votes, so they share similar fields:

All your model classes now exist. The project should compile with no errors even though nothing happens yet.

Phase 4: Core Implementation (15-65 min)

Spend 40-50 minutes here. The goal: get all core operations working end-to-end so you can run test cases and see correct output.

Implementation Order: Bottom-Up

Build your code bottom-up: models first, then the service class, then main.

Why this order? Because each layer depends only on the layer below it. When you write StackOverflow.askQuestion(), the User, Question, and Tag classes already exist and compile. You never write a method that calls something you have not built yet. This means every method you write can be tested the moment you finish it.

The opposite approach, starting with main and working down, leads to a cascade of compilation errors. You write stackoverflow.askQuestion(...) but askQuestion does not exist yet. Then you create the method but Question does not exist. You end up with 10 files open, all broken, and no way to test anything. Bottom-up avoids this entirely.

Recommended order for Stack Overflow:

When to Skip Features

Look at your MUST HAVE list from Phase 1. Work through it in priority order. If you reach minute 50 and you have three features left, make a judgment call: which ones are essential and which can be left as TODOs?

Leave a clear comment for anything you skip:

This tells the interviewer two things: you identified the requirement, and you know how you would implement it. That is worth partial credit. An empty gap with no comment looks like you forgot the feature entirely.

One more thing: never skip validation in favor of new features. A system that handles 4 features with proper error handling scores higher than a system that handles 6 features but crashes on invalid input.

The StackOverflow Manager Class

Build it method by method, testing as you go.

The Main Class

Now write a main entry point that exercises all the functionality. This doubles as your test harness and the first thing anyone reviewing your code will read.

Expected Output

When you run this, you should see:

You now have a fully working system. Compile it, run it, verify the output. If you are past the 60-minute mark and everything above works, you are in good shape.

Phase 5: Edge Cases, Validation, and Testing (65-90 minutes)

Core functionality works. Spend your remaining 20-25 minutes hardening the solution.

Common Edge Case Categories

Before diving into your specific problem, run through these categories mentally. They apply to almost every machine coding problem.

Validation Checklist

Go through each operation and ask "what could go wrong?":

Incremental Testing Strategy

Do not write all your code and test at the end. Instead, test after each major component:

If you find a bug, fix it immediately. Do not keep going and hope to fix it later. A small bug left unfixed often cascades into bigger issues.

Code Cleanup (If Time Permits)

In the last 5 minutes: