Amplify Marketing Agency Software Engineer Interview Guide

The 60-second brief

According to the role descriptions candidates cite, Amplify Marketing Agency's software engineers build and maintain the applications its marketing teams use to plan and deliver campaigns, and the work spans backend services as well as user-facing features. Engineers are described as working alongside product managers, designers and data analysts, and the stack candidates mention includes Java, JavaScript and Python, React and Node.js, RESTful APIs, Git, and both SQL and NoSQL databases, with cloud platforms such as AWS or Azure, Angular and DevOps tooling listed as extras.

This guide is for a Software Engineer candidate preparing for Amplify Marketing Agency, roughly at the level the reported requirements describe (around 3-5 years of development experience with agile teams). It covers the three reported stages, the 25 questions candidates report across technical fundamentals, coding, system design, behavioral and problem-solving case prompts, and how to practise each one in Java, JavaScript or Python.

Candidates report three rounds over about 3-5 weeks: a recruiter phone screen, a technical assessment stage with coding challenges and system design discussions, and a final onsite or virtual interview with several team members covering technical skills and cultural alignment.

Focus areas

• Coding Exercises / Implementation
• Problem Solving (coding interviews)
• System Design (scalability/design questions)

Overview

The reported question set is broad rather than deep. The coding questions are well-known problems (reversing a linked list, FizzBuzz, binary search, the longest substring without repeating characters, two sum), so a sensible target is clean, correct, tested code on the first attempt rather than a clever trick. Rehearse each one until you can write it without bugs, name its complexity and walk its edge cases in the language you will use.

The design questions range from a concrete service (a URL shortener) to open architecture topics: a scalable web application, microservices trade-offs, caching for a high-traffic site and data consistency across machines. Prepare one reusable skeleton (clients, CDN, load balancer, stateless app tier, cache, database with replicas, queue and workers) and then learn the specific depth each topic needs: key generation and redirects for the shortener, invalidation and stampedes for caching, sagas and idempotency for consistency.

The technical fundamentals questions reflect the stack candidates describe: REST versus GraphQL for APIs, state management in React, polymorphism in object-oriented code, unit testing and Agile practice. Candidates also say Node.js is often tested alongside React, so be ready to discuss it too. Answer with trade-offs and a concrete example from your own work, not a textbook definition: a two-sentence definition followed by when you would pick one option over another covers most of the ground.

Ten of the 25 reported questions are behavioral or case prompts: a challenging project, competing deadlines, team conflict, motivation, criticism, learning a technology fast, deciding with incomplete information, a slipping project, code review and debugging a production issue. Candidates report the final stage assesses cultural alignment with several team members, so build six to eight STAR stories from your own projects and map them to the ten prompts so that no story is used more than twice.

The Amplify Marketing Agency interview process

Candidates describe three stages in this order. Questions are not reported against specific stages, so keep every category ready from the technical assessment onward.

Preliminary Phone Screen

Candidates report this first stage as a conversation with a recruiter about their background and how well it fits the role. Treat it as a screen against the reported requirements: be ready to show where you have used Java, JavaScript or Python, a web framework and REST APIs, and to explain why you want to build software for a marketing agency's campaign teams. Use the end of the call to ask how the technical assessment is run and which language you may use.

What to demonstrate

• Your background, as discussed with the recruiter
• How well that background fits the role as candidates describe it

How to prepare

• Write a two-minute walkthrough of your experience that names one backend project and one user-facing project, with the languages and frameworks used in each.
• Prepare a specific answer to what motivates you to do your best work, tied to building tools that other teams (product, design, analysts, marketers) use daily.
• List questions for the recruiter: the format of the technical assessment, permitted languages, the team you would join and the work arrangement.

Technical Assessments

