Onix Interview Experience 2026 — Software Engineer

I recently appeared for the Onix Networks campus recruitment process for the Software Engineer (SDE) role.

I’m sharing my detailed interview experience, especially the technical questions and discussions, for juniors and anyone preparing for Onix or similar software engineering roles.

1. Company and Role

• Company: Onix

• Role: Software Engineer (SDE)

• Batch: 2027

• Branch: Computer Engineering

• Mode: Campus Placement

2. Recruitment Process

The application process was conducted through our college placement process in August 2026.

The recruitment process consisted of:

1. Online Assessment — 1st September 2026

2. Technical Interview Round 1 — 7th September 2026

3. Technical Interview Round 2 — 7th September 2026

4. HR Round — 7th September 2026

Both technical interviews were conducted in person.

The Online Assessment was divided into multiple sections covering:

• Aptitude

• CS Fundamentals

• DBMS

• Networking

• DSA

There was also a medium-level DSA problem as part of the assessment.

3. Interview Rounds

Round 1 — Online Assessment

Type

Online Assessment

The assessment covered multiple areas:

• Aptitude

• CS Fundamentals

• DBMS

• Computer Networking

• DSA

• Medium-level DSA

Difficulty Level

Easy to Medium

The OA tested both conceptual knowledge and problem-solving ability.

For this round, I would recommend being comfortable with:

• OOP fundamentals

• DBMS basics

• SQL

• Networking fundamentals

• Aptitude and logical reasoning

• Basic DSA patterns

• Time and space complexity

Round 2 — Technical Interview 1

Type

Technical + DSA + DBMS + System Design + Java/Spring Boot

The first technical interview started with:

“Tell me about yourself.”

After my introduction, the interviewer asked about my projects and then moved into technical questions.

The round covered:

Projects → OOP → System Design → DBMS → SQL → HTTP → Caching → DSA → Java → Spring Boot → Microservices

Library Management System — System Design

One of the major questions was:

“Design a Library Management System.”

I was asked to design the system starting from the database level.

The discussion included:

• Identifying entities

• Database design

• ER diagram

• Primary keys

• Foreign keys

• Relationships

• Database normalization

• OOP design

• Practical implementation

The interviewer wanted me to think about the system from both the database and application perspective.

OOP — Practical Implementation

The interviewer asked about OOP concepts and also wanted practical implementations.

The concepts discussed included:

• Encapsulation

• Abstraction

• Inheritance

• Polymorphism

Rather than only giving definitions, I had to explain how these concepts could actually be used while designing the Library Management System.

This was a good reminder that for interviews, knowing the definition of OOP is not enough — you should know how to apply it.

Transaction Logging

The interviewer added another requirement:

“Every transaction performed in the system should be recorded in the database.”

For example, the system could record operations such as:

text
1Book Issued
2Book Returned
3Book Reserved
4Book Added
5Book Removed

I discussed maintaining a separate transaction/logging table containing information such as:

text
1TransactionLog
2-------------------------
3log_id
4user_id
5book_id
6action
7timestamp

The purpose would be to maintain an audit/history of operations performed in the system.

SQL — Find Top 5 Most-Used Books

I was then asked:

“Write an SQL query to find the top 5 books which are used the most.”

The basic approach was to count how many times each book had been used/issued, group the records by book, sort them in descending order, and return the top 5.

I initially solved the problem using a subquery.

The interviewer then asked:

“Can you implement the same using JOIN?”

This tested my understanding of:

• JOIN

• GROUP BY

• COUNT

• ORDER BY

• LIMIT/TOP

• Subqueries

• Aggregate functions

The important part was understanding what exactly should be counted and grouped.

Database Normalization

I was initially given a denormalized Book table containing information such as:

text
1Book
2------------------------------------------------
3book_id
4book_name
5author_id
6author_name
7book_details

I was asked to normalize it.

I separated it into three tables.

Book Table

text
1Book
2-------------------------
3book_id
4book_name
5book_details

Author Table

text
1Author
2-------------------------
3author_id
4author_name

Book_Author Table

text
1Book_Author
2-------------------------
3book_id
4author_id

The third table represents the relationship between books and authors.

The interviewer then asked:

“Currently the Book_Author table is not having any key and it can contain duplicate entry. So how will you solve this problem?”

I discussed using:

text
1(book_id, author_id)

as a composite key.

This ensures that the same book-author relationship cannot be unnecessarily duplicated.

It also represents a many-to-many relationship between books and authors.

HTTP Methods

I was then asked about HTTP methods such as:

• GET

• POST

• PUT

The interviewer then moved into a practical backend question:

“How would you implement caching for GET methods?”

Caching GET Requests

I discussed multiple approaches.

1. In-Memory Cache

Frequently accessed data can be stored in application memory.

For example:

text
1GET /books/101
2        ↓
3   Check Cache
4     /     \
5   HIT     MISS
6    ↓        ↓
7 Return   Database
8             ↓
9           Cache
10             ↓
11          Response

This is very fast, but the cache is local to that application instance.

2. Distributed / Third-Party Cache

For a distributed application, a shared cache can be used so that multiple application instances access the same cached data.

This avoids every server having a completely independent cache.

3. Client-Side Cache

Caching can also be performed on the client side depending on the application and consistency requirements.

Examples include browser caching and local storage.

The important thing was understanding that the caching strategy depends on the system architecture and consistency requirements.

DSA — Array Problem

I was also asked an array-based DSA problem.

The problem was relatively simple and focused on:

• Understanding the problem

• Finding an efficient approach

• Writing the solution

• Discussing time and space complexity

8-Ball Puzzle

I was also given a classic logical puzzle.

There are 8 balls, where one ball has a different weight.

The question was:

Identify the different ball using a weighing scale only twice.

The idea is to divide the possibilities into groups and use the outcome of each weighing to narrow down the possibilities.

This tested logical thinking rather than coding.

Java & Spring Boot

Since Java and Spring Boot were mentioned on my resume, the interviewer went deeper into these technologies.

Some of the topics discussed were:

Spring

• IoC — Inversion of Control

• Dependency Injection

• Annotations

Microservices

• Microservice architecture

• Circuit Breaker Pattern

• Resilience4j

Security

• Authentication

• Authorization

The interviewer focused more on practical understanding rather than simply asking definitions.

Round 1 — Result

The first technical round covered a wide range of topics:

Introduction → Projects → OOP → Library System → ER Diagram → DBMS → Normalization → SQL → HTTP → Caching → DSA → Java → Spring Boot → Microservices → Security

I was selected for Technical Round 2.

Round 3 — Technical Interview 2

Type

Technical + DSA + System Design + Distributed Systems + Concurrency

The second technical round was more focused on problem-solving and real-world backend/system design.

The major topics were:

Rate Limiting → Sliding Window Median → Trees → Parking Lot → APIs → Microservices → Concurrency

Rate Limiting

The interviewer started with:

“Do you know about Rate Limiters?”

I explained different approaches, including:

• Token Bucket

• Leaky Bucket

• Sliding Window

Token Bucket

Tokens are generated at a fixed rate and stored in a bucket.

Each request consumes one token.

If no token is available, the request can be rejected or delayed.

text
1       Token Generator
2              ↓
3       ┌──────────────┐
4       │ Token Bucket │
5       └──────────────┘
6              ↓
7           Request
8              ↓
9      Token Available?
10        /          \
11      YES           NO
12       ↓             ↓
13   Process         Reject

Leaky Bucket

Requests enter a queue/bucket and are processed at a controlled rate.

This helps smooth out traffic spikes.

Sliding Window

The system keeps track of requests within a moving time window.

For example, if the limit is:

text
13 requests / 10 seconds

the system checks how many requests occurred within the current 10-second window.

DSA — Sliding Window Median

This was one of the more challenging DSA problems in my interview.

The problem is based on LeetCode 480 — Sliding Window Median.

Problem

Given an integer array

1nums

1k

1k

Example

text
1nums = [1,3,-1,-3,5,3,6,7]
2k = 3

The windows are:

text
1[1, 3, -1]
2[3, -1, -3]
3[-1, -3, 5]
4[-3, 5, 3]
5[5, 3, 6]
6[3, 6, 7]

After sorting each window:

text
1[-1, 1, 3]  → 1
2[-3, -1, 3] → -1
3[-3, -1, 5] → -1
4[-3, 3, 5]  → 3
5[3, 5, 6]   → 5
6[3, 6, 7]   → 6

Therefore:

text
1Output = [1, -1, -1, 3, 5, 6]

The interviewer did not stop at the basic solution.

He specifically asked:

“How will you optimize maintaining the K elements in sorted order so that finding the median is efficient?”

A straightforward solution would sort every window again:

text
1For every window:
2    Sort K elements
3    Find median

This results in approximately:

text
1O(n × k log k)

