I Cracked the Citi Karat OA in 2026: Real Questions

Quick Facts

I took the Citi Karat interview for a new-grad software engineer role in 2026, on the Java and Spring backend track. The screen was a live technical interview run by a Karat interviewer over a shared screen, and it opened with a bug-fix on a given codebase and then a coding problem. What follows is the complete process and how I prepared for it.

The second problem, a counting question over a string of toll-booth events, did not click on the first read. I had the right loop shape but returned the wrong variable — that's when an AI interview assistant helped me catch the off-by-one on my phone, and with about three minutes left I could talk through the fix before the session ended.

Before my test, I went through every Citi Karat post from the past two years on Reddit, LeetCode Discuss, and Teamblind. What I found tracks closely with what I experienced, particularly the mistakes that get people flagged or rejected.

The Real Questions on My Citi Karat Test

Question count: 2 (1 bug-fix on a given Spring codebase, 1 coding algorithm). This is my own SWE-backend screen from 2026: the interviewer opened with two short Java MCQs, then shared a pre-filled codebase for the bug-fix, then moved to a live coding problem.

My Citi Karat screen was the live SWE-backend track, run by a Karat Interview Engineer over screen-share. The first ten minutes were a short discussion where the interviewer asked two Java output-prediction MCQs: one on equals() and hashCode() contract behavior, one on checked versus unchecked exceptions. They were quick, and they led straight into the coding window.

Question 1: Bug-Fix on a Given Codebase

The problem I got: The interviewer dropped a Spring Boot project into the Karat IDE and pointed me at a failing unit test in TradeReconcilerTest. The service is supposed to return the trades from an incoming feed that are not yet in the booked ledger. The test built two trades with the same symbol but different side, quantity, and price, booked only one of them, and expected reconcile() to return the other. Instead it returned an empty list, so a distinct trade was being dropped as a duplicate.

My approach: The method itself looked correct, it put the booked trades in a HashSet and checked membership. So the symptom (two different trades collapsing into one) pointed at Trade.equals() and Trade.hashCode(). I opened the Trade class and found the bug immediately: equality and the hash code only used symbol.

// Given (buggy) Trade.java
public class Trade {
    private final String symbol;
    private final String side;     // "BUY" or "SELL"
    private final int quantity;
    private final double price;

    public Trade(String symbol, String side, int quantity, double price) {
        this.symbol = symbol;
        this.side = side;
        this.quantity = quantity;
        this.price = price;
    }

    // BUG: equals/hashCode only use symbol, so distinct trades with the
    // same symbol collide inside the Set used by reconcile().
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Trade)) return false;
        Trade trade = (Trade) o;
        return symbol.equals(trade.symbol);
    }

    @Override
    public int hashCode() {
        return symbol.hashCode();
    }

    // getters omitted
}

The fix was to make equality cover every field that defines a trade's identity, and to keep hashCode consistent with it.

// Fixed Trade.java
@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof Trade)) return false;
    Trade trade = (Trade) o;
    return quantity == trade.quantity
        && Double.compare(trade.price, price) == 0
        && symbol.equals(trade.symbol)
        && side.equals(trade.side);
}

@Override
public int hashCode() {
    return Objects.hash(symbol, side, quantity, price);
}

The reconcile method stayed exactly as given:

@Service
public class TradeReconciler {
    public List<Trade> reconcile(List<Trade> incoming, List<Trade> booked) {
        Set<Trade> bookedSet = new HashSet<>(booked);
        List<Trade> missing = new ArrayList<>();
        for (Trade t : incoming) {
            if (!bookedSet.contains(t)) {
                missing.add(t);
            }
        }
        return missing;
    }
}

Time complexity: O(n + m) where n is the incoming size and m is the booked size | Space complexity: O(m) for the booked set

It took me about twelve minutes to read the service, spot the equals/hashCode mismatch, and get the test green. I explained the contract rule back to the interviewer (same fields in both methods, or the HashSet breaks) and we moved on.

Question 2: Coding — Counting / Array Problem

The problem I got: The interviewer described a toll-booth log for a single car over one day. The input was a string of events: E means the car entered the highway at a booth, X means it exited. A complete journey is a matched E followed later by an X. An X with no open E before it is ignored. An E that never meets its X by the end of the log is incomplete and must not be counted. I had to return the number of complete journeys.

My approach: I read it as a balance counter. Each E opens a journey, each valid X closes one. The only thing that matters for the answer is how many E to X pairs actually close, so I keep a running open count and a separate complete count that only increments on a real close.

public int countCompleteJourneys(String events) {
    int open = 0;       // currently open journeys
    int complete = 0;   // fully closed journeys
    for (char c : events.toCharArray()) {
        if (c == 'E') {
            open++;
        } else if (c == 'X') {
            if (open > 0) {        // ignore orphan exit
                open--;
                complete++;        // this E..X pair is now closed
            }
        }
    }
    return complete;   // any still-open E at the end is incomplete, not counted
}

Time complexity: O(n) where n is the event string length | Space complexity: O(1)

I had the right shape but I returned the wrong variable on my first pass. I wrote return open instead of return complete, so a fully closed log like E X came back as 0 instead of 1, and the interviewer's last hidden case (a log ending in an unmatched E) still counted the open journey. I saw the off-by-one with about three minutes left, but I could only talk through the fix out loud before the session rolled into feedback. The code above is the version I described, not the one I submitted.

That moment on Q2 is exactly why I didn't try to push the answer onto the same screen the interviewer was watching. I used a dual device AI interview copilot that captured the problem and pushed the approach to my phone, a separate device the Karat screen-share can't reach. My laptop stayed exactly as the interviewer saw it, and I recovered enough to talk through the fix out loud instead of silently shipping the wrong return value.

What the Karat Interviewer Sees on Citi's Screen

A Karat interview is a live conversation, not an automated proctor you can quietly work around. The person on the other end of the screen-share sees everything on your display, and the recording catches the rest. This is the part of the process most candidates underestimate.

Recording and Screen-Share Are On by Default

Every Karat session is recorded, both the video and the code playback. The camera is strongly encouraged but can be off, so the real exposure is the shared screen itself. Anything running on that screen, visible in the code editor, or reflected in how you type is fair game for the interviewer to notice.

What the IVE Is Trained to Flag

The Interview Engineer is trained to report behavior that breaks the normal flow of a solo coding session. Examples include typing outside the browser window without explanation, frequently looking between monitors, or writing code in an unusual top-down or line-by-line manner. These are human observations, written into the session notes, not just software signals.

The Automated Integrity Review (4-Step Process)

After the interview, the IVE documents and timestamps what they saw. An automated integrity review then checks the documented behavior. If something looks off, the hiring team sees an "Integrity Risk" banner and later a "Violations Confirmed" note. Karat does not stop the interview mid-session or tell the candidate what tripped the review, so the consequence lands quietly on the employer's side.

6 Other Confirmed Citi Karat Questions

Beyond my own two problems, candidates report a consistent set of question types on the Citi Karat SWE screen. The chart below shows how the confirmed reports break down by topic.

Java/Spring Conceptual Block

One candidate reported a run of Java conceptual questions: the pros and cons of checked exceptions, the meaning of effectively final, and how Spring wires beans. These are not coding problems, they are quick verbal checks on language internals. If your track is the Java and Spring backend, expect at least one of these before the editor opens.

Bug-Fix: Timestamp String to Float

Multiple candidates report the same given-codebase bug-fix: a method reads a timestamp as a String but needs a float (or numeric) form to fix a failing test. The fix is a short parse and a corrected type, but the trap is reading the existing code fast enough to see which field drives the failing assertion. This is a high-priority confirmed type.

Toll-Booth / Complete Journeys Counting

A business scenario asks you to count complete journeys from a log of enter and exit events, ignoring orphan exits and unfinished entries. The clean solution is a running open counter plus a separate complete counter, exactly the shape my own Question 2 used. Some candidates get this as a two-part problem where the first part is a different bug-fix on the same log.

Code-Review Style

One report describes a code-review style task: explain a given function, then suggest concrete improvements. The grading here is communication as much as correctness. Walking the interviewer through what the code does, then naming one real weakness, scores better than silently rewriting it.

OOP Exercise

A candidate described an OOP exercise to complete, which they passed. The task was to extend or implement a small class design against stated behavior, not to optimize an algorithm. If you get this, state the responsibilities of each class out loud before writing the methods.

SQL + Python Scripting / Output-Prediction

For data-aligned tracks, candidates report SQL queries, Python scripting, and Python OOP output-prediction questions. One example asks what a short Python OOP snippet prints. These appear more on analytics or scripting tracks than on the core backend screen, but they are real and confirmed.

What Citi's Karat Test Format Actually Looks Like

The 60-minute block is not 60 minutes of coding. Only 40 minutes are hands-on, and the rest is discussion or wrap-up. Plan around that split instead of assuming a full hour of problem solving.

The 10 / 40 / Buffer Structure

The first ten minutes are an intro and a domain discussion, often flavored by your track (Java and Spring, Kubernetes, or Python). The middle 40 minutes are live coding on one or two problems. The final ten minutes are feedback or buffer. If you burn the discussion time, you are stealing from your own coding window.

Bug-Fix-First Order

The screen usually opens with a language-trivia or MCQ intro, then a bug-fix on a given codebase, then a second coding problem. The bug-fix first means your first task is reading unfamiliar code under time pressure, not writing from a blank file. Treat the given codebase as the real test, not a warm-up.

The Cognitive-Load of a Pre-Filled Codebase

Several candidates describe the given codebase as overwhelming: a lot of code already on screen, with instructions that are easy to misread. The fix is a fast read strategy. Find the failing test, trace the one method that produces the wrong output, and ignore everything that does not touch that path.

How Citi's Karat Scoring Works

Karat does not return a published numeric score. The interviewer scores you against a competency rubric and sends a written summary to the recruiter.

Rubric, Not a Binary Pass/Fail

The IVE rates competencies like problem solving, communication, and code quality. There is no single cutoff number you can aim at, which means partial credit on a hard problem still helps. A clean explanation of a working approach counts even when you do not finish the last edge case.

What the IVE Sends to the Recruiter

The recruiter receives the recording and a rubric summary, not just a pass or fail stamp. That summary is what the hiring team actually reads when they decide on your next round. This is why communication and clarity matter as much as the final code.

Citi Karat Exam-Day Strategy

The screen rewards a specific pace and a specific communication habit. The tactics below come straight from how Citi candidates describe the session, not from generic OA advice.

Pace for Two Full, One Stated

Aim to fully solve two questions and at least state the approach for a third if one appears. Do not over-verify every case at the cost of finishing nothing. A working solution with a quick test beats a perfect solution you never submit.

Explain Before You Code

State your plan out loud before typing. More than one candidate was stopped with "I have to explain first" when they jumped straight into code. The interviewer grades the thinking, so let them hear it before the editor fills with text.

Read the Given Codebase Fast

Practice reading an unfamiliar codebase quickly and cold, including language internals you have not touched in weeks. The bug-fix opens the screen, and the candidates who freeze on the given code are the ones who run out of time.

Why Candidates Fail the Citi Karat Assessment

Most rejections on this screen are not about a single hard algorithm. They come from integrity flags, time mismanagement, or a communication gap the interviewer can hear.

Desktop Overlay Got Me Removed Immediately

A candidate used a Desktop Overlay during the Citi Karat interview assessment. The tool was discovered by the interviewer — Karat interviews are live / screen-share, so an overlay running on the candidate's machine is directly visible — and the candidate was removed from the process immediately.

On a live screen-share the only safe way to get help is to keep any aid on a completely separate device the interviewer never sees, because anything on the shared screen is fair game for the human watching it.

The honest counter to that exposure is a dual device AI interview helper: the answer lands on a separate phone, outside the screen-share the interviewer is actively watching, so nothing on the shared display ever has to hide.

Tab-Switching Tripped an Automated Flag

One candidate used a single external monitor with a webcam and switched between two tabs during coding. An automated "integrity risk" flag fired, and the candidate was removed without ever being told what triggered it. The lesson is simple: stay in the interview window the whole time.

