Debugging scenarioHard~12 min

Interview question

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Prevent deadlocks with consistent lock ordering

Finds circular lock acquisition and replaces timing-dependent nested locking with a stable order or a simpler ownership boundary.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would capture thread dumps or runtime traces while the process is stuck and identify which thread owns each lock and which lock it is waiting for. In the transfer example, thread A may lock account 1 then wait for account 2 while thread B locks account 2 then waits for account 1. I would make every transfer acquire account locks in one stable order, such as by account ID, regardless of transfer direction. I would also keep the critical section short and avoid I/O or blocking waits while holding either lock.

Full answer below

Practice focus

Wait-for cycles, stable lock ordering, critical-section scope, diagnostics, timeouts, nested-lock removal, and distinction from database deadlocks.

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
Deadlocks are structural cycles, not merely slow locks. A reliable answer identifies the ownership graph and removes the cycle instead of adding arbitrary delays until reproduction becomes harder.
I would capture thread dumps or runtime traces while the process is stuck and identify which thread owns each lock and which lock it is waiting for. In the transfer example, thread A may lock account 1 then wait for account 2 while thread B locks account 2 then waits for account 1. I would make every transfer acquire account locks in one stable order, such as by account ID, regardless of transfer direction. I would also keep the critical section short and avoid I/O or blocking waits while holding either lock.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The ordering rule must be centralized, because one call path that reverses it can restore the cycle. I would normalize the two resources first, acquire the lower key and then the higher key, validate the invariant, update both, and release in reverse scope through structured lock blocks. If the workflow can be redesigned so one owner processes transfers sequentially, that may be clearer than nested locks. A timeout can expose and recover from excessive waiting, but it does not prove the state is safe or remove the deadlock condition.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would instrument unusually long lock waits and capture enough context to connect resource keys, operation names, and thread stacks without logging sensitive state. I would review all nested acquisition paths and document a small lock hierarchy where nesting remains unavoidable. The stronger design often removes hold-and-wait by taking an immutable snapshot, batching an update under one aggregate lock, or handing work to a partitioned owner. Process locks cannot protect transfers across service instances; those require database transactions, optimistic concurrency, or partitioned messaging. Database deadlocks have a similar wait cycle but need transaction ordering, shorter transactions, useful indexes, and safe retry behavior rather than a C# monitor rule.

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

Adding sleeps so the two operations are less likely to overlap.
Using a timeout as proof that a partially completed transfer is safe.
Applying the ordering rule in one method while other paths acquire locks directly.
Holding account locks while calling an external service or database.

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

Details

Cannot draw the circular wait between owners and requested resources.
The proposed fix depends on which thread usually runs first.
There is no centralized acquisition rule or ownership boundary.
Conflates an in-process monitor deadlock with a database transaction deadlock.

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.

What evidence would you capture from a stuck .NET process?
When would one aggregate lock be simpler than two resource locks?
How would this design work across multiple instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Locking and Awaiting

Debugging scenarioHard~12 min

Interview question

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Prevent deadlocks with consistent lock ordering

Finds circular lock acquisition and replaces timing-dependent nested locking with a stable order or a simpler ownership boundary.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Wait-for cycles, stable lock ordering, critical-section scope, diagnostics, timeouts, nested-lock removal, and distinction from database deadlocks.

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
Deadlocks are structural cycles, not merely slow locks. A reliable answer identifies the ownership graph and removes the cycle instead of adding arbitrary delays until reproduction becomes harder.
I would capture thread dumps or runtime traces while the process is stuck and identify which thread owns each lock and which lock it is waiting for. In the transfer example, thread A may lock account 1 then wait for account 2 while thread B locks account 2 then waits for account 1. I would make every transfer acquire account locks in one stable order, such as by account ID, regardless of transfer direction. I would also keep the critical section short and avoid I/O or blocking waits while holding either lock.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The ordering rule must be centralized, because one call path that reverses it can restore the cycle. I would normalize the two resources first, acquire the lower key and then the higher key, validate the invariant, update both, and release in reverse scope through structured lock blocks. If the workflow can be redesigned so one owner processes transfers sequentially, that may be clearer than nested locks. A timeout can expose and recover from excessive waiting, but it does not prove the state is safe or remove the deadlock condition.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would instrument unusually long lock waits and capture enough context to connect resource keys, operation names, and thread stacks without logging sensitive state. I would review all nested acquisition paths and document a small lock hierarchy where nesting remains unavoidable. The stronger design often removes hold-and-wait by taking an immutable snapshot, batching an update under one aggregate lock, or handing work to a partitioned owner. Process locks cannot protect transfers across service instances; those require database transactions, optimistic concurrency, or partitioned messaging. Database deadlocks have a similar wait cycle but need transaction ordering, shorter transactions, useful indexes, and safe retry behavior rather than a C# monitor rule.

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

Adding sleeps so the two operations are less likely to overlap.
Using a timeout as proof that a partially completed transfer is safe.
Applying the ordering rule in one method while other paths acquire locks directly.
Holding account locks while calling an external service or database.

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

Details

Cannot draw the circular wait between owners and requested resources.
The proposed fix depends on which thread usually runs first.
There is no centralized acquisition rule or ownership boundary.
Conflates an in-process monitor deadlock with a database transaction deadlock.

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.

What evidence would you capture from a stuck .NET process?
When would one aggregate lock be simpler than two resource locks?
How would this design work across multiple instances?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Locking and Awaiting

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper