What to expect
Prepare for your 100ms Software Engineer interview by building a small set of answers you can demonstrate: a tested coding solution, a query with a clear result, and a system design that explains what happens when something fails. This guide works through each of those skills, then turns them into a practical study plan.
Start with 100ms’s company resource for context on live video infrastructure. Choose a customer or operational workflow and ask what information must stay correct when records change or a dependency fails.
The exercises below are original interview practice, not reported 100ms questions. Confirm the assessment format and permitted tools with your recruiter, and use the Software Engineer question bank for additional practice.
Explore 8 guide-only practice questions →
Open the full-size preparation map
Editorial study map. It describes a preparation workflow, not 100ms's interview stages.
Connect your preparation to the role
For a practice discussion, consider a participant reconnecting without losing the current session state. Identify the authoritative record, the information a user sees, and the recovery path when those disagree. This is an original practice scenario inspired by the business context, not a description of the company’s systems.
Use three questions to make your answer concrete:
- What must remain correct? Define identity, ordering and valid state changes before choosing a data structure. The coding exercise below lets you practise rejecting conflicting updates while accepting an identical retry.
- What should the user or operator see? Distinguish zero activity from missing data. In the SQL exercise, check that an entity with no matching work still appears in the result.
- What happens after a partial failure? Separate a durable database change from an external notification. In the design exercise, explain how the caller discovers an operation that succeeded even if its response was lost.
Prepare one project story for each area. Describe your own decision, a rejected alternative and the evidence you used to judge the outcome. Match the depth of each story to the actual vacancy rather than assuming that every software engineering role tests the same topics.
Interview conversations to prepare for
The following conversations are a flexible preparation menu. Their order, duration, and number are not confirmed 100ms facts.
Recruiter or hiring-manager conversation
Prepare a short account of your background, one relevant project, and the kind of ownership you want next. Separate your contribution from your team's output: “I added the retry policy and reconciliation test” is more informative than “we made the platform reliable.” Ask what the technical assessment looks like, whether it is live or take-home, and whether documentation or AI tools are allowed.
Coding or practical technical discussion
Restate the problem, write down assumptions, work through a small example, and identify an ambiguity before coding. Explain complexity and test the edge cases aloud. If you run out of time, say what is correct and what remains unfinished. For take-home work, include a reproducible README, tests, assumptions, and limitations.
Architecture or project deep dive
Draw a system you actually understand. Start with users and the core workflow, then add components only when a requirement needs them. Explain data ownership, one failure scenario, and recovery. Be ready to compare two alternatives and say what would change at a different scale.
Collaboration and operational judgment
Prepare truthful examples of clarifying a vague request, handling disagreement, investigating a defect, and delivering a change safely. If you do not have a measured percentage, describe a verifiable qualitative outcome instead of inventing a number.
Guide-only practice question bank
Practice eight topics selected from Dataford’s 100ms Software Engineer guide. PracHub adds the problem clarifications, solution approaches and follow-up questions below. The third-party listing has not been independently verified as a record of questions asked by 100ms.
Trapping rainwater
Practice prompt: Given non-negative bar heights with unit width, calculate how much water remains trapped after rainfall.
Solution approach:
- For each position, water is the smaller of the highest bars to its left and right, minus its own height. Start with prefix and suffix maxima to obtain an O(n)-time, O(n)-space solution.
- To reduce extra space to O(1), use two pointers and running maxima. Process the side with the smaller running maximum: the opposite side already provides a boundary at least that high. Explain this invariant before moving a pointer.
- For [3, 0, 2, 0, 4], the total is 7. Check empty input, fewer than three bars, monotonic heights, equal heights and wide valleys.
Follow-up: How would your calculation change if bars had different widths?
Binary search in a sorted array
Practice prompt: Given a sorted integer array and a target, return a matching index or -1 if the target is absent. Any matching index is acceptable initially.
Solution approach:
- Maintain an inclusive interval [lo, hi]. Compare the middle value with the target and discard the half that cannot contain it. Stop when lo exceeds hi.
- Use mid = lo + (hi - lo) // 2; move to mid + 1 or mid - 1 after an unsuccessful comparison so the interval strictly shrinks. State O(log n) time and O(1) extra space.
- Trace an empty array, one element, an absent target below or above the range, and duplicate values. Then distinguish finding any match from finding the first match.
Follow-up: How would you return the first occurrence when the target appears multiple times?
First unique character index
Practice prompt: Return the index of the first character that occurs exactly once in a string, or -1 if every character repeats. Define a character as one element of the input string representation.
Solution approach:
- Count occurrences in one pass, then scan the original string in order and return the first index whose count is one. A map alone does not replace the second ordered scan.
- The running time is O(n); auxiliary storage is O(k), where k is the number of distinct characters. A fixed-size frequency array is appropriate only when the alphabet is constrained.
- For "swiss", return 1. Test an empty string, one character and all-repeated characters. Clarify case sensitivity and whether the API indexes bytes, code points or user-perceived characters.
Follow-up: How would you maintain the first unique character as new characters arrive in a stream?
Lowest common ancestor
Practice prompt: Find the lowest common ancestor of two distinct node objects in a binary tree. Initially assume both nodes are present; the tree is not necessarily a binary search tree.
Solution approach:
- Use a post-order recursive search. Return the current node when it matches either target; otherwise search both subtrees. If both sides return a node, the current node is the ancestor. If only one returns a node, propagate that result.
- Compare node identity rather than values, because values can repeat. Explain why the algorithm works when one target is an ancestor of the other.
- Visit each node at most once: O(n) time and O(h) recursion stack for tree height h. Test targets in separate branches, ancestor and descendant targets, and a skewed tree.
Follow-up: If either target may be missing, how would you verify that both were found before returning an ancestor?
What happens when you type a URL
Practice prompt: Walk through what happens after a user enters an HTTPS URL in a browser, from navigation to a usable page.
Solution approach:
- Start with URL parsing and possible cache or service-worker handling. Explain how the browser resolves the host if needed, accounting for cached DNS results and existing connections.
- Describe connection and security setup without claiming every request opens a new TCP connection. HTTP/1.1 and HTTP/2 commonly use TCP and TLS; HTTP/3 uses QUIC. Then explain the request, redirects and response.
- Trace HTML parsing, stylesheet and script loading, DOM and style construction, layout and painting. Distinguish receiving the initial HTML from the page becoming interactive.
Follow-up: If the page is slow, how would you separate DNS, connection, server-response and rendering time?
Interface vs abstract class
Practice prompt: When would you choose an interface rather than an abstract class? Explain your decision in a language you know.
Solution approach:
- State the language first, since inheritance rules and interface capabilities differ. Describe an interface as a contract for interchangeable behavior and an abstract class as a potential home for shared implementation or state.
- Use a concrete example: multiple notification providers can implement one sending contract, while closely related implementations might share a base class. Compare that with composition before choosing inheritance.
- Discuss substitutability, testing, coupling and API evolution. Avoid universal claims that interfaces can never include implementations; explain the rules of your chosen language.
Follow-up: How would you add a new capability without forcing every existing implementation to support it?
Designing a database schema
Practice prompt: Design a relational schema for an application with users, rooms and room memberships. A user may join multiple rooms; each membership has a role. This application scope is added for practice.
Solution approach:
- Identify users, rooms and memberships as separate entities. Use primary keys and foreign keys, and a unique constraint on (room_id, user_id) when the requirement permits only one logical membership per user per room.
- Keep connection attempts separate from logical membership if reconnects must be recorded. State deletion, membership-history and role-change requirements before choosing cascades or an audit model.
- Start indexes from actual queries: listing room members and finding rooms for a user need different access paths. Discuss atomic concurrent joins and transactions; do not rely on a read-before-insert check alone.
Follow-up: How would the schema change if a user could leave and rejoin while every membership period had to remain auditable?
Delivering under time pressure
Practice prompt: Tell me about a time you had to meet a tight deadline. How did you prioritize the work and handle the risks?
Solution approach:
- Use a real example. Establish the deadline, users affected, dependencies and the consequence of missing the date. State your own responsibilities rather than describing only the team.
- Explain how you separated essential scope from deferrable work, made tradeoffs with stakeholders and protected the checks needed for safe delivery. Describe what you deliberately did not attempt.
- Give a verifiable outcome and a lesson. If the deadline was missed, explain how early you communicated the risk, what you changed and how you recovered. Do not invent impact metrics.
Follow-up: What would you do differently if the deadline stayed fixed but your team lost a key contributor?
Worked coding exercise: keep the latest valid update
Editorial practice prompt: an internal service receives updates for several assets. Each event has an asset identifier, event identifier, integer version, and status. Events may be duplicated or arrive out of order. Return the latest event for each asset.
Assume event identifiers are globally unique and an identical redelivery may be ignored. Versions increase independently for each asset. A lower version cannot replace a newer one. Two different events for the same asset and version are a conflict, and reusing an event identifier with changed contents is invalid input. These are exercise assumptions, not 100ms requirements.
def latest_by_asset(events):
seen_ids = {}
seen_versions = {}
latest = {}
for event in events:
event_id = event["event_id"]
asset_id = event["asset_id"]
version = event["version"]
if event_id in seen_ids:
previous = seen_ids[event_id]
if previous != event:
raise ValueError("event ID reused with different content")
continue
key = (asset_id, version)
if key in seen_versions:
raise ValueError("conflicting events at the same version")
saved = event.copy()
seen_ids[event_id] = saved
seen_versions[key] = event_id
current = latest.get(asset_id)
if current is None or version > current["version"]:
latest[asset_id] = saved
return latest
For pump-7, versions 3, 1, 3 with the first event redelivered should leave version 3 as the result. A later version 4 should replace it. An update for fan-2 belongs to another sequence. The algorithm makes one pass with expected O(n) time and O(n + a) space, where n is the number of distinct events and a is the number of assets. It retains identifiers to detect conflicts, so it is not constant-memory processing.
Test empty input, an identical duplicate, reversed order, multiple assets, changed content under one identifier, two events at one version, and an older-version conflict after a newer version. The Python dictionary tutorial explains the mapping operations used here. Then discuss production limits: persistent deduplication after restart, atomic checks under concurrent consumers, retention of old identifiers, and how a replay avoids repeating side effects.
Worked SQL exercise: keep sites with zero overdue work
Editorial practice prompt: show every site and the number of work orders past their due time and not completed. Sites with no matching work must remain in the report.
Assume sites(id, name) and work_orders(id, site_id, due_at, status). A due time strictly before the database's current timestamp is overdue, and completed is excluded.
SELECT
s.id,
s.name,
COUNT(w.id) AS overdue_count
FROM sites AS s
LEFT JOIN work_orders AS w
ON w.site_id = s.id
AND w.due_at < CURRENT_TIMESTAMP
AND w.status <> 'completed'
GROUP BY s.id, s.name
ORDER BY overdue_count DESC, s.id;
Keep the work-order filters in the join condition. Moving them into WHERE can discard the null-extended row for a site with no qualifying work. COUNT(w.id) returns zero for that site; COUNT(*) would count the retained site row. Check one site with two overdue orders, one with only completed orders, and one with no orders. Ask which timezone defines due dates, whether cancelled work counts, and whether a visit join changes the row grain.
Read the PostgreSQL guide to table expressions and joins for the difference between filtering in ON and filtering in WHERE with an outer join.
For a performance discussion, inspect a query plan against representative data. Index choices depend on the database engine, table size, overdue fraction, and write volume. Do not present one index as universally correct.
System design walkthrough: a dependable operational workflow
Editorial design exercise: accept a report, create a work item, notify an authorised user, and show progress. This is a learning example, not a description of 100ms's infrastructure.
Open the full-size architecture diagram
Reference design for practice. It separates durable state from external delivery so failure cases can be explained.
Establish the smallest useful scope
Start with manual reports and a staff-facing status view. Ask who can submit, how priority is assigned, what “resolved” means, and which record is authoritative when a dashboard and an external tool disagree. If the real role involves device control or embedded software, establish that scope before borrowing this web-service model.
Define a state model
A possible exercise state machine is new → triaged → assigned → in_progress → resolved → closed. Define allowed transitions and who can make them. Preserve history when work is reopened. A version or conditional update can prevent a stale client from silently overwriting someone else's change.
Make retries safe
If a request commits and the connection drops before the response, a retry must not create a duplicate. Accept a client request identifier, scope it correctly, enforce uniqueness, and return the existing result for an identical retry. Reject reuse with a different payload. State how long the identifier is retained.
Separate durable state from delivery
Write the work item and an outbox event in one database transaction. A worker can deliver the event later and record attempts. If it crashes after delivery but before marking success, delivery may repeat; use a stable event identifier and an idempotent receiver where possible. Add bounded retry, a visible failure queue, and an operator recovery path.
The AWS transactional outbox guide explains this database-and-message consistency problem, including duplicate delivery and idempotent consumers.
Design the failure experience
Show whether a status is current, stale, or awaiting synchronisation. Preserve accepted work during an integration outage and expose delivery delay. If a client works offline, show unsent changes separately from confirmed server state and define a conflict policy for reconnecting.
Finish with tests and tradeoffs
Test duplicate submission, concurrent assignment, invalid transitions, a worker crash after delivery, prolonged dependency failure, and tenant or site isolation. A relational database and one worker can be a sensible starting point; more services need a requirement that justifies their failure and operational cost.
Debugging scenario: the dashboard says complete, the work is unfinished
Start with one affected item, its expected state, and the evidence behind the report. Establish whether the issue affects one record, one site, or all recent updates. Compare the dashboard's last refresh with the authoritative record and preserve the timeline before replaying messages or restarting services.
Trace the identifier through the client request, API, database, worker, and downstream system. Compare event versions and timestamps. Test hypotheses such as an older event overwriting a newer one, a status mapping error, or a dashboard treating “assigned” as “completed.” Communicate the affected scope and temporary workflow if people are making decisions from incorrect status.
End with correction and prevention. Reconcile affected records using the audit trail, then add a state-transition check, integration contract test, and monitoring for impossible combinations. Confirm the fix on representative records before widening it. This answer shows ownership without claiming that you know 100ms's internal tooling.
Make project and behavioral answers specific
Use situation, constraint, action, evidence, and lesson. Explain a vague request you clarified, a disagreement you resolved, a defect you investigated, or a delivery risk you communicated. Say what you personally decided and how you checked the result. A useful answer includes the tradeoff and what you would change next time.
Bring questions that expose the actual role: Which workflow causes users the most friction? How are integration failures detected? Who owns production support? How are changes tested with operational users? What would a useful first three months look like? The answers should change your follow-up preparation.
A two-week preparation plan with visible outcomes
Open the full-size practice budget
Suggested 20-hour budget for a candidate with existing fundamentals. It is not a measurement of 100ms's interview difficulty or topic distribution.
| Days | Focus | Deliverable |
|---|---|---|
| 1–2 | Role brief and coding contract | Confirm format; write the event specification and implementation. |
| 3–4 | Coding tests and SQL | Test duplicates and show zero-count sites correctly. |
| 5–6 | Workflow design | Draw ownership, state, retry, and reconciliation boundaries. |
| 7 | First mock | Explain one solution aloud and record the largest gap. |
| 8–9 | Debugging | Trace a stale-status incident and exercise recovery. |
| 10–11 | Project stories | Prepare two factual examples with decisions and evidence. |
| 12–13 | Timed revision | Repeat the weakest exercise under confirmed conditions. |
| 14 | Final review | Review assumptions, questions for the team, and recurring mistakes. |
Use a 0–3 practice rubric: 0 cannot explain the approach; 1 works only on the happy path; 2 handles important edge cases; 3 explains limitations and alternatives. This is an editorial self-review tool, not an employer scorecard.
Build a portfolio of interview examples
Make each skill in the job description concrete with a small example you can explain. For a language or framework, prepare a focused example that handles an error and has one test. For a database topic, write a query against a tiny fixture and explain the row grain. For an integration topic, draw the request, timeout, retry, and duplicate path. For a leadership topic, write down the decision, the person who disagreed, the evidence you used, and the result.
Use a three-column note while reading the job description:
| Requirement or theme | Evidence you can show | Assumption to verify |
|---|---|---|
| A named language or framework | A small implementation and test | Version, runtime, and code-review expectations |
| Data or reporting work | A query plus a clear data grain | Timezone, freshness, and ownership of the source |
| Integrations or APIs | A sequence diagram with timeout and retry paths | Which system is authoritative and how failures are recovered |
| Support or reliability | An incident timeline and prevention step | On-call, escalation, and change-control boundaries |
| Collaboration or leadership | A truthful project story with your decision | How the team measures a successful outcome |
This keeps preparation anchored to evidence. It also gives you a graceful answer when an interviewer asks about a tool you have not used: explain the adjacent system you do understand, state the gap, and describe how you would learn or validate the missing piece.
Review your answers at three levels
First review correctness. Does the code handle empty input, duplicates, invalid state, and boundary values? Does the SQL preserve the intended rows? Does the design name a source of truth? Correctness is the minimum, not the finish line.
Then review operability. What happens when the dependency is slow, unavailable, or returns a malformed response? How will someone know that work is stuck? Which identifier lets you trace one user action through logs and data? A short operational explanation often distinguishes a production-minded answer from a purely academic one.
Finally review communication. Did you make assumptions explicit before solving? Did you explain why you chose the approach and what you rejected? Could another engineer test your claim? Practise stopping after each major decision and inviting a follow-up. Interviewers can only evaluate reasoning that you make visible.
Run one mock with a deliberately changing requirement. Start with the basic event processor, then introduce a restart, a second consumer, or an offline client. Do not immediately add components. First identify which guarantee changed, then change the smallest boundary that provides it. This trains the habit of responding to constraints instead of reciting an architecture.
Practice questions and next steps
Use the Software Engineer question bank for role-level practice. Then vary the exercises: make the processor restart safely, add cancellation to the query, support offline updates, or explain recovery without duplicating work. Write the changed requirement before changing the solution.
Frequently asked questions
Is there a confirmed 100ms interview process?
This guide does not claim a verified interview sequence. Ask your recruiter which stages apply to the vacancy, whether the assessment is live or take-home, and which tools are permitted. Use the conversation types above as a preparation checklist.
Which programming language should I practise?
Use the language required by the assessment or the one in which you can write and test correct code clearly. Python is used for readability here, not because it is a verified 100ms requirement.
Should I study system design or algorithms first?
Let the confirmed format decide. For a coding screen, prioritise implementation and edge cases. For an experienced-hire architecture discussion, spend more time on data ownership, recovery, and tradeoffs. If the format is unknown, complete one exercise in each area before specialising.
What should I say when I do not know the answer?
State what you know, name the missing assumption, and propose how you would test it. An honest limitation followed by a next step is stronger than an unsupported claim about a tool or employer.
Sources and further reading
Company research
- 100ms: company information — explore live video infrastructure. Use this background to frame questions about the team’s users and responsibilities; confirm the required technologies and assessment format against the specific vacancy.
Practice question topics
- Dataford: 100ms Software Engineer guide — source of the eight selected practice topics above; PracHub supplies the solution approaches and follow-ups. The listing alone does not verify that 100ms asked each question.
Technical resources for the exercises
- Python tutorial: dictionaries — review key-based lookup, membership checks and updates before implementing the latest-event processor. Use a small input to trace how the lookup tables evolve.
- PostgreSQL: table expressions and joins — study outer joins, grouping and filters to understand why the reporting query must retain entities with no matching work.
- AWS: transactional outbox pattern — examine the failure between committing a database change and sending a message. Compare the pattern with the retry and duplicate-delivery cases in the design exercise.
These technical references support the practice material. They are not evidence of 100ms’s internal technology stack or interview questions.