Intervue Technical Interview: Rehearse Live Coding and Explain Your Trade-Offs

An Intervue technical interview is a shared working session, so a correct solution is only part of the evidence you produce. The other person needs to follow your assumptions, see what you tested, and understand why you kept a simple design or changed it.

Confirm which Intervue session you have, then rehearse one complete loop: clarify the contract, implement a baseline, run boundary tests, and explain a requirement change. Platform features do not establish a universal employer question list, scoring threshold, or interview duration.

This guide separates Intervue's official product descriptions from our original preparation exercise. We do not have independent same-cycle candidate evidence for a single hiring process.

First identify the session you are preparing for

An employer invitation using Intervue and a candidate booking a mock interview are different situations. The official live pair-programming product page describes a collaborative coding interface, configurable editor preferences, supported languages and libraries, and integrated video and messaging. These are vendor-described capabilities; they do not promise that every invited session enables the same language, package, or workflow.

The separate official mock-interview page offers candidate practice with an interviewer and feedback. Its booking and bundle descriptions concern that product. Do not transfer them into an employer's hiring invitation or assume a mock interviewer represents that employer's current hiring panel.

Read the invitation for the role, scheduled window, round type, allowed language, and joining instructions. If the contract is unclear, ask the recruiting contact whether the session is algorithmic coding, practical implementation, debugging, or design. A platform name alone cannot answer those questions.

Treat testimonials on the vendor's own site as promotional material, not independent evidence of your round. A useful preparation target is what you can control: a working environment, explicit assumptions, observable tests, and clear reasoning.

Check the environment without making unsupported assumptions

Use the invitation's approved preparation route to confirm the browser and connection work. If an editor is available beforehand, practise its normal run control, input convention, indentation, and error display. The official product describes editor customization, but that is not evidence that your particular session permits importing a repository or installing arbitrary dependencies.

Our recommendation is to rehearse with the standard library first. Keep a small function or class, an obvious entry point, and deterministic inputs. If the exercise requires a dependency, confirm its availability before building the solution around it. Knowing how to isolate a missing package is more useful than spending the session attempting an unapproved environment change.

Confirm the rules for documentation, notes, external tools, and AI assistance. Do not infer permission from the platform having a question bank or a collaborative editor. During a real assessment, the invitation and interviewer determine what assistance is allowed.

Have a concise recovery message ready: “The editor is visible, but execution has not returned. I will preserve the current version and show the expected output while we check the runner.” That distinguishes a tool problem from an algorithm claim.

Turn an ambiguous prompt into a small executable contract

For this original rehearsal, implement an in-memory manager of expiring reservation holds. It receives a fixed positive time-to-live, integer timestamps in nondecreasing order, and three commands: place a hold, release it, and count active holds. Each identifier represents one hold; quantities and multiple products are outside this first contract.

Agree that a hold is active only while expiry > now. Placing an already active identifier returns false without extending it. An expired identifier can be used again. Releasing a missing or expired identifier returns false. These decisions are exercise assumptions, not universal reservation-system rules.

Say the invariant aloud: “After cleanup at time t, every retained expiry is greater than t, and every retained identifier denotes one active hold.” That connects the code to something a partner can inspect.

Ask about equal timestamps, empty state, duplicate identifiers, and the exact expiry boundary before implementation. Also confirm whether time can move backward. We exclude that behavior here; a production system would need an explicit clock and event-order policy.

Do not spend the opening inventing distributed locks or payment workflows. State the current scope and name the point where stronger requirements would change the design. A short contract gives both participants a shared basis for deciding whether an output is correct.

Implement the baseline you can explain and test

The following original Python implementation ran locally with the boundary checks shown later. It deliberately scans retained holds during cleanup, so its cost is visible.

class Holds:
    def __init__(self, ttl):
        if ttl <= 0:
            raise ValueError("ttl must be positive")
        self.ttl = ttl
        self.expiry = {}

    def _prune(self, now):
        expired = [key for key, end in self.expiry.items()
                   if end <= now]
        for key in expired:
            del self.expiry[key]

    def place(self, key, now):
        self._prune(now)
        if key in self.expiry:
            return False
        self.expiry[key] = now + self.ttl
        return True

    def release(self, key, now):
        self._prune(now)
        return self.expiry.pop(key, None) is not None

    def count(self, now):
        self._prune(now)
        return len(self.expiry)

The Python dictionary documentation describes the mapping operations. The temporary expired-key list avoids deleting dictionary entries while iterating its live view. Expiry values are numeric under our contract, so the None sentinel in release is unambiguous.

Narrate decisions at useful checkpoints, not every keystroke. Before cleanup: “I remove expired entries first so duplicate placement uses the active-state rule.” Before release: “The return value distinguishes removal from a no-op.” Before testing: “The most important boundary is equality with expiry.”

This is a sequential rehearsal implementation. It does not promise concurrent reservation safety, persistence, or recovery after process failure. Those would introduce different invariants rather than a cosmetic replacement of the dictionary.

Use one command trace to expose the boundary

