Articles

Blogs

MCQ

SQL

Q&A

Tools

Tags

Jobs

News

Community

LogIn

Email

Password

Show Password

Forget Password

I don't have account.Sign Up!

Login

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -53%

Zebronics #1 Best Seller

ZEBRONICS Blanc Slim Wireless Mouse — Rechargeable, BT + 2.4GHz (Black)

Up to 1600 DPI · Silent clicks · 63g · Multicolor LED

★★★★★★★★★★ 4.0 (9,512) 5K+ bought last month

₹376 M.R.P. ₹799Save ₹423

Buy Now →

Adℹ

✕

Flipkart Machine Coding Round Experience ~ Log Engine Implementation

Arun Sharma

Last Updated : 23 May 2026

67 Views

#interview-experience

#interview-preparation

#coding-interview

#experienced-candidate-interview

#interview-questions

Adℹ

I recently participated in a machine coding round with Flipkart and unlike many machine coding interviews that require building an application from scratch, this exercise focused heavily on understanding existing code, interpreting requirements through failing unit tests and implementing missing functionality correctly. The overall experience felt very close to real-world software development where engineers spend more time extending and maintaining existing systems than writing entirely new applications.

The problem statement revolved around completing an in-memory log query engine. A partially implemented codebase was provided along with a set of unit tests. Several methods had intentionally been left incomplete, causing the tests to fail. The objective was straightforward: understand the expected behavior, implement the missing functionality, handle edge cases correctly and ensure all tests passed successfully.

One interesting aspect of the exercise was that requirements were not entirely described in a traditional specification document. Instead, candidates were expected to derive part of the expected behavior by reading unit tests. This mirrors real engineering scenarios where understanding existing code and test suites becomes an important skill.

Problem Overview

The system consisted of three primary components:

• LogEntry

• Represents an individual log record.

• Each log contains:

  • timestampMs : timestamp in milliseconds
  • level : log severity (DEBUG, INFO, WARN, ERROR)
  • message : log message

Example:

new LogEntry(
    1710000000000L,
    LogLevel.ERROR,
    "Database connection failed"
);

Query : Represents a search request with optional filtering conditions.

Supported filters:

• level → exact log level match
• contains → substring match on message
• startTsInclusive → lower timestamp boundary
• endTsInclusive → upper timestamp boundary

All filters are optional and can be combined together.

Example:

Query query = new Query();

query.setLevel(LogLevel.ERROR);
query.setContains("Database");
query.setStartTsInclusive(1710000000000L);
query.setEndTsInclusive(1710001000000L);

LogStore

The primary component candidates were required to implement.

Responsibilities:

• Store logs in memory
• Execute filtered searches
• Preserve insertion order
• Return immutable query results

Most of the machine coding effort was concentrated here.

Phase 1 : Implement append() and query()

The first phase required implementing two methods:

append(...)
query(...)
append()

The append method was responsible for inserting new log entries into memory.

Example:

store.append(
    1710000000000L,
    LogLevel.INFO,
    "Application Started"
);

The interviewer expected careful validation. The following inputs must be rejected:

level == null
message == null

For example:

store.append(
    1710000000000L,
    null,
    "hello"
);

should throw an exception. Similarly:

store.append(
    1710000000000L,
    LogLevel.INFO,
    null
);

must also fail validation. Another important requirement was preserving insertion order. If logs are inserted as:

INFO  -> Started
WARN  -> Cache Miss
ERROR -> DB Down

query results should appear in the exact same order regardless of filtering.

query()

The query implementation was where most of the logic existed. The method needed to apply all provided filters simultaneously. A log should only be returned if every active filter matches.

Filter 1: Level Match

Example:

Stored logs:

• INFO Started
• ERROR DB Failure
• WARN Retry

Query:

• level = ERROR

Result:

• ERROR DB Failure

This was a simple equality comparison.

Filter 2: Message Contains

Example:

Logs:

• Database failure
• Cache miss
• Database timeout

Query:

• contains = "Database"

Result:

• Database failure
• Database timeout

An important detail was that matching must be case-sensitive.

Example:

• contains = "database"

should NOT match: Database failure because the casing differs. Empty String Edge Case, One tricky requirement was:

• contains = ""

must be treated as no filter.

Example:

• query.setContains(""); should behave identically to: query.setContains(null); and return all matching records without applying message filtering.

This is a common interview edge case that many candidates overlook.

Filter 3: Time Range

Time filtering used inclusive boundaries.

Example:

Logs:

1000
2000
3000
4000

Query:

• startTsInclusive = 2000 and endTsInclusive = 3000

Result:

2000
3000

Both boundary values must be included.

Invalid Range

Special handling was required when: startTsInclusive > endTsInclusive

Example:

start = 5000
end   = 1000

In this scenario: [] must be returned immediately. No logs should match.

No Filters Provided

If every query field is empty: new Query() the result should contain every stored log.

Example:

INFO
WARN
ERROR

Output:

INFO
WARN
ERROR

while preserving insertion order.

Immutable Result Requirement

One requirement many candidates miss during interviews was: Returned list must be immutable.

For example:

List<LogEntry> result = store.query(q);

This should fail:

result.add(new LogEntry(...));

A common implementation:

Collections.unmodifiableList(...)

or

List.copyOf(...)

depending on Java version. The interviewer seemed particularly interested in whether candidates noticed this detail.

Phase 2 : Implement queryCount()

After Phase 1 tests passed, an additional requirement was introduced. A new method needed to be implemented:

int queryCount(Query q);

The goal was straightforward: Return the number of matching log entries instead of returning the entries themselves.

Example:

Logs:

ERROR DB Failure
ERROR Timeout
INFO Started

Query: level = ERROR

Output:

2

A simple implementation could internally reuse filtering logic already written for query().

However, an optimized implementation could avoid constructing intermediate collections and simply maintain a counter while scanning logs. This follow-up was less about coding and more about identifying opportunities for code reuse and performance optimization.

Phase 3 : Asynchronous Log Persistence

The final phase shifted away from filtering logic and into practical system design.

The requirement was: Write an asynchronous scheduler that periodically reads logs from local memory and writes them to a file every 10 seconds.

The interviewer explicitly mentioned that a commented-out example already existed in Main and candidates could uncomment it and execute the application to verify behavior. A typical solution involved:

• Components
• In-memory log storage
• Background scheduler
• File writer
• Graceful shutdown handling
• Possible Implementation

Using Java's: ScheduledExecutorService

Example architecture:

LogStore
    │
    ▼
Scheduled Task
    │
    ▼
Snapshot Logs
    │
    ▼
Write To File

The scheduler executes: every 10 seconds and persists current logs.

Topics that naturally emerged during discussion included:

• Thread safety
• Concurrent reads and writes
• Snapshot consistency
• File append versus overwrite strategy
• Error handling during disk failures
• Shutdown hooks
• Memory consumption

This phase felt much closer to a real backend engineering problem than a traditional coding challenge.

Overall Experience

The Flipkart machine coding round was less about solving a complex algorithmic puzzle and more about demonstrating software engineering fundamentals. Success depended on reading requirements carefully, understanding existing code, handling edge cases correctly, writing clean implementations and reasoning about production concerns.

• Areas Being Evaluated
• Requirement comprehension
• Unit test interpretation
• Clean code practices
• Validation and edge-case handling
• API design understanding
• Thread safety awareness
• Practical Java knowledge
• Maintainable implementation

Unlike many DSA-focused interviews, this exercise resembled actual day-to-day backend development. Candidates comfortable with Java collections, immutability, concurrency basics and writing testable code would likely find the challenge more approachable than traditional algorithm-heavy interview rounds.

Recommended Interview Experience

