Blue Cross and Blue Shield of North Carolina Software Engineer Interview Guide

The 60-second brief

Blue Cross and Blue Shield of North Carolina is a health care organization. Candidates describe its Software Engineer work as building and maintaining applications for two audiences: internal teams, and people who use customer-facing products. The code ranges from user-facing applications to back-end systems that hold sensitive health information. In practice that means a Software Engineer works alongside product managers, designers and other engineers, takes part in code reviews, and is expected to care about security and correctness as much as features. Reports mention Java, C# and Python as the listed languages, with HTML, CSS and JavaScript for the web side, and .NET, Angular and React appearing as topic tags on reported loops.

This guide is for engineers preparing for the Software Engineer loop at Blue Cross and Blue Shield of North Carolina. It covers the four stages candidates report, the questions they report across technical, design, problem-solving, coding and behavioral themes, and a plan you can follow in a week. Requirements candidates describe include 3-5 years of development experience (health care or a related field preferred), SQL or NoSQL databases, Git, and Agile or Scrum practice, with cloud (AWS, Azure) and health care regulations listed as nice to have.

Candidates report four stages over roughly 3-5 weeks: Phone Screening, Technical Assessment, Behavioral Assessment and Collaborative Discussions. The reported questions mix experience-based technical questions, web design questions, a few coding prompts and several behavioral questions.

Focus areas

• .NET
• RESTful API Design
• Angular

Overview

The reported questions lean toward breadth over puzzle difficulty. Several ask you to talk about your own work: which languages you are most comfortable with, a project and its technologies, how you keep code quality up, a hard bug you tracked down. Others are design-flavoured: a scalable web application, database schema design, API design. Two are case-style (a product that is not meeting user needs, prioritizing stakeholder requests) and two are plain coding prompts (reverse a string, solve a problem with a sorting or searching algorithm). Four are behavioral. Preparation therefore means having concrete, checkable stories and a clear way of explaining design trade-offs, plus enough coding fluency that the simple prompts come out clean.

The topic tags attached to reported loops are .NET, RESTful API design, Angular, React and behavioral interviewing. Combined with the listed languages (Java, C# or Python) and the web basics (HTML, CSS, JavaScript), you should be able to explain a full request path: browser component, REST endpoint, service logic, database. Choose one backend language and one frontend framework you can defend in detail rather than skimming all of them, and be ready to say what you would do differently on a stack you know less well.

Because the systems described handle sensitive health information, a design answer that mentions authentication, authorization on every endpoint, input validation, careful logging and audit trails will sound more grounded than one about throughput alone. That is preparation advice, not a claim about how any stage is run. The last two stages are described as values, teamwork and collaborative discussions with team members and hiring managers, so every technical story you prepare should also show how you worked with other people: who you consulted, who reviewed it, and what you changed because of them.

The Blue Cross and Blue Shield of North Carolina interview process

Candidates describe four stages, from an initial phone conversation through technical and behavioral assessments to discussions with team members and hiring managers. Details can differ by team and level.

Phone Screening

Candidates describe the opening stage as a phone conversation about your background and how you fit the role. No specific questions are tied to it in reports, so treat it as the place to present your experience clearly: which languages you have shipped in, one project you can describe from design to release, and why this kind of work interests you. Expect the resume to drive the conversation, so every line on it should be something you can explain in detail.

What to demonstrate

• Your background and how well it matches the Software Engineer role
• Whether your stated languages and experience are consistent with what you describe in detail
• How clearly you communicate over the phone

How to prepare

• Write a short career walkthrough that names the languages you have used professionally (Java, C#, Python are the ones the role lists) and one project for each.
• Prepare a tight answer to what programming languages you are most comfortable with, and why, with a concrete project that shows it.
• List questions to ask about the remaining stages, the team's stack and the next steps.

Technical Assessment

Reported as several interviews focused on technical skills relevant to the role. Candidates report technical and domain questions about languages, projects, code quality and troubleshooting, design questions about scalable web applications, database schemas and API design, and coding prompts such as reversing a string or applying a sorting or searching algorithm. Topic tags on reported loops include .NET, RESTful API design, Angular and React. Plan to explain your reasoning aloud as you work.

What to demonstrate

• Technical skills relevant to the Software Engineer position, as the stage is described
• Working code in your chosen language, which any coding exercise inherently tests
• Your ability to explain design choices for web applications, schemas and APIs

How to prepare

• Practise reversing a string in your strongest language, including an in-place version, empty input and Unicode surrogate pairs, then a binary search and a merge sort from memory.
• Rehearse one design walk-through that covers a REST API, the data model behind it and how the web application scales, with authorization and validation stated explicitly.
• Prepare a quality answer that names unit tests, integration tests, code review, static analysis and a CI gate, and a debugging story with evidence at each step.
• Refresh the framework you would defend (.NET with C#, Angular or React), including component structure and calling a REST endpoint.

Behavioral Assessment

Described as interviews about alignment with the organization's values and commitment to teamwork. Reported behavioral questions cover conflict with a team member, working under pressure and handling feedback, and the technical troubleshooting question is also a story question. Candidates' tips recommend a STAR structure (situation, task, action, result) and some research into the organization's mission before you go.

What to demonstrate

• Alignment with the organization's values and teamwork, as the stage is described
• How you describe your own decisions and their results in past situations
• How you talk about disagreements, pressure and feedback

How to prepare

• Write four STAR stories, one each for a conflict with a team member, work under pressure, feedback you received and a complex technical issue you troubleshot.
• Give each story a concrete result and one thing you would do differently.
• Read the organization's public mission statement and prepare one sentence connecting it to the work you want to do, in your own words.
• Say the stories aloud until each one is short enough that the action step gets most of the time.

Collaborative Discussions

Candidates report conversations with team members and hiring managers that look at how you collaborate. Expect discussion of how you work with product managers, designers and other engineers, how you give and receive code review comments, and how you handle disagreement. Design topics such as API design and prioritizing stakeholder requests fit this format well, since they are about working with others as much as technology.

What to demonstrate

• Collaboration with team members and hiring managers, as the stage is described
• Communication of technical ideas to colleagues in other roles
• How you work in a cross-functional team

How to prepare

• Prepare a prioritization answer for competing stakeholder requests: gather the impact and effort of each, name the criteria, say who decides, and describe how you tell the stakeholders no.
• Prepare an API design explanation you can give to a mixed audience, from resource naming to error responses, in plain terms.
• Write questions for team members about their branching, code review and Agile or Scrum routines, since those are listed requirements.
• Keep your conflict and feedback stories ready, because collaboration questions often bring them up.

Where candidates lose points

Answering the language and project questions with a list of technologies and no account of what you personally built

Pick one or two languages, say what you shipped in each, and describe one project in order: problem, your part, the technology choice and its trade-off, the result. Be ready to go one level deeper on anything on your resume.

Answering the code quality question with only 'I write unit tests'

Describe layers: unit tests for logic, integration tests against a real database or API, code review, static analysis or linting, a CI gate that blocks a merge, and monitoring after release. Say which of those you personally set up or changed.

Describing an API or schema without error handling, authorization or how it evolves

For the API: nouns for resources, HTTP methods and status codes, a consistent error body, pagination, versioning and authorization on every endpoint. For the schema: keys, relationships, indexes for the main queries and which data is sensitive. Say these things out loud.

Treating the simple coding prompts as trivial and delivering only the built-in call

For reversing a string, show a two-pointer in-place version, state O(n) time, and mention empty input and Unicode (surrogate pairs, combining marks). For an algorithm prompt, name the brute force first and the improvement, with complexity, then test an edge case.

Behavioral stories told as 'we did' with no clear result or personal decision

Use first person singular for the action step, include the result in plain facts, and end each story with one thing you would change. Rehearse them aloud so they are short.

Questions & practice

Write a function to reverse a string.

Medium · Coding / Algorithms

Approach

1. Confirm the contract first: is the input mutable or immutable, can it be null or empty, and does 'character' mean a byte, a UTF-16 code unit, a code point or a user-visible character (grapheme)?
2. Two-pointer swap on a character array: i from the start, j from the end, swap and move inward while i < j. That is O(n) time and O(1) extra space on a mutable array. Strings in C#, Java and Python are immutable, so the result still needs O(n) for the new string.
3. Know the idiomatic versions and their limits. Python s[::-1] reverses code points. Java new StringBuilder(s).reverse() keeps surrogate pairs intact. C# Array.Reverse on ToCharArray() and JavaScript s.split('').reverse().join('') split surrogate pairs, so emoji break. [...s].reverse().join('') keeps code points but not combining marks.
4. Avoid building the result with repeated string concatenation in a loop. In Java and C# each += copies the string, which makes the loop O(n²). Use StringBuilder or a char array.
5. Test the edges aloud: empty string, single character, even and odd lengths, palindromes, null input and non-ASCII text.

Follow-up

• Reverse the order of the words in a sentence in place, without reversing the letters inside each word.
• Write it recursively. What is the space cost, and what happens on a very long string?
• How would you reverse a string with emoji or accented characters correctly?

Solve a problem using a specific algorithm (e.g., sorting, searching).

Medium · Coding / Algorithms

Approach

1. Choose the algorithm from the input's properties, aloud. If the data is sorted or the answer is monotonic, use binary search in O(log n). If you need order, sort in O(n log n). If you only need lookups, a hash map gives O(1) average and may make sorting unnecessary.
2. Write binary search carefully: lo = 0, hi = n - 1, loop while lo <= hi, mid = lo + (hi - lo) / 2 (avoids int overflow in Java and C#), and move lo = mid + 1 or hi = mid - 1. Know the lower-bound variant that finds the first occurrence among duplicates.
3. Compare sorts by their deciding properties. Merge sort: O(n log n) worst case, stable, O(n) extra space. Quicksort: O(n log n) average, O(n²) worst case, in place, not stable. Heap sort: O(n log n) worst case, O(1) extra, not stable. Insertion sort: O(n) on nearly sorted input and fast for small n. Counting sort: O(n + k) for a small key range.
4. Know your language's built-in sort. Python's sorted is a stable Timsort. Java's Arrays.sort uses dual-pivot quicksort for primitives and stable TimSort for objects. C# Array.Sort and List.Sort are unstable introsort, while LINQ OrderBy is stable. JavaScript's sort is stable but compares as strings by default, so numbers need (a, b) => a - b.
5. Finish by stating time and space complexity, then test duplicates, an empty array, a single element, and a target smaller or larger than every element.

Follow-up

• Records must be sorted by date and then by name. How does stability let you do that in two passes?
• The data is too large to fit in memory. How would you sort it?
• How would you use binary search on the answer, for example to find the minimum capacity that meets a deadline?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

• A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
• Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

What considerations do you take into account when designing a database schema?

Medium · System Design / Architecture

Approach

1. Start from the entities and the access patterns: which queries run most often, how much they read versus write, and the volumes. The schema should serve those queries, not an abstract diagram.
2. Normalise to roughly third normal form so each fact lives in one place and updates cannot leave copies out of sync. Then denormalise deliberately (a summary table or materialised view) only for proven read-heavy reporting, and say how it stays consistent.
3. Enforce integrity in the database: primary keys (surrogate vs natural, and why), foreign keys, NOT NULL, UNIQUE and CHECK constraints. Use correct types: DECIMAL for money, never float; dates vs timestamps with time zone; a junction table for many-to-many.
4. Plan indexes from the predicates and joins: index foreign keys, order composite index columns so the leftmost prefix matches the queries, and remember that each index slows inserts and updates.
5. Cover change and sensitivity. For values that change over time, use effective-dated rows (valid_from/valid_to) or audit tables instead of overwriting history. Restrict access to and encrypt sensitive columns. Change schemas with expand-and-contract migrations, so old and new code both work during a deploy.

Follow-up

• When would you choose a NoSQL store over a relational one for part of this data?
• How do you add a NOT NULL column to a large live table without downtime?
• A report query is slow. How do you decide between adding an index and denormalising?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

What programming languages are you most comfortable with, and why?

Medium · Technical / Domain Questions

Approach

1. Name one or two languages you can defend in depth, not a list of five. Where it is true, tie them to the stack candidates report for this role: C# on .NET, Java or Python on the back end, and TypeScript with Angular or React on the front end.
2. Give the 'why' as concrete language features you used, not feelings. For C#, that could be static typing, LINQ, async/await and nullable reference types catching null bugs at compile time. For TypeScript, it could be typed API models shared across components.
3. Back each claim with a project: 'I used C# async/await for an API that fanned out to three services, which cut request latency because the calls ran concurrently with Task.WhenAll.'
4. Be ready for depth checks in the language you named: value vs reference types, IEnumerable vs IQueryable deferred execution, garbage collection basics, or the JavaScript event loop and closures.
5. Name a language you are weaker in and how you get productive in it (read idiomatic code, write small tests, use the linter). That is a better answer than claiming you know everything.

Follow-up

• What is the difference between IEnumerable and IQueryable, and when does each one run the query?
• What would you not use your favourite language for, and what would you pick instead?
• Why can blocking on .Result or .Wait() deadlock in some .NET applications?

Describe a software project you worked on and the technologies you used.

Medium · Technical / Domain Questions

Approach

1. Open with the problem and the users in two sentences, then outline the architecture in order: client (for example Angular or React), API layer (.NET, Java or Python), data store (SQL or NoSQL), hosting (on-premises, AWS or Azure).
2. Separate your own contribution from the team's. Say 'I built the claims-status endpoint and its caching' rather than 'the team built the platform'.
3. Walk through one hard technical decision: the options you had, the one you chose, and the trade-off you accepted. Examples are a relational database over a document store for transactional integrity, or server-side pagination over loading everything in the client.
4. Close with a measurable result (latency, error rate, release frequency, support tickets) and one thing you would change now.
5. Only name technologies you can be questioned on. Every tool you list invites a follow-up about why you chose it and how it behaved.

Follow-up

• Why that database or framework rather than the obvious alternative?
• What was the hardest bug in that project, and how did you find it?
• How was the project tested and deployed, and what would you automate next?

How do you ensure the quality of your code?

Medium · Technical / Domain Questions

Approach

1. Describe layers, cheapest first. Linting and static analysis (Roslyn analyzers, ESLint, SonarQube or similar) catch defects before review. Unit tests (xUnit or NUnit, JUnit, pytest, Jest or Jasmine) cover logic. A smaller set of integration and end-to-end tests covers the seams.
2. Explain how tests run automatically: a CI pipeline on every pull request, branch protection in Git so main cannot be merged red, and small pull requests that reviewers can actually read.
3. Say what you look for in code review beyond style: correctness on edge cases, error handling, input validation, how sensitive data is logged or exposed, and whether the change is testable.
4. Treat coverage as a signal, not a target: 90% coverage with no assertions on edge cases proves little. Name the cases you deliberately test (nulls, empty collections, boundaries, concurrency).
5. Carry quality past the merge with structured logging, metrics, alerts and feature flags, so a regression is detected and rolled back quickly. Give one real example where this caught a bug.

Follow-up

• How do you unit test code that calls a database or an external API?
• A deadline is tight and tests would slip. What do you do?
• Tell me about a bug that got past your process. What did you change afterwards?

How would you design a scalable web application?

Medium · System Design / Architecture

Approach

1. Fix the requirements first: the number of users, peak requests per second, read/write ratio, latency target, and how sensitive the data is. Health information changes the security requirements from the start.
2. Outline the baseline. Serve static assets for the SPA (Angular or React) from a CDN. Put a load balancer in front of stateless API instances, so you can scale horizontally by adding instances. Keep session state in signed tokens or a shared cache, never in instance memory.
3. Scale the data tier in steps: indexes and connection pooling first, then read replicas for read-heavy traffic (and say how you handle replica lag for read-your-writes), then a cache-aside layer such as Redis with TTLs, then partitioning only when one primary cannot take the writes.
4. Move slow or bursty work (notifications, document generation, integrations) onto a message queue with workers, so request latency does not depend on it. Make the consumers idempotent because messages can be delivered more than once.
5. Cover operations and security: TLS everywhere, encryption at rest, OAuth 2.0/OIDC authentication, audit logging that keeps sensitive fields out of logs and cache keys, health checks, autoscaling, and dashboards for latency, errors and saturation.

Follow-up

• Traffic grows ten times and the database is the bottleneck. What do you change first, and why?
• How would you deploy a new version with a schema change and no downtime?
• How do you keep cached data from showing a user stale or another user's information?

Explain your approach to API design.

Medium · System Design / Architecture

Approach

1. Model resources, not actions: plural nouns and nested paths only where ownership is real (for example /members/{id}/documents). Use HTTP methods by their semantics: GET is safe, PUT and DELETE are idempotent, PATCH is a partial update, POST creates.
2. Make writes safe to retry. POST is not idempotent, so accept an Idempotency-Key header and store the result per key, letting a retry after a timeout return the original response instead of creating a duplicate.
3. Design the status codes and the error body together: 201 with a Location header on create, 400/422 for validation, 401 vs 403, 404, 409 for conflicts, 429 with Retry-After. Return one consistent error shape, such as RFC 9457 problem details, with a machine-readable code.
4. Handle collections and change explicitly. Use cursor pagination for large or changing lists (offset pagination skips or repeats rows when data shifts) and documented filters. Version the API (a /v1 path or a header), keep changes additive, and publish the contract as an OpenAPI spec.
5. Secure every endpoint. Use OAuth 2.0 bearer tokens with scopes, and check object-level authorization on every request so that changing an id in the URL cannot expose another person's record. Validate inputs, keep sensitive data out of URLs and logs, and rate-limit per client.

Follow-up

• A client times out on POST and retries. How does your API avoid creating the record twice?
• How would you roll out a breaking change to an API that other teams depend on?
• How would you expose an operation that takes minutes to finish?

Given a scenario where a product is not meeting user needs, how would you approach finding a solution?

Medium · Problem-Solving / Case Studies

Approach

1. Define the gap with evidence before proposing anything: support tickets, analytics funnels showing where users drop off, error and latency dashboards, and direct usability sessions or interviews with the users.
2. Classify the cause, because each needs a different fix: a defect or performance problem, a usability or accessibility problem (unclear flows, WCAG failures, poor mobile behaviour), or a missing capability that the product never addressed.
3. Turn findings into hypotheses with a success metric, such as 'task completion rises if the form saves progress', and rank them by expected impact against effort with the product manager and designer.
4. Ship the smallest testable change behind a feature flag, then compare the metric before and after, or run an A/B test where traffic allows. Keep or roll back based on the result, not on opinion.
5. Close the loop: report the result to stakeholders and the users who raised the issue, and add monitoring so the same gap is caught earlier next time.

Follow-up

• How would you measure whether your fix actually worked?
• The data points one way and a senior stakeholder insists on another. What do you do?
• The real fix needs a large rewrite. How do you justify it or break it down?

How would you prioritize feature requests from stakeholders?

Medium · Problem-Solving / Case Studies

Approach

1. Collect each request as a problem statement with its requester, affected users and deadline, not as a ready-made solution. Two requests often turn out to be the same underlying need.
2. Score with an explicit framework so the ranking can be discussed. Options include RICE (Reach × Impact × Confidence ÷ Effort), weighted shortest job first (cost of delay ÷ job size) or MoSCoW buckets, with engineering supplying the effort and risk estimates.
3. Treat hard constraints separately from scores: regulatory or security obligations, production defects and dependencies that block other work. Reserve capacity for technical debt, so the backlog does not quietly erode delivery.
4. Make the trade-offs visible. Keep one ordered backlog owned with the product manager, revisit it at each sprint planning, and when you say no or later, give the reason and what would change the decision.
5. Give an example from your own work where you pushed back or re-sequenced a request, and what happened as a result.

Follow-up

• Two senior stakeholders each say their request is the top priority. How do you resolve it?
• An urgent request arrives mid-sprint. What do you do with the committed work?
• Where does an engineer's input end and the product manager's decision begin?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

The plan starts from the four reported stages and the reported topics, then works through the question types candidates report: experience questions, design, coding and behavioral. It ends with a spoken run-through of your stories.

Day 1 — Map the loop and the stack

• Write the four reported stages in order and note which question types (experience, design, coding, behavioral) fit each format.
• List the languages and frameworks on your resume against the listed ones (Java, C#, Python, HTML, CSS, JavaScript, plus .NET, Angular and React as reported topics) and mark your two strongest.
• Write a short career walkthrough for the phone screening.

Deliverable: A one-page loop map, a language and framework self-assessment with your two strongest marked, and a written career walkthrough.

Day 2 — Your languages and your project

• Write an answer to the question about which programming languages you are most comfortable with, with one shipped example for each language you name.
• Write a project brief: problem, architecture, your part, the technologies and one trade-off you would revisit.
• Say both answers aloud and shorten whatever repeats.

Deliverable: A written language answer, a one-page project brief and a spoken run-through of both.

Day 3 — Code quality and troubleshooting

• Write your quality checklist in layers: tests, review, static analysis, CI gate, release monitoring, naming what you personally own.
• Outline your troubleshooting story in the order reproduce, narrow, hypothesize, confirm, fix, prevent.

Deliverable: A layered quality checklist, a written troubleshooting outline and a short diagnostic write-up for the practice question.

Day 4 — Web design, schema and API

• Design a scalable web application end to end for a made-up appointment booking service: client, API, service layer, database, cache, and how each scales.
• Design the tables for it: keys, relationships, indexes for the main queries and a note on sensitive columns.
• Write the REST API for it: resources, methods, status codes, error body, pagination, versioning and authorization.

Deliverable: A system diagram, a table design, an API specification and a short note on the concurrency practice question.

Day 5 — Coding fundamentals

• Write reverse a string in your strongest language in two ways, then add tests for empty, single character and Unicode input.
• Write binary search and merge sort from memory and state their complexity and when each applies.

Deliverable: Passing code and tests for string reversal, binary search and merge sort, and a solved overlap problem with a spoken explanation.

Day 6 — Frontend and problem-solving cases

• Build a small list and detail screen in Angular or React that calls a REST endpoint, with loading and error states.
• Outline an answer to the question about a product that is not meeting user needs: gather evidence, find the gap, test a change, measure.
• Outline a prioritization answer for competing stakeholder requests, with your criteria and how you communicate the no.

Deliverable: A working list and detail screen, plus two written outlines for the case-style questions.

Day 7 — Behavioral run-through

• Write four STAR stories for the troubleshooting, conflict, pressure and feedback questions, each with a concrete result.
• Say all four aloud, keeping the action step the longest, and cut anything that does not show your own decision.
• Write three questions to ask team members and hiring managers about their Agile or Scrum routine, code review and the team's stack.

Deliverable: Four STAR stories spoken aloud and a list of three questions for the team conversation.

Behavioral stories to have ready

Candidates describe the third stage as being about values and teamwork, and the fourth as conversations with team members and hiring managers. For a Software Engineer working in cross-functional teams on applications that hold sensitive information, the best stories show a decision you made, who you worked with and what happened as a result.

1. Describe a time you had to learn a new tool or adapt to a change in direction on a project.
2. Tell me about a time you disagreed with a stakeholder's priorities and how you handled it.

Explain a time when you had to troubleshoot a complex technical issue.

Medium · Technical / Domain Questions

Approach

1. Choose a bug whose cause was not obvious from the first symptom, such as an intermittent failure, a problem that appeared only in one environment, or a defect between two services. Open with two sentences on the symptom and who was affected, then spend most of the answer on how you found the cause.
2. Narrate the debugging sequence in order: reproduce it or capture a failing request id, narrow the surface (compare working and failing environments, bisect the recent commits or deploys, toggle a feature flag), form a hypothesis, then name the evidence that confirmed it, such as a log line, trace, query plan or debugger session, and any hypotheses you ruled out.
3. Separate the mitigation from the fix. Say what you did to stop the damage first (rollback, flag, workaround) and what the real fix was, then the regression test and the monitoring or alert you added so it cannot recur silently.
4. If the system handled sensitive data, say how you kept it out of logs, tickets and chat while investigating, for example by masking identifiers. That shows judgment that matters in a health care setting.
5. Avoid a story that ends with restarting the service and moving on, or one where the cause is stated without how you proved it.

Follow-up

• How did you confirm that was the root cause and not a coincidence?
• What did you change so the same failure would be caught earlier next time?
• At what point did you decide to ask for help, and who did you pull in?

Tell me about a time you had a conflict with a team member. How did you resolve it?

Medium · Behavioral / Leadership

Approach

1. Use STAR with a real technical or process disagreement, such as an API contract, a review comment, an approach to a migration or the scope of a release. Describe the other person's position fairly and in a way they would recognise, so the story is not a villain narrative.
2. In the action step, show the sequence: you talked to them directly first, asked what constraint or risk was driving their view, and then agreed on how to decide, for example a small prototype, a measurement or a short written comparison of options. Involve a lead only if you were genuinely stuck, and say so.
3. State the result concretely: what was decided, what shipped, and how the working relationship looked afterwards. If you changed your mind in part, say that; it makes the story more credible.
4. Avoid stories where you simply won, where you gave in without discussion, or where the conflict was about personality rather than the work.

Follow-up

• What did the other person get right that you initially missed?
• What would you have done if they had not agreed after that conversation?
• How do you work with that person now?

Describe a situation where you had to work under pressure. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Pick a situation with a real constraint, such as a release deadline, a production incident or a sudden change in scope. In the situation and task steps, say what was at stake and what the deadline or pressure actually was.
2. Show triage: what you cut or deferred, what you refused to cut (tests, security checks, review), and how you made that call. Name how you told your team and stakeholders early about risk to the date, instead of at the last moment.
3. Report the outcome with facts, including the cost: for example a follow-up ticket for shortcuts you took, and whether the shortcut was later paid back.
4. Do not make the story only about long hours. The strongest version shows you prioritised and communicated, and that the result was sustainable.

Follow-up

• What did you cut, and how did you make sure it was not forgotten?
• What did you tell stakeholders when the date was at risk?
• Would you take the same shortcuts again?

How do you handle feedback on your work?

Medium · Behavioral / Leadership

Approach

1. Lead with one specific piece of feedback, such as a code review comment, a design critique or a note from a manager, ideally one you first disagreed with or that stung a little. A general statement that you welcome feedback proves nothing without an example.
2. Show the steps: you listened and asked a clarifying question, checked whether the claim was true (reread the code, ran the case, asked a second person), then acted on it with a change you can describe.
3. Finish with the result and the habit it created, for example a checklist you now run before opening a pull request or a way of writing design docs. The listed responsibilities include code reviews, so a review-based example fits.
4. Avoid a story where the feedback was really a disguised strength, or one where you quietly decided the reviewer was wrong. If you declined feedback, explain how you decided and how you told them.

Follow-up

• Tell me about feedback you chose not to follow, and why.
• How do you react when a review comment is public and you disagree?
• What changed in the way you work after that feedback?