Compass Group North America Software Engineer Interview Guide

The 60-second brief

Compass Group North America is described in candidate-facing material as a food service and support services business that serves corporate offices, hospitals and schools. The Software Engineer role is described as touching logistics and supply chain systems as well as the software people use day to day at those sites. Candidates describe the engineering work as covering the full development lifecycle: gathering requirements with product managers, building and deploying, reviewing code, writing technical documentation and mentoring junior developers, all while integrating with infrastructure that already exists.

This guide is for candidates interviewing for the Software Engineer role at Compass Group North America. It covers the three reported rounds (Initial Screen, Technical Assessment, Panel Interview), the technical questions candidates report on hash maps, the Traveling Salesman problem, data structure selection and database architectures, and the behavioral questions on stakeholders, decisions, code review, changing requirements and getting stuck.

Candidates report three rounds spread over roughly 3-5 weeks: an Initial Screen, a Technical Assessment and a Panel Interview with several stakeholders. Reported questions fall into two groups, technical knowledge and behavioral.

Focus areas

• Data Structures
• Algorithmic Problem Solving
• Hashing

Overview

The requirements candidates describe for this role are one mainstream language (Java, C# and Python are named), solid data structures and algorithms, and database design with SQL. Cloud experience on AWS or Azure, CI/CD and automated testing, and earlier work in logistics or enterprise software are listed as nice-to-haves. For preparation, that means choosing the language you code fastest in, being able to explain hash tables from the inside, and being able to talk about relational schemas and queries without notes.

The reported technical questions are mostly conceptual and explanation-driven rather than puzzle-driven. They ask how you handle hash map collisions, how you approach the Traveling Salesman problem, how you choose between data structures for a new feature, and what the trade-offs are between database architectures under heavy traffic. Each one rewards the same habit: state the access pattern or constraint first, then the structure or algorithm, then its complexity and where it breaks. Candidates also describe example scenarios about handling high-frequency data updates and about a hard-to-debug bug, so keep one concrete debugging story ready alongside your fundamentals.

Half of the reported questions are behavioral, and the final stage is described as a panel of stakeholders from different departments. Candidates report that the panel includes people who are not engineers, so practise explaining a technical decision in terms of what it changed for the business: fewer failures, faster processing, lower operating effort. Use a consistent Situation, Task, Action, Result structure, and for every story be ready to say why you picked that approach over the alternatives you rejected.

Pace the work to the loop order candidates describe: refresh technical fundamentals before the technical stage and your stories before the panel. Candidates also warn that a panel can feel friendly and settled while decisions are made after all candidates are reviewed, so keep preparing and keep other options open until an offer is in writing.

The Compass Group North America interview process

Candidates describe three stages that move from a conversation about your experience, to a technical evaluation, to a panel with multiple stakeholders. The sections below say what each stage is reported to be and how to prepare for it.

Initial Screen

Candidates describe the Initial Screen as a preliminary evaluation, with the process overall starting from a high-level discussion of your experience. Nothing more specific about its format is reported, so prepare for a conversation about your background and the stack you work in. Be ready to move from your CV into concrete detail on any project you list, because the later stages revisit your technical decisions.

What to demonstrate

• A first read on your background and how clearly you describe your past work
• Fit between your experience and the listed stack: Java, C# or Python, plus database design and SQL

How to prepare

• Write a short walk through your CV that names the language, database and deployment setup of each recent project, and the reason you chose them.
• Pick the one or two projects where you made architectural choices and rehearse the trade-offs and limitations of the tools you used.
• Prepare a sentence on why logistics, food service or enterprise software interests you, using your own experience rather than company claims.
• Have logistics details such as location and availability ready so the conversation stays on your work.

Technical Assessment

Candidates report a Technical Assessment where you demonstrate technical skill. Candidate accounts describe a mix of algorithmic problems and practical discussion of past work, with hash maps, trees, graphs, complexity analysis and system design at scale named as areas. The practised questions for this kind of stage are the hash map and collision handling question, the Traveling Salesman question, choosing data structures for a feature, and database architecture trade-offs. Clarify requirements, discuss edge cases and outline your approach before you write code.

What to demonstrate

• Working command of hash maps, trees and graphs, and the ability to reason about time and space complexity
• Whether you outline an approach and edge cases before implementing
• Database design and SQL knowledge, and how you reason about systems under heavy traffic

How to prepare

• Implement a hash map from scratch in your strongest language, with both chaining and open addressing, and state resize behavior and worst-case cost.
• Write out how you would approach the Traveling Salesman problem at three levels: brute force, dynamic programming, and a heuristic for larger inputs.
• Prepare a decision table for choosing between array, hash map, heap, tree and graph by access pattern, then test it on a feature you have built.
• Practise explaining read-heavy versus write-heavy database designs, replication and partitioning out loud, then work the SQL practice questions on index use and keyset paging.

Panel Interview

The Panel Interview is described as a comprehensive session with multiple stakeholders from different departments. Candidates say the people met across the process include the Hiring Manager, peers and sometimes leadership, and that the atmosphere can feel very positive even though decisions follow a review of all candidates. Behavioral questions on difficult colleagues, choosing between options, code review feedback, changing requirements and being stuck are the practised material, together with explaining technical choices to people outside engineering.

What to demonstrate

• Communication across technical and non-technical stakeholders
• Collaboration and how you handle disagreement, feedback and ambiguity
• Interest in the business effect of technical decisions

How to prepare

• Build five STAR stories that cover a difficult colleague, a choice between two similar options, code review feedback, a changed requirement and getting stuck, then label which ones also show a technical optimization.
• For each story, write the sentence that explains why you chose that path over the alternative, since the why is what candidates are advised to explain.
• Practise describing one technical decision for a listener with no engineering background, in terms of outcome for operations.
• Write two questions for the end, such as the team's current technical challenges or how they balance technical debt against new features.

Where candidates lose points

Describing hash map collisions only as a definition, without covering chaining versus open addressing, load factor, resizing or worst-case lookup

Be able to implement a small hash table in your strongest language and state the cost of each operation, the worst case with many collisions, and what a resize does to existing entries.

Treating the Traveling Salesman question as a request for a perfect fast algorithm, or giving only a brute-force answer

Say that exact solutions are exponential, give brute force at O(n!) and dynamic programming over subsets at O(n^2 2^n), then offer a heuristic such as nearest neighbor for larger inputs and explain when approximate is acceptable.

Answering database architecture trade-offs with brand preferences instead of workload facts

Start from the read and write pattern, consistency need and growth, then compare a single relational node, read replicas, partitioning and a non-relational store, and say what each makes harder.

Telling behavioral stories without a measured result or without explaining why you chose one path over another

For each story, state a number or concrete outcome and one sentence that begins with why you chose the option, including the alternative you rejected and what it would have cost.

Treating a friendly panel as a finished process and relaxing, or explaining technical choices in jargon to a mixed audience

Keep the same preparation until an offer is in writing, and practise explaining each technical decision in terms of what it did for operations, with no unexplained acronyms.

Questions & practice

Explain how you handle hash maps and collision resolution in your code.

Medium · Technical Knowledge and Data Structures

Approach

1. Start with the mechanism: hash the key, map it to a bucket (modulo the capacity, or a bit mask when the capacity is a power of two), and accept that collisions are unavoidable because many keys share few buckets. Lookups and inserts are O(1) on average and O(n) in the worst case when every key lands in one bucket.
2. Compare the two resolution families. Separate chaining keeps a list per bucket; Java's HashMap turns a bucket into a red-black tree once it holds 8 entries and the table has at least 64 slots, so worst-case lookup there drops to O(log n). Open addressing probes other slots (linear, quadratic, double hashing). Python's dict works this way, and deletes need tombstones so probe chains stay intact.
3. Explain load factor and resizing. Java's HashMap resizes past 0.75 full by doubling and rehashing; Python's dict grows at about two-thirds full. A single resize costs O(n), but inserts stay amortized O(1). If I know the final size, I set the initial capacity up front to skip repeated rehashing.
4. Cover what I do in my own code: keep equals and hashCode (or eq and hash) consistent, use immutable keys because a key mutated after insertion becomes unfindable, and avoid hashing on fields that change. In Python, a class that defines eq without hash becomes unhashable.
5. Edge cases: adversarial keys that all collide (hash flooding), which is why Python randomizes string hashes; thread safety (Java's HashMap is not safe for concurrent writes, so I use ConcurrentHashMap); and iteration order (Python dicts keep insertion order since 3.7, while Java's HashMap guarantees no order and LinkedHashMap does).

Follow-up

• Implement put, get and remove for a hash map with separate chaining, including the resize step.
• Why is linear probing cache-friendly, and what is primary clustering?
• What happens to lookups if a key object is mutated after it has been inserted?

Can you walk me through your approach to the Traveling Salesman problem?

Medium · Technical Knowledge and Data Structures

Approach

1. Clarify the variant before solving: how many cities, whether distances are symmetric (one-way streets make them asymmetric), whether they obey the triangle inequality, whether the tour returns to the start, and whether the optimal tour is required or a good one is enough. TSP is NP-hard, so the input size decides the method.
2. Brute force: fix the start city and try every ordering of the rest, which gives (n-1)! tours ((n-1)!/2 when distances are symmetric) at O(n) each. That is only practical for about ten cities.
3. Exact for small inputs: Held-Karp dynamic programming over subsets. dp[mask][j] is the cheapest path that starts at city 0, visits exactly the cities in mask and ends at j; extend it with dp[mask | 1<<k][k] = min(dp[mask][j] + d[j][k]). That is O(n^2 * 2^n) time and O(n * 2^n) memory, workable up to about 20 cities, and parent pointers recover the tour.
4. Large inputs need heuristics: build a tour with nearest neighbour in O(n^2), then improve it with 2-opt, which reverses a segment whenever that shortens the tour, until no move helps. For metric instances, the MST-doubling tour is within 2x of optimal and Christofides is within 1.5x. At scale, I would use a solver such as OR-Tools rather than hand-rolling one.
5. Edge cases: one or two cities, unreachable pairs (infinite distance), and duplicate points. Real routing work usually adds constraints such as vehicle capacity or time windows (the vehicle routing problem), which changes the model rather than just the algorithm.

Follow-up

• Write Held-Karp and reconstruct the actual tour, not just its cost.
• How would you check how far a heuristic tour is from optimal?
• What changes if there are several vehicles, each with a capacity limit?

How do you choose between different data structures when designing a new feature?

Medium · Technical Knowledge and Data Structures

Approach

1. Start from the operations, not the structure: list what the feature has to do (lookup by key, membership, ordered iteration, range queries, min or max, inserts in the middle), how often each runs, and how large the data gets. The most frequent operation drives the choice.
2. Map each operation to a structure and its cost. A hash map gives O(1) average lookup but no order. A balanced BST (TreeMap, SortedDict) gives O(log n) lookups plus ordered and range queries. A heap gives O(1) peek and O(log n) push or pop for the minimum. A dynamic array gives O(1) indexing and amortized O(1) append, but O(n) middle inserts. A deque gives O(1) at both ends, and a trie handles prefix lookups.
3. Combine structures when no single one covers every operation. An LRU cache pairs a hash map with a doubly linked list so get and put are both O(1). A scheduler that also needs cancel-by-id pairs a min-heap with a map from id to entry and deletes lazily.
4. Weigh costs that Big O hides: memory overhead per entry, cache locality (arrays usually beat linked lists in practice), concurrent access, and whether the data must persist. Often the real decision is a table and index design: a B-tree index serves equality and range queries, while a hash index serves equality only.
5. Close with a concrete example from my own work: the access pattern, the structure I picked, the alternative I rejected, and the measurement that confirmed or changed the choice.

Follow-up

• Design an LRU cache and state the complexity of get and put.
• When would a sorted array with binary search beat a hash map?
• How does the choice change if the data has to be shared across several service instances?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

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

Approach

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

Follow-up

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

What are the trade-offs between different database architectures in a high-traffic environment?

Medium · Technical Knowledge and Data Structures

Approach

1. Pin down the workload before naming technologies: read/write ratio, query shapes (key lookups, multi-table joins, aggregates), consistency requirements, data size and growth, and latency targets. Each architecture wins on a different mix.
2. Single-primary relational (PostgreSQL, MySQL, SQL Server): ACID transactions, joins and strong consistency. Reads scale with indexes, connection pooling and read replicas, but replication is usually asynchronous, so replicas lag and a user may not see their own write. Writes stay bound to one primary.
3. Sharding scales writes horizontally, but the shard key decides everything. A poor key creates hot shards, cross-shard joins and transactions become expensive or move into application code, and resharding later is painful. Splitting tables by function or partitioning by time can delay the need for it.
4. NoSQL options trade query flexibility for scale. Key-value and wide-column stores (DynamoDB, Cassandra) give predictable latency but require designing tables around known access patterns, with limited joins and tunable or eventual consistency; document stores allow flexible schemas. Under a network partition, a system must choose between consistency and availability (CAP).
5. Name the supporting pieces and their costs: a cache such as Redis (cache-aside with TTLs, with invalidation and stampedes as the risk), a queue to absorb write bursts, and a separate analytics store so reporting queries stay off the transactional primary. LSM-tree engines favour write throughput, while B-tree engines favour reads.

Follow-up

• A user updates a record and the next page still shows the old value from a replica. How do you fix that?
• Pick a shard key for an orders table and say which query it makes expensive.
• How would you move from one relational database to a sharded setup without downtime?

Evolve the resource contract without breaking integrations you cannot upgrade

Hard · versioning · backward compatibility · deprecation

GET /v1/resources/{id} returns status from a four-value enum ('draft','active','archived','deleted'), a numeric version, and the body inline. Consumers are a browser app you deploy and roughly 300 server-side integrations, some untouched for two years, that switch exhaustively on status and parse ids as JSON numbers. You must add a 'pending_review' status, move bodies over 256 KB to a body_ref pointer, and expose per-field change history from resource_revision. Specify the compatibility policy, the wire changes, how both generations are served, and the evidence that lets you remove the old shape.

Approach

1. Write the policy first and date it: fields are added, never retyped or repurposed; consumers ignore unknown fields; an unknown enum value maps to a documented fallback; nothing is removed until telemetry shows no caller reads it. Then say the uncomfortable part out loud - v1 shipped without the unknown-value rule, so 300 running integrations have no fallback, and no server change can install one into code that is already deployed.
2. That single fact forces per-request negotiation rather than a server-side default. Keep one internal model and select a serialiser from an explicit version in the request, and default a caller that sends nothing to the oldest supported version. Defaulting to the newest is the change that breaks every integration that never asked for anything, on the day you ship.
3. Downgrade 'pending_review' for old callers to the nearest state they already handle, 'draft', and state the loss explicitly: those integrations cannot see review state and will treat the resource as editable. If that is unacceptable for one integration, the remedy is moving it to the new version, not a cleverer projection - there is no mapping that invents a state the client has no code for.
4. Make the body change additive. Old callers keep body inline; the new shape adds body_ref and a size field, and resources over the limit are served to old callers by resolving the pointer server-side or by refusing with a documented code, chosen once and published. Never repurpose body to carry the pointer: a client that renders it shows a storage key to a user, and that failure is silent, where a missing field would have been loud. While you are here, serialise BIGINT ids as strings in the new shape - a browser parsing JSON numbers gets IEEE-754 doubles, exact only to 2^53 - and treat that as its own breaking change requiring the same negotiation, not a quiet fix.

Follow-up

• An old integration submits a status transition while the resource is really in 'pending_review'. What does the write path accept, and what does it reject?
• Two years on you want to delete the v1 serialiser. What evidence makes that safe, and who must be contacted before it happens?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan follows the reported order: fundamentals for the technical stage first, then database trade-offs, then behavioral stories for the panel, then a full run.

Day 1 — Map the loop and pick your language

• Write the three reported stages (Initial Screen, Technical Assessment, Panel Interview) on one page and mark which part of your preparation each needs.
• Choose the one language from Java, C# or Python you will code in, and set up a plain editor environment where you can run small programs.
• Write your CV walk-through with the stack, database and deployment details of each project.

Deliverable: A one-page loop map, a chosen interview language with a working environment, and a written CV walk-through.

Day 2 — Hash maps and collision resolution

• Implement a hash map with separate chaining in your chosen language, supporting put, get, delete and resize.
• Add an open addressing variant with linear probing and write down how deletion works with tombstones.
• Write a short answer on load factor, resize cost and worst-case lookup, then say it aloud for the collision resolution question.

Deliverable: Two working hash map implementations, tests for collisions and resize, and a spoken answer to the hash map question.

Day 3 — Traveling Salesman and choosing data structures

• Write brute force TSP over permutations, then the subset dynamic programming version, and record the complexity of each.
• Implement nearest neighbor as a heuristic and compare its tour length to the exact answer on a small input.
• Write a decision table for array, hash map, heap, tree and graph by access pattern, and apply it to a feature you built.

Deliverable: Three TSP solutions with a complexity note each, and a data structure decision table with one worked feature example.

Day 4 — Database architectures and SQL

• Write a comparison of a single relational database, read replicas, partitioning and a non-relational store for a high-traffic read-heavy workload and a write-heavy one.
• Practise the practice question on evolving an interface contract without breaking integrations you cannot upgrade.

Deliverable: A one-page trade-off comparison table, plus solved index and keyset paging practice questions.

Day 5 — Optimization, debugging and getting unstuck

• Write your code optimization story in STAR form with a baseline figure, the evidence that found the bottleneck, the fix and the re-measured result.
• Write your stuck-on-a-problem answer as a repeatable sequence plus one real example.

Deliverable: A written optimization story with numbers, a diagnosis note for the latency practice question, and a written getting-stuck answer.

Day 6 — Stakeholder, decision, review and pivot stories

• Write STAR stories for the difficult stakeholder, the two similar options, the code review feedback and the changing requirements prompts.
• For each story, add one sentence on why you chose that path over the alternative, and one measurable outcome.
• Rehearse one of the stories aloud for a listener who is not an engineer, with no unexplained jargon.

Deliverable: Four STAR stories, each with a why sentence and an outcome, and one recorded non-technical retelling.

Day 7 — Full dry run and questions to ask

• Run one mock that starts with a CV walk-through, then a spoken hash map, TSP and database trade-off answer, then two behavioral stories back to back.
• Review where you stopped to think, and tighten those answers.
• Write two questions for the end, on the team's technical challenges and on how they balance technical debt against new features.

Deliverable: A completed full mock with a list of weak answers to fix, and two written closing questions.

Stories for the panel and the screens

Candidates report that half of the questions are behavioral, on difficult colleagues, choosing between options, receiving code review feedback, changing requirements and getting stuck, and that the final stage is a panel with several stakeholders. Build stories you can tell in the STAR structure and always add why you chose that approach. Rehearse the code optimization story as both a technical and a behavioral answer.

Describe a time you had to optimize a piece of code that was performing poorly.

Medium · Technical Knowledge and Data Structures

Approach

1. Choose a case where the slowness was measurable, and open with the number: a request time, a batch run length, a query cost or memory use. State the baseline before any change so the result is a comparison, not an impression.
2. Show how you found the bottleneck: profiler, query plan or timing logs. Name the cause precisely, for example an N+1 query, a nested loop that a hash map lookup could replace, a missing index, repeated parsing or an oversized payload.
3. Describe the fix and the alternative you rejected, with the trade-off, such as more memory for a cache against added complexity and invalidation risk. Mention complexity change where it applies, for instance O(n^2) to O(n).
4. Close with the re-measured result, how you guarded against regressions (a benchmark, test or alert) and what you checked to be sure behavior stayed correct.
5. The mistake that sinks this story is optimizing by guess. Never say you rewrote something because it looked slow; say what the evidence pointed at.

Follow-up

• How did you know this was the bottleneck and not something upstream or downstream of it?
• What did the optimization cost in readability, memory or maintenance, and was that worth it?
• If profiling had shown no single hot spot, what would you have done next?

Tell me about a time you had to work with a difficult stakeholder or team member.

Medium · Behavioral and Leadership

Approach

1. Pick a real disagreement with a stakeholder or teammate where the relationship mattered afterwards, not a villain story. Describe the situation neutrally in two sentences: what each side wanted and why it was in conflict.
2. Spend the story on what you did: asked questions to learn their constraint, restated their position to confirm it, moved the discussion from opinions to evidence such as data, a prototype or a written comparison, and agreed on who decided.
3. Show the outcome in terms of the work: what shipped, what was changed, how the working relationship stood afterwards. If you did not get your way, say what you accepted and why.
4. If the other person was non-technical, include how you translated the technical issue into effects on their operation. The mistake that sinks it is blame or describing the other person's character rather than your actions.

Follow-up

• What would you do differently if you had to work with the same person again?
• How did you handle it when you disagreed but the decision still went the other way?
• How did you make sure the conflict did not slow the rest of the team?

Describe a project where you were given two similar options; how did you decide which path to take?

Medium · Behavioral and Leadership

Approach

1. Choose a decision where both options were credible, such as two libraries, two storage designs or build versus buy. Name the options in one sentence each so the listener can follow the trade-off.
2. State the criteria before the verdict: performance under expected load, team familiarity, operating effort, cost, reversibility and time to deliver. Show how you weighted them for that project.
3. Describe how you reduced uncertainty: a small spike or benchmark, reading documentation and failure modes, asking someone who had run it in production. Evidence beats preference.
4. Say what you decided, who agreed, and how you recorded the reasoning so it could be revisited. Close with what happened, including any cost of the option not chosen.
5. The mistake that sinks it is describing a decision that was obvious or made by someone else. Pick one where you owned the call.

Follow-up

• What would have changed your decision to the other option?
• How reversible was the choice, and how did that affect how much analysis you did?
• Looking back, was there a signal you missed or overweighted?

How do you handle feedback on your code during a pull request review?

Medium · Behavioral and Leadership

Approach

1. Describe your habit in concrete steps: read all comments first, separate defects from style or preference, reply to each with a fix or a reason, and push the follow-up commit with a short summary. Treat the review as a conversation about the code, not about you.
2. Give one real example where review changed your code, such as an edge case, a missing test, a naming problem or a simpler design. Say what you learned and whether it changed how you write the next change.
3. Include one case where you disagreed: explain how you responded with evidence or a question, asked for a call when the thread was going in circles, and accepted the team convention when it was a matter of taste.
4. Mention the other side: how you give feedback as a reviewer, with specific, kind comments tied to a reason. The mistake that sinks it is claiming you never receive meaningful comments or that you take them personally.

Follow-up

• Tell me about a review comment you disagreed with and what you did.
• How do you keep pull requests small enough to be reviewed well?
• How do you review a colleague's code that you think has a design problem?

Tell me about a time you had to pivot your strategy due to changing project requirements.

Medium · Behavioral and Leadership

Approach

1. Choose a project where requirements changed after work was underway, and state the change and its cause plainly, such as a stakeholder priority shift, a constraint discovered in testing or a new integration.
2. Show the first thing you did: assess what existing work still held, what was wasted and what the new scope would cost. Present that to the product manager or stakeholder so the decision was shared rather than silent.
3. Describe the new plan: what you cut, reused or deferred, how you adjusted tests and communication, and how you kept the team aligned. Name how you protected quality while the schedule moved.
4. Finish with the result and one lesson, such as keeping the design modular or confirming requirements earlier. The mistake that sinks it is presenting the pivot as a complaint about the stakeholder or as pure rework.

Follow-up

• How did you decide what existing work to keep and what to discard?
• How did you communicate the impact on delivery to the people depending on it?
• What did you change afterwards so a late change would hurt less?

What do you do when you are stuck on a technical problem and cannot find a solution?

Medium · Behavioral and Leadership

Approach

1. Answer with a repeatable sequence before the story. Reproduce the problem and shrink it to the smallest failing case, read the error and the relevant code or documentation, form one hypothesis at a time, and test each with a log, debugger or experiment.
2. Name your limit: you set a time box and then bring in another person. Explain how you ask, with what you tried, what you observed and the minimal reproduction, so the other person can help quickly.
3. Add a real example, such as a hard-to-debug production bug or a framework behavior you misread. Show what finally unlocked it and what you recorded afterwards, such as a test, a note or a runbook entry.
4. Give a view on escalation: you do not sit silently on a blocker that affects others. The mistake that sinks it is saying you never get stuck or that you would only search the web.

Follow-up

• How long do you work alone before asking, and how do you decide?
• Tell me about the hardest bug you debugged and what finally revealed the cause.
• How do you write up a problem so a colleague can help without a long meeting?