Motive builds software for what the source notes call the physical economy: platforms used across logistics, construction and transportation, where businesses track assets, monitor driver safety and run supply chain operations. A Software Engineer there works on distributed systems, hardware-integrated software and data pipelines that handle high volumes of information in real time, across backend services, mobile interfaces and infrastructure.
The role as described includes building features that bridge hardware and software, turning requirements from product managers and designers into working systems, writing tested code, taking part in architecture and code reviews, debugging issues in high-scale environments and mentoring peers. The listed must-haves are proficiency in at least one object-oriented or functional language, a strong grasp of data structures and experience with distributed systems. IoT, logistics or supply chain software, AWS or GCP, and CI/CD pipelines are listed as nice-to-have.
For preparation, that mix comes down to three tracks. The first is algorithmic coding on grid, tree and string problems. The second is system design around device data and tracking. The third is a Topgrading interview that walks through your roles in chronological order. The reported questions, the losing points and the seven-day plan below follow those three tracks.
Initial Screening
reportedThe title covers product work, platform work, infrastructure, mobile and frontend, and those are different jobs with different loops behind them. A screening call is the cheapest place to find out which one the seat is, and asking reads as experienced rather than fussy. The questions that separate them: what the team is on call for, what the last three projects were, and whether any round happens inside an existing repository instead of a blank file. Then say which of that you have done and which you have not. Claiming the whole posting is the fastest way to be found out one round later.
What to demonstrate
- Whether you can locate your experience inside one flavour of the role honestly instead of claiming the entire requirements list
- Whether you name what you have not done, which an experienced screener reads as a level signal and can plan the loop around
- Whether what you want next matches what the seat is: someone who wants greenfield work landing on a team that mostly operates an existing system is a hire that leaves within the year
How to prepare
- Mark every line of the posting as done, adjacent or new, and write one sentence for each adjacent line naming the closest thing you actually built
- Split your last two years into rough percentages across feature work, operating and debugging live systems, and design or review, so a question about scope gets numbers rather than adjectives
- Bring three questions that discriminate between seats: what the team is paged for, how much of the work is changing existing code versus standing up something new, and what shipped in the last quarter
Online Assessments
reportedMost of the time lost in this format is not lost to thinking. It goes to a standard-library call you half-remember, an off-by-one in a loop bound, and a debugging loop that mutates code at random until something passes. When output is wrong, stop re-reading the whole function: take the smallest input that reproduces it and walk the state through by hand, printing intermediates if the environment allows. Guessing at a fix without a failing case you understand is how a five-minute bug becomes twenty, and the clock does not pause while you do it.
What to demonstrate
- Whether you reach the right structure without a detour, and can write it from memory rather than only recall that one exists
- Whether overflow is considered where the language has fixed-width integers, since a signed 32-bit value stops at 2,147,483,647 and then wraps in Java, is undefined behaviour in C++, and does not arise in Python, whose integers grow instead
- Whether recursion depth is treated as a constraint on large inputs, given that CPython's default limit is 1000 frames and a deep recursion can exhaust the stack in any language where an iterative version would not
- Whether a failing case is isolated and explained before any edit is made to the code
How to prepare
- From an empty file and with no references open, implement the pieces you lean on most: a heap push and pop, an iterative DFS with an explicit stack, and a binary search whose midpoint is written lo + (hi - lo) / 2, which avoids the overflow that (lo + hi) / 2 can hit in a fixed-width integer type
- Time yourself on the ten library calls you look up most, such as sorting with a custom comparator, splitting and joining strings, and finding the next key at or above a value in an ordered map, until the lookup is gone
- Take a solution you know is broken and, before touching it, write one sentence naming the input, the expected value and the actual value. Repeat until you do it without deciding to.
Technical Screens
reportedCandidates describe the technical screens as in-depth technical discussions of your knowledge and expertise, without saying more about what they contain, so prepare for both technical depth and live coding. As general preparation, be ready to explain the reasons behind past architectural choices, including the alternatives you rejected. If you have depth in a specific technology such as Go, Java or React, be prepared for detailed questions on it even if the role is full-stack. Be able to explain every item on your resume from first principles. When you code live, clarify inputs and edge cases before writing anything and explain your approach as you go. The source FAQ names unstructured communication and missed edge cases as common reasons candidates are turned down.
What to demonstrate
- Whether you can explain why you made a past architectural decision, including the alternatives you rejected
- Whether claimed depth in a language or framework holds up under follow-up questions
- Whether you clarify constraints and edge cases before coding and can state the complexity of what you wrote
How to prepare
- For each technology on your resume, write down two things you know about how it works underneath, such as how goroutines are scheduled or what triggers a React re-render, and cut anything you cannot defend
- Pick two past projects and write out the key decision in each, the options you weighed and why you chose the one you did
- As preparation, work the reported coding questions (a BST traversal and a Goat Latin-style string task) aloud, naming edge cases before the first line of code
System Design Sessions
reportedCandidates describe sessions meant to show your system design ability. The source's general notes on design list topics worth preparing: distributed systems and database choice (SQL versus NoSQL), API design and data transformation, and high-throughput data streams. The example scenarios are drawing an architecture for a logistics-related service and explaining how to handle failures or latency in a distributed environment. This guide's reported design questions make good practice for that material: a real-time fleet tracking or delivery service, and an ingestion API for thousands of connected devices. Open by fixing the scope and the write rate. Separate the ingestion path from the read path, and name the failure you are designing for before you draw the recovery.
What to demonstrate
- Whether database choice is argued from the read and write access patterns rather than stated as a preference
- Whether the ingestion path handles devices that retry, reconnect and send data late or out of order
- Whether failure and latency handling is built into the design rather than added only when asked
How to prepare
- Sketch a fleet tracking design end to end: device ingestion, a queue or log, a latest-position store, location history, and the query that serves a live map
- Write the same design's schema twice, once relational and once key-value or wide-column, and list which queries each makes cheap and which it makes expensive
- Practise explaining what happens when a downstream store slows down: where data buffers, what is dropped, and how the system catches up
Topgrading Interviews
reportedThe Topgrading interview is behavioural, and the source notes describe it as highly detailed. Be prepared to go through your projects and roles in chronological order, with the focus on your personal impact. Prepare to cover accomplishments, failures and motivations across your career, how you handled technical and interpersonal challenges, your long-term goals and why you want to join Motive. The usual risk is not one hard question but a vague or inconsistent account: a role where you cannot say what you owned, a job change you have not thought through, or a project described at a different scale than earlier in the loop. Prepare it as a timeline, not as a set of separate stories.
What to demonstrate
- Whether each role on your timeline has a clear account of what you personally owned and what changed because of it
- Whether failures are described with their cause and what you did differently afterwards
- Whether your reasons for each move, and your interest in the logistics and IoT space, are specific and consistent
How to prepare
- Write your career in chronological order, one block per role: what you were hired to do, your largest contribution, one failure or mistake, and why you moved on
- For each contribution, separate your own work from the team's and attach one concrete outcome you can back up
- Write an answer to why the logistics or IoT space interests you that connects a specific area, such as fleet safety or asset tracking, to work you have done
Final Decision
reportedNobody in the room with you decides this. Interviewers typically write their rounds up separately, often before seeing anyone else's, and the outcome is settled later from those write-ups. A split panel gets resolved by whichever note carries specific evidence, so what you want out of each room is one concrete thing that person could write down: a bug you caught yourself, a trade-off you named, a decision you owned. The rest is arithmetic. The project you describe in a behavioural conversation is often the same system you sketched an hour earlier, and the two accounts have to agree.
What to demonstrate
- Whether the scale, team size and timeline you attach to a project hold steady when that project resurfaces in a different round
- Whether each interviewer leaves with a specific thing to cite rather than a general impression of competence
- Whether a trade-off you defended in one round survives a challenge in another, instead of being quietly swapped for the answer the new interviewer seemed to want
- Whether a question you have already answered earlier in the day gets the same answer at the same depth, without visible impatience
How to prepare
- Write a one-page sheet per project fixing the figures you will quote — request volume, data size, team size, elapsed time, what broke — and say them aloud from the sheet until they come out identical every time
- For each round on the schedule, decide in advance the one sentence you want in that person's notes, then check in a mock that you said it outright instead of leaving it to be inferred
- Have someone ask you the same project question twice, an hour apart, and diff the two answers for numbers that moved or a trade-off that reversed
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
Motive Account Executive interview: sales manager, leadership, and onboarding
My process had three main rounds. I started with an internal recruiter, then had the important second round with a sales manager. That stage felt decisive for whether I advanced. The final round was with senior leadership and focused more on culture and fit than anything overly technical. The timeline was longer than I expected. I was told the entire hiring process could take around a month becau…
Read full experienceMotive Account Executive interview: manager discussion and a promised quick decision
After an initial screening call, I spoke with a sales development manager. The recruiter said I should hear a decision within about 24 hours. A third interview would follow if I advanced. The sequence felt clear and tightly organized: screen, manager, then potentially one more round. The speed and how much each step mattered made it feel difficult, even though the process was straightforward. I h…
Read full experiencePracHub editorial advice for the preparation topics above.
Miscounting neighbours on a Minesweeper-style grid
One reported coding question asks you to find mine locations or compute adjacent counts on a 2D grid. Points are usually lost to an out-of-bounds read at the edges, counting the cell itself, or updating the grid in place so later cells read counts instead of mines. Loop over the eight (dr, dc) offsets and bounds-check every neighbour. Write counts to a separate output grid. Before you call it done, test a 1x1 grid, a single row and a board that is all mines.
Treating the Topgrading interview as a highlights reel instead of a timeline
The source notes describe the Topgrading interview as highly detailed and chronological, with the focus on personal impact. If you jump between your best stories, you leave gaps the interviewer will fill with questions about the roles you skipped. Prepare every role in order, including short or unsuccessful ones. For each, cover what you owned, one measurable outcome and why you left. Say 'I' where the work was yours and 'the team' where it was not.
Designing device ingestion as if every message arrives exactly once and in order
Connected devices lose connectivity and resend, which matters for a fleet tracking design or an API that takes data from thousands of devices. Give each message a device ID plus a sequence number or event timestamp, and make the write idempotent on that key. Put a log or queue between the ingestion endpoint and storage so bursts do not hit the database directly. Store the latest position separately from the history so the live map does not read through the whole trail.
Answering a schema trade-off question by naming SQL or NoSQL first
A reported design question asks for the trade-offs between database schemas in a high-write, high-read environment. Naming a technology first invites a follow-up you cannot answer. Start by listing the writes (rate, shape, update or append) and the reads (by key, by time range, by region). Then pick the schema and partition key that make the most common query cheap, and say which query it makes expensive.
Starting to code before stating edge cases and constraints
The source FAQ names unstructured communication and missed edge cases in coding rounds as common reasons for rejection. On a BST traversal, a Goat Latin-style string task or a grid problem, restate the input first. List the empty, single-element and boundary cases and state your target complexity, then explain what you are doing as you write. When a follow-up constraint arrives, say what it breaks in your current solution before you change any code.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Given a 2D grid, identify mine locations or calculate adjacent counts …
Given a 2D grid, identify mine locations or calculate adjacent counts in a Minesweeper-style problem.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- What is the worst case, and how likely is it on real data?
- How does this change if the input no longer fits in memory?
Explain how you would handle syntax and edge cases in a live coding en…
Explain how you would handle syntax and edge cases in a live coding environment.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- State the target complexity and say which constraint rules the naive version out.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- Which test case would catch an off-by-one here?
- How does this change if the input no longer fits in memory?
Solve a classic string manipulation problem, such as "Goat Latin," wit…
Solve a classic string manipulation problem, such as "Goat Latin," with follow-up constraints.
Approach
- Name the brute-force solution and its complexity before improving on it.
- State the target complexity and say which constraint rules the naive version out.
- Choose the data structure from the access pattern, not from familiarity.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Implement a function to perform a traversal of a Binary Search Tree.
Implement a function to perform a traversal of a Binary Search Tree.
Approach
- Name the brute-force solution and its complexity before improving on it.
- Restate the input: its shape, its size, and what is guaranteed about it.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- What is the worst case, and how likely is it on real data?
- Which test case would catch an off-by-one here?
Identify the heaviest tenants in a five-minute window under memory pressure
The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.
Approach
- Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
- Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
- State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
- Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
- Choose and defend it: at 50,000 tenants the exact rings cost under 100 MB in a process that already holds more, so ship exact. Keep the sketch for the case that actually motivates it, a per-principal or per-IP key where cardinality runs to millions and is not bounded by anything you control.
- Raise the fleet problem before it is asked: each of 20 to 40 instances sees only its share, and the top 50 of one shard is not the top 50 of the fleet. Either aggregate counts centrally or accept that a per-instance threshold multiplied by instance count is the limit you are really enforcing.
Worked solution 25 min
- Size the exact structure: 300 one-second counters per tenant across 50,000 tenants, plus the running-total trick that makes a window read O(1).
- Write the top-k extraction with a size-50 min-heap and compare its complexity against sorting all 50,000 sums.
- Substitute N = 900,000 and m = 1,000 into N/(m+1) and state in requests what the sketch can and cannot distinguish.
- Write the sub-window merge for the sliding case and state the resulting bound for 30 merged summaries.
Follow-up
- The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
- Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?
- You switch to per-principal keys and cardinality goes to 10 million. Walk through what changes.
Explain why the owner filter ignores the listing index
The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.
Approach
- Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
- For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
- Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
- Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.
- Answer the two negatives explicitly. owner_user_id alone is not a left prefix of the new index, so it degrades to a full scan of the index at best. Ordered by updated_at, the query still seeks on the (tenant, owner) pair but must sort, because only created_at is ordered within that pair.
- Measure both sides with EXPLAIN (ANALYZE, BUFFERS) and compare estimated against actual rows at the lowest node — a 2M-versus-200 misestimate there is usually what chose the plan, and adding an index will not fix a statistics problem.
Worked solution 25 min
- Load 2M resource rows across 5k owners in one tenant, run the query under EXPLAIN (ANALYZE, BUFFERS), and record the node reading the most rows plus the Sort Method line.
- Create (tenant_id, owner_user_id, created_at DESC) concurrently and re-run, confirming the Sort node is gone and actual rows fall to about 20.
- Run the two negative cases and capture the plan for each.
- Re-run the original tenant listing query to confirm the new index has not displaced the index that query depends on.
Follow-up
- 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
- A dashboard runs this for 40 owners in one page load. What changes about the design?
- How do you roll this index out on a table taking 1.2k writes/second, and what does it cost on every insert from then on?
Keep soft-deleted accounts from blocking re-registration
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
- 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.
- 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.
- 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.
- 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.
- Say what a soft delete must do besides setting deleted_at: increment auth_version so existing tokens stop validating, leave resource.owner_user_id and resource_revision.actor_user_id intact, and accept that the address is retained — erasure is a different requirement answered by scrubbing the column, not by a DELETE that would break those references.
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?
- What changes if a user may hold membership in two tenants?
How would you structure an API to handle high-concurrency data ingesti…
How would you structure an API to handle high-concurrency data ingestion from thousands of connected devices?
Approach
- Name the failure you are designing for, then the recovery path.
- Choose a partition key and say what query it makes expensive.
- Name the read and write paths separately; they rarely have the same bottleneck.
Follow-up
- How does this behave when that dependency is down for an hour?
- What would you drop to keep the system up under load?
Design a system architecture for a real-time fleet tracking or deliver…
Design a system architecture for a real-time fleet tracking or delivery management service.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Name the failure you are designing for, then the recovery path.
Follow-up
- What would you drop to keep the system up under load?
- How does this behave when that dependency is down for an hour?
Rebuild the search projection while it serves nine thousand queries
The read-model service answers about 9k queries/second at a 120 ms p99 from a projection built off the event log, normally under 2 seconds behind. A mapping change forces a full rebuild from resource_revision, during which apply lag rises to minutes. Writes continue at 1.2k/second and events at 4k/second. Design the rebuild: how the new index is populated and cut over, how position is tracked per log partition, what the API returns alongside results so a client can tell a stale answer from a current one, and the criterion for cutting over.
Approach
- Build into a second index and swap an alias rather than mutating the live one. The rebuild is then reversible by pointing the alias back, so a bad mapping costs a wasted rebuild instead of an outage. The price is peak storage for two full copies and double apply load during catch-up, and both numbers should be stated up front rather than discovered when disk fills.
- Track position per log partition, not globally. Order is guaranteed only within an aggregate's partition, so progress is a vector, and the only number safe to publish is taken from the least advanced partition - the slowest one is what bounds completeness. Publishing the most advanced partition's position declares the projection current while another partition sits twenty minutes behind.
- Make apply idempotent so the backfill and the live tail can overlap without a freeze. Each document records the aggregate_version it reflects, and any event at or below that version is discarded. This is why the event carries the full fact and not a delta: a delta cannot be discarded safely, and a consumer that calls back to read current state applies a state newer than the event it is processing, which is how a projection ends up with changes applied out of order.
- Turn lag into a contract instead of a surprise. Return the watermark with every result set, and return the version produced by a write so the client can compare the two. A client that wrote version 7 and receives results at a watermark older than its own commit can show that its change is still landing, rather than rendering the previous value as current. Blocking the read until the projection catches up would convert a staleness problem into an availability problem at 9k queries/second, and choosing not to do that is the trade.
- Define the cutover numerically. Writes are untouched by the rebuild - they commit to the primary and land in the outbox - so the only coupling is apply throughput. If catch-up applies slower than the 4k events/second arriving, it never converges. The cutover criterion is that lag is measurably decreasing and below a stated threshold, not that the backfill loop reached the end of its range.
Worked solution 30 min
- Write the rebuild sequence: snapshot source, populate the second index, attach the live tail, verify, swap alias, retire the old index - naming what is reversible at each step.
- Define the per-partition position record and the single watermark derived from it, and show what each would report when one partition stalls.
- Write the idempotent apply rule using the document's recorded aggregate_version, and replay one event twice against it.
- State the cutover threshold in lag terms and the measurement that shows convergence rather than completion.
Follow-up
- The rebuilt index disagrees with the primary tables for 300 documents. Which is authoritative, and how do you decide without freezing writes?
- The rebuild doubles load on the log and pushes the projection p99 from 120 ms to 400 ms. What do you throttle, and which signal sets how much?
- Clients start polling until the watermark passes their write. What does that do at 9k queries/second, and what do you offer instead?
Exports duplicate a row range about once a week
Roughly once a week an export writes a file containing a duplicated range of rows. The affected job_run rows show attempt = 1, status = succeeded, one started_at, and a lease_owner naming a different host from the one whose logs show the job starting. Leases last 30 seconds and are heartbeated every 10 from inside the handler; lease_expires_at is computed on the worker and compared against the database's now(). Find the mechanism, and give a fix that holds even if you cannot fix the clocks.
Approach
- Start from the fact that eliminates the obvious answer. attempt = 1 means no retry was recorded, so this is not a re-run after failure; two workers ran the same row concurrently and the takeover path never touched the counter. lease_owner naming a host other than the one that started the job is the same statement from the other side.
- Enumerate the mechanisms that cause a premature takeover, then find the signal that separates them. Either the lease genuinely expired because the heartbeat did not fire, which is what happens when the heartbeat runs on the handler's own thread and the handler makes a long blocking call, or it only appeared expired because two clocks disagree, since lease_expires_at is written from the worker's clock and evaluated against the database's. The discriminator is the distribution: incidents clustered on the longest exports indict the heartbeat, incidents clustered on one host indict skew. Measure both, and measure each host's offset against the database directly.
- Read the reclaim query precisely. In PostgreSQL now() is transaction start time, not statement time, so a reclaimer holding a long transaction compares against an older timestamp than expected; clock_timestamp() is the statement-time function. This is worth ruling in or out before you redesign anything, because it changes which rows look expired.
- Remove the second clock rather than trying to synchronise it. Issue and extend the lease in the database, with lease_expires_at = now() + interval '30 seconds' in both the claim and the heartbeat, so exactly one clock is ever compared and worker skew stops mattering to this predicate.
- Accept that a lease can still expire under a slow worker, because a lease cannot distinguish slow from dead, and fence the work. Carry a monotonically increasing lease generation and make every write the handler performs conditional on still holding it, as UPDATE ... WHERE job_run_id = $1 AND lease_owner = $2 AND lease_generation = $3, so a displaced worker's writes affect zero rows and it aborts instead of duplicating.
- Make the handler's writes idempotent independently of all that: give each exported chunk a natural key of (job_run_id, batch_start) with a unique constraint so a second copy conflicts rather than appends, move the heartbeat off the handler's thread, and increment attempt on takeover so the event is visible in a metric.
Follow-up
- The displaced worker has already streamed half the file to object storage. What makes that side effect safe to repeat?
- You now count takeovers. What alert fires on that counter, and at what threshold?
- What breaks if you simply raise the lease to five minutes?
For someone fluent in a dynamic language who has shipped real work but has never had to say what the runtime is doing underneath. The week is built on measuring and deliberately breaking things, because the questions that expose this background are the ones where the interviewer asks why a second time.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Screening prep and product research
- Mark each line of the posting as done, adjacent or new, using the must-haves the source lists: proficiency in one language, data structures and distributed systems. Write one sentence for each adjacent line naming the closest thing you built.
- Read up on the areas the source notes mention (asset tracking, driver safety, supply chain operations) and write one sentence connecting each to your own work.
- Prepare three recruiter questions: which team the seat is on, whether the loop includes the Real World Challenge, and whether a prep document comes before each round.
Deliverable: A marked-up posting, a note linking your experience to Motive's product areas, and three recruiter questions.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Grid and tree coding (reported coding questions)
- Solve Minesweeper board generation by counting mines in the eight neighbours of each cell with bounds checks, then test a 1x1 board, a single row and an all-mine board.
- Implement in-order, pre-order and post-order BST traversal recursively, then in-order iteratively with an explicit stack, and explain why the iterative version matters on a deep, unbalanced tree.
- From an empty file with no references open, write the standard-library calls you rely on in your interview language: sorting with a comparator, string split and join, and a hash map with default values.
Deliverable: Working grid and traversal solutions with edge-case tests, and the complexity of each written above the code.
Practice prompt ↗Practice prompt ↗03Strings, hashing and connectivity
- Solve a Goat Latin-style string transformation, then add a follow-up constraint of your own, such as preserving punctuation or processing a long input in one pass, and adapt the solution without starting over.
- Group anagrams using a sorted-string key and then a character-count key, and state the cost of each key.
- Implement Union-Find with path compression and union by rank, and track the number of connected components as unions happen.
- Generate all valid parentheses sequences by backtracking, pruning any branch where closing brackets would outnumber opening ones.
- Work the heavy-hitters exercise (drill-coding-3) and compare your top-k heap step with the worked solution.
Deliverable: Four solutions, each with its complexity and one follow-up constraint handled, plus a note on where your top-k reasoning differed from the worked exercise.
Practice prompt ↗Practice prompt ↗04APIs, JSON and data modelling
- Write a small client that fetches JSON from a REST API, parses it into typed records, and handles a timeout, a non-200 response and a missing field.
- Model a ticket booking schema: tables, keys, and the constraint that prevents two bookings for one seat.
- Work the index exercise (drill-sql-1) and explain from the access path why the original index cannot serve the query.
- Specify an endpoint that accepts batched readings from devices: request shape, idempotency key, and the response on partial failure.
Deliverable: A JSON client with error handling, a booking schema with its uniqueness constraint, and a device ingestion endpoint spec.
Practice prompt ↗Practice prompt ↗Worked solution ↗05System design: fleet and delivery tracking
- Design a real-time fleet tracking or delivery management service end to end: ingestion, a log or queue, a latest-position store, location history, and the live-map query.
- Write the schema trade-off for a high-write, high-read store two ways and name the query each version makes expensive.
- Walk through a failure: the location store degrades for an extended period. Say where data buffers, what you drop and how the system recovers.
- Work the projection rebuild exercise (drill-design-4) and compare your handling of lag and cutover with the worked solution.
Deliverable: One fleet tracking diagram with separate write and read paths, a schema comparison, and a written failure plan.
Practice prompt ↗Practice prompt ↗06Topgrading and behavioural answers
- Write your career timeline in chronological order. For each role, note what you owned, one measurable outcome, one failure and why you moved on.
- Prepare answers to the reported prompts: a challenging technical problem from your most recent role, a technical conflict, learning a new technology under a tight deadline, and why the logistics or IoT space.
- Rehearse the argue-and-lose prompt (drill-behavioral-6) and check that you state your prediction as a mechanism someone could verify.
- Tell the timeline aloud to someone who keeps interrupting with 'what did you personally do', and note every point where you drifted into describing the team's work.
Deliverable: A one-page chronological timeline and four behavioural answers, each with an outcome you can back up.
Practice prompt ↗Practice prompt ↗07Debugging and a mock loop
- Work the duplicate-export debugging drill (drill-debugging-5) aloud, stating a hypothesis before each step and naming the measurement that would disprove it.
- Have someone plant two defects in the API client you wrote on day 4, then find both while explaining your reasoning out loud.
- Run a mock sequence of one coding problem, one design question and one Topgrading walkthrough, then check that the scale, team size and timelines you quoted matched across all three.
Deliverable: A hypothesis log from the debugging drill, a mock-loop recording, and a consistency sheet of the figures you will quote for each project.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The reported behavioural questions for this role centre on the Topgrading interview, which the source notes describe as a detailed, chronological walk through your roles focused on personal impact. Build each answer around what you personally did, what changed because of it and what you would do differently. Keep the facts identical every time the same project comes up.
Describe a situation where you had to learn a new technology or domain…
Describe a situation where you had to learn a new technology or domain under a tight deadline.
Approach
- Name the disagreement and how you resolved it with evidence.
- Close with what you would do differently, concretely.
- Pick a story where you made the decision, not one where you watched it.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Walk me through a challenging technical problem you solved in your mos…
Walk me through a challenging technical problem you solved in your most recent role.
Approach
- Close with what you would do differently, concretely.
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Argue against a design, lose, and commit anyway
Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.
Approach
- State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
- Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
- Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
- Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.
- Report the outcome without editing it. If the design held and your predicted mechanism never fired, say so and say what you had mis-weighted, which is more persuasive than a vindication story.
Follow-up
- What threshold on that alert would have proved you right, and did anyone ever look at it?
- If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?
- How did you behave toward the design once it shipped and started failing in a different way than you predicted?
- 01
Walk me through a challenging technical problem you solved in your most recent role.
- 02
How do you handle conflict or differing technical opinions within a team?
- 03
Why are you interested in the logistics/IoT space, and how do you see your skills adding value to Motive?
- 04
Describe a situation where you had to learn a new technology or domain under a tight deadline.
- 05
Discuss a recent project and its impact.
- 06
Walk through your roles in chronological order: what you owned in each, your biggest contribution and failure, and why you moved on.
Is this an official Motive interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Motive. Rounds and questions reflect what candidates have reported, not a process Motive has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How long does the Motive Software Engineer interview process take?
Candidates report six rounds over roughly four to six weeks, and the source notes allow for four to eight weeks depending on the role and scheduling. Ask your recruiter for the expected timeline after the initial screening.
PracHub interview research ↗What is the most common reason for rejection?
Besides technical gaps, the source notes point to two causes: problem-solving without structured communication, and missed edge cases in coding rounds. You can prevent both. State your approach before you code, list edge cases out loud, and test them before you say the solution is done.
PracHub interview research ↗Is the interview process remote?
The source notes describe the interview process as conducted virtually. Location requirements for the job itself can vary by team, so confirm them during the initial recruiter screen.
PracHub interview research ↗How should I prepare for the "Real World Challenge"?
Treat it like a real project: focus on clean code structure, API design and robust error handling. Have your local environment ready before it starts, and be prepared to explain your design choices clearly.
PracHub interview research ↗What is the Topgrading interview?
It is a behavioural interview about your past experience and growth potential. The source notes describe it as highly detailed: be prepared to discuss your projects and roles in chronological order with the focus on your personal impact, along with failures, motivations, long-term goals and why you want to join Motive. Prepare a role-by-role timeline rather than a handful of standalone stories.
PracHub Software Engineer practice ↗What kind of coding questions are reported for this role?
Reported coding questions include a Binary Search Tree traversal, a Goat Latin-style string problem with follow-up constraints, a Minesweeper-style grid problem, and optimising a brute-force data processing solution. Related bank topics include Union-Find, grouping anagrams, generating valid parentheses and parsing JSON from a REST API. The source also lists matrix traversal, array manipulation, Big O analysis and fluent use of your language's standard library as areas to review.
PracHub Software Engineer practice ↗Will I get material before each round?
The source notes say candidates often receive a prep document before each round. Read it closely and adjust your preparation to the topics it names for that stage.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Qualcomm Software Engineer Interview Guide
Concurrency exercises for Qualcomm candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Attentive Software Engineer Interview Guide
Debugging practice for Attentive software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Moloco Software Engineer Interview Guide
API design practice for Moloco software engineer prep: which changes existing clients survive, how an optional field differs from a removed one, and what a contract costs once it is public.
Whatnot Software Engineer Interview Guide
Debugging practice for Whatnot software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.