Cencora Software Engineer Interview Guide

The 60-second brief

Candidate reports describe the Software Engineer role at Cencora in general terms: improving existing software applications and building new tools and systems that support operations, inside cross-functional teams. Day-to-day work is described as coding, turning requirements from product managers, designers and other engineers into technical specifications, taking part in code reviews, and troubleshooting and debugging. The reports do not name specific products or teams, so this guide is built around the stack and question types candidates list.

This guide is for candidates interviewing for a Software Engineer position at Cencora. It covers the four reported rounds, all 19 reported questions (coding, database and SQL Server work, REST and microservices design, production debugging and behavioral prompts), the requirements candidates describe (C#, Java or Python, SQL Server and NoSQL, Agile and Scrum), and a seven-day plan that practises them.

Candidates report four rounds over roughly 3-5 weeks: Phone Screen, Multiple Interviews, Technical Challenges and Team Discussions. Each stage is described only briefly, so the guide prepares you for every reported question type instead of guessing which one lands in which round.

Focus areas

• SQL
• React
• Microsoft SQL Server

Overview

The topics candidates tie to this role are SQL, Microsoft SQL Server, general database concepts, SSIS (SQL Server Integration Services) and React. The requirements they describe list C#, Java or Python, web frameworks and API design, SQL Server and NoSQL databases, and Agile or Scrum practice. Cloud (Microsoft Azure), CI/CD and Docker appear as nice-to-have. That is a backend-and-data-leaning stack with some front-end exposure, so your preparation should be weighted toward databases, APIs and solid general coding.

The 19 reported questions fall into five groups. Technical and domain questions ask about programming paradigms (OOP versus functional), error management, RESTful API principles, .NET Framework features you have used and asynchronous programming. Design questions cover database schema design, a microservices architecture, API design considerations and monolith versus distributed trade-offs. Problem-solving questions ask how you would diagnose an underperforming system, optimize a slow SQL query and handle a critical production bug. Coding questions are reversing a linked list, depth-first versus breadth-first search and the longest common substring. Behavioral questions cover a challenging project, prioritizing deadlines, team conflict and communicating with non-technical stakeholders.

Many of these are open-ended explanation questions rather than puzzles, so the preparation is about having a concrete example behind every concept. If you are asked which .NET Framework features you have used, a list of features is weaker than two features tied to something you built. If you do not work in .NET, say so and map the question to the equivalent in your own stack. Do the same for async: know what the runtime does, not only the keywords.

Because the stack lists SQL Server and SSIS, treat the database as a first-class topic: schema design, indexes, reading an execution plan and the shape of an ETL load all fit the reported questions on schema design and slow queries. Finish with timed, spoken practice. The Team Discussions stage is described as one-on-one conversations about collaboration and communication, so a prepared set of project and conflict stories matters as much as the technical drills.

The Cencora interview process

Candidates report four stages and an overall timeline of roughly 3-5 weeks. The descriptions below are what candidates say about each stage; formats and durations are not published.

Phone Screen

Candidates describe the opening stage as a phone screen that checks fit for the role and the organization. Nothing more about its format is reported. Prepare for a conversation that can reach your background and the stack named in the role requirements: C#, Java or Python, SQL Server, API design. Have one project ready that shows that stack in use and a plain reason for wanting this kind of work.

What to demonstrate

• Fit for the role and the organization, as the stage is described
• How well your background lines up with the languages and databases the role lists
• How clearly you summarize your own experience

How to prepare

• Write a short walkthrough of your work history that names the languages, databases and API work you have actually done.
• Choose the project you would discuss if the conversation turns to SQL Server, schema design or ETL work with SSIS.
• Be able to say which of C#, Java and Python you are strongest in, and what you have built with it.

Multiple Interviews

Candidates report a set of further interviews that mix technical and behavioral assessment. Reports list technical, design, problem-solving and behavioral question groups but do not say which sit in which interview, so prepare all of them. The technical group includes OOP versus functional programming, error management, REST principles, .NET Framework features and asynchronous programming. The design group includes schema design, microservices, API design and monolith versus distributed trade-offs.

What to demonstrate

• Technical knowledge of paradigms, REST, asynchronous programming and the languages you list
• Design reasoning on schemas, APIs and service boundaries
• Behavioral answers about projects, deadlines and teamwork

How to prepare

• Answer the programming paradigms, REST and asynchronous programming questions aloud, each with an example from code you wrote.
• Outline a schema, a REST API and a microservices split for one application you know well, with the trade-offs written down.
• Prepare four behavioral stories (challenging project, deadlines, conflict, stakeholders) that you can also reuse for error management.

Technical Challenges

Candidates describe this stage as technical challenges that test coding and problem-solving. Whether it is live or a take-home is not stated, so ask the recruiter. The coding questions candidates report are reversing a linked list, comparing depth-first and breadth-first search, and finding the longest common substring. The problem-solving questions are diagnosing a slow system, optimizing a slow SQL query and handling a critical production bug.

What to demonstrate

• Working code on classic data-structure and string problems
• Problem-solving approach on performance and production scenarios
• Handling of edge cases such as empty input or a single node

How to prepare

• Write the linked list reversal, a DFS and a BFS, and the longest common substring from scratch in the language you will use, with edge-case tests.
• Practise tuning a slow SQL Server query: read the actual execution plan, find the scan or key lookup, then fix it with an index or a rewrite.
• Rehearse a fixed sequence for an underperforming system and for a production bug: confirm, scope, mitigate, find the cause, prevent recurrence.

Team Discussions

Candidates describe one-on-one interviews with team members, aimed at collaboration and communication. This is where behavioral prompts such as resolving a team conflict, communicating with non-technical stakeholders and prioritizing competing deadlines are the natural practice. Role descriptions also mention code reviews and working with product managers and designers, so be ready to talk about how you give and receive review feedback.

What to demonstrate

• Collaboration with teammates, as the stage is described
• Communication, including with non-technical people
• Ability to describe past work and your own contribution

How to prepare

• Write each story in first person singular so your own decisions are clear, with the outcome stated as a result.
• Prepare one example of a code review disagreement and one of explaining a technical trade-off to a non-technical person.
• Write a few questions about how the team works day to day, such as review habits and how Agile or Scrum is run.

Where candidates lose points

Explaining REST, async or microservices as a definition with no example behind it

For each reported technical question, prepare one concrete case from your own work, such as a resource-oriented endpoint you designed or an awaited call that removed a blocked thread. Put the example first and the definition second.

Losing the next pointer while reversing the linked list, or confusing longest common substring with longest common subsequence

For the reversal, hold previous, current and next explicitly and test empty, one-node and two-node lists. For the substring, say aloud that it must be contiguous, then explain the dynamic-programming table where a mismatch resets the cell to zero.

Tuning a slow query by guessing at indexes instead of looking at the execution plan

Practise a fixed sequence on SQL Server: capture the actual plan, find the scan, key lookup or bad row estimate, check the predicate can use an index, then change one thing and compare reads.

Answering the microservices or monolith question with a buzzword list and no case for when not to split

Start from the problem: how many teams, how often each part changes, and where failure must be isolated. Name the cost you take on (network calls, distributed data, deployment) and say when a monolith is the right answer.

Telling behavioral stories in 'we' so your own contribution never shows, or with no result

Write each of the four reported behavioral stories in first person singular with a measurable outcome, then say it aloud to check that your decision is the centre of the story.

Questions & practice

Can you explain the concept of asynchronous programming and its advantages?

Medium · Technical / Domain Questions

Approach

1. Define it precisely. Asynchronous code starts an operation, typically I/O, and frees the calling thread while it waits, then resumes in a continuation once the result arrives. It is about not blocking, which is different from parallelism (running CPU work on several cores at once).
2. Explain the mechanics in one language. In C#, the compiler turns an async method into a state machine, and awaiting an incomplete I/O Task returns the thread to the pool. In JavaScript, a single-threaded event loop runs promise continuations from the microtask queue.
3. Give the advantages with their reasons. A server can handle more concurrent requests because threads are not parked on database or HTTP calls, a UI thread stays responsive, and independent calls can overlap with Task.WhenAll or Promise.all.
4. Name the costs and pitfalls. Calling .Result or .Wait() can deadlock where a SynchronizationContext exists (classic ASP.NET, WinForms, WPF), and in ASP.NET Core it can starve the thread pool. Exceptions from async void cannot be caught by the caller, so it belongs only on event handlers. Libraries use ConfigureAwait(false), and long operations should pass a CancellationToken.
5. Say when not to use it. CPU-bound work gains nothing from async alone. Offload it with Task.Run or Parallel.For, or keep it synchronous.

Follow-up

• Why can blocking on .Result deadlock in one application type but not in another?
• With Task.WhenAll, if two of the tasks throw, which exceptions does the caller see?
• How would you add a timeout and cancellation to a slow downstream call?

Implement a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Use the iterative three-pointer reversal. Start with prev = null and curr = head. While curr is not null, save next = curr.next, set curr.next = prev, then move prev = curr and curr = next. Return prev as the new head. This runs in O(n) time and O(1) extra space.
2. Know the recursive version too. Reverse the rest of the list, then set head.next.next = head and head.next = null, and return the new head from the base case. It is O(n) time but uses O(n) call-stack depth, so a very long list can overflow the stack.
3. Cover the edge cases explicitly: an empty list, a single node and two nodes. The original head's next must end up as null, or the result contains a cycle.
4. Test it by walking the returned list and comparing it with the expected sequence. Mention that a doubly linked list is reversed by swapping each node's prev and next pointers.

Follow-up

• Reverse only the nodes between positions m and n, in one pass.
• Reverse the list in groups of k nodes.
• How would you detect a cycle in the list before reversing it?

Explain the difference between depth-first search and breadth-first search in graph traversal.

Medium · Coding / Algorithms

Approach

1. BFS uses a queue and visits nodes level by level. On an unweighted graph it finds the shortest path in number of edges. Its memory grows with the widest frontier.
2. DFS uses a stack, either explicit or the call stack, and goes as deep as possible before backtracking. Its memory grows with the depth. It suits cycle detection, topological sort, connected components, path existence and backtracking searches.
3. Both run in O(V + E) time with an adjacency list (O(V^2) with an adjacency matrix) and need O(V) space for the visited set.
4. Cover the implementation details. In BFS, mark a node visited when you enqueue it so it is not queued twice. Loop over all vertices to handle disconnected graphs. Switch to iterative DFS when recursion depth could exceed the stack limit.
5. Say where neither is enough: for weighted shortest paths, BFS is wrong. Use Dijkstra for non-negative weights, or 0-1 BFS with a deque when weights are only 0 or 1.

Follow-up

• How do you detect a cycle in a directed graph with DFS?
• Find the shortest path from one cell to another in a grid with obstacles.
• On a very wide, shallow tree, which traversal uses less memory, and why?

Write a program that finds the longest common substring between two strings.

Medium · Coding / Algorithms

Approach

1. Clarify the problem first. A substring is contiguous, unlike a subsequence. Ask whether to return the length or the string itself, whether matching is case-sensitive, and what to return for empty input.
2. Brute force: generate every substring of one string and search for it in the other, which is at least cubic. Mention it only as the baseline.
3. Use dynamic programming over common suffixes. dp[i][j] is the length of the longest common suffix of a[0..i-1] and b[0..j-1]: dp[i-1][j-1] + 1 if a[i-1] == b[j-1], otherwise 0. Track the maximum value and its end index to recover the substring. This is O(n*m) time.
4. Reduce memory to O(min(n, m)) with a single row, iterating j from m down to 1 so that dp[j-1] still holds the previous row's value. Point out the common mistake: on a mismatch the value resets to 0, not to max(left, up) as in longest common subsequence.
5. For large inputs, binary search on the length. If a common substring of length L exists, one of length L-1 does too. Check each length with Rabin-Karp rolling hashes and verify matches to rule out collisions, giving O((n + m) log min(n, m)) expected time. A suffix automaton or generalized suffix tree solves it in linear time.

Follow-up

• Return every distinct common substring of maximum length, not just one.
• Both strings have about 100,000 characters. What changes in your approach?
• How would you extend this to the longest substring common to k strings?

How would you approach designing a database schema for a new application?

Medium · System Design / Architecture

Approach

1. Start from the domain and the access patterns. List the entities, their relationships and cardinalities (one-to-many, and many-to-many through a junction table), the queries that must be fast, and the expected write volume.
2. Normalise to third normal form so each fact is stored once and updates cannot leave contradictions. Then denormalise on purpose for hot read paths or reporting, and say which copy is the source of truth.
3. Choose keys and constraints deliberately. A surrogate BIGINT IDENTITY key, or NEWSEQUENTIALID, avoids the page splits that random NEWID() GUIDs cause as a clustered key in SQL Server. Add UNIQUE constraints on natural keys, plus foreign keys, NOT NULL and CHECK constraints. Store money as DECIMAL rather than FLOAT, and timestamps as datetime2 in UTC or as datetimeoffset.
4. Plan the indexes from the queries: the clustered index, nonclustered indexes on foreign-key and filter columns, and INCLUDE columns to cover frequent reads. Note that every index adds write cost.
5. Cover lifecycle concerns: audit columns, soft versus hard delete, history (for example SQL Server system-versioned temporal tables), and versioned migrations. Say when a document store fits better, for example an aggregate that is always read whole with a flexible shape.

Follow-up

• A product's price changes after orders were placed. How do you model that so old orders stay correct?
• How would you add a NOT NULL column to a large table that is serving live traffic?
• When would you put part of this data in a NoSQL store instead?

Explain how you would approach optimizing a slow SQL query.

Medium · Problem-Solving / Case Studies

Approach

1. Measure before changing anything. Capture the actual execution plan, run with SET STATISTICS IO, TIME ON to see logical reads and CPU time, use Query Store to check whether the plan changed, and rule out blocking (LCK_M_* waits) as the real cause.
2. Read the plan for specific problems: scans where a seek was expected, key lookups, a large gap between estimated and actual row counts (often stale statistics, fixed with UPDATE STATISTICS), sorts or hash joins spilling to tempdb, and CONVERT_IMPLICIT warnings.
3. Make predicates sargable. Replace WHERE YEAR(OrderDate) = 2025 with a date range, avoid a wildcard at the start of a LIKE pattern, and match parameter types to column types, because an implicit conversion on the column side can prevent an index seek.
4. Index for the query: a composite index with equality columns first and the range column after them, plus INCLUDE columns to cover the SELECT list and remove key lookups. Weigh the extra write and storage cost.
5. Rewrite where needed: select only the columns you use, filter early, use EXISTS for existence checks, and replace row-by-row logic with set-based statements. Batch large updates. For parameter sniffing, compare OPTION (RECOMPILE) with OPTIMIZE FOR.

Follow-up

• The query is fast in SSMS but slow from the application. What could explain that?
• How do you get rid of a key lookup, and what does the fix cost?
• When would you decide not to add the index the plan suggests?

Explain the differences between various programming paradigms (e.g., OOP vs. functional programming).

Medium · Technical / Domain Questions

Approach

1. Define each paradigm by where state lives. OOP bundles mutable state with the methods that change it, and relies on encapsulation, inheritance and polymorphism through interfaces or virtual dispatch. Functional programming uses pure functions over immutable data, treats functions as values and pushes side effects to the edges.
2. Name the trade-off known as the expression problem. In OOP, adding a new type is cheap (one new class implements the interface), but adding a new operation means touching every class. With functional data types and pattern matching it is the reverse.
3. Give a concrete mixed example from a mainstream language. C# LINQ (Select, Where, Aggregate) and Java streams are functional style inside an object-oriented language, and C# records with with expressions give non-destructive updates.
4. Tie it to testing and concurrency. A pure function returns the same output for the same input, so it can be unit-tested without mocks, and immutable objects can be shared across threads without locks. The cost is extra allocation for the copies you make.
5. Briefly place the other paradigms: procedural code, declarative code (SQL says what result you want, not how to get it) and event-driven code. Close with when you would pick each style.

Follow-up

• How would you refactor a class with a lot of mutable fields so that its core logic is easier to test?
• A LINQ query over an IEnumerable is enumerated twice. What happens, and why can that be a problem?
• When does immutability cost more than it saves?

Describe the principles of RESTful APIs and how you implement them.

Medium · Technical / Domain Questions

Approach

1. List the REST constraints rather than only the HTTP verbs: client-server, stateless requests, cacheable responses, a uniform interface built on resources identified by URIs, and a layered system. Name resources with nouns and nest them only for real ownership, such as /orders/{id}/lines.
2. State method semantics precisely. GET is safe and idempotent. PUT and DELETE are idempotent. POST is not idempotent, and PATCH is not guaranteed to be. Return 201 Created with a Location header for a create and 204 for a delete with no body.
3. Use status codes that clients can branch on: 400 for malformed input, 401 when the caller is not authenticated and 403 when they are not allowed, 404, 409 for a state conflict, 429 for rate limiting, and 5xx only for server faults. Return a consistent error body such as RFC 9457 problem details, which ASP.NET Core emits for automatic validation failures on [ApiController] controllers.
4. Explain how you use HTTP itself for caching and concurrency. An ETag on GET lets If-None-Match return 304, and If-Match on an update returns 412 when someone else changed the resource first (optimistic concurrency).
5. Cover how you implement it in practice: attribute routing, model validation, pagination and filtering through query parameters, and a versioning scheme. Admit that most production APIs skip hypermedia (HATEOAS) and say why that is usually acceptable.

Follow-up

• What is the difference between PUT and PATCH, and what does idempotency mean for each?
• How would you let a client safely retry a POST that timed out?
• How would you introduce a breaking change without breaking existing clients?

What are the key features of the.NET Framework that you have utilized in your projects?

Medium · Technical / Domain Questions

Approach

1. Clarify the version first. .NET Framework (4.x, Windows-only) is a different product from modern cross-platform .NET (.NET Core and .NET 5+). Say which one each of your projects ran on.
2. Pick three or four features you used and tie each to a problem it solved, instead of reciting a list. Good candidates are async/await with the Task Parallel Library for I/O-bound services, LINQ for querying collections, Entity Framework or ADO.NET with parameterized SqlCommand against SQL Server, and ASP.NET Core dependency injection and middleware.
3. Show depth on at least one of them. For EF Core, explain change tracking, AsNoTracking for read-only queries, migrations, and how lazy loading causes N+1 queries. For DI, explain the Transient, Scoped and Singleton lifetimes and the captive-dependency bug where a scoped service is injected into a singleton.
4. Mention runtime behaviour you have had to reason about: generational garbage collection (gen 0/1/2 and the large object heap), IDisposable with using for connections and streams, and exception handling with structured logging.
5. End with a real outcome: a measurable improvement, or a bug a feature helped you find or fix.

Follow-up

• What is the difference between IEnumerable and IQueryable when you query through Entity Framework?
• What goes wrong if a scoped DbContext is injected into a singleton service?
• What would you check first when porting a .NET Framework 4.x application to modern .NET?

Describe how you would design a microservices architecture for a large-scale application.

Medium · System Design / Architecture

Approach

1. Draw service boundaries around business capabilities (bounded contexts), not technical layers. Each service owns its data, with no shared tables and no other service reading its database directly.
2. Choose communication per interaction. Use synchronous REST or gRPC when the caller needs an answer now, and asynchronous messaging through a queue or event bus for workflows. Put an API gateway in front for routing, authentication and rate limiting.
3. Handle consistency without distributed transactions. Use a saga (orchestrated or choreographed) with compensating actions, and a transactional outbox so the database write and the event publish cannot diverge. Make consumers idempotent, because brokers deliver at least once.
4. Build in resilience: timeouts on every call, retries with exponential backoff and jitter, circuit breakers and bulkheads. Avoid long synchronous call chains, where availability multiplies down.
5. Cover operations: per-service CI/CD and containers, health checks, centralised logs, and distributed tracing with correlation IDs (for example OpenTelemetry). State the trade-off honestly: for a small team, a modular monolith may be the better first step.

Follow-up

• A report needs data owned by three services. How do you serve it?
• How would you split an existing monolith into services incrementally?
• What happens if the same message is delivered twice, and how does your design cope?

What considerations do you take into account when designing an API?

Medium · System Design / Architecture

Approach

1. Start with the consumers: who calls the API (internal service, partner, browser), what they need to do, and what they do when a call fails. Then model resources and naming consistently across endpoints.
2. Define the contract before coding: request and response schemas in OpenAPI, input validation, correct status codes, and one error format with stable machine-readable codes that callers can branch on.
3. Design for retries. Make updates idempotent, accept an idempotency key on creates so a retried POST does not create duplicates, and for long-running work return 202 Accepted with a status resource.
4. Plan for scale. Cursor or keyset pagination stays fast and stable under inserts, while OFFSET pagination reads and discards the skipped rows. Add filtering and sorting, and rate limiting that returns 429 with Retry-After.
5. Cover security and evolution: OAuth 2.0 or OIDC bearer tokens, per-object authorization checks to prevent IDOR, TLS, and no secrets or personal data in URLs or logs. Prefer additive changes and use explicit versioning for breaking ones, with a deprecation window.

Follow-up

• Compare offset pagination with cursor pagination when rows are inserted while a client is paging.
• How would you rename a response field without breaking existing clients?
• A client times out on a create request and retries it. Walk through what happens on the server.

Discuss the trade-offs between monolithic and distributed systems.

Medium · System Design / Architecture

Approach

1. Define both precisely. A monolith is one deployable unit with in-process calls and usually one database. A distributed system splits functionality across processes that communicate over a network.
2. Monolith strengths: simple build, deploy and debugging; ACID transactions across modules; cheap in-process calls; easy refactoring. Weaknesses: the whole application scales as one unit, there is one release train, coupling tends to grow, and one bad module can take everything down.
3. Distributed strengths: independent deployment and scaling, fault isolation, and team autonomy. Costs: partial failures, network latency, eventual consistency (under a network partition, CAP forces a choice between consistency and availability), contract versioning, and the operational load of tracing and monitoring many services.
4. Give decision criteria rather than a verdict: number of teams, very different scaling profiles between components, conflicting release cadences, and how stable the domain boundaries are. Name the modular monolith, with enforced module boundaries, as a middle ground.
5. Describe the migration path: the strangler fig pattern, extracting first a module with a clear boundary and its own data.

Follow-up

• What is a distributed monolith, and how would you recognise one?
• How do you keep an operation consistent when it spans two services?
• What signal would tell you it is time to extract a module into its own service?

Given a scenario where a system is underperforming, how would you diagnose the issue?

Medium · Problem-Solving / Case Studies

Approach

1. Pin down the symptom first: which metric (p95 or p99 latency, throughput, error rate), since when, and for which users or endpoints. Compare against a baseline and check recent deploys, configuration changes and traffic shifts.
2. Work systematically. For each resource (CPU, memory, disk I/O, network, connection pools), check utilization, saturation and errors (the USE method). For each service, check request rate, errors and duration (the RED method).
3. Narrow down the layer with tracing or APM: which span dominates, whether the time is spent in the frontend, the API, the database or a downstream dependency.
4. Check the usual causes: slow or blocked queries (in SQL Server, Query Store, wait statistics and sys.dm_exec_requests for blocking), N+1 queries from an ORM, connection pool exhaustion, thread-pool starvation from blocking on async code, GC pressure, lock contention, and a cache that is missing or has gone cold.
5. Change one variable at a time, reproduce the problem under a load test, confirm the fix with the same metric that showed it, and add an alert so a regression is caught next time.

Follow-up

• Latency has doubled but CPU is low. Where do you look next?
• Only p99 regressed and the median is unchanged. What does that suggest?
• How do you prove that your fix, and not a drop in traffic, resolved it?

If a critical bug is reported in production, what steps would you take to resolve it?

Medium · Problem-Solving / Case Studies

Approach

1. Triage first: who is affected, how many users, and whether data is being corrupted. Open an incident, name an owner, and tell stakeholders when the next update will come.
2. Mitigate before finding the root cause: roll back the last deploy, turn off a feature flag, fail over or scale out. Stopping the damage comes before understanding it.
3. Investigate with evidence: logs filtered by correlation ID, metrics around the start time, and the diff of recent code, configuration and dependency changes. Reproduce the bug in a lower environment with data shaped like production.
4. Fix it properly: write a failing test that reproduces the bug, fix it, get it reviewed, ship through the normal pipeline as a hotfix, confirm in production with the metric that showed the problem, and repair any data the bug damaged.
5. Close with a blameless postmortem: timeline, root cause, why tests and alerts did not catch it, and owned action items.

Follow-up

• The release included a schema migration, so a rollback is not possible. What do you do?
• You cannot reproduce the bug locally. How do you proceed?
• How do you decide between a hotfix and waiting for the next scheduled release?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

1. Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
2. Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
3. Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
4. Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

• The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
• Where should the 10-second timeout number actually come from?

Suggested practice checklist

The plan follows the reported topics: SQL Server and schema design first, then languages and APIs, coding, architecture and diagnosis, behavioral stories, and a full run-through. Each day names the reported questions it practises.

Day 1 — Map the loop and your gaps

• Write the four reported rounds (Phone Screen, Multiple Interviews, Technical Challenges, Team Discussions) and the five question groups, then grade yourself one to five on each.
• List the stack from the role requirements (C#, Java or Python, SQL Server, NoSQL, REST, Agile/Scrum) and mark which you have used in real projects.
• Write a short walkthrough of your work history aimed at the phone screen.

Deliverable: A one-page self-assessment covering the rounds, the question groups and the stack, plus a written work-history walkthrough.

Day 2 — SQL Server, schema design and ETL

• Design a schema for an application you know: choose keys, relationships, constraints and indexes, and write down where you would denormalize and why.
• Take a slow query, capture its execution plan, find the scan or key lookup, and fix it with an index or a rewrite.
• Explain SSIS in your own words: control flow versus data flow, a staging table, and how you handle bad rows.

Deliverable: A schema diagram with indexing notes, a before-and-after query with plan observations, and a short written ETL outline.

Day 3 — Languages, APIs and async

• Answer aloud the OOP versus functional comparison and the asynchronous programming question, each with an example from your own code.
• Write a REST API outline for one resource: URLs, verbs, status codes, pagination, versioning, idempotent retries and error format.
• List the .NET features you have used with a project for each, or the equivalent in the Java or Python stack you use.
• Review how a React component fetches data and manages state, since React is among the reported topics.

Deliverable: Spoken answers to five technical questions, a one-resource API sketch, and a feature-to-project list.

Day 4 — Coding drills

• Write the iterative linked list reversal and a recursive version, with tests for empty, one-node and two-node lists.
• Implement DFS (recursive and iterative with a stack) and BFS (queue) on an adjacency list, with a visited set and a note on when each is the right tool.
• Write longest common substring with a dynamic-programming table and state the time and space complexity.

Deliverable: Three tested solutions in your chosen language plus a written complexity note for each.

Day 5 — Architecture and production diagnosis

• Outline a microservices design for an application you know, then argue the monolith alternative and when each wins.
• Write a fixed diagnosis sequence for an underperforming system and a separate one for a critical production bug.
• Work through the practice debugging scenario about one endpoint stalling deliveries to other destinations, and say what you would measure first.

Deliverable: A microservices-versus-monolith trade-off table and two written diagnosis checklists, with one practice scenario answered aloud.

Day 6 — Behavioral story bank

• Write first-person stories for the challenging project, deadline prioritization, team conflict and non-technical stakeholder questions.
• Prepare an answer on error management that combines the principles with one real incident.
• Say each story aloud and cut anything that does not show a decision you made or a result.

Deliverable: Five written stories with outcomes, each rehearsed aloud once.

Day 7 — Full run-through

• Do a mixed spoken run: one design question, one SQL question, one coding problem written out, and two behavioral stories.
• Redo the weakest item from days 2 to 6 and fix the specific gap.
• Prepare questions for the team about review habits, Agile or Scrum practice and what the first projects would be.

Deliverable: A scored practice run, a list of gaps fixed, and a set of questions to ask.

Behavioral and team-discussion preparation

Candidates report behavioral questions in the Multiple Interviews stage, and the Team Discussions stage is described as one-on-one interviews about collaboration and communication. For this role that means stories about owning a project, planning around deadlines, handling disagreement in a team that includes product managers, designers and other engineers, and explaining technical work to people outside engineering.

1. How do you handle situations where team members have differing opinions?

How do you handle error management in your code?

Medium · Technical / Domain Questions

Approach

1. Open with the principle: validate input at the boundary, fail fast on states you cannot continue from, and catch an exception only at a layer that can do something useful with it (retry, translate, compensate). Say that swallowing an exception to keep things quiet is the main failure.
2. Name the mechanics in your language: specific exception types rather than a catch-all, deterministic cleanup (using or try/finally in C#, try-with-resources in Java, context managers in Python), and rethrowing without losing the stack trace (throw; rather than throw ex; in C#, or wrapping with an inner exception for added context).
3. Cover the service edge: one central handler converts exceptions to consistent API errors (status code, machine-readable code, correlation id) without leaking stack traces, and the error is logged once with context at that boundary rather than at every layer. Retry only transient faults and only idempotent operations, with backoff.
4. Mention async: an exception inside a Task surfaces when you await it, and fire-and-forget calls or async void can lose it. Close with one real incident from your work where an error was swallowed or mishandled, what it cost and what you changed.

Follow-up

• When do you catch and rethrow instead of letting the exception propagate?
• How do you decide what is logged and what the caller sees?
• A multi-step database update fails halfway through: how do you keep data consistent?

Describe a challenging project you worked on. What was your role, and what was the outcome?

Medium · Behavioral / Leadership

Approach

1. Choose a project where you owned a decision, and say in one sentence why it was hard (a constraint, an unclear requirement, a failing system, an unfamiliar technology). Keep the setup short and spend most of the answer on what you did.
2. State your role in the first person and be exact about it: what you designed, built or decided versus what teammates did. Replacing every 'I' with 'we' is the most common way this answer fails.
3. Walk through two or three real decisions with the alternatives you rejected and why, including one thing that went wrong and how you corrected it.
4. Give the outcome as something checkable (a defect rate, a load time, a release shipped, a process adopted) and finish with what you would do differently.

Follow-up

• What was the hardest decision, and what alternatives did you reject?
• What went wrong, and how did you find out?
• What would you change if you ran the project again?

How do you prioritize tasks when you have multiple deadlines?

Medium · Behavioral / Leadership

Approach

1. Show a method, not effort: list everything due, then rank by deadline, impact if missed, dependencies on other people and effort to finish. Say you check whether any item blocks someone else, because that usually moves it up.
2. Tell one real situation with specifics: the competing deadlines, what you put first and why, and what you deliberately postponed or cut.
3. Show that you renegotiated instead of silently absorbing the overload. You told stakeholders early, offered options (reduce scope, move a date, get help) and agreed the new plan in writing.
4. State the result and how you keep it from recurring, such as a visible task list or board, buffer in estimates, and a single place where new requests are triaged. 'I work longer hours' is the answer that sinks this question.

Follow-up

• Two managers each say their task is the top priority: what do you do?
• How do you handle a deadline that becomes unachievable halfway through the work?
• How do you decide when a production issue interrupts planned work?

Give an example of a time you had to resolve a conflict within your team.

Medium · Behavioral / Leadership

Approach

1. Pick a real disagreement that mattered, such as an API design choice, a code review dispute or a clash over scope, and not a personality complaint. Describe the two positions fairly, including the strongest point of the other person's view.
2. Show what you did first: spoke to the person directly and privately, asked what they were optimizing for, and tried to understand their reasons before arguing yours.
3. Show how it was resolved with evidence rather than status: a small prototype, a benchmark, a written comparison of trade-offs, or involving a tech lead for a tiebreak when the two of you could not settle it.
4. End with the outcome and the relationship afterwards, including a case where you were the one who changed your mind. A story in which you simply won, or in which the other person is the villain, sinks the answer.

Follow-up

• What if the other person still disagreed after you showed the data?
• What did you learn about how you handle disagreement?
• How do you give critical feedback in a code review without causing friction?

How do you ensure effective communication with non-technical stakeholders?

Medium · Behavioral / Leadership

Approach

1. Anchor on a specific case: a stakeholder who is not an engineer (a product owner, an operations lead or an analyst) and a technical topic that mattered to them, such as a delay, a data issue, a trade-off between two options or an outage.
2. Show the translation: you described impact, risk and options in their terms (what changes for users, what it costs in time, what happens if nothing is done) and avoided jargon, and offered a recommendation with the trade-off.
3. Describe the mechanics of staying aligned: a short written summary after each conversation, demos of working software instead of status descriptions, and a regular update rhythm so surprises come early.
4. Show you checked understanding by asking them to restate the decision or the next step, and give the result, such as a decision made faster, a requirement corrected before build or a launch with no surprises.

Follow-up

• How do you tell a stakeholder that a deadline will be missed?
• How do you handle a request that is technically unwise?
• How do you explain a technical trade-off to a stakeholder without oversimplifying?