The interviewer wanted to discuss how to maintain the sliding window efficiently while:

1. Adding the new element

2. Removing the outgoing element

3. Finding the median

This led to a deeper discussion around appropriate data structures for maintaining a dynamically changing ordered window.

Binary Tree — Mirror a Tree

I was then asked:

“Mirror a Binary Tree.”

For example:

text
1        1
2       / \
3      2   3
4     / \   \
5    4   5   6

After mirroring:

text
1        1
2       / \
3      3   2
4     /   / \
5    6   5   4

The recursive approach is:

text
1mirror(node):
2,[object Object],
text
1undefined

Then Discussed about Complexity

text
1Time:  O(n)
2Space: O(h)

where

1h

System Design — Parking Lot

The interviewer then asked:

“Design a Parking Lot System.”

I started with:

• Requirements

• Entities

• Database design

• ER diagram

• Relationships

The system included concepts such as:

text
1Parking Lot
2Parking Spot
3User
4Vehicle
5Reservation

The discussion then moved to API design.

Parking Lot API Design

I discussed APIs for operations such as:

1. Get Parking Availability

text
1GET /parking/{parkingId}/availability

The response would contain information about available parking spots.

For example:

json
1{
2"parkingId": 101,
3"availableSpots": [...]
4}

2. Allocate Parking Spot

text
1POST /parking/{parkingId}/allocate

A request could contain:

json
1{
2"userId": 123,
3"parkingId": 101
4}

The response would contain the allocated parking information.

I discussed the request body, response body and responsibilities of each API.

Nearest Parking Spot Allocation

The interviewer then changed the requirement.

The user has reserved a parking spot and reaches the gate.

Now the system needs to allocate the nearest available parking spot.

My initial approach was:

Use a Min Heap.

The available parking spots could be maintained based on their distance.

For example:

text
1Min Heap,[object Object],
2,[object Object],
text
1Spot B (5)  Spot C (8)

The nearest spot can then be retrieved efficiently.

Microservices — Multiple Min Heaps

The interviewer then introduced another constraint:

“What if this application is running as a microservice on multiple machines?”

For example:

text
1Machine A → Min Heap A
2Machine B → Min Heap B
3Machine C → Min Heap C

Each machine could have a different view of the available parking spots.

A spot allocated by Machine A might still appear available in Machine B's local heap.

This creates a consistency problem.

I then discussed using the database as the source of truth rather than relying only on local in-memory heaps.

The database could be queried to find the appropriate available parking spot.

Concurrency Control

The interviewer then asked:

“What if both machines try to book the same parking spot at the same time?”

For example:

text
1Machine A                 Machine B
2|                         |
3|---- Book Spot 10 ------>|
4|                         |
5|<---- Book Spot 10 ------|

Both machines might initially read:

text
1Spot 10 = AVAILABLE

This could create a race condition.

I discussed database concurrency control and row-level locking.

Conceptually:

text
1Transaction A
2↓
3Lock parking spot row
4↓
5Check availability
6↓
7Allocate spot
8↓
9COMMIT
10↓
11Release lock

While Transaction B trying to access the same row would have to wait for the lock.

After Transaction A completes, Transaction B would see the updated state and would not be able to allocate the same spot.

This prevents double booking.

The interviewer was satisfied with this approach.

Puzzle

At the end of the technical round, I was asked another simple logical puzzle, which I was able to solve.

Round 2 — Result

The second technical round was particularly interesting because the interviewer kept adding constraints to my initial solution.

The progression was:

Parking Lot

↓

Nearest Parking Spot

↓

Min Heap

↓

Multiple Machines

↓

Microservices

↓

Central Database

↓

Concurrent Requests

↓

Database Locking

This made the discussion much closer to a real-world backend/system-design problem.

I was selected for the HR round.

4. HR Round

The HR round was comparatively relaxed.

The focus was mainly on:

• Personal introduction

• Previous experience

• Projects

• Willingness to join Onix

• Willingness to accept the offer

• Other offers/interviews

• Relocation

• Family/background

• General fit

• Interest in the opportunity

There were no major technical questions.

The main focus was understanding whether I was genuinely interested in the opportunity and comfortable with the requirements of the role.

5. Overall Experience

Overall, my Onix interview experience was technically challenging and very valuable.

What stood out to me was that the interviewers didn't simply ask theoretical questions.

They frequently asked:

“Okay, but what if...?”

For example:

Min Heap

→ What if there are multiple machines?

→ What if each machine has its own heap?

