How are extension methods resolved and when should you use them? Explain how the compiler binds them, why instance methods always win, null receivers, ref extension methods on structs, the C# 14 extension block syntax for extension properties and static members, and the design mistakes extension methods invite.

How I would answer this in an interview

Extension methods are static methods that the compiler lets you call as if they were instance methods on another type. They're how LINQ adds operators to IEnumerable<T>, how ASP.NET Core builds fluent configuration (services.AddX(), app.UseY()), and how you add convenience to types you don't own. I'd explain binding rules, why instance methods win, null receivers, ref extensions on structs, the C# 14 extension block syntax, and the design mistakes they invite.

1. Declaring and binding

namespace Ordering.Extensions;

public static class MoneyExtensions
{
    public static decimal WithGst(this decimal amount, decimal rate = 0.10m) => decimal.Round(amount * (1 + rate), 2);
}

using Ordering.Extensions;
var gross = 100m.WithGst();      // compiled as MoneyExtensions.WithGst(100m)

Rules: a static method in a non-generic, non-nested static class, with this on the first parameter.

How the compiler binds receiver.Method(args):

1. Look for instance members named Method on the receiver's type (and base types/interfaces). If any applicable instance method exists, use it — extension methods aren't considered.
2. Otherwise, search for extension methods in enclosing namespaces, from the innermost outwards, then using directives at each level. At the first scope containing applicable candidates, run overload resolution among them; stop there.
3. Ambiguity between equally good extensions in the same scope → CS0121.

Binding is compile-time and based on the receiver's static type — no virtual dispatch.

2. Why instance methods always win

It protects types from having their behaviour changed by someone else's extension: if List<T> has Contains, a Contains extension can never hijack calls on a List<T>. The flip side: if a library later adds an instance method with the same name and compatible signature, your extension silently stops being called on the next compile — behaviour can change without any code change on your side.

3. Null receivers

Because an extension call is just a static call, the receiver can be null:

public static bool IsBlank(this string? s) => string.IsNullOrWhiteSpace(s);
string? name = null;
name.IsBlank();   // true, no NullReferenceException

Useful for null-tolerant helpers, but it can mislead readers (it looks like an instance call that should throw). Validate (ArgumentNullException.ThrowIfNull) unless null-tolerance is the explicit purpose, and annotate nullability.

4. ref extension methods on structs (C# 7.2)

public static void Advance(ref this Cursor cursor, int count) => cursor.Position += count;   // mutates caller's struct
public static int Remaining(in this Cursor cursor) => cursor.Length - cursor.Position;     // no copy (readonly struct)

• ref this lets an extension mutate the caller's struct in place (receiver must be a variable, not an rvalue).
• in this avoids copying large readonly structs.
• Only allowed for value types (ref this requires struct constraint for generic receivers).

5. C# 14 extension blocks

C# 14 introduces a new syntax that groups extension members by receiver and supports extension properties, static extension members and operators:

public static class EnumerableExtensions
{
    extension<T>(IEnumerable<T> source)
    {
        public bool IsEmpty => !source.Any();                                    // extension property
        public IEnumerable<T> WhereNotNull() => source.Where(x => x is not null);  // extension method
    }

    extension<T>(IEnumerable<T>)
    {
        public static IEnumerable<T> Empty => [];                                // static extension member
    }
}

if (orders.IsEmpty) return;
var none = IEnumerable<Order>.Empty;

The old this-parameter syntax still works and is binary compatible; the new syntax compiles to similar static methods plus metadata. Extension properties are still computed — they can't add state to the type.

6. Design mistakes extension methods invite

• Business logic in extensions (order.CalculateDiscount() in a utilities namespace) — hard to find, can't access private state, multiple competing versions.
• Hidden I/O (customer.LoadOrders()) disguised as a cheap member call.
• Polluting IntelliSense: extensions on object, string or unconstrained T in common namespaces appear everywhere.
• Duplicate/ambiguous extensions across libraries (ToJson, ToSlug), with behaviour depending on which using is in scope.
• Fragility when the extended type later adds an instance member.
• Testing/mocking: static, so callers can't substitute them — fine for pure helpers, bad for anything with dependencies.

Good uses: fluent configuration (IServiceCollection, IApplicationBuilder), LINQ-style operators, adapters/convenience over types you don't own, and domain-specific helpers on value objects in a clearly named namespace.

7. A production example

Two shared libraries both defined string ToSlug(this string) with different rules; which one ran depended on using order per file, so product URLs differed between the website and the sitemap generator, breaking SEO links. We consolidated into one implementation in a dedicated namespace, banned the duplicate via BannedSymbols.txt, and added tests comparing slugs across services.