My ACI Worldwide Interview Experience

Role: Software Engineer Intern(PPO opportunity) | Batch: 2027 | Branch: Computer Engineering (PICT) | Mode: On-campus

TL;DR: Round 1 was ~55 MCQs + 1 DSA question. Round 2 was a 1.5-hour technical interview that went scratch-to-depth on OOP, DBMS, OS, DSA and projects. I cleared the OA, didn't clear the technical round. ACI cares about core subjects far more than LeetCode. If your OOP, DBMS and OS are genuinely strong from basics to advanced, your chances are high. Everything below is what I was asked, plus what I'd do differently.

Step 0: Getting the Intel

Before anything, I messaged seniors who had sat for ACI. What they told me about Round 1:

• ~50 MCQs total

• 30–35 on Java core: OOP in Java, Collections, multithreading, plus a bit of C++ and Java fundamentals

• ~10 on core subjects: a little cloud, DBMS, SQL, OS

• ~5 comprehension and aptitude

Based on that split, I practiced roughly 600–800 MCQs. I generated question sets from the intel and drilled them. (I'm attaching 2–3 of my sample papers.)

Was it accurate? Partly. They changed the pattern this year. But the practice still carried me — the topics overlapped even though the specific questions didn't. Do the intel gathering anyway. A slightly wrong map beats no map.

Round 1: Online Assessment

This year's actual pattern: ~55 MCQs + 1 coding question.

The coding question

It was common across all slots: a queue-based simulation. A baggage-handling scenario — bags arrive and get dispatched, and you implement functions along those lines (

1arrive

1dispatch

The real difficulty wasn't the problem. It was the environment. The exam runs on Safe Exam Browser, and the editor/compiler UI is genuinely painful compared to HackerEarth or similar platforms. Budget mental energy for that.

A tip that applies to almost every OA, not just this one: it was print-based, not return-based. Input comes in as a string that you have to split and parse yourself. So be comfortable with string manipulation and splitting (by space or regex) before any OA. People lose time here on problems they could otherwise solve.

The MCQs

Roughly in this order:

• Start: 2–3 comprehension/paragraph questions, some English, then a few logical questions. Not much quantitative.

• Heavy AI section (~10–15 questions). This was the big change this year. Prompting techniques (zero-shot, one-shot, few-shot, rule-based), AI/ML algorithms, and scenario-based questions — "if X happens, what would you do?" Know some basic ML, and be ready to reason about scenarios rather than just recall definitions.

• OOP in Java and C++, plus core subjects.

• Long Java code snippets. These were big, and the exam UI made them harder to read than they needed to be.

They may change the pattern again next year, but prepare everything above, and add some software development / SDLC basics — those can come up in the interview too.

Shortlist timing: I got the shortlist at ~10:30 PM the same day, with interviews at 9 and 10 AM the next morning at the office. So don't relax after the OA. The gap can be a few hours. Keep your core-subject notes revision-ready from day one.

Around 50 students were shortlisted

Round 2: Technical Interview (~1.5 hours)

My panel had 3 interviewers, all 2023–24 passout seniors.

First, the most important thing: this round is extremely panel-dependent. Some panels stayed surface-level. Mine went scratch-to-depth on every subject. You can't control which you get, so prepare for the worst one.

ACI's focus is clear: OOP, DBMS, Operating Systems, then DSA and projects. If you're also good at Computer Networks, mention it — they're impressed by it.

They usually open with either DBMS or OOP and go from basics all the way down.

OOP

Started with the standard: what is OOP, the four pillars with examples. Then they went pillar by pillar — "how would you implement encapsulation?", "write a snippet for abstraction / polymorphism / inheritance."

You write code on pen and paper here. A clean skeleton is acceptable; you don't need a compiling program. But practice writing a small snippet for each pillar by hand.

Then:

• What changed in Java 8 and 9, before vs after

• General knowledge checks: who created Java, who created React, when were they created

• An overloading vs overriding snippet (below)

The overloading vs overriding question

They showed me something structurally like this and asked: is it overriding or overloading?

java
1class Parent {
2    int show(int a) {
3        return a;
4    }
5}
java
1class Child extends Parent {
2int show(int a, int b) {
3return a + b;
4}
5}

Answer: overloading.

DBMS and SQL

They covered this end to end:

• Types of joins, and writing actual join syntax

• Normalization

• ACID properties, isolation levels

• Triggers, views, stored procedures

• All command categories: DDL, DML, DQL, DCL, TCL — and the commands under each

• Transaction problems: dirty read, non-repeatable read, read uncommitted vs read committed

• Indexes: clustered vs non-clustered, B-tree and B+ tree

The question I couldn't answer: they gave me an unnormalized table and asked me to convert it to 2NF using SQL queries. The catch was that one column held multiple values, so it wasn't even in 1NF — I needed to reach 1NF first, and I'd never practiced doing that through SQL rather than on paper.

Practice this. Knowing normal-form theory is not the same as being able to write the queries that split a multi-valued column into a separate table and migrate the data.

Operating Systems

• Difference between a process and a thread

• Mutex and semaphore, including writing a code snippet for them

• The starvation problem and how to solve it

• Deadlock: prevention, avoidance, and the rest (below)

• Scheduling algorithms, and which algorithm causes which problem

• Memory management and page replacement: FIFO, LRU

• Virtual memory, paging, segmentation

Deadlock: the four strategies

Deadlock needs four conditions to hold simultaneously: mutual exclusion, hold and wait, no preemption, and circular wait.

1. Prevention — design the system so one of those four conditions can never hold. E.g. make a process request all resources at once (breaks hold and wait), allow preemption, or impose a global ordering on resource requests (breaks circular wait). Safe, but restrictive and wasteful.

2. Avoidance — allow the conditions, but check every request at runtime and only grant it if the system stays in a safe state. This is the Banker's algorithm, and it needs advance knowledge of each process's maximum resource needs.

3. Detection and recovery — let deadlocks happen, detect them with a wait-for / resource-allocation graph, then recover by killing processes or preempting resources.

4. Ignore it — the "ostrich algorithm." What most general-purpose OSes actually do, because deadlocks are rare and the overhead isn't worth it.

The one-line distinction they're listening for: prevention is structural and static, avoidance is dynamic and per-request.

For starvation, the answer is aging — gradually raise the priority of processes that have waited a long time.

Data Structures

• Linear vs non-linear data structures

• Write code to delete a node from a linked list

• "If it's not a doubly linked list, can you delete a node in O(1)?" I said that with only the head and no previous pointer, you can't — the worst case stays O(n) because you have to traverse to find the predecessor. (Worth knowing the standard trick too: if you're given a pointer to the node itself and it isn't the tail, you can copy the next node's data into it and delete the next node, which is O(1).)

• Binary tree: delete the second largest element. I gave the brute-force approach — traverse, collect, sort, remove the second max — and a second approach handling duplicates. Then he asked the time complexity and I fumbled on the traversal complexity. Know your complexities cold; fumbling there undoes a correct approach.

Projects

I gave them few threads to pull, as ACI is involved in payment orchestration and i have worked on a project of workflow orchestration which included FSM i thought they would love it, also worked on a RAG project which involved Role based Prompting and LLM as a judge but the interviewers did not catch on that even though they were hot topics for ACI.Other Panels for few of my friends did catch on those hot topics (like web sockets,CNS/AI based projects) and were impressed, so you can say it depends partly on luck.

• Architecture diagram and ER diagram

• Basic RAG based questions, algorithms used(BM-25), Vector dimensions for BGE-M3 model,Sparse vs Dense retrieval.

• Which part did you work on most? (I said backend, so all follow-ups went there.)

• Authentication: JWT tokens, how they're verified

• Authorization

• Insecure Direct Object Reference (IDOR) ,ChromaDB (Vector database)— I'd put it on my resume and the panel wasn't familiar with it and had given me the feedback of not putting complex terminologies on resume which seemed little weird.

• bcrypt, hashing vs encryption, cryptographic algorithms.

Lesson: every line on your resume is a question. Be ready to teach anything you've listed, not just name it.

Light HR at the end

Family background, last movie I watched. Casual, just a wrap-up.

Result: Not shortlisted. The interview ran ~1.5 hours and covered all five areas. I'd rate it mediocre-to-hard in difficulty, and I'd call my panel one of the tougher ones — other panels didn't go nearly as deep. I realised I needed much more depth in core subjects; I couldn't answer some questions and fumbled others.

Round 3: Technical + Managerial (what I heard)

I didn't reach this round, so this is secondhand from friends.

It's mostly HR-flavoured with a light technical layer — more about discussing project ideas and approaches than grilling you on internals. Most people who clear the technical round clear this one.

Expect questions on geopolitics, your life, your parents, your career plan, and strengths/weaknesses, depending on who's interviewing you.

The important warning: some panels deliberately apply pressure. They'll say things designed to dent your ego or put you on the back foot, and they're watching how you react. Friends of mine were rejected here despite having everything else, purely on this.

How to handle it: recognise that it's a test, not a verdict. Stay calm, accept criticism openly, don't get defensive, and don't let it rattle your answers. Go in expecting a tough panel and be pleasantly surprised if you get an easy one.

After the interview: I messaged the panel members on LinkedIn asking for feedback. They responded: "You were good and had decent knowledge on core subjects. Communication was solid, and you were nearly there to pass." That reality check gave me confidence despite not being shortlisted. It also told me exactly what to fix — depth in core, not breadth in DSA. The next day was FlexTrade's interview, and those insights carried me through and i was able to crack flextrade interviews.

What to Prepare

Priority order for ACI: core subjects > DSA > projects. (My personal take, it can vary).

One of my friends was told directly in the HR round that if your core is strong, you're in. They don't weight LeetCode heavily.

• OOP: pillars with examples and handwritten code snippets for each; overloading vs overriding; Java 8/9 changes; basic GK about Java,React

• DBMS: joins with syntax, normalization (including doing it via SQL queries), ACID,BASE,CAP theorem,SOLID principles,REST(NOT DBMS but asked), isolation levels, all transaction anomalies, triggers/views/procedures, DDL/DML/DQL/DCL/TCL, indexes, B-tree and B+ tree

• OS: process vs thread, mutex/semaphore with code, starvation and aging, all four deadlock strategies, scheduling algorithms and their drawbacks, page replacement (FIFO, LRU), virtual memory, paging, segmentation

• CN: not always asked, but strong CN is a differentiator here. Mention it if it's real.

• DSA: linked lists (write them by hand), queues, trees and traversals, and know every complexity precisely

• Projects: architecture, ER diagram, auth/authorization, and the ability to explain any security or crypto term on your resume

• For the OA: string parsing and splitting, queue simulations, Java snippet reading,OOP,Java core,MultiThreading,Collections Framework,C++ snippets

  and a working knowledge of prompting techniques and basic ML

Tips

1. Attend the pre-placement talk. They ask whether you attended, and why not if you didn't. Easy marks, easy to lose.

2. Don't rest after the OA. The shortlist came at 10:30 PM for a 9 AM interview. Keep core notes revision-ready the whole time, not saved for the end.

3. Practice writing code on pen and paper. The interview isn't on a laptop.

4. Gather intel from seniors, but assume the pattern will shift. Prepare the topics, not the exact paper.

5. ACI values extracurriculars, especially leadership and managing or collaborating with people. Put it on your resume and bring it into your introduction.

6. It's panel-dependent, and that's partly luck. Your job is to be prepared for the worst panel, not to hope for an easy one.

Verdict: Not selected (cleared OA, didn't clear the technical round)

Overall: positive experience. Friendly panel, fair questions, and a process that genuinely tests whether you understand your fundamentals rather than whether you've memorised problems.

Getting rejected isn't the end of anything. I went deep on core after this, and it paid off elsewhere. Prepare properly, go in with a clear head, and don't tie your self-worth to one company's decision.

Good luck — I hope you crack it.

(Attaching my resume as well.)