Interview guides · 360Learning

360Learning Software Engineer Interview Guide

360Learning Software Engineer interview prep: HackerRank test, Discovery Meeting debrief, culture-deck rounds and worked answers to reported questions.

The 60-second brief

360Learning builds a SaaS platform that companies use to onboard, train and upskill their employees through collaborative learning. The engineering work candidates describe covers interactive learning features, complex learning pathways, real-time collaborative editing of course content, and integrations with other systems. The requirements candidates report for this role centre on web development (JavaScript/TypeScript, Node.js, Python, Ruby on Rails, or Vue or React on the frontend), REST or GraphQL APIs, relational databases such as PostgreSQL or NoSQL stores, and automated testing at unit, integration and end-to-end level. Candidates also report a transparent, decentralized company model with asynchronous, written-first communication, and the responsibilities they list include writing RFC-style technical design documents that peers review asynchronously.

This guide is for software engineers preparing for the 360Learning loop as candidates report it: a recruiter screen, a technical assessment, deep-dive interviews and a culture-fit interview. It covers the four reported algorithm questions (prefix sums, graph cycles and topological order, an O(1) randomized set, interval merging), the four reported design and feature-building questions (a collaborative course editor, a notification system, a learning progress tracker, a slow analytics endpoint), the reported behavioral and culture questions, and a seven-day plan that ties each day to those questions and to the web stack candidates list for the role.

Candidates report four rounds over roughly three to five weeks, with some describing a faster finish: a recruiter screen, a technical assessment, deep-dive interviews covering coding, design and behavioral topics, and a culture-fit interview built around the company's culture deck.

Focus areas

Algorithms & Data Structures
Feature Building Exercise
Technical Choice Debrief

Overview

The reported design questions are the ones to rehearse closely: several people editing one course at once, notifications across email, push and in-app channels, progress through nested modules with prerequisites, and analytics aggregated over thousands of learners in one enterprise. Practise these four with a relational schema in front of you, because the requirements and responsibilities candidates describe name PostgreSQL, REST or GraphQL APIs and background workers, and the live feature-building exercise candidates report asks for a schema and an endpoint for a new feature.

The coding side is classic algorithm work under a clock. Candidates report a HackerRank test of four algorithmic problems of rising difficulty in 90 minutes, with example themes such as lookups in nested hierarchical data, multi-step array manipulation and string pattern parsing. The reported questions map onto standard patterns: prefix sums with a hash map, Kahn's algorithm or three-colour DFS, an array plus index map, and sort-then-sweep. Speed on those patterns matters more than knowing exotic ones, and so does leaving readable code with comments, because candidates report a later live session that walks back through the code you submitted.

The rest of the loop is about how you work. Candidates report a culture deck of more than 80 slides describing 13 core principles and an asynchronous communication model, to be read before the final stages, and culture questions about unblocking yourself without meetings: ambiguous requirements without a product manager, a blocking team in another timezone, feedback you disagreed with. Prepare stories where a written document, not a meeting, moved the work forward, and read the deck closely enough to cite specific principles accurately.

The 360Learning interview process

These four stages are what candidates report for the Software Engineer loop. Candidate descriptions also use session names such as the HackerRank test, the Discovery Meeting and the Clarification and Culture-Fit meetings, without tying each one to a numbered round.

Recruiter Screen

Candidates describe the Recruiter Screen as a short conversation about your background and your general fit with the company. Treat it as the moment to confirm the logistics of what follows: which platform and languages the technical test allows, whether the culture deck will be sent to you, and how the later meetings are organised. Because candidates report being asked to read the culture deck before the later rounds, ask for it here if it has not arrived, so the reading does not compete with algorithm practice later in the week.

What to demonstrate

Your background and how it lines up with the role
Your high-level fit with the company, as candidates describe the screen

How to prepare

Write a two-minute account of your background that names the stack you have shipped in (for example TypeScript/Node.js, Python, Rails, Vue or React, PostgreSQL) and one feature you owned from design to monitoring.
Keep a ready answer on why asynchronous, written-first work suits you, citing a design doc or RFC you wrote and what it unblocked; it also serves the culture-fit interview.
List the logistics questions to ask: test platform and allowed languages, number of later meetings, and when the culture deck arrives.

Technical Assessment

Candidates summarise this stage as an evaluation of coding and design skills, and describe the first technical screen as a timed HackerRank test: four algorithmic and data-structure problems of increasing difficulty in 90 minutes. Reported example themes are an optimized lookup over nested hierarchical data, a multi-step array puzzle where a naive solution times out, and efficient parsing and validation of string patterns. Candidates advise getting a working version of every problem before polishing any one of them, and explaining reasoning in code comments. Plan your clock before you start: read all four problems, bank the easier ones, and write complexity notes as comments, since candidates report a later session that reviews this code with you. The only concrete format candidates describe here is the coding test, so most design preparation sits in the deep-dive stage below, with one design item added here.

What to demonstrate

Correct, working code on each problem within the time limit
Choice of data structure and the time and space complexity of each solution
Handling of empty input, extreme values and boundary cases

How to prepare

Run at least two full mock sets of four problems in 90 minutes on a HackerRank-style editor, in the language you will use, and right after the real test write down each solution, its complexity and what you would improve.
Drill the patterns behind the reported coding questions until each is a few minutes of typing: prefix sum with a hash map, topological sort with cycle detection, sort-and-sweep intervals, array plus index map.
Practise tree and nested-structure lookups (recursive and iterative traversal, flattening into a map) and string validation with a stack or a single pass, matching the reported example themes.
Because the stage is also summarised as covering system design, rehearse the notification system question aloud once, with its schema, deduplication and failure handling, then do the remaining design work under the deep-dive stage.

Deep-Dive Interviews

Candidates describe this stage as a series of interviews covering coding, system design and behavioral skills. Separately, candidates describe a live technical session called the Discovery Meeting, held with senior engineers, in two parts: a debrief of your HackerRank code, where you explain your choices and how you would improve them, then a live feature-building exercise. Candidates do not say which numbered round holds it, so prepare for it alongside the technical interviews. Reported examples include adapting one of your test solutions to streaming input rather than a static array, and designing the schema and endpoint for comments pinned to timestamps in a video lesson. Candidates say the session is about collaboration, structured thinking and taking feedback in real time, and advise treating challenges to your code as a discussion between peers. Start every feature with entities and a minimal endpoint, then extend.

What to demonstrate

Coding, system design and behavioral skills, the three areas candidates say this stage covers
Topics candidates list for the live technical sessions: refactoring your own code, API and relational schema design for a product feature, and the trade-off between a quick first version and long-term maintainability
Structured reasoning on the reported design questions and on behavioral stories

How to prepare

For each of your test solutions, prepare the streaming version: what state you keep, what you can no longer do, and the new complexity.
Design the timestamped video comments feature end to end: tables, indexes, REST or GraphQL shape, pagination, and what you would leave out of the first version.
Rehearse the reported design questions (collaborative course editor, notification system, progress tracker, slow analytics endpoint) on a whiteboard with a PostgreSQL schema.
Prepare STAR stories for the disagreement, tight-deadline and production-outage questions.

Culture-Fit Interview

Candidates describe the Culture-Fit Interview as a dedicated interview on how you fit the company's culture and way of working. They report receiving a long presentation (more than 80 slides) on the company's 13 core principles and its asynchronous communication model ahead of the final stages, which they call the Clarification and Culture-Fit meetings, and report that interviewers refer to those principles directly. Reported topics include working in a decentralized organisation where information is transparent and decisions are distributed (candidates mention the Convex Framework), communicating progress and unblocking yourself without meetings, and receiving direct, transparent feedback. Reported scenarios include being blocked by another team's API whose engineers are in another timezone and not replying, and feedback you disagreed with.

What to demonstrate

Working knowledge of the culture deck's principles and how they apply to day-to-day engineering
How you communicate progress and unblock yourself asynchronously and in writing
How you receive direct, transparent feedback

How to prepare

Read the full deck and write a one-line summary per principle, then attach a real story from your work to at least four of them.
Write out your answer to the blocked-by-another-team scenario as the sequence of written steps you would take, including a workaround that keeps you moving.
Prepare one story about feedback you disagreed with: what you said back, what you changed, and what you kept.

Where candidates lose points

Spending most of the 90-minute HackerRank test perfecting the first problem and leaving the later ones blank.

Read all four problems first and order them by how quickly you can reach a correct solution. Submit a working brute force for each, with a comment stating its complexity and the faster idea, then go back and optimise. Practise this exact pacing in two full mock sets before the real test.

