Interview guides · A.T. Kearney

A.T. Kearney Software Engineer Interview Guide

A.T. Kearney Software Engineer interview guide: reported rounds, system design, integration and client-facing questions, and a 7-day prep plan.

The 60-second brief

A.T. Kearney, also called Kearney, is a global management consulting firm. Candidates describe software engineers joining specialised practice teams there, with Kearney PERLab (Product Excellence and Recovery Lab) and Kearney Activate named as examples. Reports describe PERLab work as touching physical products: teardowns, hardware-software co-design and component cost analysis, with EV powertrain systems as one example domain. Activate work is described as deploying and tuning cloud platforms for customer engagement, with Salesforce Marketing Cloud named among the platforms. In both, the engineer works on client problems next to consultants, product managers, client engineers and business analysts, and the problem space changes from project to project.

This guide is for candidates interviewing for a Software Engineer role at A.T. Kearney, whether the target team is closer to the physical-product side (PERLab-style work) or the cloud-platform side (Activate-style work). It covers the three reported stages, the twelve reported questions grouped into project deep-dives, architecture and domain questions, and client-facing scenarios, and a seven-day plan. It does not cover pay.

Candidates report three stages over roughly 3-5 weeks: a Recruiter Screen, Technical Interviews and Panel Interviews. Reports mention a collaborative panel, along with occasional scheduling shifts.

Focus areas

Software Engineering (General)
EV Powertrain Systems (Domain Knowledge)
Salesforce Marketing Cloud (Platform Concepts)

Overview

The reported work sits between engineering and consulting. Engineers are described as the technical voice on a mixed team: designing architectures, writing modular code and configuring enterprise platforms to remove a specific client bottleneck. The practical consequence for preparation is that a correct answer is not enough on its own. Each technical answer also has to carry a reason (why this design, at this cost, for this client team) and a plain-language version you could give to someone outside engineering.

Candidates describe three areas of evaluation: architecture and system design (scalability, integration patterns, cost-to-performance trade-offs), client-facing problem solving (requirements gathering, stakeholder alignment, explaining the return on a refactor), and domain-specific execution in the team you are joining. The domain half splits. Physical-product teams are associated with EV powertrain modelling and hardware-software integration; cloud-marketing teams are associated with platform configuration, with Salesforce Marketing Cloud, AWS and Azure named. Decide early which track matches your background and go deep there, while keeping the shared material (integration, scalability, build versus buy) sharp.

Candidates also report that the emphasis falls on system design, project walkthroughs and domain problems rather than algorithm puzzles, and that panel members may open your resume and ask about older projects. So the highest-value preparation is an audit of every resume bullet (architecture, technology choices, the trade-off you made, the outcome) plus a small set of STAR stories that end in a business result. The twelve reported questions in this guide are the rehearsal set; the practice-library items in the plan cover the integration and ingestion mechanics behind them.

The A.T. Kearney interview process

Candidates report these three stages, starting with the recruiter conversation. The reported questions are not tied to a specific stage, so prepare the full set before the Technical Interviews. The exact content of each conversation varies by team and location.

Recruiter Screen

The process opens with a recruiter conversation that covers your experience so far and how it matches the opening. Separately from the screen, the requirements listed for the role include a computer science, electrical or mechanical engineering degree (or a related field), hands-on depth in one specific domain, and roughly three or more years of professional engineering experience for standard roles. Treat the call as a short pitch: your domain, your strongest project, and why consulting engineering rather than a product company.

What to demonstrate

Your background, as the stage is described
Fit for the role, as the stage is described

How to prepare

Prepare a two-minute walk through your career that ends on the domain you want to work in and one project that proves it.
State your years of experience and your strongest platform or domain plainly, matching the requirements in the job posting.
Ask the recruiter for the remaining stages and how scheduling works, since some candidates report sudden shifts in timing.

Technical Interviews

Candidates report a set of technical conversations that dig into what you know and can do, with the weight on system design, project walkthroughs and domain-specific problems rather than algorithm puzzles. Resume questions are reported to push on why you made a decision, not only how you built it. Whatever the prompt, clarify the goal, state your assumptions and split the problem into parts before naming a solution.

What to demonstrate

Working command of the technologies in your target job posting
Whether you can defend design decisions and name the trade-off you accepted
Structured breakdown of an open-ended technical scenario
Testing and validation approach: unit, integration and user acceptance testing

How to prepare

Rehearse the bottleneck-in-a-legacy-system answer as a sequence: measure first, narrow the suspect, change one thing, re-measure.
Write the integration answer as a list of failure modes (duplicates, ordering, partial failure, schema drift) and the control for each.
Make a one-page list of scalability and availability patterns, each with the failure it protects against and the cost it adds.
For one resume project, be ready to say what was unit-tested, what was integration-tested, what went through user acceptance sign-off, and how a regression was caught.

Panel Interviews

Candidates describe a panel stage that judges two things at once: how well your technical background matches the team, and cultural fit. Many reports call the panel collaborative and friendly, and some say panel members open the resume and ask detailed questions about past projects. Prepare to defend your engineering history line by line and to talk to non-engineers about cost, risk and timeline.

What to demonstrate

Technical alignment with the team you are joining
Cultural fit, as the stage is described
Ability to explain technical decisions in business terms such as ROI, maintenance cost and delivery time

How to prepare

Go through your resume bullet by bullet and write architecture, technology choices, outcome and one decision you would change.
Prepare STAR stories for a production failure, a client or product-owner disagreement, an executive explanation and shifting requirements, each ending in a result you can quantify.
Write two or three questions of your own, for example how engineers and consulting teams work together, and how code quality and handoff are handled when an engagement ends.

Where candidates lose points

Describing what you built on your resume but not why you chose it

For every bullet, write the decision, the alternative you rejected and the cost you accepted. Candidates report panel members opening the resume and asking about older projects, so practise explaining the reasoning, not only the technology list.

Jumping into a design or fix for the legacy bottleneck or the scalability question without clarifying

Ask what the load, the failure impact and the budget are, state assumptions aloud, and break the problem into components. For the legacy case, begin with how you would get visibility (timing, profiling, characterization tests) before changing code.

Presenting an integration story without failure modes

Name duplicates after retries, out-of-order updates, schema drift and partial failure, and the control you used for each: idempotency keys, versions, a dead-letter store and reconciliation.

Answering build versus buy with a preference instead of criteria

Compare total cost over the life of the system, fit to requirements, delivery time, lock-in, the client team's ability to maintain it, and an exit path. Be ready to present an off-the-shelf recommendation to a client who wants a custom build.

Telling client-facing stories in "we" with no result, or bluffing on a platform or domain topic

Say what you personally decided and end with a measurable result for the client. If you do not know a platform feature or an EV powertrain detail, say so, explain how you would find out, and move to a related area you know.

Questions & practice

How do you manage your delivery timeline when client requirements are ambiguous or constantly shifting?

Medium · Behavioral & Client-Facing Scenarios

Approach

Answer with a real engagement, then describe the method: separate what is known from what is open, and turn each open question into a decision with an owner and a date rather than a vague risk.
Time-box discovery: short spikes or prototypes to resolve the riskiest unknowns first, then estimate in ranges and narrow them as answers arrive instead of committing to a single date on day one.
Deliver in thin vertical slices with frequent demos so the client reacts to working software; prioritize with a method such as MoSCoW so the must-haves land even if scope moves.
Make change explicit: each new or changed requirement is traded against scope, date or cost and written in a decision log the client signs off, which keeps the timeline honest without refusing change.
Build for changeability where change is likely (configuration over hard-coding, feature flags, clean interfaces at the volatile edges), and close the story with the outcome: what shipped, when, and what the change process saved.

Follow-up

The client adds a major feature one week before the deadline. What do you do?
How do you estimate a piece of work when half its requirements are still unknown?
Tell me about a time this approach failed and the date slipped anyway. What did you learn?

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

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

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.
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.
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.
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?

Walk me through the most complex software project on your resume. What was your technical approach, and what t

Medium · Technical & Project Deep-Dives

Walk me through the most complex software project on your resume. What was your technical approach, and what trade-offs did you make?

Approach

Choose the project where you personally made the architectural calls, then open with the constraints that shaped it: data volume, latency or throughput target, team size, deadline and the systems it had to talk to.
Sketch the architecture as 4-6 named components and the data flow between them (for example API layer, queue, workers, relational store, cache), so every later trade-off can point at a box.
Give two or three trade-offs in the form 'I chose X over Y because Z, and accepted cost C': for example a relational database over a document store for transactional joins, accepting a schema migration process; or a queue for decoupling, accepting eventual consistency and retry handling.
Close with measurable results (latency, cost, error rate, delivery date) and the business effect, then one thing you would change with hindsight and why it was not done at the time.
Rehearse every bullet on your CV at this depth: each technology named there needs a one-sentence reason it was picked over its obvious alternative.

Follow-up

Which of those trade-offs would you reverse today, and what would it cost to migrate?
Where did the system fail or come closest to failing under load, and how did you find out?
If the client's data volume grew tenfold, which component would you redesign first?

How do you approach optimizing a system bottleneck when you have limited data or visibility into the legacy co

Medium · Technical & Project Deep-Dives

How do you approach optimizing a system bottleneck when you have limited data or visibility into the legacy codebase?

Approach

Turn the complaint into a number before touching code: which operation is slow, its p50/p95/p99 latency or throughput, and the target. Reproduce it in a non-production environment or capture it from production traffic.
Gain visibility without rewriting: request timing at service boundaries, distributed tracing or APM agents, the database slow-query log and EXPLAIN ANALYZE, and a sampling profiler (py-spy, async-profiler, perf) that attaches to a running process without code changes.
Check resources with the USE method (utilization, saturation, errors) for CPU, memory, disk, network and connection pools; a saturated pool or lock contention often looks like slow code.
Use Amdahl's law to pick the target: if a component takes fraction p of the time and you speed it up by s, total speedup is 1 / ((1 - p) + p / s), so a 10x fix on 20% of the time gives only about 1.2x overall.
Protect the legacy behaviour with characterization (golden-master) tests, ship the cheapest reversible fix first (missing index, N+1 query batching, caching, pool sizing) behind a flag, and confirm with a before/after measurement under the same load.

Follow-up

The profiler shows time spread evenly with no hotspot. What do you look at next?
How would you roll back if the fix improves latency but changes an output the business depends on?
How do you explain to a non-technical sponsor why the first fix delivered less than they hoped?

How would you approach modeling and optimizing an EV powertrain system to balance thermal efficiency against m

Medium · Domain-Specific & Architecture Questions

How would you approach modeling and optimizing an EV powertrain system to balance thermal efficiency against manufacturing cost?

Approach

Fix the system boundary and the evaluation basis first: which components are in scope (motor, inverter, battery, cooling loop), which drive cycle or duty profile the losses are measured over (for example WLTP), and which temperatures are hard limits (winding insulation class, semiconductor junction temperature, cell temperature).
Build a loss model per component: copper loss I^2 R (with resistance rising with temperature), iron loss from hysteresis and eddy currents (Steinmetz form P = k f^a B^b), and inverter conduction plus switching losses; integrate over the cycle to get energy lost, not just peak efficiency.
Feed the losses into a lumped-parameter thermal network (thermal resistances and capacitances between hotspots and coolant) and calibrate it against FEA or test-bench data; it runs fast enough to sit inside an optimization loop.
Build a cost model from the bill of materials and process: copper and magnet mass, rare-earth content, Si versus SiC switches (SiC typically lowers switching loss at a higher part cost), cooling architecture. Then treat temperature limits as constraints and cost versus cycle efficiency as two objectives.
Search the design space with design of experiments and surrogate models (for example Latin hypercube sampling plus a Gaussian-process or polynomial surrogate) and a multi-objective method such as NSGA-II or an epsilon-constraint sweep; present the Pareto front and a sensitivity analysis showing which parameters drive cost.

Follow-up

How would you validate the thermal model before trusting its optimum?
Magnet material prices swing sharply. How does your optimization handle that uncertainty?
How would you present the Pareto front to a client executive who wants one recommended design?

What architectural patterns do you rely on to ensure scalability and high availability in cloud-native applica

Medium · Domain-Specific & Architecture Questions

What architectural patterns do you rely on to ensure scalability and high availability in cloud-native applications?

Approach

Keep application tiers stateless behind a load balancer so they scale horizontally with autoscaling on CPU, request rate or queue depth; push session and state into managed stores (database, cache, object storage).
Remove single points of failure: deploy across multiple availability zones, use health checks with separate liveness and readiness probes, and run the database with a standby or replicas and automated failover. Be able to do the availability arithmetic: components in series multiply (99.9% x 99.9% is about 99.8%), redundant copies in parallel give 1 - (1 - a)^n if failures are independent.
Decouple with asynchronous messaging: a queue or event stream between producers and consumers absorbs spikes, with idempotent consumers, at-least-once delivery and a dead-letter queue for poison messages.
Contain failures with timeouts on every remote call, retries with exponential backoff and jitter, circuit breakers and bulkheads, so one slow dependency does not exhaust threads or connections everywhere.
Scale the data layer deliberately: cache-aside with TTLs, read replicas for read-heavy load, partitioning or sharding by a key that spreads writes; ship safely with blue-green or canary deploys and infrastructure as code. Name the trade-off: multi-region active-active raises cost and brings write-conflict and consistency problems.

Follow-up

A popular cache key expires and the database is flooded. How do you prevent the stampede?
How would you choose RTO and RPO targets with a client, and what architecture does each level imply?
Your queue backlog keeps growing during a traffic spike. What do you check and change?

How do you evaluate whether to build a custom software solution versus integrating a third-party enterprise pl

Medium · Domain-Specific & Architecture Questions

How do you evaluate whether to build a custom software solution versus integrating a third-party enterprise platform for a client?

Approach

Start with whether the capability differentiates the client's business or is commodity: commodity functions (CRM, marketing automation, billing) usually favour buying; a capability that is the client's edge, or that no product covers, favours building.
Run a fit-gap analysis against the prioritized requirements: what the platform covers out of the box, what needs configuration, and what needs custom code. Heavy customization of a bought platform often gives the costs of both options.
Compare total cost of ownership over several years, not the first-year price: licences or usage fees, implementation, integration, hosting, support staff and upgrades for the platform, against build effort, ongoing maintenance and the team needed to own the code.
Weigh risks and constraints: time to value, vendor lock-in and data export, API rate limits, security and compliance requirements, the vendor's roadmap, and whether the client's own team can run what is delivered after handover.
Score the options in a weighted matrix agreed with stakeholders, state the recommendation with its assumptions, and keep the exit path cheap: a thin integration layer or adapter around the vendor so a later replacement does not ripple through every system.

Follow-up

The client insists on a custom build although your analysis favours the platform. How do you handle that conversation?
Which single assumption would most likely flip your recommendation, and how would you test it early?
What does a hybrid approach look like, and where do you draw the line between configured and custom code?

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

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.
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.
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.
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

Each day targets one of the reported question groups, with the practice-library items that rehearse the integration and ingestion mechanics behind them. Days 1 to 6 build the material, and day 7 is a full spoken run.

Day 1 — Map the loop and audit your resume

Write the three reported stages (Recruiter Screen, Technical Interviews, Panel Interviews) and, for each, what you expect to discuss and your weakest area.
For every resume bullet, write the architecture, the technology choices, the trade-off you made and the outcome, in two lines each.
Choose your track, physical-product work or cloud-marketing platforms, and note which of your projects supports it.

Deliverable: A one-page loop map plus a resume audit sheet with architecture, choices, trade-off and outcome per bullet.

Day 2 — Project deep-dive, testing and the production failure story

