LogIn
I don't have account.

Flipkart Machine Coding Round Experience ~ Log Engine Implementation

Arun Sharma
10 Views

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

Responses (0)

Write a response

CommentHide Comments

No Comments yet.