Ceribell Software Engineer Interview Guide

The 60-second brief

Ceribell makes point-of-care EEG for seizure monitoring, a product clinicians use when treating patients in critical care. Candidates describe the Software Engineer role as backend-focused: designing and building backend services, working on data-processing pipelines, and collaborating with product and engineering teams. They also mention working with data engineering or supply chain teams where hardware and software workflows meet, and taking part in architectural reviews where you explain and defend design choices.

This guide is for engineers preparing for Ceribell's Software Engineer loop. It covers the three reported rounds (Recruiter Screen, Technical Deep-Dive, Leadership Review), the reported technical questions on object-oriented design, concurrency and system design, and the reported behavioral questions on trade-offs, disagreement, technical debt, mentoring and business problems.

Candidates report three stages over roughly 3-5 weeks: a Recruiter Screen, a Technical Deep-Dive with engineering peers, and a Leadership Review. Reports also mention a mix of virtual and onsite conversations.

Focus areas

• System Design
• SOLID Principles
• Scalability

Overview

The work candidates describe is backend engineering for a medical device company: services that handle many concurrent requests, and pipelines that move device data reliably. The topics reported for this loop follow from that. They include SOLID principles, design patterns, concurrency models, load balancing, database sharding and partitioning, caching layers, refactoring legacy code, dependency decoupling, and unit, integration and end-to-end testing. Prepare to reason about these as engineering decisions with costs, not as vocabulary lists.

The fifteen reported questions are conceptual rather than puzzle-style. Five concern foundations (SOLID, choosing design patterns, testable and modular code, data structures under concurrency, debugging multi-threaded programs). Five concern system design (handling 10k threads at low latency, load balancing and horizontal scaling, fault tolerance, monolith-to-microservices, consistency across services). Five are behavioral. The requirements candidates describe name a modern backend language, with Java, Python or Go as examples, so choose one and be ready to show how its threading or async model, locking primitives and test tooling actually work. Reports also mention coding assessments in the process, so keep that language fluent enough to write code live.

Candidates also report two practical points. First, your resume works as the roadmap for the technical conversations, so every technology you list needs a reason it was chosen, an alternative you rejected and a result you can state with a number. Second, reported example scenarios include designing a real-time ingestion pipeline for EEG devices, handling a sudden traffic spike that threatens stability, and refactoring a module toward better SOLID compliance. Practise those as whiteboard exercises: state requirements, sketch components, name the failure modes, then give a phased plan.

The Ceribell interview process

Candidates report three stages over about 3-5 weeks. The reports do not say which questions belong to which stage, so each description below says what is reported about the stage and then how to prepare for the question types it is likely to cover.

Recruiter Screen

Candidates describe the Recruiter Screen as an initial conversation about fit for the role and an outline of how the rest of the process runs. Reports mention virtual screens combined with an onsite component later, and a total timeline of roughly 3-5 weeks that can stretch when leadership schedules are involved. Treat this stage as a place to get the loop in writing and to show you understand what the company makes: point-of-care EEG for seizure monitoring.

What to demonstrate

• Fit for a backend Software Engineer role, as the stage is described
• Awareness of the process ahead and your availability for it
• Whether your resume holds up as a summary of your experience

How to prepare

• Write a short walkthrough of your resume where each technology has a one-line reason you chose it; reports say the resume guides later technical conversations
• Prepare a specific sentence on why a point-of-care EEG product interests you, based on what the product does rather than slogans
• Name your strongest backend language (Java, Python and Go are the examples candidates cite) and one project where you used it for concurrent or distributed work
• Ask the recruiter which stages are virtual, which are onsite, and when a presentation-style scenario, if any, will happen

Technical Deep-Dive

Candidates describe the Technical Deep-Dive as in-depth technical discussion with engineering peers. The reported topic list for the loop covers SOLID and design patterns, testable and modular code, data structures and debugging under concurrency, and system design: 10k threads at low latency, load balancing, fault tolerance, monolith-to-microservices and consistency across services. Reported example scenarios include a real-time ingestion pipeline for EEG devices and a traffic spike that threatens stability. Approach it as a design conversation where every claim comes with a trade-off.

What to demonstrate

