Silverlight Interview Questions

Analogy categoryAnalogies

Preparing for Silverlight Interview Questions

Silverlight interviews, whether for greenfield work in its heyday or for maintaining legacy line-of-business applications today, typically probe four areas: understanding of the plug-in runtime model, XAML and data binding fluency, threading and asynchronous programming discipline, and awareness of the platform's constraints compared to WPF and full .NET. Interviewers use these questions less to test rote memorization and more to see whether a candidate has actually built and debugged something real in the framework.

🏏

Cricket analogy: A county selection trial checks a bowler's pace, control, variation, and fitness together rather than just one skill in isolation, similar to how Silverlight interviews probe runtime knowledge, XAML, threading, and platform limits together.

Runtime and Architecture Questions

A frequent opening question is: 'What is Silverlight, and how does it differ from WPF?' A strong answer explains that Silverlight is a browser plug-in runtime containing a scaled-down version of the .NET CLR and a subset of WPF's XAML rendering engine, installed separately from the browser and executed inside a sandboxed process. Unlike WPF, which runs as a full desktop application with unrestricted file system access, Silverlight code runs in partial trust by default, restricting file system access to isolated storage, requiring cross-domain policy files for network calls, and lacking features like 3D rendering (in early versions) or full Win32 interop.

🏏

Cricket analogy: A club-level net session with restricted equipment and a curator watching closely is a scaled-down version of a full international match, similar to Silverlight being a sandboxed, restricted subset of the full WPF/.NET desktop environment.

Data Binding and Threading Questions

Interviewers commonly ask 'What is the difference between OneWay, TwoWay, and OneTime binding, and what is the default for most properties?' The correct answer is that OneWay pushes source-to-target updates only, TwoWay pushes updates in both directions, and OneTime reads the source value once and never updates again; most dependency properties default to OneWay, though editable controls like TextBox.Text default to TwoWay. A related favorite is 'Why would background thread code throw an exception when updating a ProgressBar, and how do you fix it?' — the expected answer covers UI thread affinity and using Dispatcher.BeginInvoke to marshal the update safely.

🏏

Cricket analogy: A one-way radio broadcast from the commentary box to fans' earpieces sends information only outward, just as OneWay binding pushes source-to-target only without listening back.

csharp

// Sample interview-style question: fix the bug.
void worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    // BUG: this runs on a background thread and throws UnauthorizedAccessException.
    ProgressBar.Value = e.ProgressPercentage;
}

// Fixed version:
void worker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    Dispatcher.BeginInvoke(() => ProgressBar.Value = e.ProgressPercentage);
}

When answering threading questions in an interview, always name the specific exception (UnauthorizedAccessException) and the specific fix (Dispatcher.BeginInvoke). Vague answers like 'you need to sync the threads' signal to the interviewer that the candidate hasn't actually hit this bug in real code.

Platform and Deployment Questions

A useful closing question is 'How does a Silverlight application communicate with a backend service, and what constraints apply?' Strong candidates mention that Silverlight typically consumes WCF services (via a generated service reference producing async-only proxy methods) or plain REST/JSON endpoints via WebClient or HttpWebRequest, and that any cross-domain call requires a clientaccesspolicy.xml hosted at the target server's root. They should also be able to explain what a .xap file is and why minimizing its size and the number of assemblies referenced matters for load time, since this shows practical deployment awareness beyond textbook knowledge.

🏏

Cricket analogy: A touring team must clear customs and get ground clearance before playing on foreign soil, similar to a Silverlight app needing a clientaccesspolicy.xml before it can call a cross-domain service.

Avoid answering 'How does Silverlight call a backend service' with only 'it uses WCF' — that's incomplete. A strong answer distinguishes async-only proxy methods, REST/JSON alternatives via WebClient, and the cross-domain policy requirement, since interviewers use this question specifically to separate candidates who read documentation from those who've actually shipped a Silverlight app.

Silverlight interviews typically span runtime architecture, XAML/binding, threading, and deployment/platform constraints.
Be ready to explain Silverlight as a sandboxed, partial-trust browser plug-in runtime distinct from full-trust WPF desktop apps.
Know the three binding modes precisely: OneWay, TwoWay, and OneTime, and their defaults.
Always name UnauthorizedAccessException and Dispatcher.BeginInvoke when answering threading questions.
Explain backend communication concretely: async WCF proxies or WebClient/HttpWebRequest REST calls.
Mention the clientaccesspolicy.xml requirement whenever cross-domain communication comes up.
Demonstrate practical deployment awareness by discussing .xap size and assembly reference minimization.