Cedar Software Engineer Interview Guide

The 60-second brief

Cedar builds software aimed at making the healthcare experience smoother for the people who use it and for providers. Software Engineers are described as working across the stack, from back-end systems to the front-end interfaces people actually see, alongside product managers, UX designers and other engineering teams. The requirements candidates describe name Java, Python or JavaScript, web frameworks and RESTful API development, solid knowledge of databases and data structures, and familiarity with cloud services and deployment. Docker, Kubernetes, CI/CD and agile practice appear as extras. That stack is what your examples and coding language should line up with.

This guide is for candidates interviewing for a Software Engineer position at Cedar. It covers the three reported rounds (Initial Screening Call, Technical Assessments, Interviews with Team Members), gives worked preparation for the reported behavioral questions, and points to the coding, SQL versus NoSQL, REST, system design and debugging questions candidates report. It ends with a seven-day plan that sequences all of them.

Candidates report three stages over roughly 3-5 weeks: an Initial Screening Call, Technical Assessments that combine coding challenges with technical discussions, and Interviews with Team Members.

Focus areas

• System Design
• Debugging
• Technical Communication

Overview

The day-to-day work candidates describe is full-stack in scope: building features, improving existing systems, reviewing teammates' code, gathering requirements with product and design partners, and tracing bugs in running software. The interview questions reflect that spread. Expect to move between a coding exercise, a spoken comparison of data stores, an architecture sketch and a story about working with other people, so preparing one area deeply and ignoring the rest is the weakest plan.

The reported questions fall into five groups. Technical questions ask for the main differences between SQL and NoSQL databases, an explanation of RESTful APIs with examples from your own projects, and how you keep applications performant and scalable. Design questions cover a URL shortening service, real-time notifications for users, and reliability and fault tolerance. Problem-solving questions ask how you would troubleshoot a performance issue in a live application, cut an API's response time, and pivot when requirements change. Coding questions are the longest substring without repeating characters, implementing a binary search tree, and an explanation of how you approach dynamic programming. The behavioral group asks about a significant technical challenge, prioritizing in a fast-paced environment, and mentoring a colleague.

Candidates also mention design scenarios such as handling data consistency in a distributed system, weighing microservices trade-offs, and building a payment processing system, plus smaller questions about version control and code review habits. Several reported questions are open-ended (how do you ensure scalability, how do you approach dynamic programming), so the preparation is to turn each into a short, structured spoken answer with one concrete example from work you have done.

Because candidates are also told to expect collaborative coding sessions, practise coding while talking: state the approach, write it, run an example by hand, then name the complexity. Pick one language from the role's list (Java, Python or JavaScript) and use it for every coding drill so the syntax is automatic.

The Cedar interview process

Candidates report three rounds over about 3-5 weeks. They also say the experience varies by team and level, so use the order and formats below as a guide and confirm specifics with your recruiter.

Initial Screening Call

Candidates describe this as a preliminary call about your background and your fit for the role. There is no reported coding or design content here, so the preparation is communication: a clear summary of the work you have done that matches the stack the role lists, and a reason you want a healthcare-focused engineering job. Use the call to ask the recruiter which language and tools the technical stage will use, whether sessions are collaborative, and how the remote or hybrid arrangement works for your team.

What to demonstrate

• Your background and how it fits the Software Engineer role
• How clearly you can summarize your experience and recent projects
• Whether your languages and tools overlap with Java, Python or JavaScript and REST/database work

How to prepare

• Write a short walk through your last two projects naming the language, the database, the API style and what you personally built.
• Prepare a sentence on why a healthcare-experience product interests you, based on what Cedar says it builds, not generalities.
• List three questions for the recruiter: the language for coding, the format of the technical stage, and the team you would join.

Technical Assessments

Candidates report coding challenges together with technical discussions. The coding side is where the longest-substring, binary search tree and dynamic programming questions get practised: write working code in your chosen language, test it on small cases and state its complexity. Technical discussion is spoken, so rehearse the SQL versus NoSQL comparison, the REST explanation, the performance and scalability answer and the design and debugging questions out loud, each with a concrete example from your own work.

What to demonstrate

• Working code for algorithm and data structure problems
• Technical knowledge of databases, REST APIs and application performance
• How you structure and explain a design or debugging answer in conversation

How to prepare

• Implement the sliding-window solution for the longest substring problem and test it on abba, an empty string and a string of one repeated character.
• Build a binary search tree with insert, search, in-order traversal and delete, and be ready to say what happens when keys arrive in sorted order.
• Practise a spoken answer on SQL versus NoSQL that ends with a recommendation for a named workload, not a feature list.
• Rehearse the URL shortener and the real-time notifications design from requirements through failure handling, aloud.

Interviews with Team Members

Candidates describe interviews with team members focused on cultural fit and collaboration. The reported behavioral questions (a significant technical challenge, prioritizing in a fast-paced environment, mentoring a colleague or contributing to team learning) belong to the kind of conversation this stage covers, along with the story about pivoting when requirements changed. Prepare four real stories with your own decisions in them, and keep a couple of questions ready about how the team ships and reviews code.

What to demonstrate

• Collaboration and working with teammates, as the stage is described
• How you tell the story of a technical challenge and your own part in solving it
• How you handle competing priorities and changing requirements

How to prepare

• Write a story outline for each behavioral prompt: situation in two sentences, your decision, what you measured, the result.
• Prepare a mentoring example involving one named kind of colleague (new joiner, junior, someone switching stacks) and what changed for them.
• Pick a project where requirements shifted and be ready to say what you kept, what you dropped and who you told.
• Prepare questions for the team about code review and release practice, which the role's reported responsibilities mention.

Where candidates lose points

Answering SQL versus NoSQL with a memorized list of slogans (schema versus schemaless, vertical versus horizontal scaling) and no workload

Name two workloads, for example a ledger of orders with joins and constraints and a high-volume event feed with simple key lookups, and say which store you would use for each and which consistency you give up.

Drawing boxes for the URL shortener or the notifications system before settling the numbers and the failure behavior

Start with read and write volume, how short keys are produced (a counter encoded in base 62 or a hash with collision handling), how redirects are cached, and what happens when the delivery path for a notification is down. Then draw.

Coding the longest substring or the binary search tree in silence, or stopping at the brute-force version

Say the brute-force cost, move to a sliding window with a map of last-seen positions (left = max(left, last[c] + 1)), and trace abba by hand to catch the stale-index bug. For the tree, include delete, and mention that sorted input degrades it to a list.

Debugging a slow production application by guessing a fix, such as adding servers or restarting

Check what changed and when, look at latency percentiles and error rates, find whether time goes to the database, a downstream call or the application, and change one thing at a time with a measurement before and after.

Telling behavioral stories in 'we' so the team's success is clear but your decision is not

For each of the four stories, write the single decision you made, the alternative you rejected and the measured result, then say 'I' for those parts.

Questions & practice

Write a function to find the longest substring without repeating characters.

Medium · Coding / Algorithms

Approach

1. Clarify the output (length or the substring itself), the character set (ASCII or Unicode) and the empty string, which returns 0.
2. Name the brute force: check every substring for duplicates, O(n^3), or O(n^2) by growing each start with a set until a repeat.
3. Sliding window: keep a map from character to its last index and a left pointer. For each right index, if the character was seen at index >= left, move left to that index + 1; record the new last index; best = max(best, right - left + 1). O(n) time, O(min(n, alphabet size)) space.
4. Trace "abba": at the final 'a' its last index 0 is left of the window start 2, so left must not move back; without that check the answer comes out 3 instead of 2. Also check "bbbb" (1) and an all-unique string (n).
5. To return the substring, store the start index of the best window. A set-based window that shrinks one step at a time is also O(n) amortised, since each index enters and leaves once.

Follow-up

• Change it to the longest substring with at most k distinct characters.
• What changes if the input is a stream you can read only once?
• How would Unicode input, where one visible character can be several code points, affect the solution?

Solve a problem involving data structures, such as implementing a binary search tree.

Medium · Coding / Algorithms

