Berkshire Hathaway Software Engineer Interview Guide

The 60-second brief

Berkshire Hathaway is a holding company whose subsidiaries include businesses in insurance, energy and manufacturing. Candidates describe the Software Engineer role as building and maintaining applications for business needs across those subsidiaries, working with product managers, designers and other engineers, taking part in code reviews, debugging and tuning running systems, and writing down designs and processes. The requirements candidates list name Java, Python and C#, SQL and NoSQL databases, and Agile or Scrum, with AWS, Azure, Docker, Kubernetes and security knowledge as extras.

This guide is for software engineer candidates preparing for Berkshire Hathaway. Behavioral questions carry the most detailed guidance on this page.

Candidates report two stages over roughly 2-4 weeks: a phone screen run by HR or a recruiter, then several technical interviews with team members and possibly leadership.

Focus areas

• System Design
• Scaling (Enterprise Systems)
• Cloud Architecture Understanding

Overview

The work candidates describe is general application engineering rather than one narrow product: build and maintain software for different business units, review each other's code, track down performance and correctness problems, and document designs so others can maintain them. The reported question list matches that shape. It mixes coding basics (reversing a linked list, finding two numbers that sum to a target, depth-first versus breadth-first search, dynamic programming), design questions (millions of transactions per second, schema design, microservices, performance), diagnosis questions (a slow application, a complex bug) and a large set of behavioral prompts.

Reported topic areas for this loop are system design, scaling enterprise systems, cloud architecture, collaboration and explaining your work. For preparation that means two things. First, have a concrete design vocabulary: partitioning, caching, queues, replication, consistency, and how each one behaves when a dependency fails. Second, be able to talk about your own projects in plain language, because candidates also report being asked to explain technical ideas to non-technical colleagues.

The stack in the requirements is broad: Java, Python or C#, SQL and NoSQL stores, Agile or Scrum, and optionally AWS or Azure with Docker and Kubernetes. Pick one language and write every coding answer in it, and be ready to compare relational and document storage for one concrete schema. For the cloud and container questions, prepare real experience you can describe precisely, and say plainly where your experience stops.

Roughly half of the reported questions are behavioral or experience-based: refactoring, disagreement, running a project, prioritising, adapting to change, deadlines, learning a technology fast. Prepare six or seven stories from real work and map each to several prompts, so that you are choosing a story rather than inventing one under pressure.

The Berkshire Hathaway interview process

Candidates report two stages over roughly 2-4 weeks, a phone screen and then technical interviews. Treat the sequence as what candidates describe, not a published process, and confirm the details with your recruiter.

Phone Screen

Candidates report an initial phone screen conducted by HR or a recruiter to assess whether you fit the role. Nothing in the reports says it is a coding exercise, so treat it as a conversation about your background, your motivation and the practical details of the move. Several of the reported general questions (which languages you are most comfortable with and why, your experience with cloud-based solutions, the biggest technical problem you solved) are easy to answer badly off the cuff, so rehearse short versions of them out loud.

What to demonstrate

• Fit for the Software Engineer role, as the recruiter or HR contact assesses it
• How clearly you summarise your background and the languages and tools you have used
• Whether your experience lines up with the listed requirements: SQL and NoSQL, Agile or Scrum, a language such as Java, Python or C#

How to prepare

• Write a spoken walk through your CV that names the languages, databases and delivery methods you have used, matching the stack in the role requirements.
• Prepare a short, honest answer to the question about languages you are most comfortable with and why, including the one language you will use for coding questions.
• Prepare two sentences on your experience with cloud-based solutions that name the services you used, what you configured yourself and what a platform team handled.
• Learn what the subsidiaries in insurance, energy and manufacturing do at a high level, and prepare one reason this kind of work interests you.

Technical Interviews

Candidates report several technical interviews with team members and possibly leadership. The reported question types across the loop are technical and domain questions, system design, problem-solving and case studies, coding and algorithms, and behavioral prompts. Reported topic areas include system design, scaling enterprise systems and cloud architecture, with collaboration and communication also called out. Expect to alternate between hands-on problems and conversations about projects you have built, so keep a working routine for each: restate, clarify, outline, solve, test aloud.

What to demonstrate

• Working code and algorithmic reasoning on the coding questions (linked lists, array lookups, graph traversal, dynamic programming)
• Design reasoning for scale, schema, microservices and performance, including consistency and failure behavior
• Structured debugging and diagnosis of slow or faulty systems
• How you explain technical choices and describe teamwork, conflict and leadership

How to prepare

• Solve reversing a linked list and the two-number target problem in your chosen language, then explain time and space complexity and the edge cases (empty input, a single element, duplicates, no valid pair).
• Explain depth-first versus breadth-first search with the data structure each uses, then sketch a dynamic-programming solution from recurrence to table to space reduction.
• Practise a design walk-through for millions of transactions per second: partitioning, queues, replication, caching, consistency and what happens when a downstream service is down.
• Rehearse a diagnosis routine for a slow application and a complex bug (measure, bisect, fix, verify), and have your stories ready for the refactoring, disagreement, leadership, prioritisation, change and deadline prompts.

Where candidates lose points

Solving the coding questions silently, then pasting a finished answer with no explanation

For reversing a linked list, the two-number target problem and depth-first versus breadth-first search, state the approach and its complexity first, write the code, and trace a small example aloud including empty and single-element input.

Answering the transactions-per-second design question with a list of buzzwords such as microservices, cache and Kafka

Name the bottleneck, the partition key and what it makes expensive, the consistency you need, and what happens when a dependency is down. Add the numbers you assume.

Describing cloud, Docker or Kubernetes experience as if you had owned everything

Say what you configured, deployed and debugged yourself, and what a platform team handled. Be precise about the services you actually used.

Giving a behavioral answer with a vague 'we' and no decision of your own

For the refactoring, disagreement, project and deadline prompts, use first person singular for your decisions, name the trade-off and report the outcome, including what went wrong.

Jumping to a fix for the slow application or complex bug without measuring

Describe the order: reproduce, find what changed, measure where time goes, bisect, fix, verify. Name concrete signals such as latency percentiles, query plans, error logs and recent deploys.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the node shape and the return value (the new head), and confirm the list may be empty or have one node.
2. Iterative solution with three pointers: prev = null, curr = head. In a loop: save next = curr.next, set curr.next = prev, move prev = curr and curr = next. When curr is null, return prev. This is O(n) time and O(1) extra space.
3. A recursive version reverses the rest of the list, then sets head.next.next = head and head.next = null. It is also O(n) time but uses O(n) stack space, so a long list can overflow the stack (CPython's default recursion limit is 1000).
4. Test by hand with the empty list, a single node and two nodes, and check that the old head's next ends up null so no cycle is left behind.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes.
• How would you check whether a linked list is a palindrome in O(1) extra space?

Given an array of integers, find two numbers that add up to a specific target.

Medium · Coding / Algorithms

Approach

1. Clarify: return indices or values, is exactly one answer guaranteed, can an element be used twice, and are negative numbers and duplicates allowed?
2. The brute-force solution checks every pair in O(n^2) time and O(1) space. It is a correct baseline to state before improving on it.
3. Use a single-pass hash map from value to index. For each x at index i, look up target - x first; if it is there, return both indices, otherwise store x -> i. Looking up before inserting stops an element pairing with itself and still handles inputs like [3,3] with target 6. This runs in O(n) time and O(n) space.
4. If the array is sorted, or extra memory matters, two pointers from both ends work in O(n) time with O(1) extra space after an O(n log n) sort. Sorting loses the original indices unless you sort (value, index) pairs.

Follow-up

• Return all unique pairs that sum to the target, without duplicates.
• Extend it to three numbers that sum to the target. What is the complexity?
• The numbers arrive as a stream. How would you support add and find operations?

How would you implement a search algorithm for a large dataset?

Medium · Coding / Algorithms

Approach

1. Clarify the kind of search, because it decides the structure: exact key lookup, range queries, prefix or full-text search, or nearest neighbour. Also ask whether the data is static or updated, and whether it fits in memory.
2. In memory: a hash table gives O(1) average exact lookup but no ordering. A sorted array with binary search gives O(log n) lookups and supports ranges, but inserts cost O(n). A balanced BST or skip list gives O(log n) for both.
3. On disk or at large scale: a B+ tree keeps the number of page reads low for both point and range queries, which is why databases use it. Full-text search uses an inverted index from terms to document IDs. A Bloom filter can skip lookups for keys that are definitely absent.
4. When one machine is not enough, partition by key (hash for point lookups, range partitioning for scans), query the shards in parallel and merge the results.
5. If asked to code binary search, write the invariant explicitly, compute mid as lo + (hi - lo) / 2 to avoid integer overflow in Java or C#, and decide whether you need the first match or any match.

Follow-up

• Write binary search that returns the first index of a value that appears several times.
• The dataset gets thousands of inserts per second. Does your structure still work?
• How would you support case-insensitive prefix search over millions of names?

Explain the difference between depth-first and breadth-first search.

Medium · Coding / Algorithms

Approach

1. Mechanics: breadth-first search uses a FIFO queue and visits nodes level by level outward from the source. Depth-first search uses a stack, explicit or through recursion, and follows one path as far as it goes before backtracking.
2. Both run in O(V + E) time on an adjacency list and need a visited set on graphs with cycles. On an adjacency matrix the time becomes O(V^2).
3. Memory differs: BFS holds the whole frontier, which can be very wide, while DFS holds the current path, which can be very deep. Recursive DFS can overflow the stack on deep graphs, so use an explicit stack there.
4. Use cases: BFS finds shortest paths by edge count in unweighted graphs and does level-order traversal. DFS suits cycle detection, topological sort, connected components, and backtracking problems such as permutations or mazes.
5. For weighted edges neither is enough: use Dijkstra's algorithm when weights are non-negative, or 0-1 BFS with a deque when every weight is 0 or 1.

Follow-up

• How would you detect a cycle in a directed graph with DFS?
• Count the islands in a grid of 0s and 1s. Which traversal would you use?
• Find the shortest path when edges have different weights.

Solve a problem using dynamic programming.

Medium · Coding / Algorithms

Approach

1. Pick a concrete problem and say why DP applies: overlapping subproblems and optimal substructure. Coin change with the fewest coins is a good choice because greedy fails on it: with coins [1,3,4] and amount 6, greedy picks 4+1+1 (three coins) while the optimum is 3+3 (two).
2. Define the state and recurrence explicitly: dp[a] is the fewest coins that make amount a. dp[0] = 0, and dp[a] = min over coins c <= a of dp[a - c] + 1. Start unreachable amounts at infinity and return -1 if dp[amount] stays infinite.
3. Choose top-down or bottom-up. Memoised recursion is quick to write but uses stack depth. A bottom-up table fills a from 1 to amount and avoids recursion. Complexity is states times transitions: O(amount x number of coins) time and O(amount) space.
4. Test the edge cases (amount 0, an unreachable amount, a single coin), and mention how to rebuild the actual coins by storing the coin chosen at each amount.

Follow-up

• Count the number of distinct combinations instead of the minimum. Does the loop order matter?
• How would you reduce the memory of a two-dimensional DP such as longest common subsequence?
• How would you return the actual coins used, not just the count?

What factors do you consider when designing a database schema?

Medium · System Design / Architecture

Approach

1. Start from the entities and the access patterns: which queries run most often, the read/write ratio, and how the data grows. A schema is judged by the queries it has to serve.
2. Normalise to roughly third normal form to avoid update anomalies, then denormalise deliberately (a cached total, a reporting table) only where a measured read path needs it, and say how the copy stays in sync.
3. Enforce integrity in the database: primary keys (surrogate or natural, with the trade-off), foreign keys, NOT NULL, UNIQUE and CHECK constraints. Choose exact types, such as DECIMAL rather than floating point for money and timezone-aware timestamps.
4. Plan indexes from the WHERE, JOIN and ORDER BY clauses of the main queries, putting the equality column first in composite indexes. Remember that every index slows writes and takes space.
5. Cover change and scale: backward-compatible migrations (add the column, backfill, switch reads, then remove the old one), partitioning or archiving for tables that grow without bound, and whether a NoSQL store fits better when access is purely by key.

Follow-up

• How would you model a many-to-many relationship, such as policies and the people covered by them?
• How would you change a column's type on a large table without downtime?
• When would you choose a document or key-value store over a relational one for this data?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

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

Approach

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

Follow-up

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

Describe a challenging technical problem you solved. What was your approach?

Medium · Technical / Domain Questions

Approach

1. Pick one problem with a measurable symptom (a timeout rate, a failing batch job, a memory leak) where you owned the diagnosis, and open with the symptom and the constraint that made it hard: data volume, a legacy dependency or no reproduction outside production.
2. Walk through the hypotheses in the order you tested them, and for each one name the evidence that ruled it in or out (a profiler trace, a query plan, a log correlation). This is the technical core of the answer.
3. Name the fix and the alternative you rejected, with the trade-off: for example caching versus rewriting the query, or a quick patch versus a schema change.
4. Close with a before-and-after number and the safeguard you added so the problem cannot quietly return, such as a regression test, an alert or a runbook entry.

Follow-up

• What other solution did you consider, and why did you reject it?
• How did you prove your change caused the improvement and not something else?
• If the same symptom came back next month, where would you look first?

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

Medium · Technical / Domain Questions

Approach

1. Name one or two languages you have shipped production code in. The requirements candidates describe for this role list Java, Python and C#, so if you know one of them, lead with it.
2. Give concrete reasons tied to work you did: static typing and the JVM's tooling in Java, async/await and LINQ in C#, fast iteration and the data libraries in Python. Avoid saying a language is simply "easy".
3. Show that you know each language's limits. In CPython the GIL stops threads from running Python bytecode in parallel, so CPU-bound work needs multiprocessing or native code. In Java and C#, garbage-collection pauses and memory overhead matter for latency.
4. Say how you choose a language for a new project: what the team already runs, library support, performance needs and hiring. That shows the choice is an engineering decision, not a matter of taste.

Follow-up

• What is the biggest weakness of the language you prefer, and how do you work around it?
• How does garbage collection work in that language, and when has it caused you a problem?
• How would you get productive in a language you have never used?

Can you explain the differences between REST and SOAP?

Medium · Technical / Domain Questions

Approach

1. Frame the difference first: REST is an architectural style built on HTTP semantics (resources named by URIs, standard verbs, stateless requests, any representation, usually JSON). SOAP is a messaging protocol with an XML envelope (Envelope, optional Header, Body, Fault) and a formal WSDL contract.
2. Compare transport and caching. SOAP can run over HTTP, SMTP or JMS, and over HTTP it almost always uses POST to a single endpoint, so standard HTTP caching does not help. REST GETs can be cached by browsers, CDNs and proxies using Cache-Control and ETags.
3. Compare errors and contracts. REST signals failure with HTTP status codes and a response body, and usually describes its contract with OpenAPI. SOAP returns a Fault element and generates typed clients from the WSDL.
4. Compare the extra standards. SOAP has WS-Security for message-level signing and encryption and WS-ReliableMessaging for delivery guarantees. REST relies on TLS, OAuth 2.0 or JWT tokens, and on idempotent design for retries.
5. Finish with when to use each: SOAP for existing enterprise or partner integrations that already publish WSDL contracts and need message-level security, REST for most new web and mobile APIs because it is lighter and easier to debug.

Follow-up

• Which HTTP methods are idempotent, and how would you make a POST safe to retry?
• How would you version a REST API without breaking existing clients?
• How would you put a REST interface in front of a legacy SOAP service?

How do you ensure code quality and maintainability?

Medium · Technical / Domain Questions

Approach

1. Organise the answer into layers: what is automated, what goes through review, and what is a design habit. A list of good intentions is weaker than that structure.
2. Automation: formatters and linters in CI, static analysis or type checking (mypy for Python, compiler warnings treated as errors in Java or C#), and a test suite that blocks the merge. Most tests are fast unit tests, with fewer integration tests and only a handful of end-to-end tests.
3. Review: keep pull requests small enough to read in one sitting, review for correctness and naming rather than style the linter already enforces, and require a test that would have caught each bug fixed.
4. Maintainability: clear module boundaries, no abstraction until a second real use case appears, and a short design note or ADR for decisions a future reader would question.
5. Name a signal you track, such as escaped defects, flaky-test count or how long changes in one area take, and one example where it changed how you worked.

Follow-up

• How do you safely change legacy code that has no tests?
• Is a code coverage target useful? What number would you set, and why?
• What do you do when a reviewer and you disagree about a design in a pull request?

What experience do you have with cloud-based solutions?

Medium · Technical / Domain Questions

Approach

1. Be specific and honest. Name the provider and the services you used and what each did, for example a container service or VMs for compute, object storage for files, a managed relational database and a queue. Candidates report AWS, Azure, Docker and Kubernetes as nice-to-have skills for this role.
2. Describe how the system was deployed: infrastructure as code (Terraform, CloudFormation or Bicep), container images built in CI, and how a release was rolled out and rolled back.
3. Cover the operational side, which separates real use from tutorial use: IAM roles with least privilege, secrets in a managed store rather than in code, health checks and autoscaling, and spreading instances across availability zones.
4. Mention cost and observability: a bill you reduced (right-sizing, reserved capacity, storage lifecycle rules) or the metrics and alerts you set up.
5. If your experience is limited, say exactly what you have done and how you would close the gap. Do not stretch one tutorial into production experience.

Follow-up

• How would you make a stateless web service survive the loss of one availability zone?
• When would you choose serverless functions over containers, and what does each cost you?
• How did you manage secrets and credentials in that setup?

How would you design a system to handle millions of transactions per second?

Medium · System Design / Architecture

Approach

1. Clarify what a transaction is (a payment, an order, a ledger write), the read/write mix, peak against average load, the latency target and whether every write must be strongly consistent. Then size it: 1M writes per second at about 1 KB each is about 1 GB/s, or roughly 86 TB per day before replication.
2. Keep the API tier stateless behind load balancers so it scales horizontally. Partition the data by a key such as account ID with consistent hashing, so each shard handles a fraction of the load and per-account ordering stays inside one shard.
3. Absorb write bursts with a durable, partitioned log (Kafka-style) keyed the same way. Consumers apply events to the sharded store, and the ledger is append-only so history can be replayed.
4. Make every write idempotent with a client-supplied idempotency key stored alongside the result, so a retry after a timeout cannot double-apply. Avoid cross-shard transactions where possible; when one is unavoidable, use a saga with compensating steps instead of distributed two-phase commit.
5. Name the failure modes: hot keys (one huge merchant) that need sub-sharding, replication lag on read replicas, consumer crashes (resume from committed offsets with idempotent apply) and backpressure when the store falls behind.

Follow-up

• How would you handle a transfer between two accounts that live on different shards?
• One account generates 20% of all traffic. What breaks, and how do you fix it?
• A consumer crashes after writing to the database but before committing its offset. What happens?

How do you approach system performance optimization?

Medium · System Design / Architecture

Approach

1. Define the target before touching code: which metric (p95 or p99 latency, throughput, memory), for which operation, and what number counts as done.
2. Measure to find the bottleneck rather than guessing: application traces to see where request time goes, a CPU profiler or flame graph for hot code, EXPLAIN ANALYZE and the slow-query log for the database, and saturation metrics for CPU, memory, I/O and connection pools.
3. Fix the largest contributor first, because by Amdahl's law speeding up a part that takes 10% of the time can save at most 10%. Typical fixes are a better algorithm, removing N+1 queries, adding or correcting an index, batching calls, connection pooling and caching with a clear invalidation rule.
4. Verify with a load test or a production comparison against the baseline, check that correctness and other metrics did not regress, and add a performance test or alert so the gain is kept.

Follow-up

• How would you find an N+1 query problem in a running service?
• You add a cache and the data starts going stale. How do you decide on invalidation?
• Latency is fine at p50 but bad at p99. What causes that pattern?

Explain the concept of microservices and their advantages.

Medium · System Design / Architecture

Approach

1. Define it precisely: small services that can be deployed independently, each owning one business capability and its own data store, talking over APIs or messaging. Contrast this with a monolith that shares one deployable unit and one database.
2. Advantages: independent deployment and release cadence, scaling only the service under load, fault isolation when it is designed for, ownership by one team per service, and the freedom to use a different stack where it really helps.
3. Costs, which matter as much: network latency and partial failure on every call, no cross-service ACID transactions (so sagas and eventual consistency), harder debugging that needs distributed tracing and correlation IDs, and more operational overhead per service.
4. Name the supporting patterns: an API gateway, service discovery, timeouts with retries and exponential backoff, circuit breakers, idempotent handlers, and the transactional outbox for reliable event publishing.
5. Give a judgement: for a small team or an unclear domain, a modular monolith with clean boundaries is often the better starting point, with services split out later along proven seams.

Follow-up

• How would you break a monolith into services without a big-bang rewrite?
• How do you keep data consistent when an order spans three services?
• One downstream service becomes slow. How do you stop that from taking down its callers?

A user reports that the application is running slowly. What steps would you take to diagnose the issue?

Medium · Problem-Solving / Case Studies

Approach

1. Scope it first: one user or many, which page or action, since when, which region, device or browser. One slow user points to their data, network or client; everyone slow points to the backend or a recent change.
2. Check dashboards before guessing: latency percentiles, error rate and traffic for the affected endpoint, saturation of CPU, memory, disk and database connections, and recent deploys, configuration changes or data growth.
3. Trace one slow request end to end to split the time between client rendering, network, the API and its dependencies. Distributed tracing or timestamps with a correlation ID show which layer to open next.
4. If the database is the hot spot, read the slow-query log and EXPLAIN plans, look for missing indexes, lock contention or a plan change after table growth. If it is the application, profile it and check for N+1 calls or exhausted pools.
5. Fix it, confirm with the same metric that showed the problem, tell the user, and add an alert or test so the regression is caught next time.

Follow-up

• Only one customer is slow and everyone else is fine. What do you check?
• Rolling back the last deploy did not fix it. What next?
• How would you tell a slow database query apart from connection-pool exhaustion?

Given a dataset, how would you extract meaningful insights from it?

Medium · Problem-Solving / Case Studies

Approach

1. Start from the decision the analysis should inform, and turn it into a specific question with a metric. Without one, exploration has no stopping point.
2. Profile the data before trusting it: row counts, the time range, the grain of each row, null rates, duplicates, outliers and how each field was collected. Fix or exclude bad records and say so.
3. Aggregate and segment with SQL (GROUP BY, window functions for trends and running totals) or pandas, compare segments and time periods, and plot distributions instead of relying on averages alone.
4. Check that a finding is real: is the difference larger than normal variation (a confidence interval or significance test), could a confounder or Simpson's paradox explain it, and is it correlation rather than cause?
5. Present two or three findings with the evidence, the caveats and a recommended action, and say what further data would confirm it.

Follow-up

• The dataset does not fit in memory. How do you work with it?
• An overall trend reverses when you split by segment. How do you explain that?
• How would you show a stakeholder that a change caused the effect and was not just correlated with it?

Describe a situation where you had to learn a new technology quickly to complete a project.

Medium · Problem-Solving / Case Studies

Approach

1. Set up the constraint in a sentence or two: what the project needed, why the new technology was required and how much time you had.
2. Make the learning method concrete: official documentation and the getting-started guide first, then a small throwaway prototype of the hardest part, reading example code or source, and short questions to someone experienced.
3. Show how you limited risk while still learning: a narrow first use, tests around the new component, a fallback plan, and an early review from someone who knew the tool.
4. Give the outcome with a measurable result, and one thing you got wrong at first and how you found out. Claiming instant mastery weakens the story.

Follow-up

• How did you decide this technology was the right choice rather than something you already knew?
• What was the first mistake you made with it, and how did you catch it?
• How did you get the rest of the team productive with it?

How would you evaluate the success of a software feature post-implementation?

Medium · Problem-Solving / Case Studies

Approach

1. Define success before launch: one primary metric tied to the feature's purpose (adoption, task completion, conversion, time saved), plus guardrail metrics such as error rate, latency, support tickets and any metric the feature could cannibalise.
2. Instrument it: log the events behind each metric, confirm they fire correctly in staging, and record a baseline before release.
3. Roll out behind a feature flag. Where possible, run an A/B test with a control group, sized in advance for the effect you care about. Account for novelty effects and weekly cycles by running for at least one full cycle.
4. Also check engineering health: performance, error budgets and the feature's operational cost.
5. Decide using pre-agreed thresholds: ship to everyone, iterate or roll back. Share the result with the stakeholders even when it is negative.

Follow-up

• You cannot run an A/B test. How do you estimate the feature's effect?
• The primary metric went up but a guardrail metric got worse. What do you do?
• How do you decide how long to run the experiment?

How would you approach debugging a complex software issue?

Medium · Problem-Solving / Case Studies

Approach

1. Reproduce it reliably and shrink it to the smallest failing case: the same input, version, configuration and environment. A bug you cannot trigger on demand cannot be confirmed as fixed.
2. Gather evidence before forming theories: logs and traces joined by request or correlation ID, metrics around the first occurrence, and what changed (code, configuration, dependencies, data) just before it started.
3. List hypotheses and test the one that eliminates the most possibilities for the least effort. Bisect wherever possible: git bisect across commits, or halving the input, the configuration or the code path.
4. For intermittent failures, suspect concurrency, timing, ordering and shared state. Add targeted logging, run under stress or with randomised scheduling, and check retries and timeouts.
5. Fix the root cause rather than the symptom, add a regression test that failed before the fix, and write down the cause and the safeguard for the team.

Follow-up

• The bug disappears when you attach a debugger or add logging. What does that suggest?
• It happens only in production and you cannot reproduce it locally. How do you proceed?
• How would you know your fix worked rather than the bug just not recurring yet?

Suggested practice checklist

Seven days built around the reported phone screen and technical interviews: the first day for the screen and your own background, then coding, data and schema, design, diagnosis, and a final day for behavioral stories and a full run-through. Each day names the reported questions it practises.

Day 1 — Phone screen and your own background

• Write and say aloud a walk through your CV that names your languages, databases, cloud services and delivery method (Agile or Scrum), so it lines up with the listed requirements.
• Write short answers for the questions on your most comfortable programming language, your cloud experience and the challenging technical problem you solved.
• Prepare the practical details you will be asked about and a few questions to ask the recruiter about the technical rounds.

Deliverable: A written CV walk-through and three short written answers (language, cloud experience, a challenging problem) you can say aloud.

Day 2 — Coding fundamentals: lists, arrays, traversal

• Write iterative linked-list reversal in your chosen language, then write the recursive version and compare stack use.
• Solve the two-number target problem twice, brute force and with a hash map, and state the complexity and edge cases (duplicates, no pair).
• Implement depth-first and breadth-first search on a graph or tree and write when you would pick each.

Deliverable: Three working solutions in one language with complexities and edge cases written beside each, plus a short comparison of depth-first and breadth-first search.

Day 3 — Coding: dynamic programming and search at scale

• Solve two dynamic-programming problems (for example climbing stairs and coin change): write the recurrence, the table, and the space-reduced version.
• Write binary search and explain how a large dataset changes the choice (sorted data, an index, partitions, or a hash lookup).
• Practise narrating each solution as you write it.

Deliverable: Two dynamic-programming solutions with recurrences, a binary search implementation, and a one-paragraph answer on searching a very large dataset.

Day 4 — Schema design and data questions

• Design a relational schema for one scenario you know (for example insurance policies and claims): entities, keys, indexes, and the queries it must serve.
• Write the same data as documents in a NoSQL store and list what you gain and lose, including consistency and joins.
• Write down how you would pull insights from an unfamiliar dataset: shape, missing values, distributions, then focused questions.

Deliverable: A relational schema and a document-model version with a trade-off list, a dataset exploration checklist, and the practice SQL question solved.

Day 5 — System design and architecture

• Outline the millions-of-transactions-per-second design: ingress, queue, partitioned storage, replication, caching, and the consistency and failure behavior at each point.
• Write the REST versus SOAP comparison (message format, contract, tooling, typical uses) and a microservices answer that includes costs such as network failures and operational overhead.
• Write a performance-optimisation routine: measure, find the bottleneck, change one thing, measure again.

Deliverable: One design outline with failure behavior written next to each component, plus written answers on REST versus SOAP, microservices and performance optimisation.

Day 6 — Diagnosis, quality and learning fast

• Write the sequence you would follow for a user reporting the application is slow, including the data you gather at each step and what each result rules out.
• Walk through debugging a complex issue you actually fixed and write it up in the same sequence.
• Write your answer on code quality and maintainability (reviews, tests, naming, documentation) and on how you judge a feature's success after launch.
• Prepare a short account of learning a new technology quickly for a project.

Deliverable: A written diagnosis checklist, one real debugging case, and written answers on code quality, feature success and learning a technology quickly.

Day 7 — Behavioral stories and full run-through

• Write six stories and map them to the refactoring, disagreement, project-leadership, prioritisation, change and deadline prompts, each with situation, your decisions, measurable outcome and a lesson.
• Say each story aloud, cutting the setup to a few sentences and spending the time on your reasoning.
• Do a full mock: one coding problem, one design question, then two behavioral prompts, and note where you lose the thread.

Deliverable: Six written stories mapped to the six behavioral prompts, and a mock-interview notes sheet with the weakest area marked for review.

Behavioral stories for a team-based engineering role

Candidates report a large block of behavioral and leadership prompts, plus topics on collaboration and on explaining technical work to non-technical colleagues. The role includes code reviews and working with product managers, designers and other engineers, so stories about disagreement, shared projects and priorities fit it well. Prepare real stories with your own decisions, measured outcomes and an honest account of what went wrong.

Describe a time when you had to refactor a system. What was the outcome?

Medium · System Design / Architecture

Approach

1. Choose a refactor you drove and name the trigger in measurable terms: slow releases, a module that kept causing incidents, duplicated logic, a data model that blocked a feature. A refactor with no stated reason sounds like taste.
2. Describe the scope decision: what you rewrote, what you deliberately left alone, and how you kept the behavior identical. Mention concrete safety steps such as tests that pin current behavior before changing it, small reviewable changes, feature flags or a gradual cut-over.
3. Say what could have gone wrong and how you watched for it: error rates, latency, support tickets, rollback readiness. Use numbers you actually measured and say so if you only have qualitative evidence.
4. State the outcome plainly, including costs: time spent, features delayed, anything that did not improve. Close with what you would change in the approach.
5. If the refactor was contested, say who disagreed and what evidence settled it.

Follow-up

• How did you decide the refactor was worth the delay to feature work?
• How did you prove behavior was unchanged, and what slipped through?
• Would you do it incrementally or as a rewrite next time, and why?

Tell me about a time when you disagreed with a team member. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Pick a disagreement about something checkable: an API shape, a schema, a library, a review comment, an estimate. Avoid personality conflicts, which give the listener nothing to evaluate.
2. State the other person's position fairly, in words they would accept, then your own. Show that you understood their reasoning before arguing yours.
3. Say how you turned opinions into evidence: a small prototype, a benchmark, a look at production data, or a written comparison of options with trade-offs. Say who made the final call and how it was reached.
4. Finish with the result and the working relationship afterwards, including the case where you were wrong or the outcome was a compromise. Because the role includes code reviews, a review-thread story fits well.
5. Common failure: a story where you were simply right and the colleague was unreasonable.

Follow-up

• What would have changed your mind during the disagreement?
• What if the colleague had been senior to you, or the decision were not yours?
• How did you work with them afterwards?

Describe a successful project you led. What made it successful?

Medium · Behavioral / Leadership

Approach

1. Define leadership for a role that may have no direct reports: you set direction, broke the work into pieces, aligned product managers, designers and engineers, and cleared blockers. Pick a project where that was true for you.
2. Give the goal and how success was defined before work started (a deadline met, an error rate cut, a team unblocked), then your specific decisions: scope, sequencing, risks you raised, trade-offs you made.
3. Show coordination across roles: what you asked from product and design, how you communicated status, and how you handled a change or a slipping task.
4. Say what made it succeed in your own contribution terms and credit teammates by name. Include one thing that went badly and what you changed.
5. Common failure: a summary of what the team did with no visible decisions of yours.

Follow-up

• What was the biggest risk to the project and how did you reduce it?
• How did you handle a teammate who fell behind?
• How did you know the project was a success afterwards?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. Name your actual method rather than a list habit: rank work by impact, deadline and cost of delay, check dependencies (what blocks other people), and estimate effort so small high-value items go first.
2. Ground it in a real case where two projects competed: say what was due, who was waiting, what you chose to do first and what you postponed.
3. Show that you communicated the trade-off. Tell the stakeholder what slips and when, and ask them to confirm or reorder, instead of silently dropping work.
4. Describe how you re-check priorities when something changes, for example a production incident, and how you protect time for the work that is important but not urgent.
5. Common failure: saying you keep a to-do list without any decision rule or conflict.

Follow-up

• What do you do when two stakeholders each say their work comes first?
• Give an example of something you decided not to do and how you told people.
• How do you handle an urgent request in the middle of planned work?

Share an experience where you had to adapt to significant changes in a project.

Medium · Behavioral / Leadership

Approach

1. Pick a change that really altered the work: requirements that moved, a platform switch, a reorganisation, a dropped feature, a new dependency. State what changed and what it invalidated.
2. Describe how you re-planned: what you salvaged, what you discarded, what new risks appeared, and how you reset expectations with product managers and teammates.
3. Show the specific adjustment you made, for example a new design, a changed interface, a reduced first release or learning something new, rather than a general feeling of flexibility.
4. Report the result and one thing you learned about handling change, such as building in seams for requirements likely to move.
5. Common failure: a story that is mostly complaints about the change, or one where you simply did as told with no judgement.

Follow-up

• How did you decide what work to keep and what to throw away?
• Did you disagree with the change, and what did you do about it?
• What did you do to make later changes cheaper?

How do you handle tight deadlines and pressure?

Medium · Behavioral / Leadership

Approach

1. Choose a real deadline with consequences and state the constraint in one sentence: what was due, for whom, and what was at risk.
2. Show your triage: identify the critical path, cut or defer scope with the owner's agreement, and keep tests and review on the paths that handle money, data or customers, even when other polish is dropped.
3. Describe how you communicated early: flagging risk before the deadline, offering options such as reduced scope or later date, and sending short status updates.
4. Be honest about the cost and what you did afterwards: follow-up fixes, cleaning up shortcuts, a retrospective. Heroic overtime alone is not a method.
5. Add how you stay effective under pressure, such as splitting work into small shippable pieces and asking for help early.

Follow-up

• What did you cut, and who agreed to cutting it?
• Describe a time you missed a deadline and what you did.
• How do you stop shortcuts taken under pressure from becoming permanent?