• Depth in object-oriented design, SOLID and design pattern choice
• Reasoning about concurrency, scaling and failure in distributed systems
• Code quality habits: refactoring, dependency decoupling and layered testing
• Ability to explain technical decisions and the alternatives you rejected

How to prepare

• Take one module from your own code and write a refactor that applies dependency inversion, then explain how it makes testing easier
• Build a one-page comparison of shared-state options under high concurrency: lock-guarded structures, concurrent collections, immutable snapshots and message passing
• Sketch the EEG ingestion scenario end to end: device connection, buffering, backpressure, storage, caching and what happens on duplicate or late data
• Rehearse the 10k-threads question by contrasting thread-per-request with event-driven or bounded worker pools, and say what you would measure

Leadership Review

Candidates describe the Leadership Review as the final discussion with leadership about fit with the team and culture. Reported behavioral questions cover justifying a trade-off to a non-technical stakeholder, handling technical disagreement, balancing speed against technical debt, mentoring junior engineers, and acting on a business problem. Reports also mention scenario-based presentations later in the process, where you break a business problem into bottlenecks and a phased plan. Prepare stories with real decisions and numbers.

What to demonstrate

• Fit with the team and its way of working, as the stage is described
• Communication of technical trade-offs to a non-technical audience
• Leadership behaviours reported for this loop: influencing, mentoring and handling ambiguity

How to prepare

• Write five story outlines, one per reported behavioral question, with situation, your decision, the alternatives and a measured result
• Build a short phased-plan presentation from a real project: the problem in business terms, the technical bottleneck, phase one, phase two, risks
• Prepare a version of your trade-off story that uses no jargon, then check that a non-engineer could repeat it back
• Prepare questions about the team's current technical challenges; candidates report that closing questions are an opening to show how you think

Where candidates lose points

Reciting what SOLID stands for without showing it in code

For each letter, bring one example from your own code: the violation, the refactor and what it did for testing. Be ready to say when applying a principle would over-engineer a small module.

Answering the 10k threads question with 'add more threads or servers'

Discuss the cost of a thread (stack memory, context switching), then contrast thread-per-request with event-driven handling or bounded worker pools. Add queue limits, backpressure and the latency percentile you would measure.

Presenting microservices as simply better than a monolith

Start from the reasons to split (independent scaling, team boundaries) and the cost (network failure, distributed transactions, operational overhead). Describe an incremental migration with data ownership per service.

Designing the EEG ingestion scenario like an ordinary CRUD service

Ask about delivery guarantees, ordering and tolerance for loss first. Cover buffering, idempotent writes for duplicates, late data, and what the system does when storage is slow.

Giving behavioral answers with 'we', no numbers and no decision of your own

Use first person for your actions, state the alternatives you weighed and give before-and-after measures. Rehearse each story until you can name its trade-off in one sentence.

Questions & practice

What are the trade-offs between different data structures in a high-concurrency environment?

Medium · Technical Foundations and OOPS

Approach

1. Lay out the options and their costs. One coarse lock around a plain structure is simple and correct but serialises every caller. Fine-grained locking or lock striping is what Java's ConcurrentHashMap does: non-blocking reads, and writes that use CAS or lock a single bin. Copy-on-write gives lock-free reads, but every write copies the whole array (O(n)), so it suits read-mostly data such as listener lists.
2. For producer/consumer, compare queues. ArrayBlockingQueue uses one lock. LinkedBlockingQueue has separate put and take locks, so producers and consumers contend less. A bounded queue gives you backpressure, while an unbounded one hides overload until memory runs out. Lock-free CAS queues never block but spin under heavy contention.
3. Point out that a thread-safe structure does not make compound operations atomic. Check-then-act on a concurrent map still races, so use putIfAbsent, computeIfAbsent or merge. ConcurrentHashMap iterators are weakly consistent, and size() is only an estimate while writers are active.
4. Name contention hot spots. Use LongAdder instead of AtomicLong for a heavily updated counter: it spreads updates across cells, and sum() is not an atomic snapshot. Watch for false sharing when hot fields share a cache line.
5. Cover your language. Python's GIL does not make compound operations such as d[k] += 1 atomic. In Go, use a mutex-guarded map in general. sync.Map is built for keys that are written once and read many times, or for goroutines that work on disjoint key sets. Immutable snapshots that you swap behind a single reference often beat locking.

Follow-up

• How would you build a thread-safe LRU cache, and where does contention concentrate?
• What is the ABA problem in lock-free structures, and how is it avoided?
• Why might a read-heavy workload prefer copy-on-write over a lock-striped map, and when does that reverse?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant 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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you apply SOLID principles to ensure long-term code maintainability?

Medium · Technical Foundations and OOPS

Approach

1. Give each principle as a concrete code move. SRP: a class has one reason to change, so split a class that both parses and persists. OCP: add behaviour through a new implementation of an interface, not another branch in a switch. LSP: a subtype honours the base contract. ISP: small role interfaces. DIP: policy code depends on abstractions, and concrete adapters are wired at the composition root.
2. Anchor the answer on one before/after from your own code. Example: an export service with an if/elif on format becomes an Exporter interface with one class per format. Adding a format then touches no existing class, and each exporter gets its own unit test.
3. State the trade-off. Applied everywhere, SOLID produces an interface for every class and indirection nobody needs. Apply OCP and DIP at seams that really vary (I/O, vendors, formats, anything tests must substitute), and keep the rest concrete until a second variant appears.
4. Name the smells that show a violation: isinstance or type checks on a base reference, or overrides that throw NotImplementedError (both LSP). Others are god classes with many unrelated collaborators (SRP) and constructors that new up their own database clients (DIP).
5. Say how you would measure the gain: fewer files touched per change, smaller diffs, unit tests that run without a network or database, and fewer merge conflicts in hot files.

Follow-up

• Give an example of a Liskov violation and show how you would restructure it.
• When has splitting classes for single responsibility made code harder to follow?
• How is the dependency inversion principle different from using a dependency injection framework?

Can you explain how you select specific design patterns to solve common architectural challenges?

Medium · Technical Foundations and OOPS

Approach

1. Start from the pressure, not the pattern name. A varying algorithm points to Strategy. Creation that depends on config or type points to Factory Method or Abstract Factory. An incompatible third-party API needs an Adapter. Cross-cutting behaviour such as retry, caching or logging without editing the class fits Decorator. One state change that many parties need is Observer or pub/sub, and queued or undoable operations are Command.
2. At the architecture level, name the equivalents. Repository isolates persistence, and Circuit Breaker guards remote calls. Publish/subscribe decouples producers from consumers, and CQRS fits when read and write models diverge sharply.
3. Give your decision criteria: how many variants exist today (rule of three), whether the variation happens at runtime or build time, and what the extra indirection costs readers. Prefer composition over inheritance. In Python or Go, a passed-in function often replaces a full Strategy class hierarchy.
4. Bring two stories: one where a pattern removed duplication or coupling, and one where you removed a pattern. A classic case of removal is a Singleton that hid global state, broke test isolation and needed locking for lazy initialisation under threads. You replaced it with an instance injected at startup.

Follow-up

• When would you choose Decorator over subclassing, and what does it cost?
• Why is Singleton often treated as an anti-pattern, and when is it acceptable?
• How do you tell that a pattern in the codebase no longer earns its complexity?

How do you ensure your code remains testable and modular as the system scales?

Medium · Technical Foundations and OOPS

Approach

1. Separate pure domain logic from I/O, as in ports-and-adapters or a functional core with an imperative shell. Most business rules can then be unit-tested with plain inputs and outputs, with no database or network.
2. Make dependencies explicit through constructor injection. Remove hidden globals and module-level clients, and inject a clock and a random source so time-dependent and randomised code runs deterministically in tests.
3. Describe the test pyramid you keep: many fast unit tests and fewer integration tests against real dependencies (for example a containerised database). Add contract tests between services so interface drift fails CI, and keep end-to-end tests few because they are slow and flaky.
4. Enforce module boundaries. Each package exposes a small public interface, dependencies point one way with no cycles, and an import-rule check in CI (for example import-linter or ArchUnit) blocks violations. Packaging by feature rather than by layer keeps related changes in one place.
5. Say which signals you watch: suite runtime, flaky-test rate and coverage of changed lines rather than a global percentage. Mock only at boundaries you own, because heavy mocking ties tests to implementation details and makes refactoring painful.

Follow-up