Approach

1. State the invariant: every key in the left subtree is smaller than the node and every key in the right subtree is larger; decide a duplicate policy up front (reject, keep a count, or always go right).
2. Implement search and insert iteratively in O(h); in-order traversal yields keys in sorted order; min and max come from walking left or right.
3. Delete has three cases: a leaf is removed; a node with one child is spliced out; a node with two children takes its in-order successor (minimum of the right subtree), and the successor, which has no left child, is then removed.
4. Complexity is O(h): O(log n) when balanced, O(n) when keys arrive sorted and the tree degenerates into a list. Self-balancing variants fix that (AVL, red-black; Java's TreeMap is a red-black tree).
5. For validation, recurse with (low, high) bounds rather than comparing each node only with its children, and use null bounds instead of integer min/max sentinels. Test the empty tree, deleting the root and duplicate keys.

Follow-up

• Find the kth smallest key, and make it O(h) per query.
• Find the lowest common ancestor of two keys in a BST.
• Which insertion order produces the worst case, and how does a red-black tree prevent it?

Describe your approach to solving dynamic programming problems.

Medium · Coding / Algorithms

Approach

1. Say how you recognise a DP problem: optimal substructure plus overlapping subproblems, usually phrased as count the ways, minimum or maximum cost, or is it possible, over prefixes, intervals or grid cells.
2. Define the state in one sentence, then the recurrence, base cases and where the answer sits. Example, coin change: dp[a] = min over coins c <= a of dp[a - c] + 1, dp[0] = 0, unreachable amounts stay infinity; O(amount x coins) time.
3. Choose top-down or bottom-up: memoised recursion is quickest to derive but hits recursion limits (Python's default is 1000); tabulation fixes the evaluation order and makes space reduction easy.
4. Reduce space when a row depends only on the previous one, e.g. the LCS length in O(min(m, n)) extra space; recovering the actual answer needs the full table or stored choices.
5. Check with a small hand example and know why greedy fails: coins {1, 3, 4} for 6 gives 4+1+1 greedily (3 coins) but 3+3 with DP (2 coins).

Follow-up

• Counting coin combinations vs ordered sequences: why does the loop order change the answer?
• Reduce a two-dimensional table from O(mn) to O(n) space.
• When is a greedy choice provably correct, so DP is unnecessary?

What are the main differences between SQL and NoSQL databases?

Medium · Technical / Domain Questions

Approach

1. Say first that NoSQL is a family, not one design: document stores (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra) and graph (Neo4j), against relational engines such as PostgreSQL and MySQL with fixed schemas, foreign keys and joins.
2. Compare guarantees: relational engines give multi-row ACID transactions; many NoSQL stores scope atomicity to one item or partition by default and offer tunable or eventual consistency (Cassandra consistency levels, DynamoDB eventually vs strongly consistent reads). MongoDB has supported multi-document transactions since 4.0.
3. Compare scaling: relational databases usually scale reads with replicas and writes vertically or with manual sharding; key-partitioned NoSQL stores scale writes horizontally, but any query without the partition key becomes a scatter-gather or needs a secondary index.
4. Compare query modelling: SQL supports ad hoc joins and aggregation, while DynamoDB or Cassandra tables are designed around known access patterns first, often with denormalised copies of the data.
5. Finish with a decision rule tied to an example: records whose invariants span rows (balances, invoices) go relational; high-volume append-only events read by key can go to a wide-column store. Name what each choice gives up.

Follow-up

• A user writes a record and immediately reads it back from an eventually consistent store: what can they see, and how would you guarantee read-your-writes?
• How does a schema change roll out in each kind of database without downtime?
• If one system uses both, how do you keep them in sync without dual writes?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain the concept of RESTful APIs and how you have implemented them in past projects.

Medium · Technical / Domain Questions

Approach

1. Define REST by its constraints: resources identified by URIs, a uniform interface over HTTP methods, stateless requests that carry their own auth, cacheable responses, and representations (usually JSON) rather than remote procedure names.
2. Get method semantics right: GET is safe and idempotent, PUT and DELETE are idempotent, POST is not, PATCH is not guaranteed to be. Match status codes: 201 with a Location header on create, 400 or 422 for validation, 401 vs 403, 404, 409 for conflicts, 429 for rate limits.
3. Cover the design details: plural noun paths (/orders/{id}/items), filtering and cursor-based pagination, a consistent error body, versioning via the path or a header, and an Idempotency-Key header so a retried POST does not create a second record.
4. For the past-project half, walk one endpoint you built end to end in first person: the resource model, authentication (OAuth 2.0 bearer tokens or JWT), input validation, the OpenAPI spec, and one mistake you fixed, such as a breaking field rename.
5. Close with when REST is the wrong fit: GraphQL when clients need flexible nested reads, gRPC for typed, low-latency service-to-service calls.

Follow-up

• How would you make a POST that charges a payment safe to retry after a client timeout?
• Offset vs cursor pagination: what goes wrong with offsets when rows are inserted while a client pages?
• How do you remove a field without breaking clients that still read it?

How do you ensure the performance and scalability of your applications?

Medium · Technical / Domain Questions

Approach

1. Start from measurable targets, not techniques: p50, p95 and p99 latency, throughput and error rate for the key endpoints, then load test (k6, Locust, JMeter) to find the point where latency bends upward.
2. Profile before optimising: distributed traces to see which span dominates, EXPLAIN ANALYZE on slow queries, and checks for N+1 queries, missing indexes and connection pool exhaustion.
3. Name the scaling levers in order of cost: stateless app servers behind a load balancer for horizontal scaling, cache-aside in Redis and a CDN for static or public content, read replicas, a queue for work that need not happen inside the request, and partitioning only when a single primary's writes saturate.
4. State each lever's price: caches bring staleness and invalidation work, replicas bring replication lag (a user may not read their own write), queues make completion eventual and need idempotent consumers.
5. Keep it from regressing: SLO dashboards and alerts, autoscaling on CPU or queue depth, and a performance test in CI on the critical paths.

Follow-up

• Your p99 is ten times your p50: where do you look first?
• How do you pick a cache TTL, and how do you invalidate on writes?
• Traffic grows tenfold overnight: which component fails first in a typical web app plus relational database?

Design a URL shortening service. What considerations would you take into account?

Medium · System Design / Architecture

Approach

1. Pin requirements: shorten, redirect, optional custom alias, expiry, click analytics. Treat it as read-heavy and size the key space: seven base62 characters give 62^7, about 3.5 trillion codes.
2. Compare key generation: a counter (database sequence, or ranges handed to each app server) encoded in base62 never collides but is guessable; hashing the long URL and taking a prefix needs a collision check; random codes need a unique constraint and a retry on conflict.
3. Storage is a lookup by primary key (short code to long URL, owner, created_at, expires_at), so a key-value store or a relational table both work; partition by short code, and add an index on the long URL only if the same URL must map to the same code.
4. Redirect path: a cache in front of the store for hot links. 301 is cached by browsers and cuts load but hides repeat clicks; 302 sends every click through the service, which analytics needs.
5. Keep analytics off the redirect path: publish click events to a queue or stream and aggregate asynchronously. Add rate limits on creation, screening for malicious URLs and a cleanup job for expired codes.

Follow-up

• The same long URL is submitted twice: same code or a new one, and what does each cost?
• How do you hand out counter ranges to many servers without a single point of failure?
• How do you guarantee a custom alias never collides with a generated code?

How would you architect a system to handle real-time notifications for users?

Medium · System Design / Architecture

Approach

1. Scope first: channels (in-app, mobile push through APNs and FCM, email, SMS), delivery latency target, per-user preferences and quiet hours, and what happens to users who are offline.
2. Pipeline: producers publish events to a durable log or queue (Kafka, SQS); a notification service applies preferences, deduplication, templates and rate limits, then fans out to per-channel workers so a slow email provider cannot delay push.
3. In-app real time: clients hold WebSocket or SSE connections to gateway servers; a registry such as Redis maps user to gateway, and pub/sub routes each message to the gateway holding that socket. Long polling is the fallback.
4. Delivery guarantees: at-least-once with a notification id the client uses to deduplicate; persist every notification so a reconnecting client fetches everything after its last seen id; retry third-party sends with exponential backoff and park failures in a dead-letter queue.
5. Trade-offs: partition by user id to keep per-user order; fan out large broadcasts in batches off the hot path; keep push payloads minimal when content is sensitive and load details after the user signs in.

Follow-up

• A gateway holding many open sockets crashes: what do those clients see, and how do they recover missed messages?
• A worker retries after a timeout: how do you stop the user getting the same notification twice?
• How would you enforce a per-user cap on notifications per hour across all channels?

What strategies would you use to ensure system reliability and fault tolerance?

Medium · System Design / Architecture

Approach

1. Remove single points of failure: redundant instances across availability zones, load balancer health checks, database replication with automated failover, and explicit RTO and RPO targets that drive those choices.
2. Contain dependency failures: a timeout on every remote call, retries with exponential backoff and jitter only for idempotent operations, circuit breakers, bulkheads (separate pools per dependency) and a degraded mode instead of a hard error.
3. Protect data: synchronous replication avoids losing acknowledged writes at the cost of write latency, asynchronous replication can lose the last writes on failover; idempotent consumers and the transactional outbox pattern keep database writes and published messages consistent; backups count only once a restore has been tested.
4. Handle overload: rate limiting, load shedding of low-priority traffic, queues to absorb bursts, and autoscaling with a ceiling so a spike cannot exhaust the database.
5. Operate for it: SLOs and error budgets, alerts with runbooks, canary deploys behind feature flags with fast rollback, game days that kill real instances, and blameless postmortems.

Follow-up

• Retries turned a small outage into a large one: why, and how do you stop a retry storm?
• What exactly can you lose on failover with asynchronous replication, and how would you tell users?
• How would you prove your failover works before a real incident tests it?

If you were tasked with reducing the response time of an API, what steps would you take?

Medium · Problem-Solving / Case Studies

Approach

1. Measure where the time goes before changing anything: a trace per request split into database, downstream calls, serialisation and network, with a p95/p99 target agreed up front.
2. Fix the database work: remove N+1 queries with joins or batched lookups, add indexes and confirm them with EXPLAIN, select only needed columns, paginate large result sets, and size the connection pool.
3. Restructure the request: run independent downstream calls in parallel, give each a timeout, and move work the caller does not wait for (emails, audit logs, analytics) onto a queue.
4. Cache deliberately: HTTP caching with ETag and Cache-Control or a CDN for public GETs, cache-aside in Redis for hot reads, with an invalidation rule for writes.
5. Trim the transport: gzip or Brotli compression, smaller payloads, keep-alive connections. Verify with a before-and-after load test at the same traffic so the gain is real.

Follow-up

• The average is fine but p99 is bad: what changes in your approach?
• The slowest step is a third-party call you cannot speed up: what are your options?
• After adding a cache, how do you keep a user from seeing stale data right after their own write?

Discuss a project where you had to pivot quickly based on changing requirements.

Medium · Problem-Solving / Case Studies

Approach

1. Pick one real project where the requirement changed mid-build and say in first person what changed, why (user feedback, a new constraint, a moved deadline), and what you decided, not what the team watched happen.
2. Show the re-scoping: what you kept, what you discarded, and how you reached agreement with the product owner on the new scope and its trade-offs.
3. Name the engineering choices that made the pivot cheaper or harder: clean interfaces between modules, feature flags, incremental releases, or tight coupling you had to unwind.
4. End with a measurable outcome and one lesson you now apply, such as validating the riskiest assumption earlier. The story fails if it blames stakeholders or has no decision of your own in it.

Follow-up

• What did you cut to absorb the change, and who agreed to it?
• Which part of your design made the change cheaper, and which made it more expensive?
• What signal could have warned you earlier that the requirement would change?

How would you troubleshoot a performance issue in a live application?

Medium · Problem-Solving / Case Studies

Approach

1. Scope the impact first: which endpoints and users, since when, and whether p95/p99 or the average moved. Check recent deploys, config changes and traffic shifts, and mitigate before diagnosing if users are hurting (roll back, scale out, turn off a feature flag).
2. Localise with metrics: RED (rate, errors, duration) per service and USE (utilisation, saturation, errors) per resource; use distributed traces to find which span grew: application code, database, cache or an external dependency.
3. Drill into the suspect layer: slow query log, EXPLAIN ANALYZE and lock waits for the database; CPU profiles or flame graphs, GC pause logs, thread dumps and connection pool wait times for the application; heap snapshots if memory climbs.
4. Change one thing per hypothesis and confirm the metric recovers; separate a coincident traffic spike from the cause by comparing against a healthy instance or a previous period.
5. Close the loop: a postmortem, an alert that would have caught it earlier, and a regression or load test so it cannot return unnoticed.

Follow-up

• Latency creeps up over days and resets after every restart: what do you suspect?
• Only one instance out of many is slow: what do you check next?
• How do you profile in production without making the incident worse?

Suggested practice checklist

The plan walks the three reported rounds in order of risk: first the coding the technical stage covers, then the data, REST and design discussion topics, then debugging, then the stories for the team interviews.

Day 1 — Map the loop and pick your language

• Write the reported sequence (Initial Screening Call, Technical Assessments, Interviews with Team Members) and next to each the content candidates report for it.
• Choose one of Java, Python or JavaScript for all coding drills this week, and list which of REST, SQL and NoSQL, cloud deployment, Docker and CI/CD you can discuss from real work.
• Write a short spoken summary of your last two projects and three questions for the recruiter about the technical stage format.

Deliverable: A one-page loop map, a chosen coding language, a project summary and a list of recruiter questions.

Day 2 — Coding: strings and trees

• Solve the longest substring without repeating characters problem with a sliding window and a map of last-seen indexes, and test abba, an empty string and a single repeated character.
• Implement a binary search tree with insert, search, in-order traversal and delete (leaf, one child, two children), plus a height function.
• For both, write the time and space complexity and the worst case on a single line of notes.

Deliverable: Two working solutions with test cases, and a note of complexity and worst case for each.

Day 3 — Dynamic programming and data stores

• Write your own method for dynamic programming (define the state, write the recurrence, find the base cases, choose memoization or a table, then reduce space) and apply it to climbing stairs, coin change and longest common subsequence.
• Make a SQL versus NoSQL comparison with two concrete workloads and your choice for each, covering schema, joins, transactions and scaling.

Deliverable: Three solved dynamic programming problems, a one-page data store comparison and the completed SQL practice query.

Day 4 — REST, performance and response time

• Write out a spoken explanation of REST: resources as nouns, method semantics, idempotent PUT and DELETE, status codes, pagination and versioning, with one API you built as the example.
• List the steps you would take to cut an API's response time in order: measure percentiles, find N+1 queries, add or fix an index, cache, paginate, compress, and move slow work to a queue.
• Say how you keep an application scalable as load grows, using the same list plus statelessness and horizontal scaling.

Deliverable: A spoken-answer outline for each of the three questions, with one real example per outline.

Day 5 — System design: URL shortener, notifications, reliability

• Design a URL shortening service: key generation (counter in base 62 versus hash with collision check), storage, redirect with a 301 or 302, caching, and expiry.
• Design real-time notifications: push channel (WebSocket, server-sent events or mobile push), a queue between producers and delivery, at-least-once delivery with deduplication, and offline users.
• Write a reliability checklist: timeouts, retries with backoff and jitter, circuit breakers, replication, health checks, and graceful degradation. Add idempotency keys for a payment processing scenario.

Deliverable: Two design write-ups with a diagram each and a one-page reliability checklist.

Day 6 — Debugging and code review

• Write a debugging runbook for a live slow application: what changed, which metrics to check, how to split the problem between database, downstream calls and application code, and how to confirm the fix.
• Prepare a real bug story with the symptom, how you found the cause and the test you added afterwards.
• Write your code review habits and your version control workflow in a few sentences each.

Deliverable: A one-page runbook and a rehearsed bug story with your code review and version control notes.

Day 7 — Behavioral stories and a full rehearsal

• Write story outlines for the technical challenge, prioritization, mentoring and quick-pivot prompts, each with your decision and a measured result.
• Say all four stories aloud and replace every 'we' that hides your contribution with 'I'.
• Finish with a spoken run of one design question and one coding question, then list your two weakest answers for review.

Deliverable: Four story outlines, spoken once each, and a list of the two weakest answers.

Stories to prepare for the team interviews

Candidates describe the team-member interviews as covering cultural fit and collaboration. The reported prompts ask for a technical challenge you overcame, how you prioritize under pressure, and how you mentor or help a team learn. A fourth reported prompt is the project where you pivoted when requirements changed. Have a real story for each, with your own decision and a measured result.

1. Discuss a project where you had to pivot quickly based on changing requirements.
2. Describe a challenging bug you encountered and how you resolved it.

Describe a time when you faced a significant technical challenge. How did you overcome it?

Medium · Behavioral / Leadership

Approach

1. Choose a challenge where the difficulty was technical and the decision was yours, for example a slow query, a flaky integration, a data migration or a race condition in a service. Describe the situation and constraint in two sentences, then spend most of your time on reasoning.
2. Walk through your diagnosis in order: what you observed, the hypotheses you listed, how you tested them (profiling, logs, a minimal reproduction) and which options you weighed before choosing one.
3. Say what you did in the first person. 'I' for your decisions, and name teammates for theirs. A story told entirely in 'we' leaves the listener unable to tell what you contributed.
4. Close with evidence the fix worked: a before-and-after measurement, an error rate, a test that now guards the case. Add one thing you would change if you did it again.
5. The mistake that sinks this answer is a challenge that was only hard because of effort or deadlines, with no technical choice in it.

Follow-up

• What alternatives did you reject, and why?
• How did you know your change caused the improvement rather than something else?
• What would you do differently if you faced the same problem today?

How do you prioritize tasks in a fast-paced environment?

Medium · Behavioral / Leadership

Approach

1. Open with the rule you actually use, then prove it with an incident. A workable rule: rank work by user or business impact, the cost of waiting, and whether other people are blocked on it, and keep small unblocking tasks separate from large ones.
2. Tell one concrete story of two or more competing items, for example a production bug, a feature deadline and a review request all landing in the same week. Say what you did first, what you deferred and why.
3. Show how you communicated the trade-off: tell the product manager or requester what slips and by how much, and agree on it rather than silently dropping work. The role is described as working with product managers, designers and other engineering teams.
4. Mention how you re-plan when something new and urgent arrives, and how you protect time for the work that is important but not urgent, such as tests or tooling.
5. Avoid answering with only a framework name or 'I work longer hours'. Neither shows judgement.

Follow-up

• Two senior people each say their task is the top priority. What do you do?
• A production incident hits mid-sprint. What gets dropped, and who hears about it?
• How do you tell someone their request has been deprioritized?

Give an example of how you have mentored a colleague or contributed to team learning.

Medium · Behavioral / Leadership

Approach

1. Pick a specific person and a specific gap: a new joiner learning the codebase, a junior moving from scripts to services, or a teammate new to your database or deployment setup. Name what they could not do before.
2. Describe what you actually did: pairing on a first change, review comments that explain the reason behind each suggestion, a short written guide, or a walk-through of a past incident. Show that you adapted the method to how the person learns.
3. Give the outcome for them, not for you: they shipped a feature unaided, took over an on-call duty, or started reviewing others' code. If the learning reached the whole team, say so with the artifact (a runbook, a review checklist, a short internal talk).
4. Be honest about a difficulty: they resisted a suggestion, or you were too directive at first, and what you changed.
5. Two mistakes sink it: doing the work for them and calling it mentoring, and claiming credit for their success.

Follow-up

• What did you do when they were not improving as expected?
• How did you fit mentoring around your own deliverables?
• What is the hardest piece of feedback you have given a colleague, and how did they take it?