Arriving at the debrief unable to explain your own test code or adapt it to new constraints such as streaming input.

Right after the test, write down each solution, its complexity and two improvements. For each one, work out the streaming variant in advance: what state you keep, what is no longer possible, and the new complexity.

Opening the feature-building exercise by listing endpoints, or by designing for every future requirement, before agreeing on the data model.

Start with entities and relationships (for timestamped video comments: lesson, comment, timestamp, author, parent comment), then the one endpoint the first version needs, its pagination and indexes. Say out loud which parts are first-version scope and which you would add later.

Answering culture questions from a skim of the deck, with a vaguely named principle and a generic story.

Read the whole deck, write a one-line summary per principle, and attach a real story to at least four of them. Quote the principle accurately and spend the answer on the decision you made and its outcome.

Answering asynchronous-work scenarios, such as being blocked by another team in another timezone, with "I would set up a meeting".

Give a written-first sequence: check the other team's docs and code, write a clear issue with a reproduction and the decision you need, work around the block with a mock or a contract you can code against, and say when and through which written channel you would escalate.

Questions & practice

Given an array of integers, write an optimized algorithm to find the longest contiguous subarray with a sum eq

Medium · Algorithms & Data Structures

Given an array of integers, write an optimized algorithm to find the longest contiguous subarray with a sum equal to a target value.

Approach

Ask whether values can be negative. If they can, a sliding window fails, because shrinking the window can raise the sum; use prefix sums with a hash map instead.
Keep a running prefix sum and a map from prefix value to the FIRST index where it appeared, seeded with {0: -1}. At index i, if prefix - target is in the map, the subarray (map[prefix - target] + 1 .. i) sums to target; update the best length.
Insert the current prefix only if it is not already present: keeping the earliest index is what makes the subarray longest. O(n) time and O(n) space, against O(n^2) for the double loop over start and end.
Edge cases: empty array or no match (state what you return, such as 0 or -1), target 0, the whole array matching (handled by the {0: -1} seed), and overflow on long inputs in fixed-width languages.

Follow-up

If all values are positive, can you do it in O(1) extra space? (Two-pointer sliding window.)
How would you count all subarrays that sum to the target instead of finding the longest?
How does this change if numbers arrive as a stream and you must report the longest match so far?

Implement an efficient algorithm to detect cycles in a directed graph and output the topological sort if no cy

Medium · Algorithms & Data Structures

Implement an efficient algorithm to detect cycles in a directed graph and output the topological sort if no cycle exists.

Approach

Model the graph as an adjacency list and clarify whether nodes are 0..n-1 or arbitrary keys, and whether duplicate edges or self-loops can appear (a self-loop is a cycle).
Kahn's algorithm: compute in-degrees, push every zero in-degree node to a queue, pop, append to the output and decrement neighbours, pushing those that reach zero. If the output has fewer nodes than the graph, a cycle exists. O(V + E) time and space.
Alternative: DFS with three colours (unvisited, in progress, done). Reaching an in-progress node is a back edge and means a cycle; the reverse of the post-order gives a topological order. Say that deep graphs can overflow the recursion stack, so an iterative version is safer.
Include nodes with no edges and disconnected components: start Kahn's queue with all zero in-degree nodes, or loop DFS over every unvisited node.

Follow-up

How would you return the actual cycle rather than just reporting that one exists?
How would you produce the lexicographically smallest valid order? (Min-heap instead of a queue, O(V log V + E).)
Where would this run in a course with prerequisite modules, and when would you validate it: on every edit or on publish?

Given a list of intervals, merge all overlapping intervals and return the sorted output.

Medium · Algorithms & Data Structures

Approach

Sort intervals by start, O(n log n). Walk them once: if the next start is at or before the current merged end, extend the end to max(current end, next end); otherwise close the current interval and start a new one.
Use max on the end, not the next end, so an interval fully contained in another does not shrink the merge.
Clarify whether touching intervals such as [1,2] and [2,3] should merge; with closed intervals they do, with half-open ones they do not. Write the comparison to match.
Handle empty input, a single interval and unsorted or reversed input. Sorting in place saves memory but mutates the caller's list; mention the choice. Total O(n log n) time, O(n) for the output.

Follow-up

