Nasdaq · Software Engineer
Updated · 2026-10-02

Nasdaq Software Engineer
Interview Guide

THE 60-SECOND BRIEF

A Software Engineer at Nasdaq works at the intersection of high-performance technology, financial market infrastructure, and global scale. Nasdaq is far more than a stock exchange; it is a global technology powerhouse providing trading, clearing, exchange technology, regulatory oversight, and data analytics solutions to capital markets worldwide. Engineers in this role build, optimize, and maintain low-latency backend systems, mission-critical market platforms (such as the Nasdaq Eqlipse Trading platform or Listings Platform), and full-stack enterprise applications that process billions of financial transactions every single day. In this position, your work directly affects the speed, reliability, and security of global financial infrastructure. System failure or high latency in market technology can lead to multi-million-dollar losses or regulatory non-compliance.

This guide is scoped to a Software Engineer candidate at Nasdaq.

Nasdaq candidates report 4 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Data Structures & Algorithms (DSA)Coding AssessmentsSystem Design

26 min read

Browse Software Engineer questions

See the practice prompts

11Practice promptsAcross five skill areas

A Software Engineer at Nasdaq works at the intersection of high-performance technology, financial market infrastructure, and global scale. Nasdaq is far more than a stock exchange; it is a global technology powerhouse providing trading, clearing, exchange technology, regulatory oversight, and data analytics solutions to capital markets worldwide. Engineers in this role build, optimize, and maintain low-latency backend systems, mission-critical market platforms (such as the Nasdaq Eqlipse Trading platform or Listings Platform), and full-stack enterprise applications that process billions of financial transactions every single day. In this position, your work directly affects the speed, reliability, and security of global financial infrastructure. System failure or high latency in market technology can lead to multi-million-dollar losses or regulatory non-compliance. Consequently, Nasdaq software engineering teams place a heavy emphasis on core computer science fundamentals, resilient system design, concurrent programming, memory management, and robust test-driven development. You will collaborate closely with product managers, system architects, and platform operations teams to design architectures that maintain near-zero downtime while operating under severe throughput demands.

01

Recruiter Screening

reported

Initial contact with HR to evaluate your background and fit for the role.

What to demonstrate

  • Initial contact with HR to evaluate your background and fit for the role
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Nasdaq Software Engineer candidate reports ↗
02

Online Technical Assessment

reported

A coding assessment to evaluate your practical coding skills.

What to demonstrate

  • A coding assessment to evaluate your practical coding skills
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work Coding Assessments until you can explain it without notes
Nasdaq Software Engineer candidate reports ↗
03

Technical Interviews

reported

A series of interviews focusing on hands-on coding and system design.

What to demonstrate

  • A series of interviews focusing on hands-on coding and system design
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work Coding Assessments until you can explain it without notes
Nasdaq Software Engineer candidate reports ↗
04

Managerial Interviews

reported

Interviews that assess your behavioral alignment and managerial fit.

What to demonstrate

  • Interviews that assess your behavioral alignment and managerial fit
  • Depth in Data Structures & Algorithms (DSA)

How to prepare

  • Work Data Structures & Algorithms (DSA) until you can explain it without notes
  • Work Coding Assessments until you can explain it without notes
Nasdaq Software Engineer candidate reports ↗

PracHub editorial advice for the preparation topics above.

01

Master Core Mechanics, Not Just Syntax

Be ready to explain how execution engines handle memory allocation, garbage collection, and thread synchronization. Avoid superficial answers when discussing concepts like HashMap internal operations or interface inheritance.

02

Practice Test-Driven Development (TDD)

Given that Nasdaq technical rounds frequently feature TDD assessments where you write code to make unit tests pass, practice running test suites locally and debugging failure assertions systematically.

03

Prepare Practical Frontend/Backend Projects

If applying for full-stack or UI-oriented engineering roles, refresh your hands-on knowledge of Vue.js or React. Practice building small applications under live timed conditions.

04

Structure Your Communication During Live Coding

When solving algorithmic or matrix challenges on shared screens or CoderPad, continuously communicate your thought process. Explain your chosen data structures, trade-offs, and time complexities before typing code.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

8 technical prompts0 include a worked solution

Canonicalise a request body into a stable idempotency fingerprint

medium
parsingcanonicalisationhashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach
  1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
  2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
  3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
  4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
  • A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
  • Where does the fingerprint get computed relative to request decompression and the body-size limit?

Collapse a redelivered event batch into per-aggregate high-water marks

easy
hashingat-least-onceaggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach
  1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
  2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
  3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
  4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.
Follow-up
  • The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
  • How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Archive a resource graph without breaking live references or recursing

medium
graph traversaltopological ordertenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach
  1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
  2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
  3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
  4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.
Follow-up
  • The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
  • The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Built from the rounds and topics Nasdaq candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Nasdaq loop
  • Write out the reported sequence: Recruiter Screening, Online Technical Assessment, Technical Interviews, Managerial Interviews.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 4 reported rounds, with the weakest marked.

02Work Data Structures & Algorithms (DSA)
  • Spend the session on Data Structures & Algorithms (DSA), which Nasdaq candidates report being tested on.
  • Write one worked example in Data Structures & Algorithms (DSA) and time yourself on it.

Deliverable: One timed worked example in Data Structures & Algorithms (DSA).

03Work Coding Assessments
  • Spend the session on Coding Assessments, which Nasdaq candidates report being tested on.
  • Write one worked example in Coding Assessments and time yourself on it.

Deliverable: One timed worked example in Coding Assessments.

04Work System Design
  • Spend the session on System Design, which Nasdaq candidates report being tested on.
  • Write one worked example in System Design and time yourself on it.

Deliverable: One timed worked example in System Design.

05Consolidate
  • Re-work the problem you got wrong earliest in the week, from scratch, without looking at your previous attempt.

Deliverable: A second, cleaner solution to the problem you got wrong first.

06Rehearse your own examples
  • Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

07Dry run for Nasdaq
  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural rounds judge the decision you made and what it cost.

Ship under a deadline and bound the debt you chose

medium
paginationtechnical debttradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach
  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.
Follow-up
  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?

Turn a code review disagreement into a decision

easy
code reviewoptimistic concurrencycommunication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach
  1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
  2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
  3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
  4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.
Follow-up
  • Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
  • The author says clients cannot handle a 409. How do you check whether that is true?

Tell callers you do not own that their integration breaks

medium
deprecationcompatibilitystakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach
  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
  • 01

    You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

  • 02

    A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

  • 03

    A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

PracHub preparation framework ↗
How difficult is the technical coding portion of the interview?

The difficulty ranges from average to challenging. You will encounter standard LeetCode medium algorithmic challenges alongside practical engineering tests, such as implementing functions to pass pre-written unit tests or building frontend apps.

Nasdaq Software Engineer candidate reports ↗
Does Nasdaq expect candidates to have prior financial or stock market knowledge?

No, prior financial market domain experience is generally not mandatory unless specified for senior specialized roles. Nasdaq values strong computer science fundamentals, coding proficiency, and problem-solving skills above pre-existing finance industry experience.

Nasdaq Software Engineer candidate reports ↗
What is the primary tech stack used at Nasdaq?

While tech stacks vary by product team, Nasdaq relies heavily on Java, C# /.NET, C++ (for ultra-low-latency engines), JavaScript/TypeScript (Vue.js and React), SQL databases, and cloud infrastructure (AWS).

Nasdaq Software Engineer candidate reports ↗
What is the typical timeframe from the initial application to receiving an offer?

The hiring timeline typically spans 2 to 4 weeks. However, candidate experiences report that scheduling panel rounds across global time zones can occasionally extend the process over several weeks.

Nasdaq Software Engineer candidate reports ↗
Are remote or hybrid working arrangements supported for Software Engineers?

Yes, most Nasdaq technology hubs operate on hybrid working models (typically 2 to 3 days per week in-office), though exact expectations depend on the specific team and regional office guidelines.

Nasdaq Software Engineer candidate reports ↗
What topics does Nasdaq test in interviews?

Nasdaq interviews most often cover Behavioral Interviewing, SQL, Python, Communication Skills, and Problem Solving. The exact emphasis depends on the specific role you apply for.

Nasdaq Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.