Candidates report coding challenges and system design discussions at this stage, used to evaluate technical skills. The reported coding questions are classic data structure and algorithm problems, and the reported design questions run from a URL shortening service to caching, microservices and consistency topics. As preparation, restate each coding problem, name the brute force, write the optimal version and test it on edge cases aloud; for design, fix requirements and rough numbers before drawing components.

What to demonstrate

• Technical skills shown in coding challenges
• Technical skills shown in system design discussions

How to prepare

• Write the linked-list reversal, binary search, sliding-window substring and hash-map two sum solutions from memory in your interview language, each with a short test list.
• Practise the URL shortener end to end: base62 keys, storage schema, redirect status code, cache layer and click analytics.
• Prepare a caching and consistency toolkit you can apply to any design: cache-aside, TTLs, stampede protection, idempotency keys, the outbox pattern and sagas.

Onsite or Virtual Interview

Candidates describe the final stage as an onsite or virtual interview where they meet several team members who assess technical skills and cultural alignment. Since the reported fundamentals, debugging and behavioral questions are not tied to a stage, arrive with each of them rehearsed and with stories that show how you work with product managers, designers and data analysts.

What to demonstrate

• Technical skills, assessed by several team members
• Cultural alignment and how you work within a team

How to prepare

• Build six to eight STAR stories covering a hard project, competing deadlines, a conflict, criticism, learning a technology quickly, deciding without full information and a slipping project.
• Rehearse a step-by-step production debugging answer: mitigate, gather evidence, isolate, fix, prevent.
• Prepare short trade-off answers on REST versus GraphQL, React state management, polymorphism, unit testing and Agile, each with an example from your own code.

Where candidates lose points

Writing a classic coding problem with an off-by-one bug: a binary search that loops forever, or a reversed list whose old head still points forward.

For each reported coding problem, write the solution once, then trace it by hand on the empty input, a single element and a duplicate case before saying it is done. Pick one binary search invariant and use it every time, and in two sum check the map before inserting so an element never pairs with itself.

Jumping to microservices, Kafka and sharding for the URL shortener or the scalable web app before stating requirements or rough numbers.

Open every design answer with users, operations and read/write ratio, then build up from a single server, adding a cache, replicas, a queue or partitioning only when you can name the constraint each one fixes.

Answering REST versus GraphQL or React state management as a feature list with no trade-offs.

For each fundamentals question prepare a when-would-I-pick-each answer: caching and N+1 for GraphQL, Context re-renders and server-state libraries for React, and one example from code you wrote.

Describing a production debugging session as reading the logs until the bug turns up, with no mitigation step.

Rehearse the sequence aloud: assess impact, mitigate by rollback or feature flag, gather metrics, logs and recent changes, isolate by bisecting, fix with a regression test, then a postmortem.

Reusing one project story for all ten behavioral and case prompts, or telling stories where your own role is unclear.

Map six to eight distinct stories to the reported prompts before the final stage so none is used more than twice, and for each write down the decision you personally made and a number that shows the result.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Iterative solution: prev = null, curr = head; loop while curr: next = curr.next, curr.next = prev, prev = curr, curr = next; return prev. O(n) time, O(1) extra space.
2. Recursive alternative: reverse the rest, then head.next.next = head and head.next = null. Still O(n) time but O(n) call stack, which can overflow on long lists.
3. Edge cases: empty list, single node, two nodes. Confirm the old head's next becomes null so no cycle remains.
4. Test by converting an array to a list, reversing it, converting back and comparing with the reversed array.

Follow-up

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

Solve the FizzBuzz problem.

Medium · Coding / Algorithms

Approach

1. Loop i from 1 to n; check divisibility by 15 (or by both 3 and 5) before checking 3 or 5, otherwise 15 prints Fizz.
2. Cleaner variant: build the output string by appending Fizz when i % 3 == 0 and Buzz when i % 5 == 0, falling back to the number when the string is empty.
3. Make it extensible: drive it from an ordered list of (divisor, word) pairs so adding a rule such as 7 to Bazz is one line.
4. Clarify output: print versus return a list, and what happens for n <= 0. O(n) time.
5. Test 1, 3, 5, 15 and n = 0 aloud.

Follow-up

• Make the rules configurable at runtime.
• Solve it without the modulo operator.
• How would you unit test this function?

Implement a binary search algorithm.

Medium · Coding / Algorithms

Approach

1. Precondition: the array is sorted. Use lo = 0, hi = n - 1, loop while lo <= hi, mid = lo + (hi - lo) / 2, then return mid on match or move lo = mid + 1 or hi = mid - 1. O(log n) time, O(1) space.
2. Explain the mid formula: lo + (hi - lo) / 2 avoids integer overflow in Java, where (lo + hi) / 2 can overflow.
3. Commit to one invariant, closed [lo, hi] or half-open [lo, hi), and keep the loop condition and updates consistent with it; mixing them causes off-by-one errors and infinite loops.
4. Know the variants: lower bound (first index >= target), first and last occurrence with duplicates, and searching on an answer space.
5. Edge cases: empty array, one element, target below the minimum or above the maximum, many duplicates.

Follow-up

• Find a target in a rotated sorted array.
• Return the first occurrence of a target that appears many times.
• Find the minimum ship capacity to deliver packages within D days.

How would you find the longest substring without repeating characters?

Medium · Coding / Algorithms

Approach

1. Mention brute force first: check every substring for uniqueness, O(n^3), or O(n^2) with a set.
2. Optimal: sliding window with a map from character to its last index. For each right index, if the character was seen at or after left, move left to lastIndex + 1; update the map and the best length right - left + 1.
3. Explain the guard: left = max(left, last[c] + 1) prevents left from moving backwards on inputs like abba.
4. Complexity: O(n) time, O(min(n, alphabet size)) space.
5. Edge cases: empty string returns 0, all identical characters return 1, all unique return n.

Follow-up

• Return the substring itself, not only its length.
• Find the longest substring with at most k distinct characters.
• How would this change for a stream of characters?

Given a list of integers, find two numbers that sum to a specific target.

Medium · Coding / Algorithms

Approach

1. Clarify: return indices or values, exactly one answer or possibly none, duplicates and negatives allowed.
2. Brute force is two nested loops, O(n^2). Optimal: one pass with a hash map from value to index; for each x, check whether target - x is already in the map, then insert x. O(n) time and space.
3. Checking before inserting avoids pairing an element with itself, and still finds [3, 3] with target 6.
4. Alternative: sort and use two pointers for O(n log n) time and O(1) extra space, but original indices are lost unless you sort pairs of (value, index).
5. State what you return when no pair exists, and test with negatives and duplicates.

Follow-up

• Return all unique pairs that sum to the target.
• Extend it to three numbers that sum to zero.
• Design a class that supports add(number) and find(target) on a stream.

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

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?

Explain the differences between REST and GraphQL.

Medium · Technical / Domain Questions

Approach

1. Define both in one line each: REST exposes resources at URLs operated on with HTTP verbs and status codes; GraphQL exposes one endpoint with a typed schema where the client selects exactly the fields it needs.
2. Name the problems GraphQL solves: over-fetching and under-fetching, and nested data that would take several REST round trips (a dashboard needing a campaign, its ads and their metrics in one call).
3. Name what it costs: HTTP and CDN caching is easy for REST GET requests but harder for GraphQL POST queries (persisted queries or client caches such as Apollo help); resolvers can cause N+1 database queries, fixed with DataLoader-style batching.
4. Cover errors and evolution: REST uses status codes and versioned paths; GraphQL usually returns 200 with an errors array and partial data, and evolves by adding fields and marking old ones @deprecated.
5. Close with a decision rule: REST for simple, cache-heavy or public CRUD APIs; GraphQL when many clients need different shapes of related data.

Follow-up