Insert one new interval into an already sorted, non-overlapping list in O(n) without re-sorting.
How would you keep merged intervals current as intervals arrive one at a time? (A sorted map or balanced tree keyed by start.)
Given meeting intervals, how many rooms are needed at most? (Sort starts and ends, or use a min-heap of end times.)

How do you structure your daily work and ensure alignment with your team when working in a highly asynchronous

Medium · Behavioral & Collaboration

How do you structure your daily work and ensure alignment with your team when working in a highly asynchronous, documentation-first environment?

Approach

Although filed under coding, this is a working-style question. Answer with a concrete routine, not principles: what you write at the start and end of each day, where, and for whom.
Give the mechanics: a short written update (done, next, blocked) in a shared channel; a design doc or RFC before non-trivial work, with a deadline for comments; decisions recorded where the next person will find them; pull request descriptions that stand on their own.
Explain how you use the hours that do overlap with teammates in other timezones, and what you never let block you (you keep a second task ready).
Close with one real example where a written document replaced a meeting and what it saved.

Follow-up

When do you decide a call is better than another comment thread?
How do you notice you have been blocked for too long?
What does a good asynchronous update look like? Write one out.

Why does an asynchronous, documented-first working style appeal to you, and what challenges do you anticipate

Medium · Culture & Principles

Why does an asynchronous, documented-first working style appeal to you, and what challenges do you anticipate when transitioning to this model?

Approach

Although filed under coding, this asks for honest self-assessment. Give specific reasons the model suits you: uninterrupted focus time, decisions that are searchable later, and fair participation across timezones.
Name real challenges rather than claiming none: slower feedback loops, the temptation to over-document, tone that reads harsher in text, and feeling isolated.
Pair each challenge with a mitigation you have used or will use: time-boxed waits before escalating, short structured updates, a habit of asking clarifying questions in writing.
Use evidence from your past work (an RFC, a long-running remote collaboration) instead of describing what you imagine async work is like.

Follow-up

What is the longest you would wait on a written question before changing approach?
Give an example of something you wrote that changed a technical decision.
What would make you less effective in this model, and how would you notice?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

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

Approach

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

Follow-up

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

Design a data structure that supports insert, delete, and getRandom operations in O(1) time complexity.

Medium · Algorithms & Data Structures

Approach

Combine a dynamic array of values with a hash map from value to its index in the array. Insert: reject if present, append, record the index.
Delete: look up the index, move the last element into that slot, update the moved element's index in the map, pop the last slot and remove the deleted key. Swapping with the last element is what keeps removal O(1).
getRandom: pick a uniform random index into the array. All three operations are O(1) average because hash lookups are O(1) on average; O(n) space.
Edge cases: deleting the element that is already last (update the map before removing the key, or the stale write puts it back), getRandom on an empty structure, and deleting a value that is absent.

Follow-up

How would you support duplicates? (Map each value to a set of indices.)
Make getRandom weighted per item while keeping updates cheap? (Fenwick or segment tree over weights: O(log n) update and sampling; prefix-sum array or alias table only for read-only data, since rebuilds cost O(n).)
What changes if several threads call these operations at once?

How would you design the backend architecture for a real-time collaborative document editor where multiple use

Medium · System Design & Feature Building

How would you design the backend architecture for a real-time collaborative document editor where multiple users can edit a learning course simultaneously?

Approach

Scope it: who edits (course authors in one company), what is edited (rich text inside lessons, module order), how many concurrent editors per course, and whether offline editing is needed. Splitting a course into documents per lesson or block reduces contention.
Pick a conflict strategy and justify it: operational transformation with a central server ordering operations per document, or CRDTs (for example Yjs or Automerge) that merge without a central order and support offline edits at the cost of metadata overhead.
Real-time path: clients hold a WebSocket to a collaboration service; all editors of a document go to the same node (route by document id) or nodes fan out through a pub/sub channel. Presence and cursors are ephemeral and never persisted.
Durability: append every accepted operation to a log with a per-document version number, snapshot periodically to PostgreSQL, and on reconnect have the client send its last acknowledged version so the server replays only what it missed.
Cover permissions per course, version history and restore, and what happens when a collaboration node dies: clients reconnect elsewhere and resync from snapshot plus log.

Follow-up

How do you implement undo for one user without undoing other people's edits?
How do you compact the operation log so loading a long-lived course stays fast?
What happens if two authors reorder the same module list at the same time?

Design a scalable notification system that supports email, push notifications, and in-app alerts, ensuring ded

Medium · System Design & Feature Building

Design a scalable notification system that supports email, push notifications, and in-app alerts, ensuring deduplication and rate-limiting.

Approach

Separate producers from delivery: product services publish events (course assigned, comment reply) to a queue; a notification service applies user preferences, quiet hours and templates, then hands off to one worker pool per channel: email provider, push (APNs/FCM), and in-app.
In-app alerts are rows in a notifications table (user_id, type, payload, read_at, created_at) indexed on (user_id, created_at), plus a live push over WebSocket when the user is online.
Deduplication: build an idempotency key from event id, recipient and channel, and enforce it with a unique constraint or a set-if-absent cache entry with a TTL, so a retried event cannot send twice. Delivery is at-least-once with dedup, not exactly-once.
Rate limiting: a token bucket per user per channel, with low-priority events folded into a digest instead of dropped; transactional messages such as password resets bypass the digest.
Failure handling: retries with exponential backoff, a dead-letter queue, a delivery status table for support, and a circuit breaker when an email or push provider is down.

Follow-up

An admin assigns a course to 50,000 employees at once: how do you fan out without starving other notifications?
How do you guarantee a user never receives a notification for a channel they turned off after the event was queued?
How would you measure that notifications are actually being delivered?

How would you structure the database schema and API endpoints for a learning progress tracker that supports ne

Medium · System Design & Feature Building

How would you structure the database schema and API endpoints for a learning progress tracker that supports nested modules and prerequisite paths?

Approach

Core tables: courses; modules (id, course_id, parent_module_id nullable for nesting, position); module_prerequisites (module_id, requires_module_id) as edges of a directed graph; progress (user_id, module_id, status, score, completed_at) with primary key (user_id, module_id).
Nesting: an adjacency list read with a recursive CTE in PostgreSQL is simplest; a closure table or materialized path makes subtree reads cheaper at the cost of more expensive moves. State which you pick and why.
Validate prerequisites on write with cycle detection (topological sort) so a course can never become impossible to complete.
Endpoints: GET /courses/{id}/tree returns the module tree with the caller's progress; PUT /users/me/modules/{id}/progress is idempotent so retries are safe; GET /users/me/courses/{id}/available returns modules whose prerequisites are complete.
Roll-up: a parent is complete when all children are complete. Compute on read for small courses, or maintain per-user counters updated in the same transaction when reads dominate.

Follow-up

An author reorders or deletes modules while learners are halfway through: how do you version the course?
How would a manager see completion percentage for a team of 2,000 learners without slowing the tracker?
Would you expose this as REST or GraphQL, and what would change in the tree endpoint?

Explain how you would optimize a slow-performing API endpoint that fetches aggregate learning analytics for th

Medium · System Design & Feature Building

Explain how you would optimize a slow-performing API endpoint that fetches aggregate learning analytics for thousands of users across an enterprise.

Approach

Measure first: p50/p95 latency, the queries the endpoint issues, and EXPLAIN ANALYZE on the slowest. ORM-driven N+1 queries (one query per user) are the most common cause on this shape of endpoint.
Collapse to one aggregate query over the progress tracker schema: SELECT m.course_id, COUNT(*) FILTER (WHERE p.status = 'completed'), AVG(p.score) FROM progress p JOIN modules m ON m.id = p.module_id JOIN courses c ON c.id = m.course_id WHERE c.tenant_id = $1 GROUP BY m.course_id, with indexes on courses(tenant_id), modules(course_id) and progress(module_id).
If the joins are still the cost, denormalize course_id and tenant_id onto progress and keep them correct by setting them in the same insert (a module never changes course) or with a trigger, so a composite index starting with tenant_id serves the query directly. Say which columns you added and why.
If it is still slow for the largest tenants, precompute: a summary table updated by a background worker on progress events, or a materialized view refreshed on a schedule (REFRESH ... CONCURRENTLY needs a unique index). Say what freshness the dashboard actually needs.
Add caching keyed by tenant and filter with explicit invalidation or a short TTL, paginate per-user detail with keyset pagination rather than OFFSET, move very large exports to an async job, and compare latency before and after, watching write cost from new indexes or triggers.

Follow-up

How fresh does this data need to be, and how would you show the reader when it was last computed?
One enterprise has a hundred times more learners than the median: what do you change?
How do you prove the summary table never drifts from the raw progress rows?

Share an experience where a production deployment caused an outage. How did you debug the issue, and what prev

Medium · Behavioral & Collaboration

Share an experience where a production deployment caused an outage. How did you debug the issue, and what preventative measures did you implement afterward?

Approach

Structure: detection, mitigation, diagnosis, fix, prevention. Start with how the outage was noticed (alert, error-rate graph, customer reports) and how long it lasted.
Show that mitigation came before root cause: I rolled back or turned off the feature flag first, then investigated with the pressure off.
Diagnosis as a sequence: what changed in the deploy (diff, migrations, config), logs and traces around the start time, reproduction in staging, and how you separated the trigger from the underlying cause.
Prevention you actually shipped: a regression test, a backwards-compatible migration pattern, canary or staged rollout, a new alert, plus a blameless written postmortem.
The story fails if it is a hero narrative with no lasting prevention, or if it blames a colleague.

Follow-up

Why did your tests not catch it?
What did you change in the deployment process afterwards, and did it hold up?
How would you have detected it sooner?

Suggested practice checklist

Each day targets one stage of the reported loop: the culture deck first because it needs the most lead time, then the HackerRank patterns, the debrief and feature exercise, the reported design questions, and the behavioral and culture questions.

Day 1 — Culture deck and recruiter screen

Read the culture deck if you have it (ask the recruiter for it otherwise) and write a one-line summary for each of the 13 principles.
Attach one real story from your work to each of four principles, and write the principle answer in five sentences.
Write your two-minute background naming your stack and one feature you owned end to end, and list the logistics questions for the recruiter.

Deliverable: A principles sheet with four mapped stories, a written answer to the principles question, a two-minute background and a recruiter question list.

Day 2 — Prefix sums and constant-time structures

Solve the longest subarray with target sum using prefix sums and a hash map, then the all-positive variant with two pointers, with a timer running.
Implement the insert/delete/getRandom structure and test deleting the last element and an absent value.
Write complexity and edge-case comments in both solutions as you would in the real test.

Deliverable: Two tested, commented solutions with their complexity stated, plus one variant of each.

Day 3 — Graphs, intervals and a full timed set

Implement cycle detection with topological order twice: Kahn's algorithm and three-colour DFS, including disconnected nodes.
Implement interval merging and the insert-one-interval variant, testing touching and contained intervals.
Run a full mock of four problems in 90 minutes, including one tree or nested-data lookup and one string-validation problem.

Deliverable: Two graph implementations, two interval solutions and a scored 90-minute mock with notes on where time went.

Day 4 — Debrief and feature building

Explain yesterday's mock solutions aloud as in a debrief, then write the streaming version of one of them.
Design timestamped comments on a video lesson: tables, indexes, endpoint, pagination and first-version scope.
Design the learning progress tracker schema and endpoints, including prerequisite validation and the roll-up rule.
Outline the test plan for the video comments feature: which unit tests, which integration tests against PostgreSQL, and the single end-to-end check.

Deliverable: A recorded debrief of the mock, a streaming variant, two schema-plus-API designs on one page each, and a test outline for the comments feature.

Day 5 — Reported system design questions

Whiteboard the collaborative course editor: conflict strategy, WebSocket routing, operation log, snapshots and reconnect.
Whiteboard the notification system with idempotency keys, per-user rate limits, digests and a dead-letter queue.
Work the slow analytics endpoint from EXPLAIN ANALYZE to a summary table, and practise replacing OFFSET paging with keyset paging.

Deliverable: Three design diagrams with their trade-offs written underneath, and a rewritten keyset-paged query.

Day 6 — Behavioral stories

Write STAR stories for the technical disagreement, the tight-deadline shortcuts and the production outage, each under 200 words.
For the outage story, make mitigation, diagnosis and the prevention you shipped explicit steps.
Say each story aloud, then answer two follow-ups per story from the question cards.

Deliverable: Three written STAR stories with follow-up answers, rehearsed aloud.

Day 7 — Asynchronous work and the culture-fit interview

Write your daily asynchronous routine and one example where a document replaced a meeting.
Answer the ambiguous-requirements question and the blocked-by-another-team scenario as written step sequences.
Write an honest answer on why async work appeals to you and its challenges, then rehearse the principles answer from day 1 again.

Deliverable: Written answers to four culture questions and the blocked-team scenario, plus a final pass on the principles sheet.

Behavioural preparation

Candidates report behavioral questions in the deep-dive stage and a dedicated culture-fit interview built on the company's culture deck. For this role, prepare stories that show ownership of a feature, decisions reached in writing, honest handling of debt and outages, and how you work when the people you depend on are not online.

Share an experience where a production deployment caused an outage. How did you debug the issue, and what preventative measures did you implement afterward?
Which of the company's 13 cultural principles resonates with you the most, and how have you demonstrated this principle in your previous role?
Give me an example of a time you received constructive feedback that you disagreed with. How did you respond, and what did you do next?

Tell me about a time you disagreed with a peer's technical proposal. How did you handle the disagreement, and

Medium · Behavioral & Collaboration

Tell me about a time you disagreed with a peer's technical proposal. How did you handle the disagreement, and how was the final decision made?

Approach

Choose a real technical disagreement with stakes, such as a schema choice, a library or an API contract, where you can explain both positions fairly.
Show the mechanics: I wrote down the options with their trade-offs, gathered evidence (a benchmark, a prototype, an incident history) and asked for written comments before deciding, which fits the written-first model candidates describe.
Be explicit about how the decision was made and who made it: the owner decided, the team agreed on criteria, or the evidence settled it. Then say what happened after.
The story fails if you were simply right and the peer simply wrong, or if you went straight to a manager. Include what you learned from the other position.

Follow-up

Tell me about a time you lost that kind of argument. What did you do afterwards?
If you disagreed in writing and got no replies for two days, what would you do?
Looking back, was the final decision correct?

Describe a situation where you had to ship a feature under a tight deadline. What shortcuts did you take, and

Medium · Behavioral & Collaboration

Describe a situation where you had to ship a feature under a tight deadline. What shortcuts did you take, and how did you manage technical debt?

Approach

Set the context briefly: the deadline, why it was fixed, and the scope you started with.
Name the shortcuts as deliberate choices: what you cut (an edge case behind a feature flag, a manual admin step instead of a UI) and what you refused to cut (tests on the money or data path, security checks).
Show how you managed the debt: written down in a ticket with an owner, flagged in the pull request description, and paid back within a stated window. Give the outcome.
This connects to the MVP-first approach candidates recommend for the test and the feature exercise. The story fails if the shortcuts were accidental or the debt was never revisited.

Follow-up

What did you refuse to cut, and why that one?
How did you get the cleanup prioritised against new feature work?
Did any shortcut cause a problem later?

Which of our 13 cultural principles resonates with you the most, and how have you demonstrated this principle

Medium · Culture & Principles

Which of our 13 cultural principles resonates with you the most, and how have you demonstrated this principle in your previous role?

Approach

Read the culture deck in full before answering; candidates report that interviewers refer to its principles directly, so name a principle accurately rather than paraphrasing it loosely.
Pick a principle you have actually practised, state it in one sentence, then give one specific story with a decision you made and an outcome.
Connect it to this role: tie it to written communication, ownership of a feature end to end, or transparent feedback, themes that recur in the responsibilities candidates list.
Avoid choosing the most popular-sounding principle without evidence, and avoid listing several principles shallowly instead of one in depth.

Follow-up

Which principle would you find hardest to live by, and why?
Describe a time you acted against this principle. What happened?
How would this principle change how you run a code review?

How do you handle a situation where a project's requirements are highly ambiguous, and you do not have immedia

Medium · Culture & Principles

How do you handle a situation where a project's requirements are highly ambiguous, and you do not have immediate access to a product manager for clarification?

Approach

Show a sequence, not a mood: collect what already exists (the ticket, support requests, usage data, previous specs), then write down your understanding and your assumptions explicitly.
Share a one-page written spec with the open questions and a date by which you will proceed on your assumptions unless someone objects.
Build the smallest reversible slice first, behind a feature flag if possible, so a wrong assumption costs little.
Close the loop: record what you decided and why, and update the spec when the product manager replies. The answer fails if it amounts to waiting, or to building the full feature on a guess.

Follow-up

One of your assumptions turned out wrong after you shipped. What did you do?
How do you decide which decisions are reversible enough to make alone?
Who else besides the product manager would you ask, and how?