Articles

Blazor Interview Questions: Render Modes, Component State, and Reconnection

Prepare for Blazor interviews with render-mode decisions, prerender initialization traces, state lifetimes, circuit reconnection, and durable recovery checks.

A Blazor page shows a button, but clicking it does nothing. Another component fetches the same record twice. A third loses a half-completed form after a refresh. These problems can look unrelated until you ask two questions: where is the component executing, and how long does its state live?

For Blazor interview questions, build your answer around execution, initialization, and recovery. Naming a render mode is only the start. Explain which component instance handles the event, what happens before interactivity starts, and what the application can recover after the original instance disappears.

This guide uses official .NET 10 documentation for framework behavior. Its traces and application scenarios are original preparation exercises, not reported employer questions. The traces are documentary examples; no compiled Blazor application or runtime test is claimed.

Which render mode actually handles the button?

Official facts: Microsoft's render-mode documentation distinguishes static SSR, Interactive Server, Interactive WebAssembly, and Interactive Auto. Static SSR produces server-rendered HTML without interactive component events. Interactive Server executes through a server circuit; Interactive WebAssembly executes in the browser. Auto initially uses server interactivity and can use WebAssembly on later visits after the client bundle is available. Auto does not move an already-running component between runtimes.

Start your diagnosis with an observation rather than a preferred architecture. Does the page contain an ordinary HTML form submission, an interactive component event, or a browser script? A button can exist in static HTML without its Blazor event handler being available. Therefore, visible markup is not proof that the component has become interactive.

Consider an original appointment page with two areas. The public office description changes infrequently; the appointment picker responds to date selection. You could keep the description statically rendered and make the picker interactive. The requirement is local interaction in the picker, not interactivity in every paragraph. Conversely, if shared interactive state connects several controls, scattering boundaries can complicate the design.

When asked to choose Server or WebAssembly, state the requirement that drives your answer. A server-executed workflow depends on connectivity to that server. A browser-executed component needs its client-side code and applicable services. For a particular system, measure startup, network behavior, server capacity, and deployment complexity rather than declaring one mode universally faster.

An Auto follow-up might ask whether a user's current picker suddenly switches to WebAssembly after a download completes. The answer is no. Plan a later visit separately from the current instance. Our preparation inference is that this distinction matters when diagnosing two sessions with different execution locations; the mode's name alone does not explain their observed behavior.

Official boundary: the render-mode documentation requires parameters passed from a static parent to an interactive child to be JSON serializable. A delegate or RenderFragment cannot simply cross that boundary as ordinary serialized data.

For an original design check, suppose the static appointment page passes an office ID and a callback that creates a reservation. The office ID can describe context; the callback is executable behavior. Put the interactive behavior inside a supported interactive boundary and pass the required data explicitly. Do not assume that markup nesting supplies a shared execution context.

Rehearse the error as a boundary problem: identify the parent and child modes, the actual parameter type, and where the behavior must execute. Then test the corrected design with a valid office, an unknown office, and a later selection change. Moving a callback does not remove the backend's need to validate the final reservation request.

Why can initialization happen twice?

Official facts: prerendering is enabled by default for interactive components. Microsoft's lifecycle guidance describes initialization during prerendering and again when the component becomes interactive. OnAfterRenderAsync does not run during prerendering; its firstRender flag concerns that component instance.

Here is an original trace for an appointment component that loads available slots. Assume a full page request, interactive server rendering, prerendering enabled, and no explicit transfer of the loaded result:

Request begins
  instance P: initialize -> read slots -> produce initial HTML
Browser connects for interactivity
  instance I: initialize -> read slots -> handle user events
User changes the date
  instance I: load slots for the selected date

The two initialization reads do not mean the user clicked twice. They belong to different rendering phases. Adding a private loaded field to P cannot, by itself, make it available to I, so an instance-local guard does not solve the phase transition. Before choosing a fix, log a component-instance identifier, the phase, the requested date, and the operation being performed. Two identical HTTP calls and two different business operations require different remedies.

A read-only request for slots may be wasteful but safe to repeat. Creating a reservation inside initialization is a different problem: the application has attached a business mutation to a lifecycle event that can recur. Moving the mutation to a deliberate user action helps express intent; a durable operation identity at the business boundary handles uncertain retries. A component-level Boolean does not establish that a reservation was created only once.

Official mechanism: prerendered state persistence can transfer selected state into the interactive instance, including through public properties marked [PersistentState]. For WebAssembly and Auto, transferred data may be exposed to the browser; it must not contain private secrets.

For this exercise, persist the display-safe slot result and restore it before deciding whether to fetch. The acceptance condition is one initial logical load, followed by a new load when the selected date genuinely changes. Test an empty result as well as a populated one: “no available slots” is a valid loaded result, not necessarily evidence that loading has not occurred.

Disabling prerendering can also change the behavior, but explain its user-facing cost. What appears before the interactive runtime is ready? Does the initial page still communicate loading or availability clearly? Choose it for an explicit application requirement, not merely to hide a confusing log.

