Bridgetown Consulting Group Software Engineer Interview Guide

The 60-second brief

Bridgetown Consulting Group is a consulting firm, and candidates describe its Software Engineer role as building technology solutions for business problems on projects that span several industries. The work covers web applications, improvements to existing software and the integration of new technologies. Engineers are described as taking part in the whole delivery cycle, from gathering requirements and design through implementation and testing, alongside product managers, designers and other engineers, with code reviews and team meetings as part of the routine.

This guide is for engineers applying to Bridgetown Consulting Group as a Software Engineer. Candidates describe the role as typically drawing on 2-5 years of experience. It covers the four reported stages, the reported questions in four groups (technical and domain, behavioral and leadership, problem-solving and case studies, coding and algorithms), and a plan that spreads them across one week.

Candidates report four stages over roughly 3-5 weeks: Resume Screening, Phone/Video Screening, Technical Interviews and Behavioral Assessments. Reports do not tie individual questions to individual stages, so the plan covers every question group.

Focus areas

• Interview Process (Multi-stage Screening)
• Technology Knowledge (General)
• Telephonic Interview

Overview

The reported questions fall into four groups. Technical and domain questions are short and conceptual: which languages you are strongest in, a hard problem you solved, how you keep code quality high, what microservices are good for, and which version-control tools you use. Coding and algorithm questions cover reversing a linked list, optimizing an algorithm, stack versus queue, a dynamic programming problem and Big O notation. Problem-solving questions cover an incomplete specification, debugging a complex issue, prioritizing across projects and changing course mid-plan, plus one design prompt about handling millions of transactions per second.

Several of these are open conversational questions rather than puzzles. A prompt such as "How do you ensure the quality of your code?" has no single correct answer, so the preparation is to build answers from your own projects: the test types you actually wrote, the review habits you followed, the branching model you used. Generic answers about "writing clean code" are easy to give and easy to forget. Concrete answers name a tool, a decision and a result.

The requirements candidates describe list Java, Python or JavaScript, frameworks such as React or Django, and both SQL and NoSQL databases, with cloud services (AWS or Azure), CI/CD and Agile practice as extras. Reports also mention follow-on topics: scalability, the trade-offs of microservices and DevOps practices. Choose one language for the coding questions and be fluent in it, and be ready to describe where you used the others.

The behavioral side is large: five of the reported prompts are about conflict, motivation, leading, deadlines and team culture, and a sixth about changing plans overlaps with them. Because the role is described as collaborative and cross-functional, stories that show you working with product managers, designers and other engineers are the most useful ones to prepare. Four or five well-chosen stories can cover all of these prompts.

The Bridgetown Consulting Group interview process

Candidates report these four stages in this order, over roughly 3-5 weeks. Confirm the format of each stage with your recruiter, since reports do not say which questions come up where.

Resume Screening

Resume Screening is the first stage candidates report: a review of your resume for qualifications and fit before any conversation. The requirements candidates describe name Java, Python or JavaScript, React or Django, SQL and NoSQL, version control and Agile experience, with roughly 2-5 years in a software engineering role. Treat the resume as the script for the stages that follow, since the technical and behavioral questions are likely to start from what is written there.

What to demonstrate

• Whether your experience matches the languages, frameworks and databases the role lists
• Whether your projects show delivery from requirements to testing, not only implementation
• Whether your resume gives you material for the behavioral prompts (leading, deadlines, conflict)

How to prepare

• Rewrite each bullet as action, technology and result, and keep a number only where you can defend it
• Make sure the languages and frameworks you are strongest in are visible near the top, matching the Java, Python, JavaScript, React and Django list
• For each major project, prepare a two-sentence summary and one hard problem you solved on it
• Mark the two bullets you would most like to be asked about and rehearse them aloud

Phone/Video Screening

Phone/Video Screening is described as an early conversation to check basic skills and fit. Reports do not say which questions appear in it, so prepare the short foundational answers from the reported pool: your strongest languages and why, how you protect code quality, what you use for version control, and what microservices are. Without a shared editor to lean on, these answers have to be clear when spoken.

What to demonstrate

• Command of the fundamentals of your main language and tooling
• Clarity when explaining technical ideas aloud
• Basic fit with the collaborative, cross-functional working style the role describes

How to prepare

