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.
// 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.
Practice what you learned
1. What capability does a DependencyProperty provide that a plain CLR-backed property does not?
2. Why might a DataGrid bound to ObservableCollection<Person> fail to refresh a cell after Person.Name is changed in code?
3. What is the fundamental difference between a Style and a ControlTemplate?
4. What is TemplateBinding primarily used for?
5. Why do DependencyObjects have thread affinity?
Was this page helpful?
You May Also Like
Debugging XAML Bindings
Practical techniques for diagnosing and fixing broken data bindings in XAML applications, from reading Output window trace errors to using Snoop and Live Visual Tree.
Common XAML Pitfalls
A tour of the most frequent mistakes XAML developers make with resource lookup, StaticResource vs DynamicResource, and layout sizing, plus how to fix each one.
XAML Quick Reference
A condensed, at-a-glance reference for XAML markup extensions, layout panels, binding modes, and attached properties for fast lookup while coding.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics