WPF Interview Questions and Answers (2026)

WPF interviews tend to focus on whether you actually understand MVVM and the property/binding system that makes it work, rather than just XAML syntax. Here are the WPF questions that come up most often, covering dependency properties, commands, templates, and the UI thread.

1. What is MVVM and why is it the standard pattern for WPF apps?

   MVVM (Model-View-ViewModel) separates a UI's presentation logic from its visual definition: the Model holds domain data/business logic, the View is the XAML defining UI structure with no code-behind logic, and the ViewModel exposes data and commands the View binds to, translating Model state into something bindable and handling user actions. WPF's data binding engine, INotifyPropertyChanged, and ICommand were essentially designed to make MVVM natural — the View declaratively binds to ViewModel properties/commands via XAML without needing to know concrete types, which keeps UI logic testable (ViewModels can be unit tested without a rendered UI) and lets designers and developers work on XAML and logic somewhat independently. It also avoids the tightly-coupled, hard-to-test code-behind spaghetti common in earlier WinForms-style development.

2. What's the difference between a dependency property and a regular CLR property?

   A dependency property is registered with WPF's property system via DependencyProperty.Register and backed by an efficient internal storage mechanism rather than a simple field, which unlocks WPF features a plain CLR property can't participate in: data binding, styling, animation, resource references, value inheritance from parent elements, and automatic change notification without manually implementing INotifyPropertyChanged. Dependency properties also support a value-resolution precedence system (local value > style trigger > template > inherited > default), which is how the same property can be set by animation, style, and code all at once with well-defined winner rules. A regular CLR property is just a normal getter/setter over a field, cheaper to declare, but invisible to the WPF property engine unless you manually wire up notification.

   public static readonly DependencyProperty ValueProperty =
       DependencyProperty.Register(nameof(Value), typeof(int), typeof(MyControl));
   public int Value
   {
       get => (int)GetValue(ValueProperty);
       set => SetValue(ValueProperty, value);
   }

3. What are the data binding modes in WPF, and when do you use each?

   OneWay pushes source-to-target only, updating the UI when the ViewModel changes but not writing back user edits — good for read-only display like labels. TwoWay synchronizes both directions — the default for editable input controls like TextBox.Text — so UI edits update the ViewModel and vice versa. OneWayToSource pushes target-to-source only, rarely used, useful when you want a control's state to update a ViewModel but never be overwritten by it. OneTime reads the source once at binding creation and never updates again in either direction, useful for static/startup-only values to reduce binding overhead. Default uses the binding mode metadata defined by the target property's dependency property (e.g., TextBox.Text defaults to TwoWay, TextBlock.Text defaults to OneWay).

4. What are routed events, and what's the difference between bubbling and tunneling?

   Routed events travel through the visual tree rather than firing only on the exact element that raised them, letting a parent handle events raised deep inside its child content without wiring up a handler on every element. Bubbling events (like Click, most ...Click/...Changed events) start at the source element and travel up through ancestors to the root — useful for a container to intercept/handle interactions from any descendant. Tunneling events (prefixed Preview..., like PreviewMouseDown) start at the root and travel down to the source before the corresponding bubbling event fires, letting ancestors intercept and potentially suppress an event (e.Handled = true) before it reaches the target. This tunnel-then-bubble pairing (e.g., PreviewKeyDown then KeyDown) is a distinctive WPF input-handling design.

5. What are the basics of XAML you should understand?

   XAML (Extensible Application Markup Language) is a declarative XML-based syntax for constructing object trees — each element maps to a .NET type instantiation, and attributes map to properties or events, with the XAML compiler generating equivalent C# object-construction code (via InitializeComponent()) at build time. Property element syntax (<Button.Background>...</Button.Background>) is used when a value is too complex for a simple attribute string. Markup extensions ({Binding Path}, {StaticResource Key}, {x:Static}) provide special non-literal value assignment. x:Name gives an element a code-behind-accessible identifier, distinct from the runtime Name property. Namespaces (xmlns) map XML prefixes to CLR namespaces/assemblies, letting you reference custom controls alongside built-in WPF types in the same markup.

6. What is `ICommand`, and how does a typical RelayCommand implementation work?

   ICommand is the interface WPF's command-binding infrastructure (e.g., Button.Command) expects, exposing Execute(object parameter), CanExecute(object parameter), and a CanExecuteChanged event that WPF listens to in order to automatically enable/disable bound controls. Since implementing a new class for every command is tedious, a RelayCommand (or DelegateCommand) is a reusable generic implementation that wraps two delegates — an Action for Execute and a Func<bool> for CanExecute — passed in via constructor, letting ViewModels expose commands as simple properties without command-specific boilerplate classes. This lets Views bind buttons directly to ViewModel behavior (Command="{Binding SaveCommand}") instead of handling Click events in code-behind, which is central to keeping MVVM code-behind-free.

   public class RelayCommand : ICommand
   {
       private readonly Action _execute;
       private readonly Func<bool>? _canExecute;
       public RelayCommand(Action execute, Func<bool>? canExecute = null)
           { _execute = execute; _canExecute = canExecute; }
       public bool CanExecute(object? p) => _canExecute?.Invoke() ?? true;
       public void Execute(object? p) => _execute();
       public event EventHandler? CanExecuteChanged
       {
           add => CommandManager.RequerySuggested += value;
           remove => CommandManager.RequerySuggested -= value;
       }
   }