Put state where its required lifetime belongs

An interview answer becomes clearer when you name the state item, its owner, and the event it must survive. In this original design ledger, the values belong to the appointment exercise:

State item	Required lifetime	Candidate home and reason
Expanded help panel	Current component interaction	Component field; losing it is acceptable
Selected office and date	Reload and shareable navigation	URL parameters, with validation on entry
Unsaved appointment notes	The draft-retention interval specified by the product	Chosen draft store keyed by user and draft ID
Confirmed reservation	New sessions and server restarts	Durable business record with an operation ID

These choices are recommendations for the stated requirements, not framework guarantees. A different product might intentionally avoid saving notes, or require drafts across devices. That changes the storage decision. Explain the trade-off, including whether a stale draft can overwrite a newer edit and how the user recognizes that recovery occurred.

Component fields make local behavior easy to understand. A shared state container can connect components, but “shared” needs a scope. Sharing within one user's interaction is different from sharing among users or across servers. A singleton containing mutable per-user form state would require a very different isolation argument from a per-circuit service.

Official boundary: Microsoft's server-side state guidance describes circuit state and .NET 10 persistence of selected serializable application data. Persistence does not serialize component instances or the render tree, and full-page refresh is not covered by circuit-state persistence.

Therefore, “we enabled persistence” is an incomplete recovery answer. Identify the selected data, configured storage and retention, restoration path, and unsupported events. A restored draft can repopulate inputs; it does not resurrect an arbitrary object graph or prove that a business write succeeded.

Avoid storing the same authoritative value in several places without a reconciliation rule. If the URL says Tuesday and the restored draft says Wednesday, which wins? In this exercise, the URL selects the appointment context; the matching draft contributes only notes. A context mismatch prompts the user before applying another draft. That rule makes recovery testable.

Reconnect, reload, and recover are different actions

Official facts: SignalR guidance distinguishes reconnection failure from rejection. Rejection can mean the server no longer has the user's circuit, for example after disposal or a restart. Do not assume that every temporary network interruption destroys the circuit, or that every attempted reconnect can recover it.

Use three events to explain the appointment page:

A. Network interruption; original circuit still available
   Reconnect to that circuit -> its current component state can remain
B. User refreshes the page
   New page/component lifecycle -> rebuild context and load the draft
C. Original circuit is no longer recoverable
   Reinitialize -> restore supported data -> reconcile business records

This is an original recovery ledger, not a promise about retention durations. Ask about the actual circuit configuration and infrastructure before claiming that event A will succeed after a particular number of seconds.

The important edge case occurs after a reservation request reaches the backend but before the confirmation reaches the browser. The user sees a reconnect prompt, with no confirmation and no reliable way to tell whether the booking succeeded. Retrying with a fresh operation identity can create another reservation. Recovering the visible form without checking the durable receipt leaves the same ambiguity.

In our exercise, the client keeps a stable reservation operation ID for that attempt. On recovery, it queries the backend's result for that ID. A confirmed receipt leads to the confirmation view. A definitively absent operation can follow the defined retry policy. An unavailable backend leaves the state unresolved and should not be presented as a successful booking or a definite failure.

The backend must also validate identity and appointment availability on the final write. Restored client data is an input, not authorization. A slot shown before the outage may now be unavailable. Preserving a draft improves usability; it does not reserve scarce capacity automatically.

Blazor interview questions: diagnose state bugs

For a duplicate initialization report, reproduce a full initial page load and an internal interactive navigation separately. Record phase and instance identity. Verify that the display-safe persisted value is restored before loading. Then change the date and confirm that the new request reflects the new context rather than an old cache entry.

For a search or picker race, introduce two responses with reversed completion order. The latest selected date should determine the displayed slots. Merely awaiting each request inside its handler does not explain what happens when multiple handlers overlap. State the cancellation or response-identity rule your design uses.

For recovery, type a draft, interrupt connectivity, reconnect, refresh, and simulate loss of the original circuit. The expected outcomes should differ according to the ledger. Add a committed-but-unacknowledged reservation to distinguish UI recovery from business reconciliation. These are proposed application tests; no Blazor runtime execution is claimed here.

Question	Follow-up to rehearse
Implement an Accessible Autocomplete Search Component	Trace server versus browser events, focus and initial interactivity.
Build a Reliable Streaming Chat UI	Distinguish reconnecting a transport from restoring business state.
Design Calendar Frontend State for Recurring Events	Choose component, URL and durable homes for separate values.
Implement Search and Filters, Then Diagnose a Query-Ordering Bug	Reject stale responses when newer input wins.
Implement a multi-step form in React	Preserve draft context across a reload without trusting it as authorization.

Choose one task from the table and rehearse it aloud with the mode, state owner, initialization phase, and recovery event written down first. In frontend engineer practice, choose a stateful UI question and add a refresh plus a lost-response case. A useful answer predicts what the user sees and what the backend knows after each event, then names the evidence that would prove the prediction.