• Give a 60-second answer to the language question that names one language, two strengths and one limitation
• Prepare the code quality answer as a short list: tests you write, review habits, linters and CI checks
• Explain microservices in four sentences covering independent deployment, scaling, team ownership and the cost of network calls
• Have a version-control answer that goes beyond naming Git: branching, pull requests and how you resolve merge conflicts

Technical Interviews

Technical Interviews are in-depth assessments of technical ability. Candidates report coding and algorithm questions (reverse a linked list, optimize an algorithm, stack versus queue, a dynamic programming problem, Big O), problem-solving prompts (millions of transactions per second, incomplete specifications, debugging a complex issue) and follow-on topics such as microservices trade-offs, scalability and cloud infrastructure. Plan for working code in your chosen language and for design reasoning spoken at a whiteboard level.

What to demonstrate

• Working code for data-structure and algorithm problems, with complexity stated
• Structured reasoning on design and debugging questions
• Knowledge of the stack listed for the role, including databases and tooling such as CI/CD and testing frameworks

How to prepare

• Write the iterative linked-list reversal from memory in your chosen language, then the recursive version, and state the time and space cost of each
• Solve two or three dynamic programming problems end to end: define state, write the recurrence, then reduce memory where possible
• Outline a high-throughput transaction design covering partitioning, queues, idempotent writes and failure handling
• Rehearse a debugging narrative that moves from reproducing the issue to isolating it, fixing it and preventing a repeat

Behavioral Assessments

Behavioral Assessments are described as interviews on communication and collaboration. The reported prompts here are about a difficult team member, motivation, taking the lead, tight deadlines and team culture. Prepare stories where you made the decisions, and be ready to talk about people, trade-offs and results rather than only technology.

What to demonstrate

• How clearly you communicate your role and decisions in a team setting
• How you handle disagreement, pressure and shifting priorities
• Evidence of leadership and team contribution without a formal title

How to prepare

• Build four stories (conflict, leading a project, a deadline crunch, improving team practice) and map each to the reported prompts
• Write each story as situation, task, action and result, with your own actions in the first person
• Prepare one story in which a plan changed midway and say what you decided and why
• Prepare two questions for the interviewers about how engineers and product staff work together on projects

Where candidates lose points

Answering the code quality and version-control questions with tool names only

Turn each into a short practice: the tests you write and when, how reviews run, what CI checks block a merge, and how you handle a branching model and conflicts. Back it with one real example.

Writing the linked-list reversal or dynamic programming solution without stating complexity or edge cases

After the code, state time and space cost, then run an empty list, a single node and a two-node list. For dynamic programming, say the state, the recurrence and the base cases before typing.

Treating the millions-of-transactions-per-second question as a list of buzzwords

Fix scope first (reads or writes, consistency needs, failure behavior), then name the partitioning key, the queue between intake and processing, idempotent writes and what you do when a dependency is down.

Telling behavioral stories in the plural, so your own actions are missing

Write each story with I-statements for the action and result steps. Name the decision you made, the alternative you rejected and the outcome you can support.

Praising microservices without naming the costs

Pair each advantage (independent deployment, scaling, team ownership) with its cost (network failures, distributed data consistency, operational overhead, harder debugging) and say when a single deployable is the better choice.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the node shape (singly linked, value and next) and whether to reverse in place; then state the target: O(n) time, O(1) extra space.
2. Iterate with three pointers: prev = None, curr = head; in each step save nxt = curr.next, set curr.next = prev, then advance prev = curr and curr = nxt; return prev as the new head.
3. Mention the recursive version and its cost: O(n) call-stack space, which can exceed Python's default recursion limit of 1000 on long lists.
4. Test the edge cases aloud: empty list, single node, two nodes, and confirm the old head's next becomes None so no cycle remains.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes.
• Check whether a linked list is a palindrome using O(1) extra space.

How would you approach optimizing a given algorithm?

Medium · Coding / Algorithms

Approach

1. Measure before changing anything: profile (cProfile, a JVM profiler, browser dev tools) to find where time actually goes, and fix a benchmark input size.
2. Identify the current complexity and look for a better algorithm first: a nested scan replaced by a hash map takes O(n^2) to O(n); sorting plus two pointers or binary search gives O(n log n); prefix sums turn repeated range sums into O(1) lookups; memoization removes repeated subproblems.
3. Then reduce constant factors: avoid repeated allocation or work inside loops, batch I/O and database calls, and cache results that are reused.
4. State the trade-offs: extra memory for speed, and code that is harder to read; keep the existing tests passing and compare before/after numbers to prove the gain.