7. How do `ItemsControl` and `DataTemplate` work together?

   ItemsControl (and its subclasses ListBox, ListView, ComboBox, ItemsControl itself) binds to a collection via ItemsSource and generates a visual element for each item, but by default just calls ToString() unless you supply a DataTemplate describing how each data object should actually be rendered. The DataTemplate is XAML that gets instantiated once per item, with its root's DataContext implicitly set to that item — so bindings inside the template reference properties on the individual item, not the parent ViewModel. This cleanly separates "what data to show" (ViewModel's collection) from "how to visually represent one item" (DataTemplate), and templates can be selected dynamically per item type using DataTemplateSelector or implicit typed DataTemplates keyed by DataType.

8. What is the UI thread and `Dispatcher`, and why does it matter?

   WPF UI elements are single-threaded-apartment objects that can only be created and accessed from the thread that created them — normally one dedicated UI thread per application, running a message loop (the Dispatcher) that processes input, layout, and rendering work as prioritized queued operations. Attempting to touch a UI element from a background thread (e.g., updating a TextBlock from a Task.Run callback or a non-UI async continuation) throws an InvalidOperationException. To safely update UI from another thread, you marshal the call back via Dispatcher.Invoke/InvokeAsync, or rely on async/await's default behavior of resuming continuations on the captured SynchronizationContext, which for WPF is dispatcher-based and automatically returns you to the UI thread after an awaited background operation.

   Application.Current.Dispatcher.Invoke(() => statusLabel.Text = "Done");

9. What's the difference between styles and templates in WPF?

   A Style sets property values (and can attach triggers/event setters) on an existing control without changing its visual structure — e.g., setting Background, FontSize, and Margin consistently across all Buttons of a certain type, similar in spirit to CSS. A ControlTemplate completely replaces a control's visual tree/rendering structure while preserving its behavior and API — e.g., redefining what a Button actually looks like (shape, layout of its parts) while it still functions as a clickable button responding to the same commands and events. A DataTemplate (related but distinct) defines how to visually represent a piece of *data*, not a control. In short: Style = "how existing visuals are styled," Template = "what the visual structure itself is."

10. What are resource dictionaries, and how does resource lookup work?

    A ResourceDictionary is a keyed collection of reusable objects — brushes, styles, templates, converters — declared once in XAML and referenced elsewhere via {StaticResource Key} (resolved once at load time) or {DynamicResource Key} (resolved lazily and re-resolved if the resource changes, at a small performance cost). Resources can be scoped at the element level (<Grid.Resources>), Window/UserControl level, or merged at the Application level via App.xaml's MergedDictionaries, and lookup walks up the visual/logical tree from the requesting element to the nearest matching key, falling back to Application-level resources last. This enables centralizing a design system's colors, styles, and templates in shared dictionaries that multiple views merge in, keeping visual consistency without duplicating markup.

11. What is `INotifyPropertyChanged`, and why is it essential in MVVM?

    INotifyPropertyChanged is a single-method interface (event PropertyChangedEventHandler PropertyChanged) that a bindable ViewModel implements so WPF's binding engine knows when a property value changed and needs to refresh the UI. Without raising this event on every property setter, OneWay/TwoWay bindings would only pick up the value present at binding time and never update afterward as the ViewModel's data changes programmatically. The convention is to raise it inside each property setter, typically via a shared helper to avoid repeating boilerplate, passing the changed property's name (often via [CallerMemberName] to avoid magic strings). Most ViewModel base classes provide a reusable SetProperty helper for exactly this purpose.

    private string _name;
    public string Name
    {
        get => _name;
        set { _name = value; OnPropertyChanged(); } // raises PropertyChanged(nameof(Name))
    }

12. What are attached properties, and what's a canonical use case?

    An attached property is a special kind of dependency property that can be set on *any* DependencyObject, not just the type that defines it, using the syntax <Element OwnerType.PropertyName="value" />. It's registered via DependencyProperty.RegisterAttached and lets a parent-oriented concept "attach" metadata to arbitrary children — the canonical example is Grid.Row/Grid.Column, where Grid defines the property but any child element placed inside a Grid can set it to declare its own cell position, even though Grid.Row has nothing to do with the child element's own type. Other common examples include Canvas.Left/Top, DockPanel.Dock, and Panel.ZIndex. Attached properties are also frequently used to add MVVM-friendly "attached behaviors" to controls that don't natively expose the hook you need (e.g., binding a command to a non-command event).

More prep guides on the AI Interview Bot blog.