Fidelity Coding Interview Questions

Fidelity runs a Java-engineering interview, and prepping it like a hard-LeetCode shop wastes the weeks that matter. Can you predict a snippet's output and explain what a HashMap does under the hood? Can you say why equals and hashCode get overridden together, and reason about Spring beans, threads and JDBC without a search bar? The algorithm question, when it appears, is easy to medium and usually a single problem. The bar is fluency in the language and framework you'd build with on the job.

The coding surface has four parts, and their weight shifts by geography and level. An online assessment leads the India campus pipeline. The Java and Spring fundamentals bucket is the heaviest and most distinctive signal in the loop. A light data-structures-and-algorithms problem follows, typically arrays, strings, hashing, a stack or a touch of dynamic programming, often just one live. Last comes SQL, mandatory for data and ETL roles and frequent for software engineers too.

The Fidelity angle

Treat the loop as a Java interview with a small algorithm attached, and your prep priorities flip the right way. Candidates fresh from a generic LeetCode grind over-index on graphs and hard dynamic programming. They under-prepare what Fidelity leans on: collections internals, concurrency semantics, the Spring lifecycle, and clean idiomatic code. Fidelity builds and maintains long-lived Java systems for asset management and trading. The interview screens for engineers who understand the runtime they ship on. Spend your hours on the language and framework, keep one easy-to-medium algorithm pattern warm, and drill SQL.

What coding questions does Fidelity ask?

Fidelity coding questions come in three layers. The heaviest is Java and Spring fundamentals (output-prediction snippets, HashMap internals, concurrency, beans and scopes), tested for real understanding. On top sits one easy-to-medium algorithm over arrays, strings, hashing or a stack, usually a single problem. Underneath both is SQL, mandatory for data roles and frequent for software engineers. The named problems that recur are below.

Read this page for how each layer is graded, then route by track. The India campus and early-career loop leads with an online assessment, and the US and experienced loop is lighter on live coding. For the whole process, see the Fidelity interview questions guide. Pair this with the system design and behavioral rounds.

The online assessment

In India, where the early-career pipeline is campus-driven, the loop opens with a timed online assessment of roughly ninety minutes to two hours. It runs on a platform in the HirePro and HackerRank family (no CodeSignal) and comes in sections. A short aptitude and English block comes first, with fill-in-the-blanks, comprehension and synonyms, in ten to fifteen minutes. A Core-CS multiple-choice section follows, often twenty to forty questions on operating systems, DBMS, object-oriented programming and sometimes computer networks. Then comes the coding, two problems in the easy-to-medium range. Some sittings add a short algorithm-or-pseudocode section where you write the approach without fully working code.

The coding problems stay pattern-based and away from the hard end. One representative shape counts the distinct pairs in an array whose sum is divisible by sixty, a prefix-and-hashmap counting problem. Others sum an array while excluding flagged elements, or generate primes with a minimum count of a given digit. A recursive layer-counting problem with a modular growth rule has also appeared. None need an advanced data structure. They reward spotting the ordinary pattern (arrays, strings, a hashmap, occasionally a monotonic stack or light dynamic programming) and implementing it cleanly inside the timer.

The Java and Spring fundamentals bucket

This bucket defines a Fidelity interview, and a generic frequency list will leave you underprepared for it. The classic opener is output prediction. The interviewer shows a short Java snippet and asks what it prints and why. These probe whether you understand object identity, autoboxing, the string pool, and how the collections framework keys its entries. Reciting a definition won't get you there. The one below is a compact example of the genre.

Map<String, Integer> counts = new HashMap<>();
String a = "SPY";
String b = new String("SPY");
counts.put(a, 1);
System.out.println(counts.get(b));  // 1: HashMap keys by equals + hashCode, not by reference
System.out.println(a == b);         // false: a and b are distinct objects
System.out.println(a.equals(b));    // true: same character contents

From there the questions fan out across the parts of Java you'd use to build a service. Expect HashMap internals (buckets, hashing, collisions, resize) and why equals and hashCode must be overridden as a pair. You may get the methods every object inherits from Object, and which class tops the hierarchy. Concurrency comes up in concrete terms, such as Thread.sleep versus Object.wait, what a semaphore is for, and in newer sittings virtual threads. On the framework side, expect Spring beans, how to declare one, the bean scopes and a prototype-versus-singleton example, plus JDBC's flow, connection pooling, and try-with-resources. Messaging over JMS, Kafka, or RabbitMQ and REST basics such as GET versus POST round it out.

The Fidelity angle

Fidelity grades Java on correctness and idiom, so how you write matters as much as what you compute. Interviewers in these rounds are often senior or principal engineers, and they watch whether your code reads like something a Java team would merge. One candidate was asked to justify a call as ordinary as getOrDefault. Name types precisely, use the collections API as intended, and close resources with try-with-resources. Be ready to explain a design choice as well as produce a passing answer. Clear-and-correct beats optimal-but-cryptic here, the reverse of what a speed-run judge trains.

The one DSA problem

The live algorithm question, when there is one, is deliberately modest: easy to medium, and usually a single problem. Named examples map to familiar patterns. Think first non-repeating character in a string, Minimum Path Sum as a grid dynamic-programming warm-up, or a nearest-smaller-element scan that points to a monotonic stack. Senior software candidates have seen a Best Time to Buy and Sell Stock variation with a capital-and-shares twist: given a fixed budget and a price list, buy whole shares once and maximize profit. Some US manager rounds accept clean pseudocode in place of compiled code. Here is the first-non-repeating pattern, written the way a Fidelity reviewer wants to see it.

static Character firstUnique(String s) {
    Map<Character, Integer> freq = new LinkedHashMap<>();
    for (char c : s.toCharArray()) {
        freq.merge(c, 1, Integer::sum);  // count while preserving insertion order
    }
    for (Map.Entry<Character, Integer> e : freq.entrySet()) {
        if (e.getValue() == 1) {         // Integer unboxes to int against the literal
            return e.getKey();
        }
    }
    return null;  // no unique character
}

The points in that solution come from ordinary good judgment. A LinkedHashMap, because order matters for "first". The merge method instead of a manual get-null-check-put. A comment where a reader might pause. Reach for the right collection, write it idiomatically, and be ready to discuss time and space cost. Skip micro-optimizations the problem never asked for, since the round grades working, readable Java.

SQL is load-bearing here

Treat SQL as a first-class part of the coding surface. It's mandatory for data-engineering and ETL roles and appears often for software engineers. Some experienced and lateral sittings include a HackerRank assessment pairing a handful of coding tasks with two SQL problems, one easy and one medium. The staples are joins and the window functions (RANK, DENSE_RANK, ROW_NUMBER), plus grouping and aggregation. Data roles go further into PL/SQL, Oracle and Liquibase-managed schema changes, and often add Python for helper and sorting work. A representative window-function query is small but load-bearing.

SELECT trader_id,
       pnl,
       RANK() OVER (PARTITION BY desk ORDER BY pnl DESC) AS desk_rank
FROM   daily_pnl
WHERE  trade_date = CURRENT_DATE;

Interviewers listen for the difference between RANK, DENSE_RANK and ROW_NUMBER, how each handles ties, and when a partition changes the answer. Be fluent enough to write one under light time pressure and explain why you chose it. For any data-adjacent role, rehearse SQL as hard as Java, because in those loops it carries as much of the signal.

India and the US diverge

Your geography and level are the biggest routing decision, because the two tracks look genuinely different. The India campus and early-career path leads with the sectioned online assessment. A technical interview follows, opening on your projects and moving into Core Java (output-guessing, HashMap internals, threads, Spring beans and scopes) plus OOP, DBMS, and OS. It usually includes one DSA problem and sometimes SQL, and an HR round closes the loop. The US and experienced path mostly skips the campus OA for a recruiter screen and one to three interviews of thirty to forty-five minutes. Expect a STAR-style manager and behavioral round, and technical rounds built on a live, often easy coding task and a deep Java conversation.

In the US, a coding round is not guaranteed at senior levels. One director-level candidate was told to be ready to share an IDE and was never asked to write code. The sessions were pure Java, Spring, SQL, and REST discussion with peer managers, plus an architecture review of their own systems. The higher the level, and the more the role leans quantitative or lead, the more the "coding" round can become a concepts-and-design conversation. Don't assume a live algorithm at senior US level, and do expect to defend any Java claim you make in depth.

The Fidelity angle

Pick your track first, then load the matching prep, because prepping for the wrong one is the most common avoidable miss. India campus or early-career candidates should front-load the OA shape: aptitude and Core-CS multiple choice, then two easy-to-medium coding problems. Pair it with the Core Java bucket and clean project narratives. US or experienced candidates should weight the deep Java and Spring conversation and STAR stories most, keep one easy coding pattern warm, and prepare an architecture walkthrough of a system they built. Both tracks share the Java spine, and data roles share the SQL layer, so those stay on the list.

The lessons in this section

The two lessons that follow go deep where this overview only points. Start with the Java and OA lesson, since the fundamentals bucket is the densest signal for every candidate. Then move to the coding and SQL lesson for algorithm patterns and query work. On a data or ETL track, treat the SQL half of the second lesson as required.

Common questions