Follow-up

• Your O(n log n) version is slower than the O(n^2) one on real data: why might that be?
• How do you decide the optimisation is good enough to stop?
• What changes if the data no longer fits in memory?

Can you explain the difference between a stack and a queue?

Medium · Coding / Algorithms

Approach

1. Define both by order: a stack is LIFO (push and pop at the same end), a queue is FIFO (enqueue at the back, dequeue from the front); both operations are O(1) with the right implementation.
2. Name the implementation pitfalls: in Python a list works as a stack (append/pop amortized O(1)) but list.pop(0) is O(n), so a queue should use collections.deque; in Java, ArrayDeque serves as both and is generally preferred over the legacy synchronized Stack class.
3. Tie each to uses: stacks for function calls, undo, DFS, bracket matching and monotonic-stack problems; queues for BFS, task scheduling and producer-consumer buffers.
4. Mention the relatives: a deque allows both ends, a priority queue (binary heap) dequeues by priority in O(log n), and a circular buffer gives a fixed-capacity queue.

Follow-up

• Implement a queue using two stacks and give the amortized cost per operation.
• Design a stack that returns its minimum element in O(1).
• Use a stack to check whether a string of brackets is balanced.

Solve a problem involving dynamic programming.

Medium · Coding / Algorithms

Approach

1. Confirm DP applies: the problem has optimal substructure and overlapping subproblems, which a naive recursion reveals by recomputing the same arguments.
2. Define the state in one sentence, then the recurrence, base cases and evaluation order; for minimum coins: dp[0] = 0, dp[a] = min over coins c <= a of dp[a - c] + 1, with unreachable amounts set to infinity and reported as -1.
3. Choose top-down memoization or a bottom-up table and give complexity as states times transitions: coin change is O(amount x coins) time and O(amount) space.
4. Optimise space where only recent rows matter (rolling arrays, as in longest common subsequence, which drops from O(mn) to O(min(m, n)) space), and test the edge cases: amount 0, no valid answer, a single coin.

Follow-up

• Count the number of ways to make the amount instead: how does the loop order change the answer?
• How do you reconstruct which coins were used, not just how many?
• How would you convert your memoized solution to bottom-up, and why might you?

What is the Big O notation, and why is it important?

Medium · Coding / Algorithms

Approach

1. Give the definition: f(n) is O(g(n)) if there are constants c and n0 with f(n) <= c * g(n) for all n >= n0, so it is an upper bound on growth that drops constants and lower-order terms.
2. Walk the common classes with examples: O(1) average hash lookup, O(log n) binary search, O(n) a single scan, O(n log n) comparison sorting (also the lower bound for comparison sorts), O(n^2) nested loops, O(2^n) enumerating subsets.
3. Separate worst, average and amortized cases (a dynamic array append is amortized O(1)), and mention Theta for tight bounds and Omega for lower bounds, plus space complexity including recursion depth.
4. Explain why it matters with numbers: at n = 10^6, an O(n^2) algorithm needs about 10^12 steps while O(n log n) needs about 2 x 10^7, and add the limit: for small n, constants and cache behaviour can decide which is faster.

Follow-up

• What is the worst-case lookup in a hash map, and how do implementations mitigate it?
• Why is appending to a dynamic array amortized O(1)?
• Give the time and space complexity of a recursive Fibonacci with and without memoization.

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

1. 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.
2. 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.
3. 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.
4. 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?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

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

Approach

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

Follow-up

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

What programming languages are you most proficient in, and why?

Medium · Technical / Domain Questions

Approach

1. Lead with one primary language from the set candidates report for this role (Java, Python or JavaScript) and anchor it to a project you shipped in it, rather than listing every language you have touched.
2. Explain the 'why' through concrete language properties: Java's static typing, generics and the java.util.concurrent toolkit; Python's fast iteration and libraries such as Django; JavaScript's single-threaded event loop with async/await for I/O-heavy front ends in React.
3. Show you know the limits of your main language, for example: in standard CPython builds the GIL lets only one thread run Python bytecode at a time, so I move CPU-bound work to multiprocessing or native extensions.
4. Separate proficiency levels honestly: 'production depth' versus 'can read and fix', and name the tooling you use in each (test runner, linter, package manager).

Follow-up

• What is a bug your main language let you write that a stricter type system would have caught?
• How would you pick a language for a new CPU-heavy backend service?
• What do you miss from your second language when you work in your first?

Describe a challenging technical problem you faced and how you resolved it.

Medium · Technical / Domain Questions

Approach

1. Pick a problem that was hard for a technical reason (a race condition, a memory leak, a slow query, a data inconsistency), not one that was hard only because of a deadline.
2. Structure it as constraint, symptom, investigation, root cause, fix, result: say what made it hard and which hypotheses you ruled out with what evidence.
3. Name the actual tools and data: profiler output, a query plan, a heap dump, logs with a request id, a git bisect that isolated the commit.
4. Quantify the outcome (latency, error rate, incidents) and close with what you added so it cannot recur: a regression test, an alert, a code review check.
5. Keep the narrative in the first person singular so your own contribution is clear.

Follow-up

• Which alternative fix did you reject, and why?
• How did you confirm the root cause rather than a coincidence?
• What would you do differently if the same problem appeared today?

How do you ensure the quality of your code?

Medium · Technical / Domain Questions

Approach

1. Describe layered checks, not one habit: unit tests for logic, a smaller set of integration tests for database and API boundaries, and only a few end-to-end tests, using frameworks such as pytest, JUnit or Jest.
2. Add static checks that run before review: formatter, linter (ESLint, Ruff or flake8), and type checking (TypeScript, mypy) so reviewers spend time on design rather than style.
3. Explain the review workflow: small pull requests, a CI pipeline that must pass before merge, and a reviewer who checks naming, error handling and test coverage of edge cases.
4. State the trade-off: a coverage percentage measures executed lines, not correct assertions, so I test behaviour at boundaries (empty input, nulls, concurrency, failure of a dependency).
5. Mention quality after release: logging, metrics and feature flags so a defect that escapes is caught and rolled back quickly.

Follow-up

• How do you decide what not to test?
• What do you do about a flaky test that blocks the CI pipeline?
• How would you add tests to legacy code that has none?

Can you explain the concept of microservices and its advantages?

Medium · Technical / Domain Questions

Approach

1. Define it precisely: an application split into small services that are deployed independently, each owning its own data store and talking over the network through HTTP/gRPC APIs or a message broker.
2. Name the advantages with the mechanism behind each: independent deploys shorten release cycles, each service scales on its own load, a crash is contained to one service, and teams can own services end to end.
3. Give the costs in the same answer: network calls add latency and partial failure (needing timeouts, retries with backoff and circuit breakers), and there are no ACID transactions across services, so consistency uses sagas or a transactional outbox.
4. Cover the operational overhead: service discovery, per-service CI/CD, centralised logging and distributed tracing with correlation ids.
5. Say when not to use them: for a small team or an unclear domain, a modular monolith with clean module boundaries is often cheaper, and services can be extracted later.

Follow-up

• How would you split an existing monolith into services?
• How do you keep an order and its payment consistent when they live in two services?
• How would you trace one slow user request across five services?

What tools do you use for version control, and why?

Medium · Technical / Domain Questions

Approach

1. Name Git and the hosting platform you have used (GitHub, GitLab or Bitbucket), and explain why: local commits, cheap branches, full history and pull-request review.
2. Describe your branching workflow and its trade-off: trunk-based development with short-lived branches keeps merges small, while long-lived release branches (GitFlow style) suit scheduled releases but cause bigger conflicts.
3. Show command-level fluency: merge versus rebase (rebase rewrites commit ids, so never on a shared branch), git revert to undo a pushed commit safely, and git bisect to find the commit that introduced a regression.
4. Cover hygiene: small atomic commits with messages that explain why, CI checks on every pull request, and protected main branches.

Follow-up

• A commit already pushed to main broke production: how do you undo it?
• You committed a secret to a public repository: what do you do first?
• How do you resolve a merge conflict in a file you did not write?

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

Medium · Problem-Solving / Case Studies

Approach

1. Clarify first: what a transaction is (payment, order, event), the read/write ratio, required latency, and whether every write must be durable and strongly consistent. Then size it: 1M writes/s 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, and require an idempotency key on each request so client retries cannot create duplicate transactions.
3. Partition the write path by a key such as account id, so each shard handles a fraction of the load with local ACID transactions; put a partitioned log (for example Kafka) in front to absorb bursts and decouple downstream consumers.
4. Address cross-shard work and hot keys: a transfer between shards becomes a saga with compensating steps, and a hot account needs sub-partitioning or batching.
5. Separate the read path (caches, read replicas or a CQRS read model updated from the log) and state the durability trade-off: synchronous replication within a shard costs latency, asynchronous replication risks losing recent writes on failover.

Follow-up

• One merchant suddenly produces a large share of all traffic: what breaks and how do you fix it?
• How do you get effectively exactly-once processing when the broker delivers at least once?
• How would you load-test this before launch?

If given an incomplete specification for a project, how would you proceed?

Medium · Problem-Solving / Case Studies

Approach

1. List the unknowns and rank them by the cost of guessing wrong: data model and external contracts are expensive to change later, UI details usually are not.
2. Go to the stakeholder with specific questions and concrete options ('A or B, and here is what each costs'), rather than an open 'what do you want?'.
3. Write down the assumptions I am proceeding on and get them acknowledged, so a later change is a visible scope change, not a surprise.
4. Build a thin end-to-end slice first and show it early, because working software surfaces missing requirements faster than documents.
5. Isolate the uncertain parts behind interfaces, configuration or feature flags so a changed answer touches one module.

Follow-up

• What do you do if the stakeholder cannot be reached for a week?
• How do you handle a requirement that changes after you have built the feature?
• How do you decide you have asked enough questions and should start building?

How do you prioritize tasks when working on multiple projects?

Medium · Problem-Solving / Case Studies

Approach

1. Start from a single list of everything in flight, then rank by impact, deadline and dependencies: work that unblocks other people goes first.
2. Separate urgent from important explicitly: production issues and blockers interrupt, everything else is scheduled.
3. Make trade-offs visible: when two priorities collide, I tell both stakeholders what slips if I take one first and let the owner of the priority decide.
4. Limit work in progress: finishing one task beats having three half-done, and I time-box investigation work so it cannot swallow a week.
5. Back it with one real example in the first person: the competing tasks, the order I chose, why, and how it turned out.

Follow-up

• Two managers each say their project is the top priority: what do you do?
• An urgent bug lands in the middle of a planned feature: how do you handle it?
• Tell me about a time you got the prioritisation wrong.

Discuss a scenario where you had to pivot from your original plan. What was your thought process?

Medium · Problem-Solving / Case Studies

Approach

1. Set up the original plan and the assumption it depended on, for example an expected data volume, a library's capability or a deadline.
2. Name the concrete signal that broke the assumption (a benchmark, a failing load test, a changed requirement) and when you noticed it.
3. Walk through the options you weighed, including staying the course, with their cost; ignore sunk cost and compare only remaining effort and risk.
4. Say how you made and communicated the decision to the team and stakeholders, then quantify the result.
5. Close with what you reused from the first plan and what check you now run earlier to catch that kind of signal.

Follow-up

• Could you have spotted the problem earlier, and how?
• What did the pivot cost, and was it worth it?
• How did you convince people who preferred the original plan?

Describe your approach to debugging a complex software issue.

Medium · Problem-Solving / Case Studies

Approach

1. Reproduce it reliably first and shrink it to a minimal case: exact inputs, environment, version and data; a bug I cannot reproduce I instrument instead of guessing.
2. Establish what changed: recent deploys, configuration, dependency upgrades, data volume or shape; then read the evidence (stack traces, logs keyed by request id, metrics, traces) before forming a theory.
3. Narrow the search by halving: git bisect across commits, disabling components, or cutting the input in half, so each test eliminates half the candidates.
4. Test one hypothesis at a time with a prediction that could prove it wrong; for intermittent failures suspect races, timeouts and shared state, and add targeted logging or stress tests.
5. Fix the root cause rather than the symptom, add a regression test that fails without the fix, and record what monitoring would have caught it sooner.

Follow-up

• The bug only appears in production and never locally: what do you do?
• The bug disappears when you add logging: what does that suggest?
• How do you tell the trigger of an incident from its cause?

