Oracle Software Engineer Interview Experience (2024) - Rejected After Onsite

The first was a bank loan comparison problem. Given two banks with tiered interest rate segments (each segment covers a number of years at a specific annual rate), compute the total amount paid on each loan using the standard EMI formula, and output which bank is cheaper. The math was the hardest part because the EMI formula is specific and you have to be careful about re-amortizing the remaining principal at each segment boundary. I wrote a function that took the principal and walked segment by segment, paying down by month, which took me about 45 minutes of the 90-minute slot.

The second was a packet-repackaging problem. Given a stream of packet sizes, you can only emit packets of size exactly a power of two. Each arrival gets packaged into the largest power of two that fits, and the remainder carries forward to the next packet. Return the largest repackaged size across the stream. The trick was realizing you just need to walk the stream once, maintain a running carry, and use bit tricks to find the largest power of two less than or equal to the current total. I got this one out in about 25 minutes with time to spare.

HackerRank is fine as a platform but Oracle's test harness is strict about exact output format, which burned me for two submissions on the first problem before I noticed I was printing an extra newline.

[[problem/582?company=20|Array Sum After K Halving Operations]] is the same kind of "apply an operation repeatedly and track state" problem Oracle seems to like for their OAs.

Virtual Onsite (3 rounds)

Round 1: Coding - Network Packet Ordering

Problem: A stream of packets arrives at a server out of order, each tagged with a sequence number and a timestamp. You must emit packets in sequence-number order as soon as contiguous prefixes become available. Design a data structure that supports insert-packet and emit-available-packets operations efficiently.

I went with a hash map keyed by sequence number plus a pointer to the next expected sequence. On each insert, I stored the packet in the map, and if the inserted sequence number equaled the next expected, I walked forward from there, emitting packets and advancing the pointer until I hit a gap. Amortized O(1) per packet over the lifetime of the stream.

The interviewer asked me to think about what happens if a packet never arrives, and I talked through a timeout mechanism where I would keep a min-heap of arrival timestamps and evict stale entries. We also discussed the thread-safety of concurrent inserts, and I sketched a version using a concurrent hash map plus a single-writer thread doing the emission, which is the standard lock-free-ish approach. This round went well. I finished with about eight minutes to spare.

has the same sliding-data shape.

Round 2: Coding - LRU-Style Cache with Expiry

Problem: Implement a cache with three operations: put(key, value, ttl), get(key), and delete(key). The cache must evict least-recently-used entries when full and also evict any entry past its TTL on access.

I implemented it with a doubly-linked list plus a hash map keyed by key, which is the standard LRU pattern. For TTL, I stored an expiration timestamp on each node and checked it lazily on get. The interviewer pushed on how I would handle TTL eviction for keys that are never read again, and I talked through two options: a background sweeper thread that periodically scans the tail of the LRU list, or a secondary expiry-ordered min-heap that the cache pops from on each access. I went with the min-heap variant and wrote out the push/peek logic.

This round also went fine. The interviewer seemed engaged, asked one curveball about what would happen if two concurrent gets raced on the same expired key, and I answered that with a per-key lock or a compare-and-swap on the expiration field. Passing signal, I thought.

is unrelated but a good reminder that Oracle interviewers love the classic "tweak a standard data structure" pattern.

Round 3: System Design - Design a Database Replication Layer

Problem: Design a replication layer for a relational database. Primary writes, multiple read replicas, cross-region. Focus on consistency, failover, and how you would handle a primary going down.

This is where the interview went sideways. I had prepped system design from the usual sources: Grokking, Alex Xu, a couple of YouTube walkthroughs. None of them had prepared me for a deep database-internals conversation. The interviewer wanted to talk about write-ahead log shipping, synchronous versus asynchronous replication, quorum reads, and how Paxos or Raft would fit into the failover flow. I knew the high-level concepts but could not answer the concrete questions he kept drilling into.

Specifically, he asked what happens to in-flight transactions when the primary crashes mid-commit. I said "they get rolled back," but he pushed: rolled back where, on the replicas that had already received some of the log records, or on the client that had already gotten an ack. I fumbled through an answer about two-phase commit, which was the wrong answer because 2PC is for distributed transactions across shards, not for primary-replica replication. He also asked how I would handle a network partition where a minority of replicas got cut off, and I talked about it in terms of CAP, but he wanted me to be concrete about what a quorum-write-plus-quorum-read setup actually looks like in practice. I gave a mushy answer.

The interview did not crash and burn, but it was clearly a lower-quality conversation than either of my coding rounds. I left the round knowing I had underperformed and hoping the coding rounds would carry me.

Result

Rejection call came about a week later. The recruiter said the coding feedback was strong but the system design round flagged "gaps in distributed systems depth that are critical for the networking team." That was fair. I had leaned on general system design prep for a team that wanted actual database-internals knowledge.

Tips

1. Research the team before the loop, not the company. Oracle is a federation of very different orgs. The OCI networking team wants distributed systems depth. The applications team does not. The database team wants transaction-processing internals. Your prep should match the team, and the recruiter will usually tell you what the team works on if you ask.
2. Oracle system design is not the same as FAANG system design. Nobody is going to ask you to design Twitter. They are going to ask you about replication, consistency, transaction isolation, and log-shipping. Read the Raft paper, read a chapter of Designing Data-Intensive Applications, and be able to talk about write-ahead logs concretely.
3. The OA problems are math-heavy. The EMI formula problem is representative: Oracle likes problems that have a specific arithmetic formula you have to translate correctly. Practice doing careful simulation problems, not just pattern-matching algorithm problems.
4. HackerRank output format is unforgiving. I lost two submission attempts to a trailing newline. Always run your code against the sample input locally and compare byte-for-byte before submitting.
5. Do not pretend to know a distributed systems concept you do not. My biggest tactical mistake in the system design round was hand-waving through 2PC instead of saying "I know the high-level shape of 2PC but I have not implemented it, let me reason from first principles." Interviewers can tell when you are bluffing, and honest reasoning lands better than confident incorrect answers.
6. Ask the recruiter what the onsite rounds will cover. Oracle recruiters will often tell you "one coding, one coding, one system design" if you ask, and sometimes they will tell you the focus area of the design round. I did not ask. I should have.

If you are going into an Oracle loop, prep the team-specific systems knowledge hard and the coding will mostly take care of itself. Best of luck.