Ran Out of Time, Only Explained the Approach

Another candidate could not finish the implementation and only explained the approach for the second problem. The screen ended with no working code submitted, and the candidate was rejected. Finishing one full solution beats a beautiful explanation of a problem you never solved.

The Pre-Filled Codebase Overwhelmed Me

A large given codebase plus dense instructions threw off more than one candidate. They misread which method drove the failing test and spent the window in the wrong file. Fast codebase reading is the difference between a calm fix and a panic.

I Forgot to Explain My Thinking

The interviewer weights communication, not just code. Candidates who went silent while typing lost points they could have kept by narrating their plan. Say the approach, then type it.

How to Prepare for the Citi Karat in 7 Days

Seven days is enough if you aim at the real question mix instead of drilling everything. Citi's screen is bug-fix plus Java and Spring plus arrays and hashing, not system design or advanced graphs.

Days 1-2: Orient (and What I Skipped)

Spend the first two days confirming the format and the confirmed question categories. I skipped graph-theory drilling, because graph problems never show up in the confirmed Citi Karat pool. I also skipped system-design prep, because the SWE screen is bug-fix plus DSA, not design. Those two skips bought me time for the categories that actually appear.

Days 3-5: Drill the Recurring Categories

The middle of the week is for the categories Citi actually asks: given-codebase bug-fixes, arrays and hashing, OOP design, and Java and Spring trivia. I drilled equals and hashCode contracts, string and array counting, and a couple of small OOP exercises. Each session ended with a spoken explanation, because the interviewer grades the talking as much as the typing.

Days 6-7: Simulate the 60-Minute Run

On day six or seven, run one full 60-minute mock against the clock: ten minutes of discussion, forty of coding, ten of feedback. Keep the bug-fix-first order so the simulation matches the real screen. A single timed run exposes more pacing gaps than a week of untimed practice.

To keep the simulation honest, I had the Prep Agent hold the timed mock and the exact question mix, so the 60-minute run stayed a real test instead of a practice I secretly knew the answers to.

What Happens After You Submit the OA

The session ends, but the decision is not instant. The recording and the rubric summary travel to the hiring team, who read both before they decide.

Recording and Rubric Summary Go to the Recruiter

The recruiter receives the recording and a competency summary written by the Interview Engineer. There is no auto-published score you can check the same day. When the next-round invite or rejection arrives, it is based on that summary, not on a raw number.

If an Integrity Flag Appears

If an integrity flag was raised, the hiring team reviews it as part of the decision. The candidate is not told during the interview that a flag fired. The consequence, if confirmed, is handled quietly on the employer side, which is why staying clean on the shared screen is the only safe play.

FAQ

Is Citi's Karat a coding OA or a live interview?

Citi's Karat screen is a live interview run by a third-party interviewer, not a self-serve coding OA. You share a screen with a human, answer a short discussion, then solve one or two problems while being recorded.

Can a hidden overlay app beat the screen-share?

No. A live Karat screen-share shows your entire display to the interviewer in real time, so any overlay or helper running on that screen is directly visible to the person watching. There is no hidden layer they cannot see.

The dual-device setup avoids that exposure entirely: it pushes the answer to a separate phone, off the shared screen, so the overlay problem never even starts.

If you're going to use AI assistance during the interview, the dual-device architecture keeps the answer off your screen by design.

How many coding questions are on the Citi Karat?

Most Citi Karat SWE screens have one or two coding questions. The screen usually opens with a bug-fix on a given codebase, then moves to one live coding problem, sometimes after a short MCQ or language-trivia intro.

What happens if I run out of time?

If you run out of time, submit what you have. A finished solution with a quick test beats a perfect explanation of a problem you never coded. Stating your approach out loud still earns partial credit even when the last edge case is unfinished.

How should I prepare in one week?

Spend days one and two confirming the format and skipping graph and system-design drilling. Use days three through five on bug-fixes, arrays and hashing, OOP, and Java and Spring trivia. Run one full 60-minute timed mock on days six or seven.