• How would you stop a GraphQL resolver tree from issuing one database query per item?
• How would you protect a GraphQL API from a deeply nested, very expensive query?
• How would you cache GraphQL responses at the edge?

How do you manage state in a React application?

Medium · Technical / Domain Questions

Approach

1. Classify state before picking a tool: local UI state (useState, useReducer), shared client state, server state fetched from an API, URL state (route and search params) and form state.
2. Keep local state local and lift it to the nearest common parent when siblings share it; use Context for low-frequency global values such as theme or the signed-in user, and Redux Toolkit or Zustand when many components write to shared state and you want devtools and middleware.
3. Treat server data as a cache, not app state: React Query or SWR handle loading, errors, refetching, deduplication and invalidation after mutations.
4. Avoid common bugs: storing derived values instead of computing them, mutating state instead of returning new objects, stale closures in useEffect, and fetch races (cancel with AbortController or ignore stale responses).
5. Mention render cost: every Context consumer re-renders when the value changes, so split contexts, memoise the value and use selectors in Redux.

Follow-up

• When would you move from Context to Redux or Zustand, and what would push you there?
• How would you implement an optimistic update with rollback on failure?
• How do you find and fix unnecessary re-renders?

Describe the concept of polymorphism in object-oriented programming.

Medium · Technical / Domain Questions

Approach

1. Define it: code written against a common interface works with many concrete types, and the right behaviour is chosen per type.
2. Separate the kinds: subtype (runtime) polymorphism through method overriding and dynamic dispatch; compile-time polymorphism through overloading; parametric polymorphism through generics such as List<T>.
3. Give a concrete example: a Notifier interface with EmailNotifier and SmsNotifier implementations; the caller loops over List<Notifier> and calls send(), so adding a channel needs no caller change, unlike a switch on a type field.
4. Mention language differences: Java resolves overrides through virtual dispatch (vtables) and overloads on the static type; Python and JavaScript rely on duck typing and prototypes.
5. Add the design caveat: subtypes must honour the base contract (Liskov substitution), and composition is often safer than deep inheritance.

Follow-up

• What is the difference between overloading and overriding, and when is each resolved?
• Give an example that violates Liskov substitution and how you would fix it.
• How does dynamic dispatch work under the hood in Java?

What are the key principles of Agile software development?

Medium · Technical / Domain Questions

Approach

1. State the four values of the Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.
2. Pick out the principles that drive daily work: frequent delivery of working software, welcoming changing requirements, close daily collaboration between business people and developers, sustainable pace, simplicity, and regular reflection to adjust.
3. Map them to practice: Scrum (sprint planning, daily standup, review, retrospective, backlog) and Kanban (visualised flow, WIP limits).
4. Make it personal: describe one retrospective outcome or one change in requirements your team absorbed, and what it changed in how the work shipped.
5. Avoid the trap of reciting ceremonies; say that Agile is about short feedback loops, not the absence of planning or documentation.

Follow-up

• How do you handle a request to change scope in the middle of a sprint?
• Scrum or Kanban: when would you choose each?
• What goes into a good definition of done?

Explain the importance of unit testing and how you implement it.

Medium · Technical / Domain Questions

Approach

1. Say why: unit tests give fast feedback, catch regressions, make refactoring safe and document the intended behaviour of a function.
2. Describe the structure: Arrange-Act-Assert, one behaviour per test, descriptive names, using JUnit for Java, Jest for JavaScript or pytest for Python, run in CI on every pull request.
3. Cover isolation: inject dependencies so databases, HTTP clients, clocks and randomness can be replaced by fakes or mocks at the boundary, without mocking the internals you are testing.
4. List the cases you always write: happy path, empty and null input, boundaries, invalid input and error paths.
5. Place it in the test pyramid: many fast unit tests, fewer integration tests, a few end-to-end tests; treat coverage as a signal of gaps, not a target.

Follow-up