• Disney+ Hotstar SDE-2 Interview Experience | Coding + System Design + Techno Managerial
• Uber Senior Software Engineer Interview Experience | Real Interview Questions, System Design & Preparation Guide
• Meta Business Engineer (L4 → L5 Consideration) Interview Experience
• Rupeek Android Developer Interview Experience | Real Questions Asked, Preparation Tips & Complete Process
• Rupeek SDE-3 Interview Experience (3 Rounds ~ Coding, LLD & HLD)
• WheelsEye Backend Engineer Interview Experience | DSA Questions, System Design, Backend Deep Dive
• Wise Software Engineer Interview Experience | DSA, System Design, Product Thinking
• Yext SDE 1 Interview Experience – Complete DSA Questions, Debugging Round, API Challenge & HR Round
• Uber SDE 2 Interview Experience (5 Rounds, Selected)
• Adobe Software Engineer 2 Interview Experience
• Volvo Cars Full Stack Developer Interview Experience (Selected)
• Wayfair SDE Interview Experience
• Wells Fargo SDE I Interview Experience
• My Vegapay Backend Engineer (SDE 2) Interview Experience (Rejected)

Trending Developer Reads

Meesho SDE-1 Online Assessment Interview Experience (Remote) - Rejected

Blinkit (Eternal) SDE-1 Interview Experience (June 2026) – Offer Received

Google L4 Software Engineer III interview experience | Selected

System Design Interview – BIGGEST Mistakes to Avoid

Rippling SDE-2 Interview Experience (4+ Years Experience) | Offer Received | Coding, LLD & System Design

Meesho SDE-1 Backend Interview Experience (Remote | 3 Round) - Rejected

Spinny SDE-1 Interview Experience (Selected)

Uber SDE 2 Interview Experience (5 Rounds, Selected) - Complete DSA Questions with solution, System Design & Managerial Round

Zepto SDE-1 Interview Experience (Backend Developer) : Real DSA, LLD, Chess Game Design

Top 50+ SQL Interview Questions and Answers for Intermediate to Advanced

Responses (0)

Write a response

Hide Comments

No Comments yet.

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -53%

Zebronics #1 Best Seller

ZEBRONICS Blanc Slim Wireless Mouse — Rechargeable, BT + 2.4GHz (Black)

Up to 1600 DPI · Silent clicks · 63g · Multicolor LED

★★★★★★★★★★ 4.0 (9,512) 5K+ bought last month

₹376 M.R.P. ₹799Save ₹423

Buy Now →

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -34%

iQOO Amazon's Choice

iQOO Z10 Lite 5G — Cyber Green, 4GB RAM, 128GB Storage

Dimensity 6300 · 50MP Sony AI Camera · 6000 mAh · IP64

★★★★★★★★★★ 4.0 (2,052) 500+ bought last month

₹18,997 M.R.P. ₹28,999Save ₹10,002

Buy Now →

\n \n \n \n \n

I recently participated in a machine coding round with Flipkart and unlike many machine coding interviews that require building an application from scratch, this exercise focused heavily on understanding existing code, interpreting requirements through failing unit tests and implementing missing functionality correctly. The overall experience felt very close to real-world software development where engineers spend more time extending and maintaining existing systems than writing entirely new applications.

The problem statement revolved around completing an in-memory log query engine. A partially implemented codebase was provided along with a set of unit tests. Several methods had intentionally been left incomplete, causing the tests to fail. The objective was straightforward: understand the expected behavior, implement the missing functionality, handle edge cases correctly and ensure all tests passed successfully.

One interesting aspect of the exercise was that requirements were not entirely described in a traditional specification document. Instead, candidates were expected to derive part of the expected behavior by reading unit tests. This mirrors real engineering scenarios where understanding existing code and test suites becomes an important skill.

Problem Overview

The system consisted of three primary components:

\n
• \n

  LogEntry

  \n
\n
• \n

  Represents an individual log record.

  \n
\n
• \n

  Each log contains:

  \n
  \n
  • timestampMs : timestamp in milliseconds
  \n
  • level : log severity (DEBUG, INFO, WARN, ERROR)
  \n
  • message : log message
  \n
  \n