→ What if two machines try to book the same spot?

→ How will you handle concurrency?

This tested whether I could adapt my solution when real-world constraints were introduced.

My biggest takeaway was:

Don't just learn the definition of a concept. Understand why it exists, how it works, and where it can fail.

6. What to Prepare for Onix

Based on my experience, I would recommend preparing:

DSA

• Arrays

• Strings

• Hashing

• Sliding Window

• Trees

• Heaps

• Two Pointers

• Binary Search

• Basic Dynamic Programming

• Time & Space Complexity

OOP

• Encapsulation

• Abstraction

• Inheritance

• Polymorphism

• SOLID principles

• Practical implementation

DBMS & SQL

• Normalization

• Primary Keys

• Foreign Keys

• Composite Keys

• ER Diagrams

• One-to-One

• One-to-Many

• Many-to-Many

• JOINs

• Subqueries

• GROUP BY

• HAVING

• Aggregate functions

• Transactions

• Concurrency

• Row-level locking

Backend

• REST APIs

• HTTP methods

• API design

• Caching

• Rate limiting

• Authentication

• Authorization

Java & Spring Boot

• OOP in Java

• IoC

• Dependency Injection

• Annotations

• REST APIs

• Spring Boot

• Microservices

• Circuit Breaker

• Resilience4j

System Design

Practice designing:

• Library Management System

• Parking Lot System

• Banking System

• Food Delivery System

And while designing, think about:

Database → APIs → Scalability → Caching → Concurrency → Failure Handling

7. Tips for Aspirants

1. Know your resume thoroughly

Anything mentioned on your resume can become a detailed discussion.

If you mention Java, Spring Boot or Microservices, be ready to explain how you have actually used them.

2. Start with a simple solution

Don't immediately try to give the most complicated solution.

Start with a working approach, identify its limitations, and then optimize it.

3. Expect follow-up questions

Be prepared for:

“What if there are multiple servers?”

“What if two requests come at the same time?”

“What if the cache is stale?”

The interviewer may keep changing the constraints.

4. Practice DBMS practically

Don't just memorize normalization definitions.

Practice going from:

Requirement → ER Diagram → Tables → Keys → Normalization → SQL → Transactions

5. Practice system design

Even as a fresher, knowing basic system design can give you an advantage.

Practice designing systems and, more importantly, be prepared to explain why you selected a particular design.

6. Explain your thought process

If you don't know the optimal solution immediately, don't panic.

Explain your approach, identify the limitation, and improve it.

The interviewer can learn a lot about your problem-solving ability from your thought process.

8. The Unexpected Ending — Two Offers

One interesting part of my journey happened after the interviews.

The Onix result took around 4 days, so during those four days I wasn't sure whether I would be selected.

Meanwhile, on 10th September 2026, I appeared for an interview with Principal Financial Group (PFG).

Fortunately, I cleared that interview as well.

Then came a very memorable day.

On 11th September 2026, the PFG result came around 12 PM, and I was selected.

At that point, I was already very happy.

Then, at around 1 PM, the Onix result arrived.

And I was selected for Onix as well! 🎉

So suddenly, I had two offers and had to choose only one.

After considering various factors such as:

• Job security

• Role

• Long-term growth

• Work environment

• Work-life balance

• Work location

• Overall opportunity

I decided to accept Principal Financial Group, even though the package was lower than the Onix offer.

For me, the decision wasn't based only on the highest package. I wanted to consider the overall opportunity and long-term fit.

Getting selected by both companies within the same day was definitely one of the most memorable moments of my placement journey. ❤️

9. Final Thoughts

Looking back, this entire placement journey taught me a lot.

The biggest lesson was:

Strong fundamentals matter more than memorizing interview answers.

DSA helped me solve problems.

DBMS helped me design the data layer.

OOP helped me structure the application.

System Design helped me think about scalability.

And concepts like caching, rate limiting and concurrency helped me think about what happens when the system is actually used by thousands or millions of users.

To all juniors preparing for placements:

Don't just prepare questions. Prepare concepts.

Understand them deeply enough that even when the interviewer changes the problem, you can adapt.

And most importantly, believe in your preparation. 🚀

All the best for your placements!

#Onix #OnixInterviewExperience #InterviewExperience #SoftwareEngineer #SDE #CampusPlacement #PlacementPreparation #DSA #SystemDesign #Java #SpringBoot #DBMS #SQL #Microservices #SoftwareEngineering #EngineeringStudents