Answer the most-complex-project question aloud in three minutes, including one trade-off with the option you rejected, and record it.
For the same project, write what was unit-tested, what was integration-tested and what went through user acceptance sign-off, and how one regression was caught.
Write the production-failure story as a timeline: detection, containment, diagnosis, recovery, prevention, with the blast radius in numbers.

Deliverable: One recorded project walkthrough, a three-level testing summary for that project, and a written failure timeline with the prevention steps listed.

Day 3 — Legacy bottlenecks and integration integrity

Write the investigation sequence for a bottleneck in a legacy codebase with little visibility: what to measure, how to narrow it, how to confirm the fix.
Write the integration story with the source of truth per field, the idempotency approach and the reconciliation checks.
Work the practice-library items on concurrent-edit detection, version gaps and relay lag, and the stalled log partition, to rehearse the mechanics.

Deliverable: A bottleneck investigation checklist, an integration controls table (failure mode and control), and notes from three practice-library items.

Day 4 — Scalability, availability, build versus buy and two design sketches

List the patterns you rely on for scale and availability (stateless services, load balancing, queues, caching, redundancy across zones, graceful degradation), each with the failure it prevents and its cost.
Using that table, sketch two reported scenarios: real-time telematics ingestion for an EV fleet (Kinesis Data Streams or Azure Event Hubs, stream processing, storage) and a secure API gateway from a legacy ERP to a mobile app (Amazon API Gateway or Azure API Management, OAuth, rate limits).
Build a build-versus-buy matrix with cost over time, fit, delivery time, lock-in, maintainability and exit path.
Speak aloud how you would tell a client that an off-the-shelf product beats the custom platform they want, and how you would present the cost case.

Deliverable: A pattern table, two labelled design sketches, a build-versus-buy matrix, and a spoken recommendation script.

Day 5 — Domain track: EV powertrain and Marketing Cloud journeys

EV powertrain: list the parameters that drive thermal performance and the levers that drive manufacturing cost, then outline how you would frame the trade-off as an optimisation with sensitivity checks.
Activate track: write one sentence each on Journey Builder, API Event and Data Extension entry sources, Contact Builder and Contact Key, sendable Data Extensions, Automation Studio and journey versions, then sketch a multi-channel journey using them with consent handling and deduplicated, ordered ingestion.
Rehearse the reported scenario of debugging a failing automation trigger without disrupting active journeys: check the entry source and its filter, the Automation Studio activity log and Data Extension population, then test on a new journey version or seeded contacts, not the live version.
Work the practice-library item on merging partitioned event streams to rehearse ordered, late-tolerant ingestion.

Deliverable: An EV trade-off outline, a Marketing Cloud object sheet with a labelled journey diagram, a trigger-debugging checklist, and notes from the event-stream practice item.

Day 6 — Client-facing stories

Write STAR stories for a disagreement with a product owner or client, an executive explanation, and a multidisciplinary team that did not follow the software lifecycle.
Prepare the delivery-timeline answer for shifting requirements: how you re-plan, communicate and protect scope.
Make sure each story has an "I" action and a measurable result.

Deliverable: Four STAR stories, each with a one-line result, and a requirements-change playbook.

Day 7 — Full spoken run and questions to ask

Run a spoken session of six questions: project walkthrough, failure, bottleneck, integration, build versus buy and the executive explanation. Record and review them.
Prepare two or three questions to ask at the end and note your scheduling constraints for the recruiter.

Deliverable: A reviewed recording of six answers with the weakest one rewritten, plus a list of questions to ask.

Client-facing and delivery stories to rehearse

Candidates report that the panel assesses cultural fit alongside technical alignment, and the reported behavioral questions focus on production failures, system integration, disagreements with clients, explaining architecture to executives, and working with colleagues outside engineering. Each story should show a decision you made, the evidence behind it and a result the client could see.

Describe a time when a technical solution you implemented failed in production. How did you diagnose the issue

Medium · Technical & Project Deep-Dives

Describe a time when a technical solution you implemented failed in production. How did you diagnose the issue, and what was your recovery strategy?

Approach

Choose a failure you owned: a release, migration or integration you built that broke in production. Open with two sentences of context, then walk the sequence in order: how it was detected, how you contained it, how you found the cause, how you recovered, and what you changed afterwards.
Containment before diagnosis: say what you did first to stop the damage (rollback, feature flag off, pausing a job or a queue consumer) and why. Name the roll-back versus roll-forward decision and what drove it, such as whether bad data had already been written.
Diagnosis: describe the evidence you used, such as the deploy diff, error rates against the release time, logs and traces, a reproduction in staging, and how you ruled out other suspects. State the root cause in one precise sentence, not a symptom.
Recovery and prevention: say how bad records were repaired or replayed, then the permanent fixes (a regression test, an alert, a runbook, a staged rollout). Give the blast radius in real numbers: users, records or hours affected.
The mistake that sinks it: blaming a teammate or the vendor, telling a story where you only watched, or stopping at "we fixed it" with no prevention.

Follow-up

Why did you roll forward instead of rolling back, or the reverse?
How did you repair data that had already been written wrongly?
What monitoring or test would have caught this before release?

Explain your experience with system integration. How do you ensure data integrity when connecting disparate en

Medium · Technical & Project Deep-Dives

Explain your experience with system integration. How do you ensure data integrity when connecting disparate enterprise systems?

Approach

Describe one concrete integration: the systems on each side, the direction of data flow, and the mechanism (API calls, message queue, file batch, database sync). Say which system is the source of truth for each important field, because most integrity problems come from two systems both believing they own a value.
Integrity controls by layer: validate schema and required fields at the boundary and send rejects to a quarantine or dead-letter store instead of dropping them; use a stable cross-system key with a mapping table; make writes idempotent with upserts or idempotency keys so a retry cannot duplicate a record.
Ordering and concurrency: carry a version or timestamp so a stale update cannot overwrite a newer one. For a change that must span two systems, use an outbox or saga with compensating steps rather than hoping for a distributed transaction.
Verification after go-live: run scheduled reconciliation (row counts, per-day totals, checksums on key fields) and alert on drift. Report what reconciliation actually found in your project and what you changed.
The mistake that sinks it: listing tools and connectors with no failure mode. Name at least one real incident, such as duplicates after a retry or a field-mapping mismatch, and how you caught it.

Follow-up

What happens when the sender retries after a timeout and the first call actually succeeded?
Two systems hold different addresses for the same customer. Which wins and how did you decide?
How did you detect drift between the systems months after launch?

Describe your approach to setting up a multi-channel customer journey within a cloud marketing platform. How d

Medium · Domain-Specific & Architecture Questions

Describe your approach to setting up a multi-channel customer journey within a cloud marketing platform. How do you handle real-time data ingestion?

Approach

Start from the trigger and identity. In Salesforce Marketing Cloud a journey starts in Journey Builder from an entry source: an API Event when an app or backend fires the trigger in real time, or a Data Extension entry for an audience refreshed on a schedule. Identify each person by Contact Key in Contact Builder, a stable id from the source system rather than an email address, so email, SMS and push resolve to one contact.
Model the data, then the canvas. A sendable Data Extension holds the entry audience and the fields messages personalise on, linked to the contact in Contact Builder's data model; keep per-channel consent in its own fields and apply suppression before sends. On the canvas, place Email, SMS (MobileConnect) and push (MobilePush) activities, waits, decision splits on contact data or engagement, and goal or exit criteria, plus frequency caps.
Pick the ingestion path by the latency the use case needs. Event-driven: the source system calls the API Event over the REST API with the Contact Key and payload as the event happens. Batch: Automation Studio runs imports and SQL query activities on a schedule to refresh Data Extensions that feed scheduled entry. Upstream, validate, deduplicate on an event id and order by event time so a late event cannot route a contact down a stale branch.
Change and debug safely. Test with seeded contacts and test sends before activation, reconcile entry counts against sends and suppressions, and change a running journey by publishing a new version: contacts already inside finish on the old one. For a failing trigger, check the entry source and its filter, the Automation Studio activity history and whether the Data Extension actually populated, then retest on a new version or seeded contacts, not the live version.
If you have not used Marketing Cloud, say so and map each step to something you have built: entry source to an event consumer, Contact Key to a customer master id, Data Extensions to tables, Automation Studio to a scheduler, decision splits to a rules engine. Do not improvise platform details.

Follow-up

The same event arrives twice within a second. How do you stop a duplicate send?
How would you change a journey that already has customers in it?
Which data must be ready before the first message, and which can arrive later?

Describe a scenario where you disagreed with a product owner or client regarding a technical requirement. How

Medium · Behavioral & Client-Facing Scenarios

Describe a scenario where you disagreed with a product owner or client regarding a technical requirement. How did you resolve the conflict?

Approach

Use a real disagreement over a technical requirement, such as a client asking for a design that was costly, risky or slow to deliver. In the first two sentences give the requirement and your specific concern, in terms the other side cares about: cost, deadline, risk or maintenance burden.
Show how you found the underlying need behind the request before arguing. Then show how you backed your view with evidence: an estimate, a small prototype, a failure scenario, or a comparison of two options with their costs.
Present options rather than a verdict: what each option gives, what it costs, and your recommendation. State who made the final call and how you recorded it.
Either outcome works if it is honest. You may have persuaded them, or been overruled and delivered anyway while writing down the risk and a mitigation. What matters is the working relationship afterwards and the result.
The mistake that sinks it: a win-lose story in which the client was simply wrong, or one where you gave in silently and never raised the concern.

Follow-up

What would you have done if they still insisted after seeing your evidence?
How did you keep the relationship working after the decision?
What did you check before you pushed back, to be sure you were right?

Tell me about a time you had to explain a highly complex technical architecture to a business executive who ha

Medium · Behavioral & Client-Facing Scenarios

Tell me about a time you had to explain a highly complex technical architecture to a business executive who had no engineering background.

Approach

Choose a real architecture and say who the executive was and what decision they had to make. The story is about that decision, not the diagram, so begin with the business question the architecture answered.
Say how you adapted: lead with the outcome and the options, use one picture of four to six labelled boxes, use one analogy that fits their world, and translate every technical trade-off into cost, time or risk. Name what you left out on purpose and why.
Describe how you checked understanding, for example asking them to restate the decision or the risk, and how you followed up with a one-page summary they could forward.
Close with the result: the decision made, the budget or scope agreed, or the risk accepted knowingly. Add what you would change in how you explained it.
The mistake that sinks it: a story about simplifying with no result, or one that only shows you speaking slowly. Use plain terms, not jargon with a thin analogy on top.

Follow-up

What did you deliberately leave out, and why?
How did you know they had understood, rather than just nodded?
What question from the executive surprised you, and how did you handle it?

How do you handle working in a multidisciplinary team where other members do not understand the software devel

Medium · Behavioral & Client-Facing Scenarios

How do you handle working in a multidisciplinary team where other members do not understand the software development lifecycle?

Approach

Open with a specific moment, such as a stakeholder asking for a change after testing sign-off, or treating a feature that works in a test environment as already released. Name the misunderstanding of the software lifecycle behind it.
Describe what you put in place: a short shared glossary (environments, done versus released, regression), a visible board with a few clear statuses, written acceptance criteria, a release calendar, and demos on a regular cadence so people see progress without reading tickets.
Show how you made the cost of change concrete without lecturing: for instance, a simple view of what a late change touches (code, tests, user acceptance testing, deployment) and the options with their dates.
Involve non-engineers in the lifecycle where they add value, such as writing acceptance criteria and running user acceptance testing, so they own part of the quality bar.
The mistake that sinks it: framing colleagues as ignorant. Present it as a gap in shared vocabulary that you closed, and give the result, such as fewer late changes or a smoother release.

Follow-up

A colleague asks for a change after user acceptance testing has been signed off. What do you do?
How do you keep stakeholders informed without adding more meetings?
What do you do when someone repeatedly bypasses the agreed process?