Suggested practice checklist

Each day targets one cluster of reported questions: resume and fundamentals, data structures, dynamic programming and optimization, engineering practice, design, then behavioral stories and a full mock pass. Each day ends with something you wrote or said aloud.

Day 1 — Resume, stack and the spoken fundamentals

• Write the four reported stages in order and note what you still need to confirm with the recruiter about each
• Rewrite your resume bullets around the Java, Python, JavaScript, React, Django and SQL/NoSQL work you have done
• Record a one-minute spoken answer to the question about your strongest programming languages and why

Deliverable: A one-page loop map, a revised resume with action-technology-result bullets and one recorded language answer.

Day 2 — Data structures and complexity

• Implement iterative and recursive linked-list reversal in your chosen language and state the time and space complexity of each
• Write stack and queue from scratch, once with an array and once with linked nodes, and list a real use for each
• Write a Big O explanation using three examples (a hash lookup, a binary search, a nested loop) and what each costs as input grows

Deliverable: Two working reversal functions, two data-structure implementations and a half-page Big O explanation with examples.

Day 3 — Dynamic programming and optimizing an algorithm

• Solve three dynamic programming problems of increasing difficulty (such as climbing stairs, coin change and longest common subsequence), writing state and recurrence before code
• Reduce the memory of one solution from a full table to a rolling row
• Take a slow brute-force solution you wrote earlier and optimize it step by step, naming the bottleneck at each step

Deliverable: Three DP solutions with written recurrences, one space-optimized version and a short before-and-after complexity note for the optimization.

Day 4 — Engineering practice answers

• Write the code quality answer as a list of practices tied to a real project: tests, reviews, linters, CI
• Prepare a version-control answer covering branching, pull requests and resolving a merge conflict
• Write a four-sentence explanation of microservices with two advantages and two costs
• Outline a debugging story from a real incident: reproduce, isolate, fix, prevent

Deliverable: Four spoken-ready answers on code quality, version control, microservices and debugging, each written as bullet points from your own work.

Day 5 — System design and ambiguity

• Design a system for millions of transactions per second on paper: components, partition key, queue, storage and failure handling
• Write the questions you would ask first when given an incomplete specification, and how you would record assumptions

Deliverable: One design diagram with a written failure analysis, a list of clarifying questions for an incomplete spec and notes on both practice exercises.

Day 6 — Behavioral story bank

• Write four stories in situation, task, action, result form: a conflict, a project you led, a deadline crunch and a team practice you improved
• Map each story to the five reported behavioral prompts and the prioritization and plan-change questions
• Say each story aloud and trim it until your own actions are clear and the result is stated

Deliverable: Four written stories with a prompt-to-story map, and a spoken version of each that you can deliver in a few minutes.

Day 7 — Full mock pass

• Do a mock technical session: reverse a linked list, solve a dynamic programming problem and answer the transaction-scale design question aloud
• Do a mock behavioral session with a friend and ask for feedback on clarity and ownership of actions
• List the three weakest answers from the week and rewrite them once more

Deliverable: A recording or notes from the mock session, plus three revised answers.

Behavioral stories for the Bridgetown loop

Candidates report that the behavioral stage centers on communication and collaboration, and the prompts concern conflict, motivation, leadership, pressure and team culture. For a role described as cross-functional, prepare stories where you worked with product managers, designers and other engineers, and be explicit about what you personally decided and did.

1. Discuss a scenario where you had to pivot from your original plan. What was your thought process?

Describe a time when you had to work with a difficult team member. How did you handle the situation?

Medium · Behavioral / Leadership

Approach

1. Choose a real friction with specific behavior, such as repeated missed review deadlines, dismissive comments on pull requests or a stalled decision, rather than a vague personality clash. Describe the impact on the work in one or two sentences.
2. Show your first move was to understand them: a private one-to-one, asking what constraint or pressure they were under, and checking whether you had contributed to the problem.
3. Describe the concrete agreement you reached, for example a review turnaround, a written design note before large changes, or a split of ownership. Disagreements about technical choices are best settled with evidence such as a prototype or benchmark.
4. State when you escalated, if you did, and how: to a lead, with facts and a proposal, after trying direct conversation first. Close with the result for the project and the working relationship.
5. The story fails if the other person is the villain or if you tell it passively. Speak about your actions and what you would change next time.

