6 Onehouse / Infinilake interview experiences are collected in this two-part series, from 2021 to August 2026.

Part 1 focuses on the technical questions: LRU and LFU caches, two Kafka-like queue designs, an Uber-like system, a Kafka-to-S3 connector, and a thread-safe workflow orchestrator.

Part 2 covers the other candidate stories, behavioral questions, and the parts of the process that mattered beyond coding, including on-call, time-zone expectations, take-homes, hiring-manager decisions, and recruiter communication.

Matching questions link directly to Onehouse practice on FastPrep.

The short version

The clearest complete Software Engineer loop was:

1. Introductory conversation about Onehouse and the candidate's product interest
2. Data structures and algorithms
3. Low-level design
4. High-level/system design
5. Behavioral and cultural fit

Across the public engineering material, candidates reported:

• LRU and LFU caches
• A distributed queue like Kafka
• An in-memory Kafka-like message queue where every consumer reads the same messages
• An Uber-like cab-aggregation system
• A Kafka sink connector that writes to S3 in Java without existing connector packages
• A thread-safe in-memory workflow orchestrator with dependencies, parallel workers, retries, random failure, and graceful shutdown
• One undisclosed hard DSA problem in a separate 2026 Backend Engineer loop

The pattern is broader than algorithm questions alone:

DSA + LLD/OOD + Concurrency + Kafka/S3 + Distributed Systems + Resume Depth + Product Interest

One very trivial naming note: Onehouse is the public brand, while Infinilake Inc. is the corporate/legal identity behind it. Early company material used Infinilake before the Onehouse brand was established. They are one employer throughout this post.

Behavioral and motivation questions from reported interviews

Product interest

1. Why Onehouse?
2. What interests you about the product?
3. Why does this problem space genuinely matter to you?

Ownership and production judgment

1. Describe a challenging project you completed.
2. Describe a production outage you handled.
3. What did you do after the outage?

Feedback and conflict

1. Describe a disagreement with your manager and how you handled it.
2. What was the most recent constructive feedback you received?
3. What changed because of that feedback?

Common follow-ups: What did you personally own? Why that approach? What alternatives and trade-offs did you consider? What was the measurable result? What did you learn? What would you do differently now?

Onehouse engineering interview experiences and OA info

01. Backend Engineer: Two DSA Rounds, HLD, LLD, and HM

Post date: August 26, 2026
Candidate: 5.2 years of experience
Outcome: Rejected

The candidate completed five interviews:

1. DSA Round 1
2. DSA Round 2
3. HLD
4. LLD
5. Hiring Manager

The feedback/results they reported were:

• DSA Round 1: One hard problem, solved with an optimal approach -- Lean Hire
• HLD: Hire
• LLD: Hire
• Hiring Manager: Rejected

02. Remote India Software Engineer: Caches, Kafka, and Ride Hailing

Interview report: November 2023
Offer date reported separately: Early 2023
Candidate: 3.5 YOE; Tier-1 Indian college, Engineering/CS
Location: Remote, India
Outcome: Offer

This is the most complete successful Onehouse engineering experience I found.

Round 1: Introductory conversation

The company gauged the candidate's interest in the Onehouse product and whether that enthusiasm felt genuine. No technical task was reported in this round.

Round 2: Data structures and algorithms

The candidate was asked to design a Least Recently Used Cache and a Least Frequently Used Cache.

Round 3: Low-level design

The LLD round was to Design a Kafka-Like Distributed Queue.

Round 4: High-level design

The HLD prompt was to Design Ride-Hailing Dispatch and Trip Lifecycle for an Uber-like cab-aggregator business.

Round 5: Behavioral and cultural fit

The candidate remembered four areas:

• A challenging project they had completed
• A production outage, how they handled it, and what they did afterward
• A disagreement with a manager and how they handled it
• Their latest constructive feedback and an explanation of it

Result and historical compensation

The candidate received an offer. A companion post reported:

• Base salary: INR 42,00,000
• Cash bonus: none reported
• Signing or relocation bonus: none reported
• Equity: 8,000 ESOP units
• One-time US$500 work-from-home setup allowance
• Meal allowance

03. Two Technical Sessions: Kafka to S3 and an In-Memory Message Queue

Post date: October 30, 2023
Candidate context: General software-engineering category; master's degree; already employed and interviewing to change jobs
Route: Headhunter
Role: Full-time
Candidate rating: Neutral experience; average difficulty
Outcome: No further rounds after the second session

The interview mechanics were unusually specific:

• The candidate shared their screen.
• They wrote code in their own IDE.
• The interviewer placed the prompt in a Google document.
• At the end, the candidate pasted their Java classes back into that document for later evaluation.

First session: Kafka to S3

The first prompt was:

Design a Kafka sink connector to S3 in Java without using the existing packages.

The candidate said they had little experience in this area and did not know how to solve it. They tried to reason through the problem aloud with two interviewers and understand what the interviewers wanted, but still could not complete it.

Why there was a second session?

The candidate thought the process was over. Later, the recruiter said something had gone wrong during the first session and offered another interview. The candidate decided to take it for more interview practice.

Second session - In-memory Kafka-like message queue

The second question was to design an in-memory Kafka-like message queue with producers and consumers. Every consumer had to receive the same messages:

producer  -> [1, 2, 3]
consumer1 -> [1, 2, 3]
consumer2 -> [1, 2, 3]

The candidate described it as an OOD problem and wrote classes such as Message, MessageQueue, Consumer, and Producer. The queue was created with a given size.

They first tried using a Queue, but poll removed messages before the other consumers could read them, so they switched to an ArrayList.

The interviewers tested cases such as:

• A consumer trying to consume more messages than the producer had produced
• A producer adding new messages after a consumer had consumed all previous messages

More than a week later, the candidate was told that the Hiring Manager had not selected their profile. There were no further rounds.

04. A Detailed Online Assessment Question: Thread-Safe Workflow Orchestration

One detailed assessment asked the candidate to Design a Thread-Safe In-Memory Workflow Orchestrator.

The task was to build a workflow system where tasks could depend on one another. It needed to support adding tasks, adding dependencies, executing the workflow asynchronously, and shutting down gracefully after everything finished. A task could only run after all of its prerequisites had completed.

For example, tasks 1 and 2 were both prerequisites of task 3. Tasks 1 and 2 could finish in either order, but task 3 always had to run afterward.

The assignment was divided into three milestones:

1. Run the tasks sequentially.
2. Run independent tasks in parallel in a multithreaded environment.
3. Add retries for individual tasks and make each attempt fail randomly about 20% of the time, while still allowing the workflow to complete through retries.

What the engineering evidence suggests

• DSA matters: LRU and LFU were explicitly reported, and the 2026 loop had two DSA rounds.
• Domain knowledge can appear immediately: Kafka-to-S3 was a first technical screen.
• Queue semantics matter: another session required every consumer to see every produced message, so destructive queue reads were the wrong model.
• LLD and HLD may be separate interviews: the successful SWE loop had both.
• Concurrency is practical: the workflow task combines dependencies, workers, retries, failure, and shutdown.
• Product motivation is evaluated: the offer loop began with interest in Onehouse's product.
• Behavioral judgment can decide the outcome: the 2026 candidate reported positive design feedback but rejection at Hiring Manager.

Preparation checklist

Kafka, queues, and S3 ᕙ( •̀ ᗜ •́ )ᕗ

• Review partitions, consumer groups, offsets, ordering, backpressure, and rebalancing.
• Compare at-most-once, at-least-once, and exactly-once claims precisely.
• Explain batching, idempotent object identity, replay, retry, partial failure, and graceful drain.
• Be able to model broadcast delivery with an append-only message list and a separate cursor for each consumer.
• Test a consumer reading past currently available data and a producer appending after a consumer reaches the end.

ᕙ( •̀ ᗜ •́ )ᕗ Concurrency and design

• Model a dependency DAG and reject cycles.
• Schedule ready tasks without running one attempt twice.
• Reason about worker pools, locks, condition variables, retry exhaustion, and shutdown races.
• Practice the Kafka-like queue LLD and ride-hailing HLD aloud from requirements through failure modes.

Behavioral ᕙ( •̀ ᗜ •́ )ᕗ

• Prepare one real story each for a difficult project, production outage, manager disagreement, and constructive feedback.
• Explain your own contribution without making yourself the flawless hero.
• Know why Onehouse and its data-infrastructure problem genuinely interest you.

The public Onehouse question bank is small, but it is unusually coherent. It points toward engineers who can move between code, objects, threads, queues, distributed guarantees, and real production judgment.

Due to the 2,000-word limit, the remaining Onehouse / Infinilake interview experiences continue in Part 2.

Come hang out on FastPrep Experience and share whatever’s on your mind！

These experiences were gathered from LeetCode Discuss, Reddit, Glassdoor, and just about anywhere else useful interview information could be found. 🧡