Runway Software Engineer Interview Guide 2026: Coding, Video ML Systems, and Product Engineering

A Runway software engineer interview in 2026 calls for more than familiarity with generative video. Prepare to explain how correct code becomes a reliable creative feature: a request starts work, a model produces output, and the application turns that output into an asset a creator can actually use.

This guide concerns the generative AI company at runway.com and runwayml.com. As of September 7, 2026, official openings distinguish API, product, and research engineering. Public candidate evidence is older and does not establish one current interview loop. The preparation below separates official facts, historical reports, and original exercises. Runway careers

Use Runway interview questions for company context. The verified collection currently contains Machine Learning Engineer material, so the practice table also includes clearly labeled software-engineering supplements.

Choose the engineering track before choosing your practice

Official role requirements: Runway’s Backend Engineer, API posting emphasizes TypeScript, asynchronous workflows, Postgres, task orchestration, billing, permissions, and asset management. It asks for at least three years of production API experience. Its published stack description separates the TypeScript API from a Python inference backend. These are responsibilities and technologies, not a promise about interview questions. Backend Engineer, API

Official product context: The Staff Product Engineer opening asks for at least five years of software-engineering experience and describes full-stack video-creation features. It names React and TypeScript, browser media processing, and node-based creative workflows. Preparation should therefore include state management, media interfaces, debugging, and delivery across frontend and backend boundaries. Staff Product Engineer

Official research context: The Research Engineer opening asks for at least four years of ML research or engineering experience. It spans multimodal models, data pipelines, training, evaluation, and production deployment. That is a different preparation target from implementing a product API, even when both roles work on the same user feature. Research Engineer

Preparation inference: API candidates should lead with contracts and failure recovery; product candidates with interaction quality and state correctness; research candidates with experiments and evaluation. All three should explain how their decisions affect the creator’s workflow. Ask the recruiter which team and scope the opening belongs to before treating every topic below as equally important.

What candidate reports actually establish

Historical candidate reports: A Software Engineer account posted October 6, 2022 describes a September 2022 interview that included reviewing a sample pull request. A separate June 3, 2022 report describes an initial conversation followed by technical and conversational interviews, with questions about previous challenges and project interests. The second report does not state its exact interview month. Runway NYC Software Engineer reports

These reports support practicing code review and project explanation, but they are historical. Two independent accounts establishing the same 2026 SWE cycle were not verified. Do not turn the old candidates’ turnaround times into a current recruiting estimate.

Also check the employer identity before using a search result. Reports about the financial-planning company called Runway, Rent the Runway, or a creative assignment for a support role do not establish this engineering process.

For an upcoming interview, confirm the permitted language, whether you will implement or review code, how design is assessed, and whether a portfolio discussion is included. Prepare for the invitation you received rather than an assumed number of rounds.

Coding exercise: calculate selected video duration correctly

Original practice exercise, not a reported Runway question: A video editor lets a user select multiple ranges for export. Return their merged coverage and total duration without counting overlapping time twice. Use integer time units for the exercise and define each range as half-open: its start is included, its end is excluded.

Suppose the selections are [0,4), [3,7), [7,9), and [12,15). The contract allows touching ranges to coalesce. The answer is [0,9) and [12,15), covering 12 seconds. Adding the four input lengths gives 13 seconds because the interval from 3 to 4 was counted twice.

A straightforward solution sorts by start time, tracks the active interval, and extends its end whenever the next range overlaps or touches it. Otherwise, emit the active interval and begin another. Explain the invariant: emitted intervals are ordered and disjoint, and the active interval covers every un-emitted range processed so far.

Sorting takes O(n log n) time; the scan is linear. Output storage depends on the number of merged intervals. Clarify whether sorting the caller’s input in place is acceptable. Even a correct duration calculation can break the editor if it unexpectedly rearranges shared selections.

Test empty input, one range, nested ranges, duplicates, touching endpoints, and input supplied in reverse order. Decide whether zero-length selections are ignored and whether reversed endpoints are rejected. Those rules belong in the contract, not in accidental implementation behavior.

For a media-specific follow-up, ask how timeline units map to frames. Do not casually round each endpoint independently and assume the exported duration stays unchanged. Specify the representation and conversion boundary before extending the algorithm to variable-rate media.

Code review: identify the user-visible consequence

The historical pull-request report makes review practice worthwhile. An original review drill: imagine a generation button whose handler creates a task, stores the returned output URL, and immediately marks the project complete. Review the contract around those steps before commenting on naming or formatting.

Ask what happens when the user clicks twice, leaves the page, reopens the project tomorrow, or edits the prompt while a previous request is still running. A useful comment names the failing condition and its consequence, then suggests a bounded correction.

For example: “This stores the provider’s temporary output URL as the project asset. Reopening the project after that URL expires can leave the clip unavailable. Can we persist the file and commit our own asset record before marking the project ready?” The next section explains the official contract behind that concern.

Separate blockers from suggestions. Missing authorization or incorrect state transitions may invalidate the feature; a preferred helper name usually does not. Ask for a regression test that reproduces the failure instead of merely requesting “more tests.”

Video ML systems: generation success is not project readiness

Official API behavior: Runway’s getting-started documentation shows creating a generation task and waiting for its output; the HTTP example returns an identifier used to retrieve task status. This supports thinking in terms of asynchronous work rather than holding the browser interaction open until all processing completes. Using the API

Official output contract: Runway says generated output URLs are temporary and expire within 24–48 hours of accessing the API. It instructs developers to save the data to their own storage and not expose those temporary URLs directly in their products. API output formats

Original design exercise: Build a small generation workspace around that contract. Persist an application job and its owning project. Submit the generation request, associate the provider task ID, retrieve its eventual result, copy the output into application-managed storage, and commit an authorized asset record. Only then show the asset as ready in the project. If file storage succeeds but the database update fails, retain a stable asset key so recovery can complete the record without producing another unrelated copy. Explain how you find and clean up genuinely abandoned files.

Use separate states for provider completion and application readiness. If generation succeeds but copying the file fails, the application has unfinished storage work. Resubmitting generation would repeat expensive work while potentially producing a different clip. Retry the failed storage step while the source remains available.

A lost submission response is another case. The provider may have accepted the request even though your application did not receive its ID. Do not claim exactly-once behavior just because your database has a unique local job key. Explain what can be reconciled through documented provider capabilities and what remains uncertain. A timeout alone does not prove that generation never started.

Keep asset ownership separate from possession of a URL. A project lookup should authorize the current user before returning access to its media. Record the generation configuration and source-input identity with the asset so that collaborators can understand which version they are viewing.

For a changed prompt, retain the original job’s association with the original project revision. An older result may still be useful, but it should not silently replace the active selection. That is an application policy to design explicitly, not a claim about Runway’s internal architecture.

Failure handling should change the next action

Official failure guidance: Runway distinguishes invalid assets, moderation rejections, and internal processing errors. Its documentation says not to retry invalid-input or input-moderation failures unchanged, while certain internal errors may be retried after a delay. It also cautions that diagnostic failure codes should not be exposed directly to users. Handling task failures

Preparation recommendation: Describe a bounded retry policy, a useful user message, and enough internal diagnostics to investigate. “Retry everything” can waste capacity and obscure the original problem. “Something went wrong” gives the creator no way to recover.

Test these cases with controlled fixtures. Verify both the stored state and the visible interface after reopening the project. A green request log is insufficient evidence that the user can play the saved video.

Discuss quality, capacity, and creative usefulness together

Preparation inference from the research and product roles: A video ML system needs evaluation that goes beyond successful HTTP responses. Start by defining the intended task. A visually attractive clip may still miss the requested action, drift in appearance across frames, or fail the export workflow.

Build a held-out evaluation set covering different motion, scene complexity, input quality, and requested styles. Keep the model version and generation configuration with each result. Compare text adherence, temporal consistency, and whether the output is usable for the stated editing task. Include human review where the criterion is subjective, with a rubric so reviewers judge the same properties.

Then connect quality to operational measures. Track end-to-end time to a usable asset, queue waiting, generation failures, storage failures, and cost per accepted output. Define “accepted” before computing that last metric; a downloaded file is not necessarily a creator-approved result.

For capacity, separate active inference slots from incoming requests. A queue can absorb a short burst, but it cannot make sustained demand above service capacity disappear. Discuss admission limits, per-workspace fairness, cancellation, and whether different job shapes should share a queue.

For a proposed batching optimization, ask what improves and what might regress. Throughput can rise while an individual creator waits longer for a compatible batch. Measure both sides under a realistic workload before claiming an improvement. No particular latency target, GPU configuration, or batching policy is established here as Runway’s own.

Five practice questions with clear role boundaries

The first two records are Runway-tagged Machine Learning Engineer practice. The remaining three are cross-company SWE exercises selected for the video-timeline and asynchronous-workflow problems above. They are preparation material, not a prediction of your next interview.

Finish preparation with one project story that connects a technical decision to an observable result. Explain what you owned, what failed, how you investigated, and what evidence supported the fix. Product candidates can emphasize a complete editing interaction; API candidates can explain a recovery path; research candidates can defend an evaluation decision.

Bring questions about the team’s ownership boundary, how prototypes become production features, and how success is measured. Return to Runway interview questions for targeted practice, and use the actual requisition and recruiter guidance to choose the depth appropriate to your role.

Sources and Further Reading

• Runway careers
• Runway Backend Engineer, API
• Runway Staff Product Engineer
• Runway Research Engineer
• Historical Runway NYC Software Engineer candidate reports
• Runway API getting-started guide
• Runway API output formats
• Runway task-failure guidance