Follow-up

• What if the person had not changed their behavior after your conversation?
• What did you learn about your own working style from this?
• How did you keep the project moving while the conflict was unresolved?

What motivates you in a work environment, and how do you stay productive?

Medium · Behavioral / Leadership

Approach

1. Name two real motivators and attach each to a behavior or a project: for instance, solving unfamiliar problems (and how you chose a hard task), or seeing users depend on something you shipped. Avoid a list of adjectives.
2. Role-specific angle: candidates describe work spanning several industries and cross-functional teams, so connect your motivation to learning a new domain quickly and working with product and design colleagues, if that is true for you.
3. Describe the productivity habits you actually use: planning the day around one main task, protected focus blocks, small pull requests, fast local test runs, and written notes at the end of the day.
4. Say what you do when motivation dips, such as repetitive maintenance work: you break it down, automate part of it or pair with someone. Show self-awareness, not perfection.
5. Avoid generic answers like "I like challenges" with no example, and avoid motivators that sound like they conflict with teamwork.

Follow-up

• What demotivates you at work, and what did you do the last time it happened?
• How do you stay productive when requirements keep changing?
• Tell me about a project that did not motivate you and how you handled it.

Tell me about a time when you took the lead on a project.

Medium · Behavioral / Leadership

Approach

1. Pick a story where you led without necessarily having the title: a feature, a migration, an on-call improvement or a release. State the goal and the stakes briefly.
2. Show the leadership mechanics: how you broke the work into pieces, agreed interfaces so people could work in parallel, assigned work to match strengths, and set up regular check-ins or a short written status.
3. Include a decision that was yours, such as cutting scope, choosing one technical option over another or deciding who pairs with whom, and the reasoning behind it. Mention how you handled a setback or someone falling behind.
4. Finish with the result and what you learned about leading, using specifics from the project such as shipped date, reduced incidents or adoption by other teams, only where you can state them truthfully.
5. Common failure: saying "we" throughout so your role is invisible, or showing that leading meant doing everything yourself.

Follow-up

• How did you handle a teammate who was not delivering?
• What did you decide not to do, and how did you communicate that?
• What would you change about how you led it if you ran it again?

How do you handle tight deadlines and pressure?

Medium · Behavioral / Leadership

Approach

1. Choose a real deadline with a real constraint, such as a fixed launch date or customer demo, and describe what was at risk if it slipped.
2. Show your sequence: list everything outstanding, rank by user impact and risk, agree the minimum shippable scope with the stakeholder, and cut or defer the rest explicitly instead of quietly dropping it.
3. Say how you protected quality under pressure: kept tests on the critical path, shipped behind a feature flag, or limited changes to reviewed code. Explain what you deferred and the follow-up ticket you left behind.
4. Show communication: you raised the risk early, gave options with trade-offs, and updated people at agreed points. Describe how you managed your own energy so the team did not run on heroics.
5. The answer sinks if it is all overtime and no prioritization, or if you hid the risk until the last day.

Follow-up

• What would you do if the deadline were impossible even after cutting scope?
• Tell me about a deadline you missed and what you learned.
• How do you say no to a request without damaging the relationship?

Can you give an example of how you have contributed to a positive team culture?

Medium · Behavioral / Leadership

Approach

1. Give a concrete contribution that changed how a team worked: introducing a pull-request checklist, writing an onboarding guide, running pairing sessions, starting blameless post-incident reviews or rotating demo duty. Generic claims about being friendly are not enough.
2. Explain why you did it, meaning the problem you saw, such as slow reviews, repeated incidents or new hires waiting on answers. Show you asked teammates before changing anything.
3. Describe the effect with evidence from your own team, such as faster review turnaround, a new hire shipping sooner or fewer repeat bugs. Use only measurements you can back up.
4. Show inclusion in practice: making sure quieter people got heard in design discussions, or giving credit publicly. Link it to collaborating with product managers and designers if you have that experience.
5. Avoid answers that are only social events or that make you the one hero of the culture; show something that continued after you stopped pushing.

Follow-up

• How would you improve culture on a team that resists change?
• Describe a time a team practice you introduced did not work.
• How do you keep the team connected when people are remote or on different schedules?