\n

Example:

\nnew LogEntry(\n    1710000000000L,\n    LogLevel.ERROR,\n    \"Database connection failed\"\n);\n

Query : Represents a search request with optional filtering conditions.

Supported filters:

\n
• level → exact log level match
\n
• contains → substring match on message
\n
• startTsInclusive → lower timestamp boundary
\n
• endTsInclusive → upper timestamp boundary
\n

All filters are optional and can be combined together.

Example:

\nQuery query = new Query();\n\nquery.setLevel(LogLevel.ERROR);\nquery.setContains(\"Database\");\nquery.setStartTsInclusive(1710000000000L);\nquery.setEndTsInclusive(1710001000000L);\n

LogStore

The primary component candidates were required to implement.

Responsibilities:

\n
• Store logs in memory
\n
• Execute filtered searches
\n
• Preserve insertion order
\n
• Return immutable query results
\n

Most of the machine coding effort was concentrated here.

Phase 1 : Implement append() and query()

The first phase required implementing two methods:

\nappend(...)\nquery(...)\nappend()\n

The append method was responsible for inserting new log entries into memory.

Example:

\nstore.append(\n    1710000000000L,\n    LogLevel.INFO,\n    \"Application Started\"\n);\n

The interviewer expected careful validation. The following inputs must be rejected:

\nlevel == null\nmessage == null\n

For example:

\nstore.append(\n    1710000000000L,\n    null,\n    \"hello\"\n);\n

should throw an exception. Similarly:

\nstore.append(\n    1710000000000L,\n    LogLevel.INFO,\n    null\n);\n

must also fail validation. Another important requirement was preserving insertion order. If logs are inserted as:

\nINFO  -> Started\nWARN  -> Cache Miss\nERROR -> DB Down\n

query results should appear in the exact same order regardless of filtering.

query()

The query implementation was where most of the logic existed. The method needed to apply all provided filters simultaneously. A log should only be returned if every active filter matches.

Filter 1: Level Match

Example:

Stored logs:

\n
• INFO Started
\n
• ERROR DB Failure
\n
• WARN Retry
\n

Query:

\n
• level = ERROR
\n

Result:

\n
• ERROR DB Failure
\n

This was a simple equality comparison.

Filter 2: Message Contains

Example:

Logs:

\n
• Database failure
\n
• Cache miss
\n
• Database timeout
\n

Query:

\n
• contains = \"Database\"
\n

Result:

\n
• Database failure
\n
• Database timeout
\n

An important detail was that matching must be case-sensitive.

Example:

\n
• contains = \"database\"
\n

should NOT match: Database failure because the casing differs. Empty String Edge Case, One tricky requirement was:

\n
• contains = \"\"
\n

must be treated as no filter.

Example:

\n
• query.setContains(\"\"); should behave identically to: query.setContains(null); and return all matching records without applying message filtering.
\n

This is a common interview edge case that many candidates overlook.

Filter 3: Time Range

Time filtering used inclusive boundaries.

Example:

Logs:

\n1000\n2000\n3000\n4000\n

Query:

\n
• startTsInclusive = 2000 and endTsInclusive = 3000
\n

Result:

\n2000\n3000\n

Both boundary values must be included.

Invalid Range

Special handling was required when: startTsInclusive > endTsInclusive

Example:

\nstart = 5000\nend   = 1000\n

In this scenario: [] must be returned immediately. No logs should match.

No Filters Provided

If every query field is empty: new Query() the result should contain every stored log.

Example:

\nINFO\nWARN\nERROR\n

Output:

\nINFO\nWARN\nERROR\n

while preserving insertion order.

Immutable Result Requirement

One requirement many candidates miss during interviews was: Returned list must be immutable.

For example:

List<LogEntry> result = store.query(q);\n

This should fail:

result.add(new LogEntry(...));\n

A common implementation:

\nCollections.unmodifiableList(...)\n\nor\n\nList.copyOf(...)\n

depending on Java version. The interviewer seemed particularly interested in whether candidates noticed this detail.

Phase 2 : Implement queryCount()

After Phase 1 tests passed, an additional requirement was introduced. A new method needed to be implemented:

int queryCount(Query q);\n

The goal was straightforward: Return the number of matching log entries instead of returning the entries themselves.

Example:

Logs:

\nERROR DB Failure\nERROR Timeout\nINFO Started\n

Query: level = ERROR

Output:

\n2\n

A simple implementation could internally reuse filtering logic already written for query().

However, an optimized implementation could avoid constructing intermediate collections and simply maintain a counter while scanning logs. This follow-up was less about coding and more about identifying opportunities for code reuse and performance optimization.

Phase 3 : Asynchronous Log Persistence

The final phase shifted away from filtering logic and into practical system design.

The requirement was: Write an asynchronous scheduler that periodically reads logs from local memory and writes them to a file every 10 seconds.

The interviewer explicitly mentioned that a commented-out example already existed in Main and candidates could uncomment it and execute the application to verify behavior. A typical solution involved:

\n
• Components
\n
• In-memory log storage
\n
• Background scheduler
\n
• File writer
\n
• Graceful shutdown handling
\n
• Possible Implementation
\n

Using Java's: ScheduledExecutorService

Example architecture:

\nLogStore\n    │\n    ▼\nScheduled Task\n    │\n    ▼\nSnapshot Logs\n    │\n    ▼\nWrite To File\n

The scheduler executes: every 10 seconds and persists current logs.

Topics that naturally emerged during discussion included:

\n
• Thread safety
\n
• Concurrent reads and writes
\n
• Snapshot consistency
\n
• File append versus overwrite strategy
\n
• Error handling during disk failures
\n
• Shutdown hooks
\n
• Memory consumption
\n

This phase felt much closer to a real backend engineering problem than a traditional coding challenge.

Overall Experience

The Flipkart machine coding round was less about solving a complex algorithmic puzzle and more about demonstrating software engineering fundamentals. Success depended on reading requirements carefully, understanding existing code, handling edge cases correctly, writing clean implementations and reasoning about production concerns.

\n
• Areas Being Evaluated
\n
• Requirement comprehension
\n
• Unit test interpretation
\n
• Clean code practices
\n
• Validation and edge-case handling
\n
• API design understanding
\n
• Thread safety awareness
\n
• Practical Java knowledge
\n
• Maintainable implementation
\n

Unlike many DSA-focused interviews, this exercise resembled actual day-to-day backend development. Candidates comfortable with Java collections, immutability, concurrency basics and writing testable code would likely find the challenge more approachable than traditional algorithm-heavy interview rounds.

Recommended Interview Experience

\n
• Disney+ Hotstar SDE-2 Interview Experience | Coding + System Design + Techno Managerial
\n
• Uber Senior Software Engineer Interview Experience | Real Interview Questions, System Design & Preparation Guide
\n
• Meta Business Engineer (L4 → L5 Consideration) Interview Experience
\n
• Rupeek Android Developer Interview Experience | Real Questions Asked, Preparation Tips & Complete Process
\n
• Rupeek SDE-3 Interview Experience (3 Rounds ~ Coding, LLD & HLD)
\n
• WheelsEye Backend Engineer Interview Experience | DSA Questions, System Design, Backend Deep Dive
\n
• Wise Software Engineer Interview Experience | DSA, System Design, Product Thinking
\n
• Yext SDE 1 Interview Experience – Complete DSA Questions, Debugging Round, API Challenge & HR Round
\n
• Uber SDE 2 Interview Experience (5 Rounds, Selected)
\n
• Adobe Software Engineer 2 Interview Experience
\n
• Volvo Cars Full Stack Developer Interview Experience (Selected)
\n
• Wayfair SDE Interview Experience
\n
• Wells Fargo SDE I Interview Experience
\n
• My Vegapay Backend Engineer (SDE 2) Interview Experience (Rejected)
\n