Set the time-to-live to ten. Trace the following commands without looking at the implementation, then run them. The expected results below belong to our original contract.

Command	Expected result and reason
Place A at time 0	True; A expires at 10
Place A at time 5	False; duplicate does not renew A
Place B at time 5	True; B expires at 15
Count at time 10	1; A expires at equality
Release A at time 10	False; A is already absent
Place A at time 10	True; new A expires at 20
Count at time 15	1; B is expired, new A remains

These assertions exercise the same trace:

h = Holds(10)
assert h.place("A", 0)
assert not h.place("A", 5)
assert h.place("B", 5)
assert h.count(10) == 1
assert not h.release("A", 10)
assert h.place("A", 10)
assert h.count(15) == 1
assert h.release("A", 15)
assert h.count(15) == 0

A tempting bug is changing end <= now to end < now. The equality test catches it immediately. Another is overwriting an active duplicate, which silently changes the expiry from 10 to 15. The trace catches both without a large test suite.

Also check an empty count, an unknown release, invalid time-to-live, and reuse after expiry. Describe what each assertion proves. A passing ordinary example alone does not establish the expiry contract, and a coverage percentage alone does not show that the assertions are meaningful.

Explain the cost before choosing a more complex structure

Let m be the number of retained entries before a command. Cleanup examines all m entries and may temporarily store up to m expired identifiers. Each command is therefore O(m) for this baseline, with O(m) retained state and worst-case temporary cleanup space. Calling the dictionary lookup constant time does not make the whole command constant time.

If the interviewer gives a large operation stream, propose a dictionary plus a min-heap of expiry records. The heap lets cleanup examine the earliest expirations rather than scan every active entry. Explain the additional bookkeeping, not just “use a heap.”

Now change the requirement: active holds may be renewed. An old heap entry can remain after the dictionary records a newer expiry. A stale expiry must not delete the renewed hold. Compare the popped record with the current record before removal; a generation identifier is useful when identifiers can be released and reused.

Even with correct stale-record handling, many renewals can accumulate obsolete heap entries. State space in terms of retained heap records, not only active holds, and discuss periodic rebuilding if memory becomes material. The proposed optimization is a design follow-up here, not an unexecuted claim that the baseline already has heap performance.

Make collaboration observable when you are stuck

Use short, testable statements: “The first version satisfies the sequential contract. Its scan cost is the limitation. I can keep it as a reference while adding expiry ordering.” That gives the partner a reason to accept the baseline or ask for an optimization.

When a test fails, identify the smallest discrepancy. “At time ten I expected A to be absent, but the count still includes it” is more useful than “something is wrong with the map.” Trace the relevant input, inspect the boundary predicate, and rerun the failing case before broad changes.

If the interviewer proposes a different duplicate policy, restate it and update the expected trace first. Otherwise, you can accidentally satisfy the new implementation while still testing the old contract. Preserving a baseline also makes a later refactor easier to compare.

A brief pause to think is reasonable. Explain the question you are resolving, such as whether renewal should preserve identity. Avoid filling silence with unverified complexity claims or apologizing repeatedly instead of examining the state.

Recover differently from different failures

Our preparation guidance distinguishes three problems. A compiler or syntax error is visible evidence about the submitted program: read its location and fix the smallest cause. A runner that fails without executing the program is an environment issue: preserve code and tell the partner what ran and what did not. A lost connection or missing shared view is a session issue: use the invitation's approved reconnection or contact route.

Before refreshing, ask whether the current work is saved or can be recovered through the permitted interface. We have not verified a universal Intervue autosave or recovery guarantee. Do not tell a candidate that closing a tab is harmless based only on another coding platform's behavior.

If execution is unavailable, a manual trace can still communicate reasoning, but label it as a trace rather than a passing test. When execution returns, run the boundary case and confirm the visible output. This keeps your account of progress accurate.

Practise code, tests and explanations together

Some are coding exercises; others ask you to explain a practical or collaborative approach.

Question	Rehearsal focus
Manage Authentication Tokens with a Fixed Time to Live	Exact expiry and state-changing operations
Build an Automatic Refund Decision System in a Pair-Programming Session	Clarify rules before implementation
Bank Account Simulation Class With Self-Written Tests at 90% Coverage	Explain assertion strength beyond coverage
Describe pair programming communication approach	Keep assumptions and decisions visible
Evaluate Defensive Testing and Pair Programming	Explain what collaboration and tests each address

Rehearse the hold manager with a partner who changes one requirement after the first tests pass. Ask for feedback on the contract, the failing-case explanation, and the cost discussion separately. That produces actionable evidence without pretending to reproduce an employer's private rubric.

Use the fixed-time-to-live question for another attempt. Your goal is a solution and explanation that remain understandable when the partner asks a follow-up.

Sources and Further Reading

• Intervue: live pair-programming product
• Intervue: candidate mock-interview product
• Python documentation: dictionary operations and views

Research checked October 4, 2026. Official product descriptions, original rehearsal code, and preparation recommendations are identified separately. No employer-specific question frequency, score threshold or outcome is asserted.