Replit Interview Questions: Official Process and a Deployment-Diff Exercise

TL;DR

• Replit publishes a general hiring process covering recruiter, hiring-manager, technical and panel conversations. The technical format varies with the role.
• Prepare a project walkthrough that connects a user's problem, your implementation, a concrete test and a tradeoff you can defend.
• The original deployment-manifest exercise below practices validation, deterministic output and the difference between editing a project and publishing a snapshot.
• These are practice questions grounded in public product context, not a list of Replit's private interview questions. Confirm the actual exercise and tool policy with recruiting.

What does Replit say about its interview process?

Replit's general process starts with a recruiter conversation, followed by a discussion with the hiring manager. A technical stage may involve live work or a take-home, with formats such as a project walkthrough or coding exercise depending on the role. A panel then considers relevant technical, problem-solving and behavioral skills. The company describes its assessment as focused on practical work. See Replit's official interview process.

Use that information to prepare the right kind of evidence, but do not assume every position uses the same assignment or duration. Ask which format applies to your role, whether you need a local environment, what language choices are available and which reference or AI tools are permitted. If there is a take-home, confirm the expected time investment and submission format. Our guide to common tech interview formats covers what to confirm and prepare for coding, design, take-home and collaborative rounds.

For a project walkthrough, select something you understand deeply enough to modify. You should be able to explain a bug, an unhappy path and a decision you would now change. A polished demo is useful, but a rehearsed demo that cannot survive a follow-up question does not reveal much about your engineering judgment.

The rest of this guide provides original exercises. It is not a report from a candidate interview and does not claim that Replit asks these exact questions.

Question 1: how would you explain a product you built?

Begin with the person using it. For example, “I built a preview service so a designer could inspect a proposed website change before it reached the public site.” Then describe the shortest useful path through the system: submit a revision, build an artifact, inspect the preview and promote a reviewed revision.

Make your ownership concrete. Identify a component you designed, an interface you negotiated and a failure you investigated. If a teammate implemented the build system, give them credit and explain how your component depended on their contract.

Finally, show evidence. A deterministic test, a before-and-after trace or a resolved customer problem is easier to assess than “the system became scalable.” If you lack a reliable before measurement, do not invent one. State the observable behavior you improved and how you verified it.

Keep a short version ready for the opening conversation and a deeper version for technical follow-ups. You should be able to move from the product's purpose to a specific function without losing the connection between them.

Question 2: why can an editor and a published app differ?

Replit's publishing documentation describes publishing as creating a snapshot that runs separately from the project in the editor. Updating the working project and updating the published app are therefore distinct events. The documentation also cautions against relying on writes to a published app's filesystem for persistent application data. See the official publishing documentation.

An original debugging prompt follows naturally: “A user says the editor shows the new header, but the public site still shows the old one. What do you inspect?” Ask for the intended revision and compare it with the actual published artifact. Check whether a new build succeeded, whether the public domain points to that deployment and whether a cache is serving an older response.

Avoid changing production immediately to make the symptom disappear. First establish which revision is supposed to be live. If two people are editing the project, publishing the current workspace may include work the user did not intend to release.

That reasoning motivates a small programming problem: produce a clear difference between two immutable file inventories. The following code is our teaching model, not a description of Replit's internal storage or deployment implementation.

Question 3: can you implement a deterministic manifest comparison?

Each manifest maps a relative POSIX file path to a lowercase SHA-256 string. Return four sorted lists: added, removed, changed and unchanged. Treat case as significant. Reject absolute paths, backslashes, empty path components, dot segments and invalid digests rather than silently normalizing them.

These restrictions create a narrow exercise contract. The function compares supplied metadata; it does not read files, hash their contents, follow symbolic links or perform a deployment.

import re


def validate_manifest(manifest):
    if not isinstance(manifest, dict):
        raise ValueError("manifest must be a dictionary")
    for path, digest in manifest.items():
        if not isinstance(path, str) or not path:
            raise ValueError("path must be a nonempty string")
        parts = path.split("/")
        if "\\" in path or any(c in path for c in "\x00\r\n"):
            raise ValueError("unsupported path character")
        if any(part in ("", ".", "..") for part in parts):
            raise ValueError("path must be relative and normalized")
        if not isinstance(digest, str) or not re.fullmatch(
                r"[0-9a-f]{64}", digest):
            raise ValueError("invalid SHA-256")


def manifest_diff(before, after):
    validate_manifest(before)
    validate_manifest(after)
    old_paths, new_paths = set(before), set(after)
    shared = old_paths & new_paths
    return {
        "added": sorted(new_paths - old_paths),
        "removed": sorted(old_paths - new_paths),
        "changed": sorted(p for p in shared if before[p] != after[p]),
        "unchanged": sorted(p for p in shared if before[p] == after[p]),
    }


before = {"app.py": "a" * 64, "old.txt": "b" * 64,
          "static/logo.svg": "c" * 64}
after = {"app.py": "d" * 64, "new.txt": "e" * 64,
         "static/logo.svg": "c" * 64}
assert manifest_diff(before, after) == {
    "added": ["new.txt"], "removed": ["old.txt"],
    "changed": ["app.py"], "unchanged": ["static/logo.svg"],
}

The output is stable even if the input dictionaries were constructed in a different order. That matters when a reviewer compares a saved plan with a later result, or when a test needs a reproducible artifact. Sorting adds O(n log n) work in the worst case; the set operations and comparisons are expected O(n), excluding the length of strings being validated.

Space use is O(n) for the sets and returned lists. Both manifests remain unchanged. A rename appears as one removal and one addition, which is correct for this contract. Detecting moves by equal content hashes could be a separate feature, but duplicate files would make the matching ambiguous.

Question 4: what tests expose the important mistakes?

Start with the complete fixture above and two empty manifests. Then test an identical manifest, a file whose name changes, a digest whose value changes and a case-only path difference. Run permutations of dictionary insertion order and confirm that the returned lists stay identical.

The validation is not a filesystem sandbox. A real file reader would need its own root containment, symlink, platform and race checks. Nor does a syntactically valid digest prove the corresponding file exists or that its contents were hashed correctly. Those guarantees belong to the component that creates and verifies the artifact.

That distinction is a useful follow-up answer: local tests can prove this classification logic behaves as specified, while integration tests must verify the actual build, storage and release process.

Question 5: how would you turn the comparison into a safe publish flow?

Keep the reviewed input immutable. Suppose the user reviews artifact A while someone else keeps editing the project. The publish command should identify A explicitly; it should not quietly rebuild an unrelated current workspace and claim that the reviewed change was released.

Separate a plan from its application. A useful plan includes the intended artifact reference, the current public version, visible changes and validation results. Applying it should check whether the expected current version still matches. If another release happened first, the system needs an explicit conflict path rather than silently overwriting it.

Discuss rollback separately from code promotion. Restoring an older application artifact does not automatically reverse database changes, outgoing messages or other external actions. State which changes are reversible, which require a compatible schema and which need a compensating operation.

Also define a success condition that reaches the user. A successful build is not the same as a working public route. For a web app, check a representative page, its expected content and a relevant interaction after the intended domain serves the new revision. This is an original system-design discussion, not a promise about a particular provider's release mechanism. A mock system design interview with skeptical follow-up questions is one way to rehearse defending design choices like these aloud.

Question 6: how do you make a developer error easier to resolve?

Use a specific example: a project references a missing environment value at startup. “Build failed” alone leaves the developer to guess which stage failed and what to do next. A useful error identifies the failing stage, names the missing configuration key without exposing its value, and points to the place where the user can supply it.

Distinguish errors the user can fix from failures that require service recovery. A malformed manifest can return a focused validation error. A transient storage failure might allow retrying the same operation reference. An unknown release outcome needs status lookup before another release is started.

In a walkthrough, show the difference between diagnostic information for an operator and an action the product user can take. Do not bury the next step in an internal stack trace. Our worked code-review exercise provides another way to practice prioritizing correctness and user impact together.

Question 7: how would you handle a changed requirement mid-exercise?

Suppose the interviewer adds a requirement to handle hundreds of thousands of files. Ask whether both inventories fit in memory and whether they arrive sorted. A merge over sorted streams can change the memory tradeoff; a database-backed inventory introduces different consistency and query concerns. Do not rewrite the solution before clarifying which constraint actually changed.

If the new requirement is case-insensitive paths, discuss collisions before calling a lowercase function. Two previously distinct names may map to one identity. If the requirement is move detection, ask whether the user needs an exact identity history or just a helpful suggestion in the review interface.

These follow-ups test whether you can revise a contract deliberately. State what remains valid, what needs to change and which earlier tests should now fail or be replaced. That makes your reasoning easier to inspect than a rapid series of unannounced edits.

Prepare a complete rehearsal

Spend one session walking through a real project, one implementing and testing a small exercise, and one discussing release behavior with a partner. Ask the partner to challenge an assumption rather than simply checking whether your code runs.

Before the real interview, confirm logistics using the phone-screen preparation checklist. Follow the stated tool policy during the assessment. Public company context helps you choose useful practice, but your best evidence remains work you can explain and modify yourself.

Sources checked September 14, 2026. This guide is independent of Replit and does not claim access to confidential hiring material.