Architecture scenarioHard~12 min

Interview question

A .NET component discovers handlers with reflection and attributes. What are the benefits and risks, especially when the application is trimmed or Native AOT compiled?

Reflection and attributes under trimming and AOT

Uses metadata-driven behavior deliberately and protects reflection-dependent code when publishing with trimming or ahead-of-time compilation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Attributes attach metadata to program elements; reflection reads that metadata and inspects types or members at runtime. This can support plugin discovery, serialization, validation, or mapping without hard-coded registration. The cost is more runtime work, weaker compile-time guarantees, and failures that appear only when a type or constructor is missing. With trimming or Native AOT, code reached only through reflection may be removed because static analysis cannot prove it is needed.

Full answer below

Practice focus

Reflection, attributes as metadata, discovery cost, explicit registration, caching, trimming, source generation, and Native AOT compatibility.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Reflection can remove repetitive registration code, but it creates a runtime dependency that the compiler and linker may not be able to see. Deployment mode turns that convenience into a correctness boundary.
Attributes attach metadata to program elements; reflection reads that metadata and inspects types or members at runtime. This can support plugin discovery, serialization, validation, or mapping without hard-coded registration. The cost is more runtime work, weaker compile-time guarantees, and failures that appear only when a type or constructor is missing. With trimming or Native AOT, code reached only through reflection may be removed because static analysis cannot prove it is needed.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a bounded set of handlers I prefer explicit registration or a source generator that produces registration code at build time. If runtime discovery is appropriate, I scan a known assembly and contract rather than every loaded type, validate duplicates and constructors at startup, and cache the resulting delegates or descriptors. Repeating GetTypes, GetCustomAttributes, or MethodInfo.Invoke on every request adds avoidable latency and allocation. Attribute presence also does not enforce behavior by itself; some component must interpret it consistently.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For trimmed deployments I would run the publish configuration in CI, treat linker warnings as design feedback, and describe unavoidable dynamic access with targeted annotations such as DynamicallyAccessedMembers rather than broad suppression. Dependency descriptors can preserve members, but they are easy to let drift from code. Source-generated serializers, DI registration, and mapping often give better startup behavior and AOT compatibility while retaining declarative use at the source level. True runtime plugins may conflict with Native AOT's closed-world assumptions, so I would make that product requirement explicit before choosing deployment mode. I would test startup discovery and one end-to-end invocation from the actual published artifact, not only from an untrimmed debug build.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Scanning every loaded assembly on each request instead of building a startup registry.
Assuming an attribute automatically enforces the behavior it describes.
Suppressing all trimming warnings without identifying dynamically required members.
Testing reflection discovery only in an untrimmed development build.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The discovered contract has no duplicate, missing-constructor, or startup validation.
Reflection is chosen only to avoid writing a small explicit registration list.
Native AOT is promised while unrestricted runtime plugin loading remains a requirement.
Runtime invocation failures replace compile-time checks with no compensating test.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is source generation a better fit than reflection?
How do trimming annotations help static analysis?
What would you test from the published artifact?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Architecture scenarioHard~12 min

Interview question

A .NET component discovers handlers with reflection and attributes. What are the benefits and risks, especially when the application is trimmed or Native AOT compiled?

Reflection and attributes under trimming and AOT

Uses metadata-driven behavior deliberately and protects reflection-dependent code when publishing with trimming or ahead-of-time compilation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Reflection, attributes as metadata, discovery cost, explicit registration, caching, trimming, source generation, and Native AOT compatibility.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Reflection can remove repetitive registration code, but it creates a runtime dependency that the compiler and linker may not be able to see. Deployment mode turns that convenience into a correctness boundary.
Attributes attach metadata to program elements; reflection reads that metadata and inspects types or members at runtime. This can support plugin discovery, serialization, validation, or mapping without hard-coded registration. The cost is more runtime work, weaker compile-time guarantees, and failures that appear only when a type or constructor is missing. With trimming or Native AOT, code reached only through reflection may be removed because static analysis cannot prove it is needed.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a bounded set of handlers I prefer explicit registration or a source generator that produces registration code at build time. If runtime discovery is appropriate, I scan a known assembly and contract rather than every loaded type, validate duplicates and constructors at startup, and cache the resulting delegates or descriptors. Repeating GetTypes, GetCustomAttributes, or MethodInfo.Invoke on every request adds avoidable latency and allocation. Attribute presence also does not enforce behavior by itself; some component must interpret it consistently.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For trimmed deployments I would run the publish configuration in CI, treat linker warnings as design feedback, and describe unavoidable dynamic access with targeted annotations such as DynamicallyAccessedMembers rather than broad suppression. Dependency descriptors can preserve members, but they are easy to let drift from code. Source-generated serializers, DI registration, and mapping often give better startup behavior and AOT compatibility while retaining declarative use at the source level. True runtime plugins may conflict with Native AOT's closed-world assumptions, so I would make that product requirement explicit before choosing deployment mode. I would test startup discovery and one end-to-end invocation from the actual published artifact, not only from an untrimmed debug build.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Scanning every loaded assembly on each request instead of building a startup registry.
Assuming an attribute automatically enforces the behavior it describes.
Suppressing all trimming warnings without identifying dynamically required members.
Testing reflection discovery only in an untrimmed development build.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The discovered contract has no duplicate, missing-constructor, or startup validation.
Reflection is chosen only to avoid writing a small explicit registration list.
Native AOT is promised while unrestricted runtime plugin loading remains a requirement.
Runtime invocation failures replace compile-time checks with no compensating test.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is source generation a better fit than reflection?
How do trimming annotations help static analysis?
What would you test from the published artifact?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

A .NET component discovers handlers with reflection and attributes. What are the benefits and risks, especially when the application is trimmed or Native AOT compiled?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

A .NET component discovers handlers with reflection and attributes. What are the benefits and risks, especially when the application is trimmed or Native AOT compiled?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice