My Oracle Interview Experience (July 2026) : Round 1 (Senior Platform Engineer)

Nishant Verma

Last Updated : 30 August 2026

715 Views

#interview

#oracle

#dsa

#interview-experience

#technical-interview

#coding-interview

#interview-questions

#backend-interview-experience

Adℹ

I'll be honest, I went into this round expecting mostly systems and infra questions, given the "Platform Engineer" title. Instead I got one array problem that looked deceptively simple and one SQL question that looked deceptively simple in a completely different way. Both of them had a trap sitting just under the surface and I walked into both traps before I found my way out.

This is the write-up of Round 1 exactly as it happened, mistakes included. I'll add the later rounds as separate posts once I've been through them.

Detail	Info
Company	Oracle
Role	Senior Platform Engineer
Round	Round 1 (Technical / Problem Solving)
Topics	Array + Sliding Window, SQL
Number of questions	2
Overall Difficulty	⭐⭐⭐☆☆ (3/5)

Question 1: Maximum of Minimums of Every Window

The problem: given an array A of size n and an integer x, look at every contiguous window of length x, find the minimum inside each window and return the largest of those minimums.

Example:


A = [1, 3, -1, 5, 3, 6]
x = 3

Windows:
[1, 3, -1]  -> min = -1
[3, -1, 5]  -> min = -1
[-1, 5, 3]  -> min = -1
[5, 3, 6]   -> min = 3

Answer = 3

My First Instinct (and Why It Was Slow)

The obvious first approach: for every window, just scan its x elements and find the minimum directly.

static int bruteForce(int[] a, int x) {
    int best = Integer.MIN_VALUE;
    for (int i = 0; i + x <= a.length; i++) {
        int windowMin = Integer.MAX_VALUE;
        for (int j = i; j < i + x; j++) {
            windowMin = Math.min(windowMin, a[j]);
        }
        best = Math.max(best, windowMin);
    }
    return best;
}

I said out loud that this is O(n · x), since there are roughly n windows and each one costs x work to scan. The interviewer just asked, "Can we avoid recomputing the minimum from scratch every time the window slides by one?" That was the nudge most of the work in the window barely changes between one window and the next, so redoing it all every time is wasteful.

My Actual Mistake: Trying to Track "the Minimum So Far"

My first attempt at speeding it up was to just keep a single running minimum as I scan left to right, updating it as I go.

// WRONG: a running minimum never "forgets" old values that have
// already slid out of the current window.
static int wrongGlobalMin(int[] a, int x) {
    int runningMin = Integer.MAX_VALUE;
    int best = Integer.MIN_VALUE;
    for (int i = 0; i + x <= a.length; i++) {
        for (int j = i; j < i + x; j++) {
            runningMin = Math.min(runningMin, a[j]);
        }
        best = Math.max(best, runningMin);
    }
    return best;
}

This felt right for about ten seconds, until I tested it on a small case in my head: A = [-100, 5, 6, 7, 8, 9], x = 2. The real answer is 8 (the window [8, 9] has the largest minimum). But my running minimum locks onto -100 in the very first window and never lets go, since I never remove old values once they slide out of the window. So it returns -100, which is completely wrong. I caught this by testing it, not because I spotted the flaw by staring at the code worth remembering that trick for yourself.

The hint that got me unstuck: the interviewer asked, "What if a value that used to be your minimum has already slid out of the window do you have any way to know that?" That's the entire problem in one sentence. A plain running minimum has no concept of "expiring."

The Fix: A Monotonic Deque

The right structure here is a deque (double-ended queue) that stores indices, kept in increasing order of their values, front to back. Two rules keep it correct:

Drop indices from the front once they've slid out of the current window (they're too old to matter anymore). Drop indices from the back whenever the new value is smaller than or equal to them (they can never be the minimum again while this new, smaller value is still inside the window, so there's no reason to keep them around).

Because of these two rules, the front of the deque is always the index of the current window's minimum no rescanning needed.

Here's how it plays out on the actual interview example, step by step:

i	A[i]	Expired from front	Popped from back (≥ A[i])	Deque after (indices)	Window min
0	1	none	none	[0]	–
1	3	none	none	[0, 1]	–
2	-1	none	1(3), 0(1)	[2]	-1
3	5	none	none	[2, 3]	-1
4	3	none	3(5)	[2, 4]	-1
5	6	2	none	[4, 5]	3

Max of window minimums = 3 matching the expected answer.

import java.util.*;

public class MaxOfMins {
    static int optimal(int[] a, int x) {
        Deque<Integer> deque = new ArrayDeque<>(); // indices, values increasing front-to-back
        int best = Integer.MIN_VALUE;

        for (int i = 0; i < a.length; i++) {
            // Drop indices that fell out of the window on the left.
            while (!deque.isEmpty() && deque.peekFirst() <= i - x) {
                deque.pollFirst();
            }
            // Maintain increasing order.
            while (!deque.isEmpty() && a[deque.peekLast()] >= a[i]) {
                deque.pollLast();
            }
            deque.offerLast(i);

            if (i >= x - 1) {
                best = Math.max(best, a[deque.peekFirst()]);
            }
        }
        return best;
    }
}

I cross-checked this against the brute force version on 2,000 randomly generated arrays before I trusted it fully every single one matched.

Follow-Up Questions I Got and What I Said

"What's the time and space complexity?"

O(n) time each index gets pushed and popped from the deque at most once across the whole run, so the total work is linear, not quadratic. O(x) space for the deque in the worst case, since it can never hold more than the current window size.

"Why does popping from the back never lose the true answer?"

Because if a later value is smaller than or equal to something already in the deque, that older value can never win it will expire from the window before or at the same time as the new value and the new value is smaller anyway. It's safe to throw away, not just convenient.

"What if x is larger than the array?"

I said there are zero valid windows in that case, so I'd return something like Integer.MIN_VALUE or throw an explicit exception, depending on what the caller expects and that I'd rather make that contract explicit than silently return a meaningless number.

"Could you solve this with a different data structure, like a max-heap or a TreeMap?"

Yes , a multiset-style structure (like a TreeMap<Integer, Integer> counting occurrences) also works, giving O(log x) per operation instead of O(1) amortized with the deque. I said I'd prefer the deque here since it hits true O(n) instead of O(n log x) and the code ends up simpler too.

Question 2: SQL Classify Every Node in a Tree

The table:


id   pid
1    NULL
2    1
3    1
4    2

The task: label every node as Root (no parent), Inner (has at least one child) or Leaf (no children).

Expected output: 1 → Root, 2 → Inner, 3 → Leaf, 4 → Leaf.

My Mistake: The Classic `NOT IN` + `NULL` Trap

My first pass at the query looked completely reasonable:


SELECT id,
    CASE
        WHEN pid IS NULL THEN 'Root'
        WHEN id NOT IN (SELECT pid FROM Tree) THEN 'Leaf'
        ELSE 'Inner'
    END AS label
FROM Tree;

I ran it against the sample data in my head and it looked fine at first glance. But the interviewer asked me to actually trace what SELECT pid FROM Tree returns on this exact table. That list is NULL, 1, 1, 2 and it includes a NULL, because the root's pid is NULL.

Here's the trap: in SQL, NOT IN against a list that contains even one NULL doesn't behave the way most people expect. For any value v, v NOT IN (list containing NULL) evaluates to UNKNOWN, not TRUE or FALSE because SQL can't prove v doesn't equal the unknown NULL. An UNKNOWN result is treated as false in a WHERE/CASE check, so my NOT IN branch silently never fires for anyone. When I actually ran it, every non-root node came back as Inner, including nodes 3 and 4, which are actually leaves.

The hint that helped me catch it: he simply asked, "What does the subquery actually return here walk me through the values." That single question is what exposed the NULL sitting in the list.

The Fix: Filter Out NULLs Before Using IN / NOT IN

The safe pattern is to flip the logic to IN instead of NOT IN and explicitly exclude NULL from the subquery so it can never poison the comparison:

SELECT id,
    CASE
        WHEN pid IS NULL THEN 'Root'
        WHEN id IN (SELECT pid FROM Tree WHERE pid IS NOT NULL) THEN 'Inner'
        ELSE 'Leaf'
    END AS label
FROM Tree
ORDER BY id;

I ran both versions against the sample table to see the difference side by side:

id	Buggy `NOT IN` version	Correct version	Expected
1	Root	Root	Root
2	Inner	Inner	Inner
3	Inner (wrong)	Leaf	Leaf
4	Inner (wrong)	Leaf	Leaf

The corrected query matched the expected output exactly.

Follow-Up Questions I Got and What I Said

1. Is IN always safer than NOT IN when NULLs might be involved?

Not automatically safer, but the failure mode is much gentler: a stray NULL inside an IN list just means that particular NULL comparison contributes nothing extra, since you're checking "does a match exist," not "does no match exist." NOT IN is the one where a single NULL can quietly break every row, so I said I try to default to IN plus an explicit IS NOT NULL filter whenever the subquery might contain nulls at all.

2. How would you write this using a LEFT JOIN instead of a subquery?


SELECT t.id,
    CASE
        WHEN t.pid IS NULL THEN 'Root'
        WHEN c.id IS NOT NULL THEN 'Inner'
        ELSE 'Leaf'
    END AS label
FROM Tree t
LEFT JOIN Tree c ON c.pid = t.id
GROUP BY t.id, t.pid;

I explained that joining each node to any row where it appears as a parent, then checking whether that join produced a match, sidesteps the NULL-in-a-list issue entirely, since a LEFT JOIN naturally handles "no match" as NULL on the joined side without any special-casing.

3. What if a node could have more than one parent does your query still work?

I said the classification logic itself wouldn't change, since I'm only checking existence of at least one child or one parent either way, but I'd want to add a DISTINCT or GROUP BY to make sure a node with multiple children doesn't get counted more than once and produce duplicate rows in the LEFT JOIN version.

Biggest Learnings From This Round

Both of my mistakes had the same root cause, even though one was an array problem and the other was SQL: I trusted a mental shortcut that works most of the time and stopped checking it against a concrete example. A running minimum "usually" looks right until a value expires. A NOT IN subquery "usually" looks right until a NULL sneaks into it. In both cases, actually tracing through a small, specific example not just reasoning abstractly is what exposed the bug and in both cases that's exactly what the interviewer's question pushed me to do.

Preparation Tips

Practice sliding window problems specifically with the monotonic deque pattern . it comes up constantly in "min/max of every window" style questions and it's a genuine pattern worth having memorized, not reinvented under pressure.

Before trusting any optimization to a brute force solution, test it against the brute force version on a handful of small, deliberately tricky cases especially cases where the "obviously right" answer changes partway through the array. That's exactly how I caught my running-minimum bug.

For SQL rounds, always ask yourself whether any subquery you're using inside an IN or NOT IN could ever return a NULL. If there's any chance of it, either filter the NULLs out explicitly or switch to a LEFT JOIN pattern instead.

Say your complexity analysis out loud even when it's not asked for directly in my round, walking through why something is O(n) instead of O(n log x) was where a couple of the best follow-up questions came from.

Don't be afraid to trace through a tiny concrete example on the spot, even mid-explanation. Both of my mistakes were caught by tracing, not by cleverness and interviewers generally see that as a strength, not a stall.

FAQs

1. What kind of questions does Oracle ask in a Senior Platform Engineer interview?

In my Round 1, it was a mix of a classic array/sliding-window DSA problem and a SQL question not the infrastructure-heavy questions I expected going in based on the "Platform Engineer" title. Don't assume the title tells you the whole syllabus.

2. What is the monotonic deque pattern and when should I use it?

It's a technique for maintaining the min or max of a sliding window in O(n) total time, using a deque that stores indices in increasing (or decreasing) order of their values. Reach for it any time you see "minimum/maximum of every window of size k" recomputing from scratch every window is the giveaway that a smarter structure is expected.

3. Why is NOT IN risky in SQL?

Because if the subquery inside NOT IN can return even a single NULL, every row's NOT IN check evaluates to UNKNOWN instead of TRUE/FALSE, which is treated as false silently breaking the query for every row, not just the one tied to the NULL. Filtering NULLs out of the subquery or rewriting the check as IN (or a LEFT JOIN), avoids the trap.

4. Is Oracle's technical round hard for a senior-level role?

I'd call it a solid 3 out of 5 for Round 1 specifically the concepts themselves (sliding window, basic tree classification) aren't obscure, but both questions had a real trap that a less careful answer would walk straight into. The bar felt like it was on catching the trap and reasoning about complexity, not memorizing a rare algorithm.

Conclusion

Two questions, two traps, two mistakes I caught myself into mostly by testing small examples instead of trusting my first instinct. If Round 2 happens, I'll write that one up too. For now, my one takeaway for anyone prepping for something similar: whatever pattern you reach for first, run it against one small, deliberately awkward example before you commit to it out loud.

Question 1: Maximum of Minimums of Every Window

The problem: given an array A of size n and an integer x, look at every contiguous window of length x, find the minimum inside each window and return the largest of those minimums.

Example:

\nA = [1, 3, -1, 5, 3, 6]\nx = 3\n\nWindows:\n[1, 3, -1]  -> min = -1\n[3, -1, 5]  -> min = -1\n[-1, 5, 3]  -> min = -1\n[5, 3, 6]   -> min = 3\n\nAnswer = 3\n

My First Instinct (and Why It Was Slow)

The obvious first approach: for every window, just scan its x elements and find the minimum directly.

static int bruteForce(int[] a, int x) {\n    int best = Integer.MIN_VALUE;\n    for (int i = 0; i + x <= a.length; i++) {\n        int windowMin = Integer.MAX_VALUE;\n        for (int j = i; j < i + x; j++) {\n            windowMin = Math.min(windowMin, a[j]);\n        }\n        best = Math.max(best, windowMin);\n    }\n    return best;\n}\n

I said out loud that this is O(n · x), since there are roughly n windows and each one costs x work to scan. The interviewer just asked, \"Can we avoid recomputing the minimum from scratch every time the window slides by one?\" That was the nudge most of the work in the window barely changes between one window and the next, so redoing it all every time is wasteful.

My Actual Mistake: Trying to Track \"the Minimum So Far\"

My first attempt at speeding it up was to just keep a single running minimum as I scan left to right, updating it as I go.

// WRONG: a running minimum never \"forgets\" old values that have\n// already slid out of the current window.\nstatic int wrongGlobalMin(int[] a, int x) {\n    int runningMin = Integer.MAX_VALUE;\n    int best = Integer.MIN_VALUE;\n    for (int i = 0; i + x <= a.length; i++) {\n        for (int j = i; j < i + x; j++) {\n            runningMin = Math.min(runningMin, a[j]);\n        }\n        best = Math.max(best, runningMin);\n    }\n    return best;\n}\n

The hint that got me unstuck: the interviewer asked, \"What if a value that used to be your minimum has already slid out of the window do you have any way to know that?\" That's the entire problem in one sentence. A plain running minimum has no concept of \"expiring.\"

The Fix: A Monotonic Deque

The right structure here is a deque (double-ended queue) that stores indices, kept in increasing order of their values, front to back. Two rules keep it correct:

Because of these two rules, the front of the deque is always the index of the current window's minimum no rescanning needed.

Here's how it plays out on the actual interview example, step by step:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

i	A[i]	Expired from front	Popped from back (≥ A[i])	Deque after (indices)	Window min
0	1	none	none	[0]	–
1	3	none	none	[0, 1]	–
2	-1	none	1(3), 0(1)	[2]	-1
3	5	none	none	[2, 3]	-1
4	3	none	3(5)	[2, 4]	-1
5	6	2	none	[4, 5]	3

Max of window minimums = 3 matching the expected answer.

import java.util.*;\n\npublic class MaxOfMins {\n    static int optimal(int[] a, int x) {\n        Deque<Integer> deque = new ArrayDeque<>(); // indices, values increasing front-to-back\n        int best = Integer.MIN_VALUE;\n\n        for (int i = 0; i < a.length; i++) {\n            // Drop indices that fell out of the window on the left.\n            while (!deque.isEmpty() && deque.peekFirst() <= i - x) {\n                deque.pollFirst();\n            }\n            // Maintain increasing order.\n            while (!deque.isEmpty() && a[deque.peekLast()] >= a[i]) {\n                deque.pollLast();\n            }\n            deque.offerLast(i);\n\n            if (i >= x - 1) {\n                best = Math.max(best, a[deque.peekFirst()]);\n            }\n        }\n        return best;\n    }\n}\n

I cross-checked this against the brute force version on 2,000 randomly generated arrays before I trusted it fully every single one matched.

Follow-Up Questions I Got and What I Said

\"What's the time and space complexity?\"

\"Why does popping from the back never lose the true answer?\"

\"What if x is larger than the array?\"

\"Could you solve this with a different data structure, like a max-heap or a TreeMap?\"

Question 2: SQL Classify Every Node in a Tree

The table:

\nid   pid\n1    NULL\n2    1\n3    1\n4    2\n

The task: label every node as Root (no parent), Inner (has at least one child) or Leaf (no children).

Expected output: 1 → Root, 2 → Inner, 3 → Leaf, 4 → Leaf.

My Mistake: The Classic `NOT IN` + `NULL` Trap

My first pass at the query looked completely reasonable:

\nSELECT id,\n    CASE\n        WHEN pid IS NULL THEN 'Root'\n        WHEN id NOT IN (SELECT pid FROM Tree) THEN 'Leaf'\n        ELSE 'Inner'\n    END AS label\nFROM Tree;\n

The hint that helped me catch it: he simply asked, \"What does the subquery actually return here walk me through the values.\" That single question is what exposed the NULL sitting in the list.

The Fix: Filter Out NULLs Before Using IN / NOT IN

The safe pattern is to flip the logic to IN instead of NOT IN and explicitly exclude NULL from the subquery so it can never poison the comparison:

SELECT id,\n    CASE\n        WHEN pid IS NULL THEN 'Root'\n        WHEN id IN (SELECT pid FROM Tree WHERE pid IS NOT NULL) THEN 'Inner'\n        ELSE 'Leaf'\n    END AS label\nFROM Tree\nORDER BY id;\n

I ran both versions against the sample table to see the difference side by side:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

id	Buggy `NOT IN` version	Correct version	Expected
1	Root	Root	Root
2	Inner	Inner	Inner
3	Inner (wrong)	Leaf	Leaf
4	Inner (wrong)	Leaf	Leaf

The corrected query matched the expected output exactly.

Follow-Up Questions I Got and What I Said

1. Is IN always safer than NOT IN when NULLs might be involved?

Not automatically safer, but the failure mode is much gentler: a stray NULL inside an IN list just means that particular NULL comparison contributes nothing extra, since you're checking \"does a match exist,\" not \"does no match exist.\" NOT IN is the one where a single NULL can quietly break every row, so I said I try to default to IN plus an explicit IS NOT NULL filter whenever the subquery might contain nulls at all.

2. How would you write this using a LEFT JOIN instead of a subquery?

\nSELECT t.id,\n    CASE\n        WHEN t.pid IS NULL THEN 'Root'\n        WHEN c.id IS NOT NULL THEN 'Inner'\n        ELSE 'Leaf'\n    END AS label\nFROM Tree t\nLEFT JOIN Tree c ON c.pid = t.id\nGROUP BY t.id, t.pid;\n

I explained that joining each node to any row where it appears as a parent, then checking whether that join produced a match, sidesteps the NULL-in-a-list issue entirely, since a LEFT JOIN naturally handles \"no match\" as NULL on the joined side without any special-casing.

3. What if a node could have more than one parent does your query still work?

Biggest Learnings From This Round

Both of my mistakes had the same root cause, even though one was an array problem and the other was SQL: I trusted a mental shortcut that works most of the time and stopped checking it against a concrete example. A running minimum \"usually\" looks right until a value expires. A NOT IN subquery \"usually\" looks right until a NULL sneaks into it. In both cases, actually tracing through a small, specific example not just reasoning abstractly is what exposed the bug and in both cases that's exactly what the interviewer's question pushed me to do.

Preparation Tips

Practice sliding window problems specifically with the monotonic deque pattern . it comes up constantly in \"min/max of every window\" style questions and it's a genuine pattern worth having memorized, not reinvented under pressure.

Before trusting any optimization to a brute force solution, test it against the brute force version on a handful of small, deliberately tricky cases especially cases where the \"obviously right\" answer changes partway through the array. That's exactly how I caught my running-minimum bug.

FAQs

1. What kind of questions does Oracle ask in a Senior Platform Engineer interview?

In my Round 1, it was a mix of a classic array/sliding-window DSA problem and a SQL question not the infrastructure-heavy questions I expected going in based on the \"Platform Engineer\" title. Don't assume the title tells you the whole syllabus.

2. What is the monotonic deque pattern and when should I use it?

It's a technique for maintaining the min or max of a sliding window in O(n) total time, using a deque that stores indices in increasing (or decreasing) order of their values. Reach for it any time you see \"minimum/maximum of every window of size k\" recomputing from scratch every window is the giveaway that a smarter structure is expected.

3. Why is NOT IN risky in SQL?

4. Is Oracle's technical round hard for a senior-level role?

Conclusion

","categoryId":363,"subCategoryId":143,"contentFormat":5,"blogId":185,"userId":"MjlfNF84LVsxMDhdMm4tdENfQU5nZV9fSXQ=","title":"My Oracle Interview Experience (July 2026) : Round 1 (Senior Platform Engineer)","url":"my-oracle-interview-experience-july-2026-round-1-senior-platform-engineer","bannerImage":"","seoDescription":"Read my Oracle Senior Platform Engineer Round 1 interview experience covering a Sliding Window array problem, SQL question, interviewer hints, mistakes, and sol","generatedOn":"2026-08-12T12:48:09","updatedOn":"2026-08-30T06:47:52"},"popularContents":[{"id":138,"title":"DSA Patterns for Coding Interviews: Complete LeetCode Roadmap (Beginner to Advanced)","url":"dsa-patterns-for-coding-interviews-complete-leetcode-roadmap-beginner-to-advanced","description":null,"seoDescription":"Master every LeetCode pattern for coding interviews. Learn Arrays, Sliding Window, Graphs, Dynamic Programming, Trees, Heaps and more with 250+ curated problem","contentType":5,"generatedOn":"2026-10-14T22:22:43.842105Z","viewCount":0},{"id":167,"title":"Meesho SDE-1 Online Assessment Interview Experience (Remote) - Rejected","url":"meesho-sde-1-online-assessment-interview-experience-remote-rejected","description":null,"seoDescription":"Read a real Meesho SDE-1 online assessment experience with coding questions, DSA topics, solutions, difficulty level, preparation tips and interview insights.","contentType":5,"generatedOn":"2026-10-14T22:22:43.842112Z","viewCount":0},{"id":168,"title":"Amazon SDE-2 Interview Experience (3 Years Experience)","url":"amazon-sde-2-interview-experience-3-years-experience","description":null,"seoDescription":" Read a real Amazon SDE-2 interview experience covering the online assessment, coding rounds, object-oriented design, leadership principles and system design.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421138Z","viewCount":0},{"id":34,"title":"System Design Deep Dive: 25 Essential Interview Questions","url":"system-design-deep-dive-25-essential-interview-questions","description":null,"seoDescription":"","contentType":5,"generatedOn":"2026-10-14T22:22:43.842096Z","viewCount":0},{"id":35,"title":"Cursor vs Copilot : Which AI Coding Assistant Wins in 2025?","url":"cursor-vs-copilot-which-ai-coding-assistant-truly-wins-in-2025","description":null,"seoDescription":"Compare Cursor vs GitHub Copilot on speed, context awareness, multi-file support, pricing and code quality to choose the best AI coding assistant for developers","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421009Z","viewCount":0},{"id":166,"title":"System Design Interview – BIGGEST Mistakes to Avoid","url":"system-design-interview-biggest-mistakes-to-avoid","description":null,"seoDescription":"Learn the biggest mistakes to avoid in a system design interview, from unclear requirements to poor trade-off analysis. Includes real-world cases, advanced insights and examples to help you ace your next system design interview.","contentType":2,"generatedOn":"2026-10-14T22:22:43.8415352Z","viewCount":0},{"id":173,"title":"Uber SDE-2 Interview Experience : LLD, HLD, DSA & Hiring Manager Round","url":"uber-sde-2-interview-experience-lld-hld-dsa-hiring-manager-round","description":null,"seoDescription":"Read a real Uber SDE-2 interview experience covering DSA, low-level design, high-level system design, behavioral rounds, hiring freeze and key takeaways.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421172Z","viewCount":0},{"id":153,"title":"Visa Software Engineer 1 (SDE-1) Interview Experience | CodeSignal OA + Graph-Based Technical Rounds","url":"visa-software-engineer-1-sde-1-interview-experience-codesignal-oa-graph-based-technical-rounds","description":null,"seoDescription":" Ace your Visa SDE-1 interview with this complete interview experience covering CodeSignal OA, graph coding rounds, hiring manager questions and tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421067Z","viewCount":0},{"id":171,"title":"Meesho SDE-1 Backend Interview Experience (Remote | 3 Round) - Rejected","url":"meesho-sde-1-backend-interview-experience-remote-3-round-rejected","description":null,"seoDescription":"Read a real Meesho SDE-1 Backend interview experience covering the online assessment, DSA interview, machine coding round, LLD questions and preparation tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421154Z","viewCount":0},{"id":130,"title":"Rippling SDE-2 Interview Experience (4+ Years Experience) | Offer Received | Coding, LLD & System Design","url":"rippling-sde-2-interview-experience-4-years-experience-offer-received-coding-lld-system-design","description":null,"seoDescription":"Detailed Rippling SDE-2 interview experience with complete 5 rounds, coding questions, rules engine design, system design and preparation tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8421031Z","viewCount":0}],"latestContents":[{"id":219,"title":"6 Tools That Made My Life Easier as a Software Engineer","url":"6-tools-that-made-my-life-easier-as-a-software-engineer","description":null,"seoDescription":"The 6 developer tools I use daily as a software engineer: Git, VS Code, Docker, Postman, Chrome DevTools, and AI assistants, with real tips, mistakes, and trade","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406266Z","viewCount":0},{"id":218,"title":"When Should a Business Use Multiple AI Agents Instead of One?","url":"when-should-a-business-use-multiple-ai-agents-instead-of-one","description":null,"seoDescription":"Single agent or multi-agent AI? Learn the 4 signals that justify splitting agents by knowledge, permissions, and risk, plus routing and handoff tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406303Z","viewCount":0},{"id":216,"title":"AI in Clinical Trials Market Estimated to Experience a Hike in Growth by 2035","url":"ai-in-clinical-trials-market-estimated-to-experience-a-hike-in-growth-by-2035","description":null,"seoDescription":"The exclusive information about market dynamics serves as a valuable guide to predict economic scenarios and initiatives taken to enhance future growth. Our mar","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406325Z","viewCount":0},{"id":217,"title":"AI in Clinical Trials Market Estimated to Experience a Hike in Growth by 2035","url":"ai-in-clinical-trials-market-estimated-to-experience-a-hike-in-growth-by-2035","description":null,"seoDescription":"The exclusive information about market dynamics serves as a valuable guide to predict economic scenarios and initiatives taken to enhance future growth. Our mar","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406341Z","viewCount":0},{"id":215,"title":"What Happens When an AI Agent Doesn't Know the Answer?","url":"what-happens-when-an-ai-agent-doesnt-know-the-answer","description":null,"seoDescription":"Most AI agents fail quietly. They guess instead of saying \"I don't know.\" Here's how to design better fallback and human-handoff behavior.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406356Z","viewCount":0},{"id":214,"title":"Greedy Algorithms Explained: How They Work, When They Fail and How to Use Them","url":"greedy-algorithms-explained-how-they-work-when-they-fail-and-how-to-use-them","description":null,"seoDescription":"Learn greedy algorithms step by step with C# code Dijkstra, Huffman coding, knapsack and MSTs plus when greedy fails and how to prove it's correct","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406377Z","viewCount":0},{"id":213,"title":"Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026","url":"amazon-sde-ii-interview-experience-bangalore-selected-aug-2026","description":null,"seoDescription":"Amazon SDE II interview experience from Bangalore covering 4 rounds, DSA, LLD, system design, Leadership Principles, coding questions and selection.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406392Z","viewCount":0},{"id":212,"title":"How to Get 10x Better AI Answers Without Writing Better Prompts : 10 Proven Techniques","url":"how-to-get-10x-better-ai-answers-without-writing-better-prompts-10-proven-techniques","description":null,"seoDescription":"Get better AI answers without complex prompts. Learn 10 practical techniques using context, examples, tools, feedback, and verification.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406407Z","viewCount":0},{"id":211,"title":"I Interviewed for a Microsoft SDE I Role. Here's Everything That Happened.","url":"i-interviewed-for-a-microsoft-sde-i-role-heres-everything-that-happened","description":null,"seoDescription":"My real Microsoft SDE I interview experience, all 4 rounds, the exact DSA problems with fully tested solutions, the WhatsApp system design round","contentType":5,"generatedOn":"2026-10-14T22:22:43.8406423Z","viewCount":0},{"id":140,"title":"PolicyBazaar Software Development Engineer (SDE) Interview Experience | DSA, Core CS & System Design","url":"policybazaar-software-development-engineer-sde-interview-experience-dsa-core-cs-system-design","description":null,"seoDescription":"Detailed PolicyBazaar SDE interview experience covering 3 rounds: DSA coding, core CS assessment and system design with key learnings and insights.","contentType":5,"generatedOn":"2026-10-14T22:22:43.840644Z","viewCount":0}],"relatedContents":[{"id":28,"title":"Oracle Interview Experience (Senior Applications Engineer)","url":"oracle-interview-experience-senior-applications-engineer","description":null,"seoDescription":"","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485032Z","viewCount":0},{"id":213,"title":"Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026","url":"amazon-sde-ii-interview-experience-bangalore-selected-aug-2026","description":null,"seoDescription":"Amazon SDE II interview experience from Bangalore covering 4 rounds, DSA, LLD, system design, Leadership Principles, coding questions and selection.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485047Z","viewCount":0},{"id":211,"title":"I Interviewed for a Microsoft SDE I Role. Here's Everything That Happened.","url":"i-interviewed-for-a-microsoft-sde-i-role-heres-everything-that-happened","description":null,"seoDescription":"My real Microsoft SDE I interview experience, all 4 rounds, the exact DSA problems with fully tested solutions, the WhatsApp system design round","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485063Z","viewCount":0},{"id":139,"title":"Blinkit (Eternal) SDE-1 Interview Experience (June 2026) – Offer Received","url":"blinkit-eternal-sde-1-interview-experience-june-2026-offer-received","description":null,"seoDescription":"Blinkit SDE-1 interview experience with a 30 LPA offer. Covers House Robber DP, ticket booking system design, culture fit round and tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485077Z","viewCount":0},{"id":137,"title":"JPMorgan SDE-2 Interview Experience - 3 Rounds | Java, Code Review & System Design","url":"jpmorgan-sde-2-interview-experience-3-rounds-java-code-review-system-design","description":null,"seoDescription":" JPMorgan Chase SDE-2 interview experience covering code review, Core Java, system design, concurrency, behavioral rounds and key learnings.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485096Z","viewCount":0},{"id":140,"title":"PolicyBazaar Software Development Engineer (SDE) Interview Experience | DSA, Core CS & System Design","url":"policybazaar-software-development-engineer-sde-interview-experience-dsa-core-cs-system-design","description":null,"seoDescription":"Detailed PolicyBazaar SDE interview experience covering 3 rounds: DSA coding, core CS assessment and system design with key learnings and insights.","contentType":5,"generatedOn":"2026-10-14T22:22:43.848513Z","viewCount":0},{"id":135,"title":"Spinny SDE-1 Interview Experience (Selected)","url":"spinny-sde-1-interview-experience-selected","description":null,"seoDescription":"Spinny SDE-1 Interview Experience (Selected) | 4 Rounds Breakdown: Coding, LLD, Java, SQL + Real Interview Questions","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485143Z","viewCount":0},{"id":209,"title":"Adobe Computer Scientist 1 Interview Experience: Real Questions, Solutions & Tips","url":"adobe-computer-scientist-1-interview-experience-real-questions-solutions-tips","description":null,"seoDescription":"Real Adobe CS-1 interview experience covering C++, DSA questions, coding solutions, reschedules, rejection, interview challenges and preparation tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8485161Z","viewCount":0},{"id":172,"title":"Google L4 Software Engineer III interview experience | Selected","url":"google-l4-software-engineer-iii-interview-experience-selected","description":null,"seoDescription":"Google L4 Software Engineer III interview experience with API design, Googlyness, route matching, graph coding rounds, follow-up questions and tips.","contentType":5,"generatedOn":"2026-10-14T22:22:43.8519514Z","viewCount":0}]}}},"source":{"isMobile":false}}; window.__CLIENT_RENDER__ = false;

My Oracle Interview Experience (July 2026) : Round 1 (Senior Platform Engineer)

Question 1: Maximum of Minimums of Every Window

My First Instinct (and Why It Was Slow)

My Actual Mistake: Trying to Track "the Minimum So Far"

The Fix: A Monotonic Deque

Follow-Up Questions I Got and What I Said

Question 2: SQL Classify Every Node in a Tree

My Mistake: The Classic NOT IN + NULL Trap

The Fix: Filter Out NULLs Before Using IN / NOT IN

Follow-Up Questions I Got and What I Said

Biggest Learnings From This Round

Preparation Tips

FAQs

Conclusion

Trending Developer Reads

Question 1: Maximum of Minimums of Every Window

My First Instinct (and Why It Was Slow)

My Actual Mistake: Trying to Track \"the Minimum So Far\"

The Fix: A Monotonic Deque

Follow-Up Questions I Got and What I Said

Question 2: SQL Classify Every Node in a Tree

My Mistake: The Classic NOT IN + NULL Trap

The Fix: Filter Out NULLs Before Using IN / NOT IN

Follow-Up Questions I Got and What I Said

Biggest Learnings From This Round

Preparation Tips

FAQs

Conclusion

My Mistake: The Classic `NOT IN` + `NULL` Trap

My Mistake: The Classic `NOT IN` + `NULL` Trap