Blazor Interview Questions

Analogy categoryAnalogies

How to Use This Interview Guide

This guide groups Blazor interview questions by depth, starting with fundamentals interviewers use to confirm you understand the mental model (hosting models, component lifecycle, data binding), moving into intermediate topics that separate candidates who've shipped real apps from those who've only followed tutorials (state management patterns, JS interop, forms and validation), and finishing with advanced questions probing performance and architecture decisions (render mode selection, prerendering pitfalls, SignalR scaling). For each question, focus your answer on the underlying mechanism, not just the syntax, since interviewers commonly follow up by asking why a given approach behaves the way it does.

🏏

Cricket analogy: A commentator explaining a dismissal walks through the mechanics of the delivery, seam position, and footwork rather than just stating 'he's out', mirroring how a strong interview answer explains the underlying mechanism, not just the syntax.

Fundamentals: Hosting Models and Lifecycle

A frequent opening question is to explain the difference between Blazor Server and Blazor WebAssembly: Server executes component code on the server and streams UI diffs to the browser over SignalR, giving instant startup and full access to server resources but requiring a constant connection and adding per-interaction network latency, while WebAssembly downloads the .NET runtime and app to the browser and runs everything client-side, trading a larger initial download for offline capability and no per-interaction round trip. A follow-up commonly probes the component lifecycle order: SetParametersAsync runs first and calls base.SetParametersAsync to populate [Parameter] properties, then OnInitialized/OnInitializedAsync runs once per component instance, OnParametersSet/OnParametersSetAsync runs after SetParametersAsync on every parameter update including the first, and OnAfterRender/OnAfterRenderAsync runs after the component has been rendered to the DOM, useful for JS interop that needs the actual DOM element to exist.

🏏

Cricket analogy: A live radio commentary describing every ball to listeners in real time mirrors Blazor Server's constant SignalR connection, whereas a pre-recorded podcast summary you download and replay offline mirrors WASM running independently once downloaded.

Intermediate and Advanced: Interop, State, and Performance

Interviewers often ask how JavaScript interop works and why it's asynchronous: IJSRuntime.InvokeAsync<T> serializes arguments to JSON, calls into the JS side (either a global function or an imported ES module via IJSObjectReference), and returns a Task because the call may cross a network boundary in Blazor Server or, in WASM, still needs to be async since JS execution and .NET execution run on the same thread and a synchronous blocking call would deadlock the UI. A strong answer also distinguishes JS-to-.NET calls: static methods marked [JSInvokable] can be called via DotNet.invokeMethodAsync, while instance methods require passing a DotNetObjectReference created with DotNetObjectReference.Create(this), which must be disposed in the component's Dispose method to avoid leaking the reference on the .NET side.

🏏

Cricket analogy: Requesting a DRS review sends a query to the third umpire and the players wait for the result rather than the on-field umpire guessing instantly, mirroring how InvokeAsync awaits a response rather than blocking synchronously.

Explaining Render Modes and Prerendering Pitfalls

A question that trips up candidates who haven't worked with .NET 8+ is explaining prerendering: by default, Interactive Server and Interactive WebAssembly components are prerendered, meaning the server renders the component once to static HTML for a fast first paint before the interactive runtime (SignalR circuit or WASM) takes over and re-runs the component's lifecycle a second time to attach interactivity, which means OnInitializedAsync can run twice and any code with side effects, incrementing a counter in a database, calling an API that isn't idempotent, needs to guard against double execution using a check like OperatingSystem.IsBrowser() or by checking if RendererInfo.IsInteractive is true before doing the work. Interviewers may also ask when to pick each render mode: Static Server for content that never needs interactivity (fastest, no runtime cost), Interactive Server for internal tools where users are on a reliable network and server resources are cheap relative to a large WASM download, Interactive WebAssembly for public apps needing offline capability or minimal per-interaction latency after load, and Interactive Auto to get fast first-load via Server while WASM downloads in the background for subsequent visits.

🏏

Cricket analogy: A pitch report given before the toss offers a static preview of conditions, similar to prerendering giving a fast static HTML preview, before the actual live, interactive match play begins once the toss happens, mirroring the interactive runtime taking over.

csharp

@page "/dashboard"
@rendermode InteractiveServer

@code {
    private int _viewCount;

    protected override async Task OnInitializedAsync()
    {
        // Guard against double execution during prerender + interactive attach
        if (RendererInfo.IsInteractive)
        {
            _viewCount = await AnalyticsService.IncrementAndGetViewCountAsync();
        }
    }
}

// JS-to-.NET instance interop, disposed correctly
@implements IAsyncDisposable
@inject IJSRuntime JS
@code {
    private DotNetObjectReference<Dashboard>? _dotNetRef;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            _dotNetRef = DotNetObjectReference.Create(this);
            await JS.InvokeVoidAsync("dashboardInterop.init", _dotNetRef);
        }
    }

    [JSInvokable]
    public void OnResize(int width) => _viewCount += 0; // handle resize event

    public async ValueTask DisposeAsync()
    {
        if (_dotNetRef is not null)
        {
            await JS.InvokeVoidAsync("dashboardInterop.dispose");
            _dotNetRef.Dispose();
        }
    }
}

When asked 'what happens if you don't await an async lifecycle method', give the precise answer: Blazor calls OnInitializedAsync and continues without waiting if you don't structure the code to await it internally, but the framework itself does await the returned Task and triggers a second render automatically once it completes, so the UI shows an initial state (e.g., a loading spinner) and then updates once the async work finishes.

A common interview trap is asking candidates to spot the bug in a component that calls a payment API inside OnInitializedAsync without any prerendering guard; because prerendering runs the component's lifecycle a first time to generate static HTML, that API call would fire twice by default under Interactive Server or WebAssembly render modes, potentially double-charging a customer.

Explain mechanisms, not just syntax; interviewers commonly follow up with 'why does that happen'.
Blazor Server executes on the server over SignalR; Blazor WebAssembly runs entirely in the browser after download.
Lifecycle order is SetParametersAsync, OnInitialized(Async) once, OnParametersSet(Async) on every update, OnAfterRender(Async) after DOM attachment.
JS interop is async because Blazor Server calls cross a network boundary and WASM shares a single thread with JS, so a sync blocking call would deadlock.
Instance-level JS-to-.NET calls need a DotNetObjectReference that must be disposed to avoid leaking references.
Prerendering runs the component lifecycle twice by default (static render, then interactive attach), so side effects need a RendererInfo.IsInteractive guard.
Render mode choice trades off first-load speed, offline capability, per-interaction latency, and server resource cost.