cswork / libraryOpen practice workspace

Interview guides · Cresta (CA)

Cresta (CA) Software Engineer Interview Guide

Cresta (CA) Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Cresta, you build real-time Generative AI tools that transform how enterprise contact centers operate. Cresta leverages advanced machine learning, speech recognition, and real-time streaming pipelines to analyze live agent conversations and deliver instant guidance, automation, and analytics. Operating in this space means engineering systems that process high-frequency audio and text streams with millisecond latency while maintaining high reliability for major enterprise clients. Engineers at Cresta work across a diverse set of technical domains. You might build complex rule engines to evaluate feature rollouts across thousands of active users, engineer real-time interval processing pipelines that aggregate active conversation data, or design full-stack interfaces that render dynamic guidance to customer service agents without UI lag.

This guide is scoped to a Software Engineer candidate at Cresta (CA).

Focus areas

  • Feature flag evaluation engine
  • Algorithms: interval merging & deduplication
  • SQL (JOINs)

The Cresta (CA) interview process

Cresta (CA) candidates report 7 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

Online Coding Challenge

Fast-paced challenge combining algorithmic problems with practical domain questions.

What to demonstrate

  • Fast-paced challenge combining algorithmic problems with practical domain questions
  • Depth in Feature flag evaluation engine

How to prepare

  • Answer aloud and timed: Implement a low-latency rate limiter in your language of choice (e.g., token bucket or sliding window counter).
  • Answer aloud and timed: Build a function that fetches data asynchronously from the Wikipedia API and processes the returned data structures efficiently under memory constraints.

Technical Phone Screen

Live coding session testing speed and accuracy with medium-level algorithmic questions.

What to demonstrate

  • Live coding session testing speed and accuracy with medium-level algorithmic questions
  • Depth in Feature flag evaluation engine

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.

Onsite Loop

Consists of 3 to 4 rounds including coding session, system design, project presentation, and hiring manager conversation.

What to demonstrate

  • Consists of 3 to 4 rounds including coding session, system design, project presentation, and hiring manager conversation
  • Depth in Feature flag evaluation engine

How to prepare

  • Answer aloud and timed: Given a flags.json file (defining keys, default states, and multi-condition logical rules), a users.json dataset (10,000 users with attribute maps), and an expected_decisions.json dataset, implement a feature flag evaluation engine that handles ANDed conditions, multi-rule conflicts, and percentage-based rollouts.
  • Answer aloud and timed: Given a grid matrix containing obstacles and distinct puzzle pieces, return which piece can be moved or removed safely without intersecting adjacent boundary values.

Deep-Dive Coding Session

In-depth coding interview focusing on problem-solving and coding syntax.

What to demonstrate

  • In-depth coding interview focusing on problem-solving and coding syntax
  • Depth in Feature flag evaluation engine

How to prepare

  • Answer aloud and timed: Given a list of overlapping conversation time intervals, compute the total occupied conversation duration and identify all non-overlapping gap intervals. Ensure the solution scales efficiently for large datasets.
  • Answer aloud and timed: Implement graph data structures from scratch to represent relationship networks, and write algorithms (e.g., Breadth-First Search or Depth-First Search) to evaluate connectivity and optimal paths.

System Design Interview

Evaluation of system design skills and architectural patterns.

What to demonstrate

  • Evaluation of system design skills and architectural patterns
  • Depth in Feature flag evaluation engine

How to prepare

  • Answer aloud and timed: Transform a flat list representation of hierarchical structures into a deeply nested tree data structure.
  • Answer aloud and timed: Solve dynamic programming and matrix traversal challenges under time-bound constraints.

Project Presentation

Detailed presentation of past projects to an engineering panel.

What to demonstrate

  • Detailed presentation of past projects to an engineering panel
  • Depth in Feature flag evaluation engine

How to prepare

  • Answer aloud and timed: Write SQL queries utilizing multi-table JOIN operations, window functions, and aggregations to analyze user interaction logs.
  • Answer aloud and timed: Parse, de-duplicate, sort, and merge high-throughput interval logs efficiently without exceeding operational memory limits.

Hiring Manager Conversation

Discussion with the hiring manager regarding fit and expectations.

What to demonstrate

  • Discussion with the hiring manager regarding fit and expectations
  • Depth in Feature flag evaluation engine

How to prepare

  • Prepare two projects you led end to end, each with the decision you owned and what it cost.
  • Have three questions about the team's roadmap and how success is measured in the first six months.

Where candidates lose points

Prioritize Clean Code Structure

In practical coding rounds, organize your solution into clear modular functions. Avoid placing all evaluation logic in a single monolith function block.

Validate Edge Cases Proactively

Always test your logic against potential edge cases—such as missing fields, null values, circular dependencies, or overlapping ranges—before declaring your solution complete.

Practice Language Primitives

Ensure you can build standard data structures (trees, graphs, interval lists, min-heaps) manually without depending entirely on external utility libraries.

Questions & practice

Build a function that fetches data asynchronously from the Wikipedia API and processes the returned data struc

Medium · Practical Engineering & Systems Programm

Build a function that fetches data asynchronously from the Wikipedia API and processes the returned data structures efficiently under memory constraints.

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Given a list of overlapping conversation time intervals, compute the total occupied conversation duration and

Medium · Algorithms & Data Structures

Given a list of overlapping conversation time intervals, compute the total occupied conversation duration and identify all non-overlapping gap intervals. Ensure the solution scales efficiently for large datasets.

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Implement graph data structures from scratch to represent relationship networks, and write algorithms (e.g., B

Medium · Algorithms & Data Structures

Implement graph data structures from scratch to represent relationship networks, and write algorithms (e.g., Breadth-First Search or Depth-First Search) to evaluate connectivity and optimal paths.

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Transform a flat list representation of hierarchical structures into a deeply nested tree data structure.

Medium · Algorithms & Data Structures

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Solve dynamic programming and matrix traversal challenges under time-bound constraints.

Medium · Algorithms & Data Structures

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Construct an autocomplete search engine given an input query string and a dictionary of words.

Medium · Practical Engineering & Systems Programm

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?

Write SQL queries utilizing multi-table JOIN operations, window functions, and aggregations to analyze user

Medium · Data Engineering & SQL

Write SQL queries utilizing multi-table JOIN operations, window functions, and aggregations to analyze user interaction logs.

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?

Implement a low-latency rate limiter in your language of choice (e.g., token bucket or sliding window counter)

Medium · Practical Engineering & Systems Programm

Implement a low-latency rate limiter in your language of choice (e.g., token bucket or sliding window counter).

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?

Reimplement a high-throughput Node API endpoint handling dynamic payloads while maintaining clean middleware a

Medium · Practical Engineering & Systems Programm

Reimplement a high-throughput Node API endpoint handling dynamic payloads while maintaining clean middleware abstractions.

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?

Given a grid matrix containing obstacles and distinct puzzle pieces, return which piece can be moved or remove

Medium · Practical Logic & Rule Engines

Given a grid matrix containing obstacles and distinct puzzle pieces, return which piece can be moved or removed safely without intersecting adjacent boundary values.

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?

Parse, de-duplicate, sort, and merge high-throughput interval logs efficiently without exceeding operational m

Medium · Data Engineering & SQL

Parse, de-duplicate, sort, and merge high-throughput interval logs efficiently without exceeding operational memory limits.

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?

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 Cresta (CA) candidates report.

Day 1 — Map the Cresta (CA) loop

  • Write out the reported sequence: Online Coding Challenge, Technical Phone Screen, Onsite Loop, Deep-Dive Coding Session, System Design Interview, Project 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 7 reported rounds, with the weakest marked.

Day 2 — Work Feature flag evaluation engine

  • Spend the session on Feature flag evaluation engine, which Cresta (CA) candidates report being tested on.
  • Write one worked example in Feature flag evaluation engine and time yourself on it.

Deliverable: One timed worked example in Feature flag evaluation engine.

Day 3 — Work Algorithms: interval merging & deduplication

  • Spend the session on Algorithms: interval merging & deduplication, which Cresta (CA) candidates report being tested on.
  • Write one worked example in Algorithms: interval merging & deduplication and time yourself on it.

Deliverable: One timed worked example in Algorithms: interval merging & deduplication.

Day 4 — Work SQL (JOINs)

  • Spend the session on SQL (JOINs), which Cresta (CA) candidates report being tested on.
  • Write one worked example in SQL (JOINs) and time yourself on it.

Deliverable: One timed worked example in SQL (JOINs).

Day 5 — Answer out loud: Practical Engineering & Systems Programming

  • Answer aloud, timed: Implement a low-latency rate limiter in your language of choice (e.g., token bucket or sliding window counter).
  • Answer aloud, timed: Build a function that fetches data asynchronously from the Wikipedia API and processes the returned data structures efficiently under memory constraints.

Deliverable: Spoken answers to 2 reported Practical Engineering & Systems Programming question(s), under time.

Day 6 — Answer out loud: Practical Logic & Rule Engines

  • Answer aloud, timed: Given a flags.json file (defining keys, default states, and multi-condition logical rules), a users.json dataset (10,000 users with attribute maps), and an expected_decisions.json dataset, implement a feature flag evaluation engine that handles ANDed conditions, multi-rule conflicts, and percentage-based rollouts.
  • Answer aloud, timed: Given a grid matrix containing obstacles and distinct puzzle pieces, return which piece can be moved or removed safely without intersecting adjacent boundary values.

Deliverable: Spoken answers to 2 reported Practical Logic & Rule Engines question(s), under time.

Day 7 — Answer out loud: Algorithms & Data Structures

  • Answer aloud, timed: Given a list of overlapping conversation time intervals, compute the total occupied conversation duration and identify all non-overlapping gap intervals. Ensure the solution scales efficiently for large datasets.
  • Answer aloud, timed: Implement graph data structures from scratch to represent relationship networks, and write algorithms (e.g., Breadth-First Search or Depth-First Search) to evaluate connectivity and optimal paths.

Deliverable: Spoken answers to 2 reported Algorithms & Data Structures question(s), under time.

Behavioural preparation

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

Given a flags.json file (defining keys, default states, and multi-condition logical rules), a users.json d

Medium · Practical Logic & Rule Engines

Given a flags.json file (defining keys, default states, and multi-condition logical rules), a users.json dataset (10,000 users with attribute maps), and an expected_decisions.json dataset, implement a feature flag evaluation engine that handles ANDed conditions, multi-rule conflicts, and percentage-based rollouts.

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?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

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?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

  1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
  2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
  3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
  4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

  • How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
  • Their handler calls an external endpoint before recording that it did. What do you tell them to change first?