XAML Interview Questions

Analogy categoryAnalogies

Core Concepts Interviewers Probe First

Almost every XAML interview opens with the difference between a CLR property and a DependencyProperty: a DependencyProperty is registered with the property system via DependencyProperty.Register, stored in an efficient sparse dictionary rather than as a normal field, and gains data binding, styling, animation, and value-inheritance support for free — none of which a plain CLR-backed property gets. A strong candidate can also explain why DependencyObject-derived classes must be accessed from the thread that created them (the Dispatcher/UI thread affinity) and what happens if you try to mutate one from a background thread.

🏏

Cricket analogy: It's like the difference between a player's informal net-session stats that only the coach jots in a notebook versus stats officially registered with the ICC that feed into rankings, DRS reviews, and broadcast graphics — DependencyProperty registration unlocks the whole surrounding system the way official registration unlocks rankings infrastructure.

csharp

// DependencyProperty registration boilerplate
public static readonly DependencyProperty ValueProperty =
    DependencyProperty.Register(
        nameof(Value),
        typeof(double),
        typeof(GaugeControl),
        new PropertyMetadata(0.0, OnValueChanged));

public double Value
{
    get => (double)GetValue(ValueProperty);
    set => SetValue(ValueProperty, value);
}

Bindings, Converters, and the MVVM Pattern

Interviewers frequently ask candidates to explain INotifyPropertyChanged versus INotifyCollectionChanged, and why a ViewModel property setter must raise PropertyChanged for a bound TextBlock to refresh, while an ObservableCollection raises CollectionChanged automatically on Add/Remove but not on a property change of an item inside it — a very common trip-up where a list bound to ObservableCollection<Person> doesn't refresh when Person.Name changes unless Person itself implements INotifyPropertyChanged. Expect follow-up questions on IValueConverter versus IMultiValueConverter, and on why converters should be stateless and culture-aware via the ConvertBack/culture parameter rather than hardcoding formats.

🏏

Cricket analogy: It's like a scoreboard that automatically updates when a new player walks in (Add) but doesn't automatically update if that player's name is corrected mid-innings unless someone explicitly re-announces it — the collection change and the item's own property change are two separate notification events.

A classic interview gotcha: binding a DataGrid to ObservableCollection<Person> and mutating Person.Name in code will not refresh the grid cell unless Person implements INotifyPropertyChanged and raises PropertyChanged(nameof(Name)) — ObservableCollection only notifies about the collection's membership, never about its items' internals.

Templates, Styles, and Control Composition

Expect questions distinguishing Style from ControlTemplate: a Style sets property values (and can trigger on property/state changes) on an existing control's exposed properties, while a ControlTemplate replaces the entire visual tree that renders the control, which is how you can make a Button look like a circular icon button while keeping all of its click, focus, and command behavior intact via TemplateBinding. A strong candidate should also be able to explain TemplatePart/TemplatedParent, and why TemplateBinding is a lighter-weight one-way alternative to {Binding RelativeSource={RelativeSource TemplatedParent}} used specifically inside ControlTemplates.

🏏

Cricket analogy: It's like the difference between changing a team's kit colors (Style — surface properties) versus completely re-drafting the entire batting lineup and fielding formation while keeping the same team name and league rules intact (ControlTemplate — the whole visual structure changes, behavior stays).

A common interview trap: candidates say Style and ControlTemplate are interchangeable. They aren't — a Style cannot add new visual elements or restructure the control's parts, it can only set property values and define triggers on the control's existing, exposed dependency properties.

DependencyProperty registration (vs a plain CLR property) unlocks data binding, styling, animation, value inheritance, and change notification support built into the property system.
DependencyObjects have thread affinity — they must be created and accessed from the Dispatcher/UI thread that owns them.
ObservableCollection notifies about Add/Remove/membership changes only; item-level property changes require the item itself to implement INotifyPropertyChanged.
IValueConverter handles single-value transforms; IMultiValueConverter combines multiple bound values into one target value.
Style sets property values and triggers on a control's existing exposed properties; ControlTemplate replaces the entire visual tree while preserving behavior.
TemplateBinding is a lightweight one-way shortcut for binding a template part's property back to the templated control's property, commonly used only inside ControlTemplates.
Interviewers often probe with a concrete gotcha scenario (like the ObservableCollection item-change trap) rather than pure definitions, so practice explaining the 'why' with an example.