• How do you test code that depends on the current time or on a third-party API?
• How would you get a legacy module with no seams under test before refactoring it?
• When is a mock the wrong tool, and what do you use instead?

How would you design a system to handle 10k threads while maintaining low latency?

Medium · System Design and Architecture

Approach

1. Clarify first. Is this 10k concurrent connections or requests, or literally 10k OS threads? Ask for the latency target (p99, not the average) and whether the work is I/O-bound or CPU-bound. This is the classic C10K problem, and the answer depends on that mix.
2. Explain why 10k OS threads is costly. Each one reserves its own stack (Java's default is about 1 MB on 64-bit Linux), and the scheduler and context switches add overhead that shows up in tail latency. The alternatives are non-blocking I/O on epoll or kqueue with a few event-loop threads, or lightweight threads (Go goroutines, Java 21 virtual threads) multiplexed onto a small carrier pool.
3. Size the pools deliberately. Give CPU-bound work a bounded pool of roughly one thread per core. Size I/O concurrency with Little's law (in-flight requests = throughput x latency). Keep separate pools as bulkheads so one slow dependency cannot starve the others.
4. Add backpressure and admission control. Use bounded queues, shed load with 429 or 503 instead of queueing without limit, and put timeouts on every downstream call. Remember that the database cannot take 10k connections, so go through a connection pool or a pooler and accept that the pool caps real concurrency.
5. Say what you would measure and load-test: p50 and p99 latency, queue depth, context-switch rate, GC pauses and lock wait time. Keep shared locks off the hot path, because one contended lock removes the benefit of any threading model.

Follow-up

• What changes if each request does 50 ms of CPU work instead of waiting on I/O?
• With virtual threads and a database pool of 50 connections, where do requests wait, and how do you bound that wait?
• How would you degrade gracefully when traffic reaches twice the planned peak?

What strategies do you employ for load balancing and horizontal scaling?

Medium · System Design and Architecture

Approach

1. Separate the layers. DNS or global routing sends clients to a region. An L4 balancer forwards TCP connections cheaply. An L7 balancer understands HTTP, so it can route by path or header, terminate TLS and retry. Say which layer solves which problem.
2. Compare algorithms. Round robin and weighted round robin are simple. Least connections or least outstanding requests handles uneven request costs better. Power-of-two random choices gets most of that benefit with little coordination. Consistent hashing gives cache or shard affinity: adding or removing a node remaps only about 1/n of the keys.
3. State the prerequisite for horizontal scaling: a stateless app tier. Keep sessions in a shared store or in signed tokens. Use sticky sessions only as a last resort, because they skew load and lose state when a node dies.
4. Cover operations. Use active and passive health checks, drain connections during deploys, and autoscale on a signal that tracks load (requests per instance, queue depth or CPU) with cooldowns to avoid flapping. The balancer itself must be redundant.
5. Scale the stateful tier differently: read replicas for read-heavy traffic, partitioning or sharding by a key that spreads writes evenly, and caching in front of hot reads. Watch for retry amplification at the balancer, and use retry budgets so retries cannot multiply an overload.

Follow-up

• Once the app tier scales out, how do you scale the database behind it?
• A node returns errors very quickly. Why might least-connections send it more traffic, and how do you stop that?
• What happens to in-flight requests and long-lived connections during a rolling deploy?

How do you design for fault tolerance in a distributed system?

Medium · System Design and Architecture

Approach

1. Start from a failure model and a target. List the failures you design for (process crash, node or zone loss, network partition, slow dependency, bad deploy), then agree the availability goal and the recovery point and time objectives (RPO, RTO).
2. Remove single points of failure. Run replicas across zones. Use consensus (Raft via etcd, or ZooKeeper) for leader election and coordination. For replicated data, use quorum reads and writes where W + R > N so that every read overlaps the latest write.
3. Handle partial failure on every remote call: timeouts, retries with exponential backoff and jitter only for idempotent operations (use idempotency keys), circuit breakers that fail fast, bulkheads, and a degraded fallback response.
4. Make async work durable. Use at-least-once queues with idempotent consumers and dead-letter queues for poison messages. For device-ingestion examples, buffer locally on the producer and send sequence numbers so the server can deduplicate and detect gaps after an outage.
5. Explain how you prove it works: health checks wired to automatic failover, fault-injection or chaos tests, and failover drills. Also name the CAP trade-off: during a partition, each operation must choose between staying consistent and staying available.

Follow-up

• How do you make a retried write safe when the client cannot tell whether the first attempt succeeded?
• What does your system do during a network partition between two zones, and who is allowed to accept writes?
• How would you test that failover actually works before a real outage forces it?

What are the considerations when moving from a monolithic architecture to microservices?

Medium · System Design and Architecture

Approach

1. Ask why before how. Good reasons are independent deploys, team ownership, and parts with very different scaling or reliability needs. If the real pain is tangled code, a modular monolith with enforced boundaries may fix it at a fraction of the cost.
2. Draw boundaries around business capabilities (bounded contexts) and data ownership. Each service owns its tables and nothing else writes to them, so a shared database is ruled out. Change-coupling history (which files change together) shows where the real seams are.
3. Migrate incrementally with the strangler fig pattern. Put a routing facade in front of the monolith, extract one well-bounded, low-risk capability at a time, shadow or compare traffic before cutover, then delete the old path. Add an anti-corruption layer where old and new models differ.
4. Name the new costs. Network latency and partial failure replace in-process calls. Cross-service transactions need sagas or an outbox. You need distributed tracing with correlation ids, versioned APIs with contract tests, and more deployment and on-call surface.
5. Plan the data move. Dual writes from application code drift out of sync, so prefer change data capture or an outbox, then backfill and run reconciliation checks. Reports that used one SQL join now need an API composition or a read model or warehouse.

Follow-up

• Which capability would you extract first, and why that one?
• How do you replace a query that was a single SQL join across tables now owned by two services?
• How do you release safely when a feature needs coordinated changes in three services?

How do you manage data consistency across distributed services?

Medium · System Design and Architecture

Approach

1. Decide the consistency each flow needs instead of applying one level everywhere. Balances and inventory usually need strong consistency within the owning service. Dashboards and search can be eventually consistent. Users usually expect read-your-writes on their own changes.
2. Explain why two-phase commit across services is usually avoided: it blocks while the coordinator is down and couples every participant's availability. Use a saga instead, a sequence of local transactions with compensating actions, either orchestrated by one coordinator or choreographed through events.
3. Solve the dual-write problem with a transactional outbox. Write the state change and the event row in the same local database transaction, and have a relay (polling, or change data capture such as Debezium) publish it. The event can no longer be lost when the service crashes between the commit and the publish.
4. Make consumers idempotent, because at-least-once delivery produces duplicates. Deduplicate on the event id with a processed-messages table. Keep per-entity ordering by partitioning on the entity key. Use optimistic concurrency (version columns) to reject stale updates.
5. Cover the edges. Run reconciliation jobs that detect drift, and alert on outbox lag. Use semantic compensation for steps that cannot be undone, such as a notification that was already sent. The UI must tolerate a read model that is briefly stale.

Follow-up

• What happens if the outbox relay publishes an event twice or out of order, and how do consumers cope?
• When is two-phase commit an acceptable choice?
• How do you show users their own change immediately when the read model lags behind the write?

How do you approach debugging complex, multi-threaded applications?

Medium · Technical Foundations and OOPS

Approach

1. Classify the symptom before forming a theory. Threads stuck with idle CPU suggest deadlock. Threads busy but making no progress suggest livelock or starvation. Intermittent wrong or corrupted values point to a data race. Slow but correct usually means lock contention or an exhausted thread pool.
2. Capture state while the problem is happening. Take several thread dumps a few seconds apart: jstack for the JVM, py-spy dump for Python, or a Go goroutine dump via SIGQUIT or pprof. Look for lock cycles (jstack prints a Java-level deadlock section when it finds one) and many threads parked on the same monitor.
3. Make races reproducible. Run Go's -race flag or ThreadSanitizer for C/C++, write stress tests that repeat the operation thousands of times across many threads, and add yields or sleeps to widen the race window. Log with thread ids and monotonic timestamps, and remember that logging changes the timing.
4. Fix the root cause, not the timing. Enforce a consistent lock order, shrink critical sections, use tryLock with timeouts where waiting forever is unsafe, and prefer thread confinement or immutable messages over shared mutable state.
5. Verify under the same load that triggered the bug and keep the stress test as a regression test. A fix that only makes the window smaller will pass a few runs and then fail again in production.

Follow-up

• How would you debug a race that never reproduces on your laptop?
• What is the difference between deadlock and livelock, and how would each show up in a thread dump?
• Which production metrics would show thread-pool starvation before users report timeouts?

Suggested practice checklist

The plan follows the three reported rounds: resume and process on day one, foundations and concurrency next, then system design and consistency, and finally behavioral stories and a phased presentation. Practice-set drills are pointed at the days they support.

Day 1 — Map the loop and audit your resume

• Write the three reported rounds on one page: Recruiter Screen, Technical Deep-Dive, Leadership Review.
• List every technology on your resume with why you chose it, one alternative, and one measured result.
• Write a short statement of why a point-of-care EEG product interests you, using only what the product does.

Deliverable: A one-page loop map, a resume audit table, and a written why-Ceribell statement.

Day 2 — SOLID, design patterns and testable code

• Take one module from your own project and mark where it breaks single responsibility or dependency inversion, then write the refactor.
• Write when-to-use and when-not-to-use notes for three patterns you know well, such as strategy, factory and observer.
• Answer aloud: how you keep code testable and modular as a system grows, naming unit, integration and end-to-end layers.

Deliverable: A before-and-after refactor outline, three pattern notes, and spoken answers to the SOLID, design patterns and testability questions.

Day 3 — Concurrency and debugging multi-threaded code

• In Java, Python or Go, write a small program with a deliberate race condition, then fix it two ways.
• Build a comparison table of shared-state options: lock-guarded map, concurrent collection, immutable snapshot, queue-based message passing.
• Write a debugging checklist for hangs and intermittent failures: reproduce, capture thread dumps or traces, use race detectors, test hypotheses.

Deliverable: A working race and its two fixes, a data structure trade-off table, and a one-page debugging checklist.

Day 4 — Scaling: 10k threads, load balancing, large datasets

• Sketch a design that serves 10k concurrent connections with low latency, comparing thread-per-request, event loop and bounded pools.
• List load balancing strategies (round robin, least connections, consistent hashing) and when sessions or caches affect the choice.
• Outline the EEG ingestion scenario with buffering, backpressure and a caching layer.

Deliverable: Two diagrams (10k connections, EEG ingestion), a load balancing comparison and a solved paging drill.

Day 5 — Fault tolerance, consistency and service boundaries

• Write a fault tolerance checklist: timeouts, retries with jitter, circuit breakers, bulkheads, idempotent operations.
• Outline a monolith-to-microservices migration: seams, data ownership, incremental extraction, and what to measure at each step.
• Compare consistency options across services, such as sagas, outbox pattern and eventual consistency, and when each is acceptable.

Deliverable: A fault tolerance checklist, a working rolling-failure-rate solution, a migration outline and a consistency comparison.

Day 6 — Behavioral stories, part one

• Write outlines for the trade-off story, the disagreement story and the speed-versus-technical-debt story, each with the options you weighed and a measured result.
• Rewrite the trade-off story with no jargon and have someone outside engineering repeat it back.
• Say each story aloud and cut anything that is about the team rather than your own decisions.

Deliverable: Three story outlines with options and results, and one jargon-free version of the trade-off story.

Day 7 — Mentoring, business problem and full mock

• Write the mentoring story around one named mentee and the specific actions you took.
• Write the business-problem story, then build a short phased-plan presentation from it: problem, bottleneck, phase one, phase two, risks.
• Run a mock across all reported question types: one foundations question, one system design question and one behavioral question, answered aloud.
• Prepare closing questions about the team's current technical challenges.

Deliverable: Two story outlines, a phased-plan presentation, a recorded mock and a list of questions for the team.

Behavioral stories for the Leadership Review

The behavioral questions reported for this loop concern technical judgment explained to others: justifying trade-offs to non-technical people, resolving disagreement, weighing speed against debt, mentoring juniors, and turning a business problem into a technical plan. Candidates also cite sample prompts such as 'Growing a Junior Engineer' and 'Explaining Technical Constraints Clearly'. Prepare stories in the STAR structure with your own decisions and measured results.

1. Describe a project where you had to balance speed-to-market with technical debt.
2. Describe a situation where you identified a critical business problem and put forward a technical solution.
3. Growing a Junior Engineer

Describe a time you had to justify a technical trade-off to a non-technical stakeholder.

Medium · Behavioral and Leadership

Approach

1. Choose a trade-off you decided yourself, such as shipping a simpler design now versus a more scalable one later, or consistency versus latency. State the two options in plain terms in your first minute.
2. Translate the engineering terms into the stakeholder's currency: delivery date, cost, risk to users, and what could go wrong in operation. Avoid acronyms they would have to ask about.
3. Show that you gave options rather than an ultimatum: two or three paths, what each costs, your recommendation and what the stakeholder gives up by agreeing.
4. Close with the decision, the measured outcome and what you would change. A weak story ends with 'they understood'; a strong one ends with a decision made and a result observed.

Follow-up

• What would you have done if the stakeholder had insisted on the other option?
• How did you check the stakeholder had understood the risk and not just agreed?
• Which number or example convinced them most?

How do you handle disagreements within an engineering team regarding technical direction?

Medium · Behavioral and Leadership

Approach

1. Choose a real disagreement about technical direction, such as framework choice, service boundaries or a rewrite versus incremental refactor. State the other person's position fairly before yours.
2. Explain how you moved from opinion to evidence: a benchmark, a small prototype, a written design note with agreed decision criteria, or consulting the people who run the system.
3. Say who made the final call and how you handled it. Disagree-and-commit is stronger than winning, and a story where you were overruled and still helped the outcome is strong.
4. Report the outcome and the relationship after it. The mistake that sinks this answer is a story where you were right and the other person was obstinate.

Follow-up

• What if the data had been inconclusive?
• Tell me about a time you were the one overruled.
• How do you keep a disagreement from becoming personal in a design review?

Tell us about a project where you had to balance speed-to-market with technical debt.

Medium · Behavioral and Leadership

Approach

1. Pick a project with a hard date where you knowingly took on debt. Name the shortcut precisely, such as skipping a abstraction layer, hard-coding configuration or deferring a migration, rather than saying 'we cut corners'.
2. Explain how you bounded the debt: behind an interface so it can be replaced, covered by tests for the core path, tracked with an owner and a trigger for repayment.
3. State what you refused to cut, such as tests on the data path or monitoring on the ingestion service, and why. This shows judgment, not just speed.
4. Give the result with numbers: release date met, incidents afterwards, and whether and when the debt was repaid. A story with no repayment needs an honest account of why.

Follow-up

• How did you decide which shortcuts were off limits?
• How did you get time scheduled to pay the debt back?
• Did the debt ever cause an incident, and what did you change afterwards?

How do you mentor junior engineers and contribute to a culture of high performance?

Medium · Behavioral and Leadership

Approach

1. Use one named mentee (no real name needed) and describe where they started, such as hesitant in code review or new to the service. Avoid a general philosophy of mentoring.
2. Describe concrete actions: pairing on a first change, review comments that explain the reasoning, a scoped task that stretched them, and handing over design ownership in steps.
3. Show the result in observable terms: they shipped a feature unaided, handled an on-call issue or reviewed others. Also mention a team practice you introduced, such as a review checklist or blameless post-incident reviews.
4. Be honest about trade-offs: mentoring cost you delivery time, and say how you managed it. Avoid defining high performance as pressure or long hours.

Follow-up

• What did you do when a mentee was not progressing?
• How do you give hard feedback to someone junior?
• How did you balance mentoring with your own deliverables?

Describe a situation where you identified a critical business problem and proposed a technical solution.

Medium · Behavioral and Leadership

Approach

1. Start with how you found the problem yourself: support tickets, incident reviews, cost data or a customer complaint, rather than a task you were assigned. State it in business terms with a number.
2. Explain the technical diagnosis: the bottleneck you identified, the options you considered and why you chose one. Include one option you rejected.
3. Describe getting buy-in with a phased plan: a small first step that proved value, then later phases, with risks named.
4. Report the measured result and anything that fell short. The mistake is a purely technical story with no business measure, or results that cannot be checked.

Follow-up

• How did you size the problem before asking for time to fix it?
• What alternatives did you reject and why?
• How did you phase the work so it delivered value early?