Machine Coding Interview Guide

Introduction

Machine Coding is one of the most important rounds in frontend interviews.

Unlike JavaScript or DSA rounds, where interviewers evaluate your theoretical knowledge and problem-solving ability, Machine Coding evaluates how you build a real application.

It answers questions such as:

• Can you convert requirements into working software?
• Can you structure your code properly?
• Can you think about scalability and maintainability?
• Can you write clean, modular code under time pressure?
• Can you communicate your thought process while coding?

Many candidates know React very well but still struggle in Machine Coding because they jump directly into implementation without planning.

“The name comes from the idea that you're expected to build a working feature, almost like a machine would execute a specification.”

What is a Machine Coding Round?

A Machine Coding round is a practical coding interview where you're asked to build a small application or a feature within a given time.

Unlike DSA, there is no single "correct" solution.

Interviewers are evaluating your engineering skills, including:

• Problem understanding
• Requirement clarification
• Component design
• State management
• Code organization
• Reusability
• Performance considerations
• Communication
• Debugging ability

Some common frontend machine coding problems include:

• Todo Application
• Autocomplete Search
• Infinite Scroll
• File Explorer
• Nested Comments
• Kanban Board
• Accordion
• Carousel
• Pagination
• Progress Bar
• Memory Game
• Tic Tac Toe
• Image Gallery

The objective is not just to make the application work but to demonstrate how you think while building it.

Categories Based on Time

Different companies allocate different durations depending on the complexity of the problem.

A. 30-Minute Round

Usually focuses on a small UI component or a limited feature.

Examples:

• Accordion
• Star Rating
• Progress Bar
• Tabs
• Traffic Light
• Password Strength Indicator

The interviewer expects:

• Clean implementation
• Correct functionality
• Basic edge cases
• Good communication

There is very little time for overengineering.

B. 45–60 Minute Round

This is the most common frontend machine coding format.

Examples:

• Todo Application
• Autocomplete
• Nested Comments
• Infinite Scroll
• File Explorer
• Shopping Cart

The interviewer expects:

• Component decomposition
• Proper state management
• Modular code
• Good naming conventions
• Basic optimizations

C. 2–3 Hour Machine Coding

Generally involves building a mini application.

Examples:

• Expense Tracker
• Notes Application
• Chat Application
• Dashboard
• Kanban Board
• Mini E-commerce Application

In addition to functionality, interviewers may evaluate:

• Folder structure
• Code quality
• Reusability
• Error handling
• Loading states
• Responsiveness
• Performance

D. Take-Home Assignment

Some companies prefer giving assignments that can be completed over a few days.

Examples:

• Movie Search App
• Weather Dashboard
• Blog Platform
• Task Management Tool

Since candidates have more time, expectations are significantly higher.

Interviewers may look for:

• Clean architecture
• Reusable components
• Responsive UI
• Testing
• Accessibility
• Error handling
• Documentation
• Deployment

Categories Based on Technology

Not every company expects the same implementation style.

Understanding what the company expects can save valuable interview time.

A. ReactJS-Based Machine Coding

B. Vanilla JavaScript Machine Coding

Which Companies Ask Which?

There is no universal rule, and interview formats evolve over time. However, a general trend is:

Vanilla JavaScript is more common in companies that want to evaluate strong JavaScript fundamentals.

Examples include companies such as:

• Microsoft
• Amazon
• Adobe

React-based Machine Coding is common when the role primarily involves React development.

Examples include:

• Uber
• Atlassian
• CRED
• Tekion

Always read the interview instructions beforehand. Many companies explicitly mention whether the solution should be built using React or Vanilla JavaScript.

How to Approach a Machine Coding Problem

One of the biggest mistakes candidates make is starting to code immediately.

Instead, follow this process.

Step 1: Understand the Problem

Read the requirements carefully.

Don't assume anything.

Take one or two minutes to fully understand what is expected.

Step 2: Ask Relevant Questions

Clarify ambiguous requirements before writing code.

Examples:

• Should the data persist after refresh?
• Can duplicate items exist?
• Is editing required?
• Should completed items move to the bottom?
• Are keyboard shortcuts expected?
• Is responsiveness important?

Interviewers appreciate candidates who clarify requirements instead of making assumptions.

Step 3: Modularize the Problem

This is where many candidates gain an advantage.

Consider a Todo Application.

Instead of seeing it as one big problem, divide it into smaller modules.

For example:

• Input Component
• Add Todo Logic
• Todo List
• Individual Todo Item
• Delete Functionality
• Edit Functionality
• Mark Complete
• Filtering
• Local Storage

Now you're solving several small problems instead of one large one.

This approach also makes your code cleaner and easier to maintain.

What to Focus On During the Interview

A common misconception is:

"I must finish every single feature."

This is not always true.

Interviewers generally value quality over quantity.

Suppose you're given a Todo Application with the following features:

• Add Todo
• Delete Todo
• Edit Todo
• Search Todo
• Filter Todo
• Persist Data

If time is limited, prioritize the core functionality.

A better strategy is:

✅ Add Todo

✅ Delete Todo

✅ Proper component structure

✅ Clean state management

✅ Good naming conventions

Then, if time permits:

• Edit
• Search
• Filtering
• Persistence

A well-structured application with the major functionality completed often creates a stronger impression than a rushed application containing many incomplete features.

Before implementing optional features, communicate your priorities:

"I'll first complete the core functionality so that we have a working application. If time permits, I'll continue with editing, filtering, and persistence."

This demonstrates planning and prioritization.

Is It Okay to Search Online?

Yes—but only for syntax, and only after asking the interviewer.

Examples of acceptable searches:

• CSS Flexbox syntax
• Array method syntax
• React Hook API reference
• JavaScript Date formatting
• HTML input attributes

Do not search for:

• Complete solutions
• Similar interview questions
• GitHub implementations
• YouTube tutorials

A simple way to ask is:

"I'm unable to recall the exact syntax for this API. Would it be okay if I quickly refer to the official documentation?"

Most interviewers appreciate honesty.

Remember:

Interviewers are evaluating your engineering ability, not your ability to memorize every syntax.

Is It Okay to Ask for Hints?

Absolutely.

Many candidates hesitate because they think asking for hints is a sign of weakness.

In reality, interviewers often expect some level of interaction.

If you've genuinely explored different approaches and are still stuck, asking for a hint is much better than sitting silently for ten minutes.

For example:

"I've considered two possible approaches, but I'm not convinced either is ideal. Could you provide a small hint on the direction you'd recommend?"

A hint often unlocks the rest of the problem.

Interviewers usually prefer:

• A candidate who asks for a hint, understands it, and successfully completes the solution.

over

• A candidate who remains stuck for the remainder of the interview without making progress.

Use hints wisely. First, spend a reasonable amount of time thinking through the problem yourself. If you're blocked, communicate your thought process and ask for guidance. This shows collaboration, self-awareness, and a willingness to learn—qualities that interviewers value highly.

Common Mistakes

1. Rushing to solve the problem without understanding it completely. Ex: create a stop watch which is accurate. Here not paying attention to the word “Accurate”.
2. Not reading the problem fully. Ex: Create a square boxes in the shape of C. Where each box has a colour white to begin with. Once user press the box, the colour changes to green. Once all the boxes turned into green colour, de-colour the boxes in the reverse order. Have a second delay between each box de-colouring. Most miss the second delay between the box de-colouring.
3. Falling to the interviewer’s trap very quickly. Ex: If question is too easy for the level then there is something your missing in the problem, try to decode it.
4. Not asking questions around the problem. Remember, the questions you ask about a problem shows your experience.
5. Not explaining the approach to interviewer and seek their approval before implementing.
6. Try to solve the problem as a whole without breaking it down into meaningful sub problems.
7. Try to focus more on styling than the functionality.
8. Not able to stay calm in the interview environment. Once the things planned do not work, getting tensed and try to experiment everything.
9. Add a series of console.log to understand the code written by themselves.
10. Series of runs to ensure everything works, which effects your confidence.
11. Trying to run the code without asking interviewer.
12. Making logic so rigid that even a small change requires a lot of code change.
13. Using a series of nested functions ex: .sort().includes().split() which makes code harder to read and difficult to understand and increase the complexity.
14. Not using any optimisation while coding. Trying to solve the problem in a Brute force way and left with no time to solve it optimised way.
15. Less / Over modularise the code.

Final Thoughts

Machine Coding is not a race to write the most code.

It is an opportunity to demonstrate how you think as a software engineer.

A successful candidate typically:

• Understands the requirements before coding.
• Clarifies ambiguities with thoughtful questions.
• Breaks the problem into smaller modules.
• Prioritizes core functionality.
• Writes clean, maintainable code.
• Communicates their decisions throughout the interview.
• Stays calm under pressure and adapts when needed.

Remember, interviewers are not only evaluating the final application—they're evaluating your problem-solving approach, engineering judgment, and ability to collaborate. A clear thought process and a well-structured solution often leave a stronger impression than a feature-complete application built in a hurry.

The SMART Rule

• S – Study the problem
• M – Modularize the solution
• A – Ask clarifying questions
• R – Review edge cases
• T – Test important scenarios

Applying the SMART Framework

SMART - Machine Coding Framework

S - Study the Problem

Understand what needs to be built.

Autocomplete

• Search input
• Show matching suggestions
• Click a suggestion to fill the input
• Update suggestions as the user types

M - Modularize

Break the problem into smaller pieces.

Components

• SearchInput
• SuggestionList
• SuggestionItem

State

• searchText
• filteredSuggestions

A - Ask Clarifying Questions

• Is the data static or from an API?
• Should search be case-sensitive?
• Match from the beginning or anywhere?
• Show suggestions when input is empty?
• What should happen if there are no results?
• Is keyboard navigation required?

R - Review Edge Cases

• Empty input
• No matching results
• Duplicate values
• User types spaces
• Large dataset

T - Test Important Scenarios

• Typing shows suggestions
• Clearing input hides suggestions
• Clicking a suggestion fills the input
• Search works regardless of case
• "No Results" is shown when nothing matches

Solution

import React, { useState } from "react";

const users = [
  { id: 1, name: "Vasanth Kumar", company: "Test", role: "Staff Engineer" },
  { id: 2, name: "Rahul Sharma", company: "Google", role: "Software Engineer" },
  { id: 3, name: "Priya Singh", company: "Microsoft", role: "Senior Engineer" },
  { id: 4, name: "Akshay Patil", company: "Amazon", role: "Frontend Engineer" },
  { id: 5, name: "Sneha Reddy", company: "Adobe", role: "React Developer" },
  { id: 6, name: "Rohit Verma", company: "Flipkart", role: "SDE-2" },
  { id: 7, name: "Ankit Gupta", company: "Swiggy", role: "Software Engineer" },
  { id: 8, name: "Pooja Nair", company: "PhonePe", role: "Senior Frontend Engineer" },
  { id: 9, name: "Karthik Rao", company: "Paytm", role: "React Developer" },
  { id: 10, name: "Naveen Kumar", company: "Oracle", role: "UI Engineer" },
  { id: 11, name: "Harish R", company: "Salesforce", role: "Frontend Engineer" },
  { id: 12, name: "Vivek Jain", company: "Uber", role: "Software Engineer" },
  { id: 13, name: "Neha Kapoor", company: "Intuit", role: "Senior UI Engineer" },
  { id: 14, name: "Amit Yadav", company: "SAP", role: "React Engineer" },
  { id: 15, name: "Kiran Kumar", company: "Zoho", role: "Frontend Developer" },
  { id: 16, name: "Sanjay R", company: "Freshworks", role: "UI Developer" },
  { id: 17, name: "Ajay Sharma", company: "Cisco", role: "Software Engineer" },
  { id: 18, name: "Nikhil Gupta", company: "Atlassian", role: "Frontend Engineer" },
  { id: 19, name: "Megha Joshi", company: "LinkedIn", role: "Senior Engineer" },
  { id: 20, name: "Arjun Patel", company: "Netflix", role: "React Developer" }
];

export default function App() {
  const [search, setSearch] = useState("");

  const filteredUsers = users.filter(
    (user) =>
      user.name.toLowerCase().includes(search.toLowerCase()) ||
      user.company.toLowerCase().includes(search.toLowerCase()) ||
      user.role.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div style={{ width: 450, margin: "40px auto" }}>
      <h2>User Search</h2>

      <input
        type="text"
        placeholder="Search by name, company or role..."
        value={search}
        onChange={(e) => setSearch(e.target.value)}
        style={{ width: "100%", padding: 10 }}
      />

      {search && (
        <ul>
          {filteredUsers.map((user) => (
            <li key={user.id}>
              <strong>{user.name}</strong>
              <br />
              {user.company} • {user.role}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

In-Session Practice Problem

Build a traffic light where the lights switch from green to yellow to red after predetermined intervals and loop indefinitely. Each light should be lit for the following durations:

• Red light: 4000ms
• Yellow light: 500ms
• Green light: 3000ms

You are free to exercise your creativity to style the appearance of the traffic light.