Real, anonymized candidate journeys from recent (2025) Oracle interview loops — round by round, including what was asked, how the candidate approached it, and the outcome.
One complete journey, start to finish
Round 1 — Pre-screening
A recruiter from Oracle Health messaged me on LinkedIn in July and set up a pre-screening call for the following week. It was a one-hour video call, all Java. The interviewer started with exceptions — checked versus unchecked, and what happens if an exception is thrown inside a finally block. Then he asked me to design an immutable class, so I wrote one out loud: final class, final fields, no setters, and a defensive copy for the list field. Next was deadlocks — I described two threads taking two locks in opposite order and how a fixed lock ordering avoids it. After that he went through SOLID one principle at a time and asked for a real example of each from my work. Then he asked the difference between factory and abstract factory, and I drew a small example with a notification factory. The last ten minutes were Spring Boot basics — how dependency injection works and what a starter is. He said the recruiter would get back to me, and two days later I was moved to the loop.
Round 2 — Hiring Manager Loop
The first loop round was with the hiring manager, about an hour. He said the problem was a ticket booking service and then stopped talking — he wanted me to gather the requirements myself. So I started asking: what can be booked, whether seats are numbered, roughly how many users, and whether a seat can ever be sold twice. He answered briefly each time and let me write the list. Then I moved to APIs before drawing anything: a browse endpoint for shows, a seat-map endpoint, and a reserve-then-confirm flow for booking. He pushed on why I had split reserve and confirm, and I explained the short hold while the user pays. Only after that did he let me draw the diagram — an API layer, a catalog service, a booking service on a relational database, a cache for the seat map, and payments to the side. Near the end he asked how two users booking the same seat at the same time would be handled, and I described a conditional update on the seat row. The round ended right on time.
Round 3 — DSA Loop
The DSA loop round was the next day, one hour, on a shared code editor. The problem was integer to Roman numeral. I first said the greedy idea: keep values from largest to smallest, including the subtractive ones like 900 and 400, and keep subtracting. Then I wrote it in Java with two parallel arrays, and walked through 1994 to show MCMXCIV. That took maybe twenty minutes. After it worked, she asked the real question: if the numeral system changed tomorrow, or a new symbol was added, what would I have to change. I said the arrays were the problem — the mapping should be a separate ordered table passed into the converter rather than hardcoded in the method. She asked me to refactor it that way, so I made the converter take a list of value-symbol pairs and showed that the loop itself did not change. Then she asked what would break if the table was not sorted, and I added a check for that. We spent the last few minutes on time complexity and edge cases like zero.
Round 4 — Behavioral Loop
The behavioral round was a few days later, about 45 minutes, with a senior person from the team. He started with my current role: what I owned, how big the team was, and what a normal week looked like. Then he asked me to pick two features I had built and explain them end to end, so I went through one API migration and one reporting feature, including what went wrong and how I fixed it. The main part was about disagreements. He asked for a time I disagreed with a senior colleague, so I described a design decision where I wanted to split a service and my lead did not. I explained how I put together a small comparison, presented it, and then went with the lead's decision when the team chose that way. He asked how I felt about that afterwards and whether I would do anything differently. He was very friendly the whole time and it felt like a relaxed chat, which honestly made me think it had gone better than it probably had.
Round 5 — DSA Loop
The last round was another technical one, about an hour, and it was a mix. First she asked me to explain producer-consumer with wait and notify, so I wrote a small bounded buffer class in Java with a synchronized put and take, and she asked why the wait had to be inside a while loop rather than an if. Then a quick pass on immutability again and how to write a thread-safe singleton — I gave the enum version and the double-checked locking version. After the theory came two coding problems. The first was detecting a cycle in a linked list; I explained the slow and fast pointer idea and coded it in a few minutes. The second was summing the values of the deepest level of a binary tree. I used a level-order traversal with a queue and kept the sum of the last level processed. She asked for the space complexity and one edge case with a single node. It ended on time. About a week later the recruiter told me I was not selected, with no detailed feedback.
Key takeaway: Watch out for interviewers who seem unusually friendly — it may not correlate with how consistently they evaluate the answers; this candidate covered Java fundamentals, system design, DSA, and behavioral across five full rounds but was ultimately not selected.
More real interview journeys
The first round of each journey below is shown in full; the rest of each candidate's journey — every remaining round, verbatim — is part of the Placement-Ready PYQ Kit.
Round 1 — Resume & Project Discussion
Oracle came to campus in September for the intern plus full-time role. After the online test, the shortlist went up on a Tuesday evening and my first interview was the next morning in a classroom on campus. The interviewer started with my resume and picked my backend project. First he asked how the REST APIs were structured and how I handled auth, so I explained the JWT flow — where the token is issued, where it is checked, and what happens when it expires. Then he moved to networking: the difference between TCP and HTTP, and why I had used WebSockets for one feature instead of plain polling. After that it was fundamentals one after another — the four OOP pillars with examples from my code, ACID properties, and a short discussion on what changes when a service is split across machines. At the end he asked how I had used Docker and Redis in the project and what Redis was actually storing. The round took about 45 minutes and I was called for the next round the same afternoon.
🔒 3 more rounds — continue this journey in the full kit
Round 1 — Online Technical Screening
I applied through a referral in January and the recruiter set up an online technical screening for the next week, about an hour on a video call. The interviewer began with Java basics — how I would write an immutable class, and the difference between checked and unchecked exceptions with a case from my own code. Then came the two coding problems. The first was checking whether two strings are anagrams, and he added that I could not sort either string. I used a character count map, incrementing for the first string and decrementing for the second, and explained why checking the lengths first matters. The second was sorting an array of 0s and 1s in one pass, which I did with two pointers. After coding he switched to design: how I would design a REST API for a small resource, including status codes and versioning. Finally he gave me a slow SQL query and asked how I would speed it up — I talked about indexes and rewriting a subquery as a join. The recruiter called two days later to set up the next round.
🔒 2 more rounds — continue this journey in the full kit
Round 1 — Screening (~1.5 hrs)
A recruiter reached out for an OCI backend role in March and the screening was scheduled about a week later. It ran close to an hour and a half. The interviewer started by asking me to implement the factory design pattern in Java, not just describe it — so I wrote a small shape factory with an interface, two implementations, and the factory method, and then she asked how I would add a new type without touching the existing code. Next was the DSA problem: given a string and a list of words, count how many of the words are subsequences of the string. I first gave the straightforward two-pointer check per word, then she asked me to make it faster for many words, and I described grouping words by their next needed character and walking the string once. I coded the faster version and tested it on her example. The rest of the time was general Java — collections, equals and hashCode, and a bit on garbage collection. She said the feedback would come through the recruiter, and I was moved to the loop a few days later.
🔒 4 more rounds — continue this journey in the full kit