Architecture scenarioMedium~10 min

Interview question

If nullable reference types are enabled, can a string still be null at runtime? How would you design a reliable boundary around that?

Nullable reference types and runtime validation

Uses nullable annotations as a compile-time contract while still validating untrusted and legacy runtime inputs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Yes, a variable declared as non-nullable string can still receive null at runtime through deserialization, reflection, older assemblies, disabled nullable context, or an incorrect null-forgiving operator. Nullable annotations tell the compiler and callers what the code intends, and flow analysis warns about paths that may violate that intent. I still validate untrusted input at the API or message boundary. After validation, I map it into a domain type whose constructor or factory preserves the non-null invariant.

Full answer below

Practice focus

Nullable flow analysis, annotations, warnings, null-forgiving use, external input validation, legacy code, serialization, and domain invariants.

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
Nullable reference types improve the compiler's model; they do not change the CLR representation or sanitize values arriving from outside the annotated code.
Yes, a variable declared as non-nullable string can still receive null at runtime through deserialization, reflection, older assemblies, disabled nullable context, or an incorrect null-forgiving operator. Nullable annotations tell the compiler and callers what the code intends, and flow analysis warns about paths that may violate that intent. I still validate untrusted input at the API or message boundary. After validation, I map it into a domain type whose constructor or factory preserves the non-null invariant.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a request DTO can use nullable properties to represent fields that may be absent in incoming JSON, even when the domain requires them. Validation checks presence and format, then creates a CustomerName or command with non-null values. Marking the DTO property string = null! can silence initialization warnings, but it does not prove the serializer supplied a value. Attributes such as NotNullWhen and MemberNotNull can teach flow analysis about helper methods when the runtime guarantee is real and tested.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat warnings as design feedback and keep nullable enabled across projects so contracts do not disappear at assembly boundaries. I use ! only where another mechanism has established the invariant and a short explanation would survive review; broad suppression hides defects. Generic code needs attention to T?, class?, and notnull because meaning depends on constraints and nullable context. Public libraries can expose nullable metadata to consumers, but runtime guards remain useful for externally callable APIs. In production I would monitor validation failures separately from unexpected NullReferenceException, because one is rejected input and the other signals a broken internal invariant.

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

Assuming nullable annotations prevent the CLR from storing null.
Using null-forgiving operators throughout mapping code instead of validating once.
Declaring request fields non-nullable and assuming deserialization enforces required input.
Disabling warnings because a legacy boundary has incomplete annotations.

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

Details

Cannot name a runtime path that bypasses nullable flow analysis.
Uses empty strings as universal replacements for missing required values.
Lets nullable DTO state leak deep into the domain model.
Suppresses warnings without identifying the established invariant.

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 the null-forgiving operator justified?
How would you model an optional field versus a required input field?
What do nullable attributes such as NotNullWhen communicate?

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

Opening drill

Architecture scenarioMedium~10 min

Interview question

If nullable reference types are enabled, can a string still be null at runtime? How would you design a reliable boundary around that?

Nullable reference types and runtime validation

Uses nullable annotations as a compile-time contract while still validating untrusted and legacy runtime inputs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Nullable flow analysis, annotations, warnings, null-forgiving use, external input validation, legacy code, serialization, and domain invariants.

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
Nullable reference types improve the compiler's model; they do not change the CLR representation or sanitize values arriving from outside the annotated code.
Yes, a variable declared as non-nullable string can still receive null at runtime through deserialization, reflection, older assemblies, disabled nullable context, or an incorrect null-forgiving operator. Nullable annotations tell the compiler and callers what the code intends, and flow analysis warns about paths that may violate that intent. I still validate untrusted input at the API or message boundary. After validation, I map it into a domain type whose constructor or factory preserves the non-null invariant.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a request DTO can use nullable properties to represent fields that may be absent in incoming JSON, even when the domain requires them. Validation checks presence and format, then creates a CustomerName or command with non-null values. Marking the DTO property string = null! can silence initialization warnings, but it does not prove the serializer supplied a value. Attributes such as NotNullWhen and MemberNotNull can teach flow analysis about helper methods when the runtime guarantee is real and tested.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat warnings as design feedback and keep nullable enabled across projects so contracts do not disappear at assembly boundaries. I use ! only where another mechanism has established the invariant and a short explanation would survive review; broad suppression hides defects. Generic code needs attention to T?, class?, and notnull because meaning depends on constraints and nullable context. Public libraries can expose nullable metadata to consumers, but runtime guards remain useful for externally callable APIs. In production I would monitor validation failures separately from unexpected NullReferenceException, because one is rejected input and the other signals a broken internal invariant.

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

Assuming nullable annotations prevent the CLR from storing null.
Using null-forgiving operators throughout mapping code instead of validating once.
Declaring request fields non-nullable and assuming deserialization enforces required input.
Disabling warnings because a legacy boundary has incomplete annotations.

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

Details

Cannot name a runtime path that bypasses nullable flow analysis.
Uses empty strings as universal replacements for missing required values.
Lets nullable DTO state leak deep into the domain model.
Suppresses warnings without identifying the established invariant.

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 the null-forgiving operator justified?
How would you model an optional field versus a required input field?
What do nullable attributes such as NotNullWhen communicate?

Continue practice

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

If nullable reference types are enabled, can a string still be null at runtime? How would you design a reliable boundary around that?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

If nullable reference types are enabled, can a string still be null at runtime? How would you design a reliable boundary around that?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice