cswork / libraryOpen practice workspace

Interview guides · CXApp US

CXApp US Software Engineer Interview Guide

CXApp US Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

At CXApp US, a Software Engineer plays a pivotal role in shaping the future of workplace experience technology. The company specializes in delivering a comprehensive, cloud-native employee app platform that integrates indoor mapping, desk booking, amenities, and real-time IoT communications. As a software engineer, you will work on scaling this high-density mobile-first platform, ensuring that thousands of concurrent enterprise users experience seamless, low-latency interactions daily. This position sits at the intersection of high-scale cloud architecture and real-time physical-to-digital integrations. Depending on your team alignment—whether you lean toward the Software Architect track or the Microservices Development Engineer track—your work will directly influence how enterprise clients manage their physical campuses.

This guide is scoped to a Software Engineer candidate at CXApp US.

Focus areas

  • Microservices Architecture
  • Take-Home Assignment Development
  • Problem Solving

The CXApp US interview process

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

Initial Screening

The process begins with an initial screening to assess candidate qualifications.

What to demonstrate

  • The process begins with an initial screening to assess candidate qualifications
  • Depth in Microservices Architecture

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.

Take-Home Challenge

Candidates complete a practical take-home challenge to demonstrate their engineering capabilities.

What to demonstrate

  • Candidates complete a practical take-home challenge to demonstrate their engineering capabilities
  • Depth in Microservices Architecture

How to prepare

  • Answer aloud and timed: Describe a scenario where you had to choose between synchronous REST communication and asynchronous message queues. What were the trade-offs?
  • Answer aloud and timed: How would you design a rate-limiting mechanism for an API gateway servicing millions of requests daily?

Technical Presentation

Candidates present their work to the engineering team, simulating a real-world design review.

What to demonstrate

  • Candidates present their work to the engineering team, simulating a real-world design review
  • Depth in Microservices Architecture

How to prepare

  • Answer aloud and timed: Why did you choose this specific database schema for your take-home assignment, and how does it scale?
  • Answer aloud and timed: If you had another week to work on this challenge, what architectural changes or optimizations would you introduce?

Where candidates lose points

Prioritize Readability and Structure

When writing your take-home assignment, treat it as if you are shipping code to production. Use clear naming conventions, keep functions small, and follow the standard style guides for your chosen programming language.

Document Your Trade-offs

In your take-home README, explicitly state the assumptions you made and the trade-offs you chose. For example, explain why you chose a relational database over a document store, or why you opted for a specific library. This shows mature engineering judgment.

Be prepared to discuss the scalability of your take-home solution

Interviewers will push your design to its limits to see how you think about scale.

Brush Up on Microservices Patterns

Since CXApp US relies heavily on microservices, be ready to discuss patterns like API Gateways, Service Discovery, Circuit Breakers, and Event-Driven Architecture. Knowing when not to use these patterns is just as important as knowing when to use them.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

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?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

  1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
  2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
  3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
  4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

  • The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
  • Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

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

Easy · hashing · at-least-once · aggregation

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?

What strategies do you use to ensure data consistency between a relational database and a search index or cach

Medium · Microservices & System Architecture

What strategies do you use to ensure data consistency between a relational database and a search index or cache?

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Why did you choose this specific database schema for your take-home assignment, and how does it scale?

Medium · Take-Home Challenge & Design Defense

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

How do you handle distributed transactions across multiple microservices without compromising system performan

Medium · Microservices & System Architecture

How do you handle distributed transactions across multiple microservices without compromising system performance?

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Describe a scenario where you had to choose between synchronous REST communication and asynchronous message qu

Medium · Microservices & System Architecture

Describe a scenario where you had to choose between synchronous REST communication and asynchronous message queues. What were the trade-offs?

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

How would you design a rate-limiting mechanism for an API gateway servicing millions of requests daily?

Medium · Microservices & System Architecture

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

If you had another week to work on this challenge, what architectural changes or optimizations would you intro

Medium · Take-Home Challenge & Design Defense

If you had another week to work on this challenge, what architectural changes or optimizations would you introduce?

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

How would you modify your take-home solution to support real-time data streaming or push notifications?

Medium · Take-Home Challenge & Design Defense

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Walk us through your testing strategy for this assignment. How did you ensure edge cases were covered?

Medium · Take-Home Challenge & Design Defense

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

  1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
  2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
  3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
  4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

  • Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
  • How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Built from the rounds and topics CXApp US candidates report.

Day 1 — Map the CXApp US loop

  • Write out the reported sequence: Initial Screening, Take-Home Challenge, Technical Presentation.
  • 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 3 reported rounds, with the weakest marked.

Day 2 — Work Microservices Architecture

  • Spend the session on Microservices Architecture, which CXApp US candidates report being tested on.
  • Write one worked example in Microservices Architecture and time yourself on it.

Deliverable: One timed worked example in Microservices Architecture.

Day 3 — Work Take-Home Assignment Development

  • Spend the session on Take-Home Assignment Development, which CXApp US candidates report being tested on.
  • Write one worked example in Take-Home Assignment Development and time yourself on it.

Deliverable: One timed worked example in Take-Home Assignment Development.

Day 4 — Work Problem Solving

  • Spend the session on Problem Solving, which CXApp US candidates report being tested on.
  • Write one worked example in Problem Solving and time yourself on it.

Deliverable: One timed worked example in Problem Solving.

Day 5 — Answer out loud: Microservices & System Architecture

  • Answer aloud, timed: How do you handle distributed transactions across multiple microservices without compromising system performance?
  • Answer aloud, timed: What strategies do you use to ensure data consistency between a relational database and a search index or cache?

Deliverable: Spoken answers to 2 reported Microservices & System Architecture question(s), under time.

Day 6 — Answer out loud: Take-Home Challenge & Design Defense

  • Answer aloud, timed: Why did you choose this specific database schema for your take-home assignment, and how does it scale?
  • Answer aloud, timed: If you had another week to work on this challenge, what architectural changes or optimizations would you introduce?

Deliverable: Spoken answers to 2 reported Take-Home Challenge & Design Defense question(s), under time.

Day 7 — Answer out loud: Behavioral & Team Collaboration

  • Answer aloud, timed: Describe a time when you disagreed with an architectural decision made by a team lead. How did you resolve the conflict?
  • Answer aloud, timed: How do you prioritize refactoring legacy code or addressing technical debt when faced with tight product deadlines?

Deliverable: Spoken answers to 2 reported Behavioral & Team Collaboration question(s), under time.

Behavioural preparation

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

Describe a time when you disagreed with an architectural decision made by a team lead. How did you resolve the

Medium · Behavioral & Team Collaboration

Describe a time when you disagreed with an architectural decision made by a team lead. How did you resolve the conflict?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

How do you prioritize refactoring legacy code or addressing technical debt when faced with tight product deadl

Medium · Behavioral & Team Collaboration

How do you prioritize refactoring legacy code or addressing technical debt when faced with tight product deadlines?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Tell me about a complex technical problem you solved recently. How did you explain the solution to non-technic

Medium · Behavioral & Team Collaboration

Tell me about a complex technical problem you solved recently. How did you explain the solution to non-technical stakeholders?

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?