• What is the difference between a mock, a stub and a fake?
• How would you test code that depends on the current time?
• When is an integration test more valuable than a unit test?

How would you design a URL shortening service?

Medium · System Design / Architecture

Approach

1. Fix requirements: create a short link, redirect, optional custom alias and expiry, click counts; reads far outnumber writes, so size storage and redirect traffic with rough numbers.
2. Key generation: base62-encode a unique ID from a counter, range-allocated per server to avoid one bottleneck (7 base62 characters give about 3.5 trillion codes), or hash the URL and handle collisions; reject taken custom aliases with a unique constraint.
3. Storage and reads: a table keyed by code with long URL, owner, created and expiry times; a key-value store or SQL with a primary key on code; cache hot codes in Redis in front of it.
4. Redirect choice: 301 is cached by browsers and loses click counts; 302 keeps every click visible to analytics.
5. Since this company is a marketing agency, you can frame the links as campaign tracking links and say so aloud as your assumption: keep UTM parameters intact through the redirect, attribute each click to a campaign and client, and plan for the traffic spike when a campaign launches by queuing click events and aggregating them asynchronously. Add rate limits on creation and screening of malicious URLs.

Follow-up

• How do you count billions of clicks without slowing down redirects?
• How would you expire and delete links safely?
• What happens if two users request the same custom alias at once?

Discuss the architecture of a scalable web application.

Medium · System Design / Architecture

Approach

1. Start from the request path: DNS, CDN for static assets, load balancer, stateless application servers in an autoscaling group, cache, primary database with read replicas, object storage for files.
2. Keep the app tier stateless by storing sessions in Redis or using signed tokens, so any server can take any request.
3. Scale reads with caching and replicas (handle replica lag for read-your-writes); scale writes with partitioning or sharding by a key that matches the main access pattern.
4. Move slow work (emails, report generation, imports) to a queue with background workers.
5. Add operations: health checks, metrics, logs and tracing, and rolling or blue-green deploys; finish by naming what breaks first at ten times the load.

Follow-up

• Where do sessions live once you run many app servers?
• A user updates a record and immediately sees the old value. Why, and how do you fix it?
• Which component fails first when traffic grows tenfold?

What considerations do you take into account when designing a microservices architecture?

Medium · System Design / Architecture

Approach

1. Draw boundaries around business capabilities, and give each service its own data store; a shared database couples deployments.
2. Choose communication per call: synchronous REST or gRPC when the caller needs an answer now, asynchronous events through a queue or log when it does not. Add timeouts, retries with backoff and jitter, circuit breakers and idempotent handlers.
3. Handle cross-service consistency with sagas and compensating actions, and publish events reliably with the transactional outbox pattern.
4. Count the operational cost: CI/CD per service, service discovery, an API gateway, distributed tracing and correlation IDs, and contract versioning so consumers do not break.
5. State when not to split: a small team is often better served by a modular monolith, extracted gradually with the strangler fig pattern.

Follow-up

• How would you split an existing monolith without a big-bang rewrite?
• How do you change a service API without breaking its consumers?
• How would you debug a slow request that crosses five services?

Describe how you would implement a caching strategy for a high-traffic website.

Medium · System Design / Architecture

Approach

1. Layer the caches: browser (Cache-Control, ETag), CDN for static assets and cacheable pages, an application cache such as Redis or Memcached, and the database's own buffer cache.
2. Pick a pattern: cache-aside (read, miss, load, populate) for most reads; write-through when reads must see fresh data; write-behind only when some loss is acceptable.
3. Handle invalidation: TTLs plus deleting the key after a successful database write, or versioned keys; explain the race where a stale read repopulates the cache.
4. Name the failure modes: stampede on a hot expired key (request coalescing, a lock, jittered TTLs, stale-while-revalidate), cache penetration (cache negative results), hot keys and cold starts.
5. Measure hit rate and latency, choose LRU or LFU eviction, and keep personalised responses out of shared CDN caches.

Follow-up

• How do you keep the cache and database consistent when a record is updated?
• What happens when a cache node fails?
• What would you deliberately not cache?

Explain how to ensure data consistency in a distributed system.

Medium · System Design / Architecture

Approach

1. Start by stating the consistency the feature needs: strong (linearisable), read-your-writes, or eventual. Use CAP and PACELC to explain the trade-off with availability and latency.
2. Inside one database, rely on ACID transactions, unique constraints and optimistic concurrency with version columns.
3. Across nodes or services: two-phase commit gives atomicity but blocks if the coordinator fails; sagas with compensating steps trade atomicity for availability.
4. For replicated data: leader-based replication, quorum reads and writes where R + W > N, and consensus protocols such as Raft for leader election.
5. Make delivery safe: at-least-once messaging plus idempotent consumers keyed by a request ID, and the outbox pattern so the database write and the event publish cannot diverge.

Follow-up

• What happens in two-phase commit if the coordinator crashes after prepare?
• How do you get effectively-once processing from a queue that delivers at least once?
• How would you enforce a budget cap that two services update concurrently?

Describe a situation where you had to make a decision with incomplete information.

Medium · Problem-Solving / Case Studies

Approach

1. Describe the decision, what was known, what was missing and why waiting was costly.
2. Show the reasoning: was the decision reversible, what was the worst case, and what information could be gathered within the time available.
3. Explain the call you made, the assumptions you wrote down and the checkpoint you set to revisit it.
4. Give the outcome, including whether the assumptions held and what changed when new information arrived.
5. The mistake that sinks it: a story where you waited until all the information arrived.

Follow-up

• What would have changed your decision?
• How did you communicate the uncertainty to others?
• Tell me about a time this went wrong.

How would you handle a project that is falling behind schedule?

Medium · Problem-Solving / Case Studies

Approach

1. Diagnose first: scope creep, bad estimates, blocked dependencies or unplanned work, using the task board and burn-down rather than guesswork.
2. Lay out the options: cut or phase scope to a smaller first release, re-sequence work to unblock others, add help (noting Brooks's law: late additions slow things down at first), or move the date.
3. Communicate early with the options and their costs, and let the stakeholder choose.
4. Prevent a repeat: smaller milestones, risk review at planning, buffers for known unknowns.
5. Anchor it in a real project and say what you personally changed.

Follow-up

• Which scope would you cut first, and how would you decide?
• How would you tell a client-facing stakeholder that the date is moving?
• How do you notice slippage before it becomes a crisis?

How would you approach debugging a production issue?

Medium · Problem-Solving / Case Studies

Approach

1. Triage first: scope and severity (which users, which endpoints, since when) and whether to declare an incident.
2. Mitigate before diagnosing: roll back the latest deploy, turn off a feature flag, scale out or fail over, so users stop being affected.
3. Gather evidence: error rates, latency and saturation metrics, logs and traces filtered to the failing requests, plus recent deploys, config and dependency changes.
4. Isolate the cause: reproduce in staging, bisect recent changes, compare failing and healthy requests, and verify your dashboards before trusting a symptom.
5. Fix and prevent: add a regression test, ship the fix, add or tune an alert, and write a blameless postmortem with follow-up actions.

Follow-up

• What do you do when a rollback is not possible because a migration already ran?
• How do you debug an issue that you cannot reproduce locally?
• How do you tell the cause apart from a coincidence in the timeline?

Suggested practice checklist

Each day targets one block of the reported questions. The plan starts with preparation for the recruiter screen and ends with stories for the final stage, with coding, fundamentals, design and distributed-systems blocks in between.

Day 1 — Prepare the recruiter screen

• Write a two-minute background walkthrough naming one backend and one user-facing project and the languages from the reported stack you used in each.
• Write and say aloud an answer to what motivates you to do your best work, backed by one concrete example.
• List the questions you will ask the recruiter: assessment format, allowed language, team and work arrangement.

Deliverable: A written walkthrough, a rehearsed motivation answer and a list of recruiter questions.

Day 2 — Core coding: lists, loops and binary search

• Write the iterative and recursive linked-list reversal in your interview language and trace both on empty, one-node and two-node lists.
• Write FizzBuzz with a configurable rule table and test 1, 3, 5, 15 and n = 0.
• Write binary search plus a lower-bound variant and test it on an empty array, duplicates and targets beyond either end.

Deliverable: Three tested solutions with complexity notes and an edge-case list for each.

Day 3 — Hash maps and sliding windows

• Solve two sum with a hash map, then with sorting and two pointers, and write down when each fits.
• Solve the longest substring without repeating characters with a sliding window and confirm the abba case.
• Solve each follow-up variant once: all unique pairs, and at most k distinct characters.

Deliverable: Five working solutions (two sum with a hash map, two sum with two pointers, the sliding-window substring, all unique pairs, at most k distinct characters) with complexity notes and passing edge-case tests.

Day 4 — Technical fundamentals out loud

• Write a one-page REST versus GraphQL comparison covering caching, N+1, errors and versioning, then explain it aloud.
• Sketch a small React app's state map (local, shared, server, URL) and explain the tool you would use for each.
• Explain the Node.js event loop and async/await error handling aloud, then build a small REST endpoint in Express.
• Prepare a polymorphism example in your language, a unit testing answer using one of your own functions with Arrange-Act-Assert tests, and an Agile answer with one real retrospective outcome.

Deliverable: Five rehearsed fundamentals answers, each with a personal example, plus a working Express endpoint and a spoken Node.js explanation.

Day 5 — System design: shortener, web app, caching

• Design the URL shortener end to end: requirements, base62 keys, schema, redirect code, cache and click analytics.
• Draw a scalable web application skeleton and name what breaks first at ten times the load.
• Write a caching plan for a high-traffic site covering layers, invalidation and stampede protection.

Deliverable: Three design diagrams with written trade-offs for each.

Day 6 — Distributed systems, debugging and databases

• Write a microservices considerations checklist: boundaries, communication, sagas, outbox, observability, and when to stay monolithic.
• Explain how you would keep a counter or budget consistent across two services, covering two-phase commit, sagas and idempotency.
• Rehearse the production debugging sequence aloud with one real incident you worked on.
• Work the two SQL practice questions on soft-deleted accounts and per-tenant caps to sharpen constraints and concurrency.

Deliverable: A microservices checklist, a consistency explanation, a debugging story and two SQL solutions.

Day 7 — Behavioral stories for the final stage

• Map six to eight STAR stories to the reported behavioral and case prompts so no story is used more than twice.
• Rehearse each story aloud with the situation in two sentences and a measured result.
• Write your code review process as author and reviewer, with one example of a bug a review caught.

Deliverable: A story-to-prompt map and eight rehearsed answers.

Behavioural preparation

Candidates report that the final stage assesses cultural alignment as well as technical skill, across several team members. For this role, that means stories showing how you deliver under competing deadlines, settle disagreements, take feedback and work with product managers, designers and data analysts.

Describe a challenging project you worked on and how you overcame obstacles.

Medium · Behavioral / Leadership

Approach

1. Choose a project where the obstacle was technical or organisational and you personally removed it: a failing migration, a performance problem, an unclear requirement.
2. Use STAR, keeping the situation to two sentences and spending most of the answer on the actions you took and the alternatives you rejected.
3. Quantify the result: latency, error rate, delivery date, user or team impact.
4. End with what you would change next time.
5. The mistake that sinks it: a team story where your own contribution never becomes clear.

Follow-up

• What would you do differently if you started that project again?
• How did you know your fix caused the improvement?
• Who disagreed with your approach, and how did you handle it?

How do you prioritize tasks when managing multiple deadlines?

Medium · Behavioral / Leadership

Approach

1. Describe a real week with competing deadlines, not a general philosophy.
2. Show the method: rank by impact and by how firm each deadline is, find dependencies that block others, and identify work that can be cut or deferred.
3. Show communication: tell stakeholders early which item will slip and offer options (reduced scope, a later date, extra help).
4. Give the outcome and what you changed in how you plan.
5. The mistake that sinks it: answering that you simply work longer hours.

Follow-up

• What did you decide not to do, and who did you tell?
• How do you handle two stakeholders who both say their item is the top priority?
• How do you keep urgent interruptions from swallowing important work?

Share an example of how you resolved a conflict within a team.

Medium · Behavioral / Leadership

Approach

1. Pick a disagreement about substance (a technical approach, an estimate, a review comment) rather than a personality clash.
2. Show that you understood the other side first and restate their position fairly.
3. Explain how it was settled with evidence: a prototype, a benchmark, data, or an agreed decision owner.
4. Give the outcome for the work and the working relationship afterwards.
5. The mistake that sinks it: a story in which the other person is simply wrong and you win.

Follow-up

• What would you have done if the evidence had gone against you?
• How did you work with that person afterwards?
• When do you escalate a conflict instead of resolving it yourself?

What motivates you to do your best work?

Medium · Behavioral / Leadership

Approach

1. Name one or two concrete motivators and back each with an example from your work, such as shipping a feature people used the next day or fixing a slow tool a teammate relied on.
2. Connect them to this role as candidates describe it: building software used by marketing teams and working with product managers, designers and data analysts.
3. Show how the motivator shows up in your behaviour, such as following a feature after launch to see whether it was used.
4. The mistake that sinks it: generic lines like loving challenges, or an answer about compensation only.

Follow-up

• Tell me about a time your motivation dropped. What did you do?
• What kind of work drains you?
• What would make you leave a role?

How do you handle constructive criticism?

Medium · Behavioral / Leadership

Approach

1. Quote a specific piece of criticism you received, such as review comments that your pull requests were too large or feedback on how you communicated a delay.
2. Describe your first reaction honestly, then what you did to understand and test the feedback.
3. Show the concrete change and evidence it stuck: smaller pull requests, faster reviews, fewer follow-up questions.
4. The mistake that sinks it: a disguised strength such as working too hard, or feedback you never acted on.

Follow-up

• Tell me about feedback you disagreed with.
• How do you give critical feedback to a peer?
• What feedback have you received most often?

Discuss a time when you had to learn a new technology quickly.

Medium · Problem-Solving / Case Studies

Approach

1. Set up the constraint: what you had to learn, why, and the deadline.
2. Describe the method: official docs and a tutorial for the core model, a small throwaway spike, reading existing code that used it, pairing with someone experienced.
3. Show what you delivered with it and the measurable result.
4. Mention a mistake you made while learning and how you caught it.
5. The mistake that sinks it: claiming you mastered it overnight with no sign of how.

Follow-up

• What would you learn first if you had to pick up a new framework next week?
• How did you know your work with it was correct?
• What did you get wrong at first?

Explain your process for conducting a code review.

Medium · Problem-Solving / Case Studies

Approach

1. As author: keep pull requests small, write a description of what and why, link the ticket, self-review the diff and make sure tests pass first.
2. As reviewer: understand the intent, then check correctness and edge cases, tests, readability and naming, security (input validation, secrets) and performance (N+1 queries, unbounded loops).
3. Leave formatting and style to linters and formatters so the review focuses on substance.
4. Write comments as questions or clear suggestions, label minor ones as non-blocking, and respond within a predictable turnaround.
5. Give an example where a review caught a real bug or where you changed your own code after review.

Follow-up

• What do you do when an author disagrees with a blocking comment?
• How do you review a 2,000-line pull request?
• What would you never approve, even under deadline pressure?