Concept questionHard~9 min

Interview question

How would you collect or aggregate results from parallel work without introducing a new race condition?

Aggregate results from parallel work safely

Uses reduction, thread-local state, atomic scalar updates, or indexed output instead of mutating a shared collection from parallel workers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would avoid calling List<T>.Add or mutating one normal dictionary from multiple workers. If every input has a known output index, workers can write distinct slots in a preallocated array. For a scalar counter or sum, an Interlocked operation may be enough. For richer aggregation, I would prefer local accumulators per partition and combine them at the end, or use a supported PLINQ aggregate. A concurrent collection is useful when unordered item collection is the real requirement, but it still has synchronization cost.

Full answer below

Practice focus

Parallel reduction, thread-local accumulators, concurrent collections, indexed output, Interlocked, associativity, determinism, and merge overhead.

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
Parallel computation is often correct until every worker writes into the same result object. The aggregation strategy is part of the algorithm, not cleanup after parallelization.
I would avoid calling List<T>.Add or mutating one normal dictionary from multiple workers. If every input has a known output index, workers can write distinct slots in a preallocated array. For a scalar counter or sum, an Interlocked operation may be enough. For richer aggregation, I would prefer local accumulators per partition and combine them at the end, or use a supported PLINQ aggregate. A concurrent collection is useful when unordered item collection is the real requirement, but it still has synchronization cost.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, Parallel.ForEach supports thread-local initialization, a local update for each iteration, and a final merge under a narrow synchronization boundary. That avoids one global lock on every item. The combine operation must be safe and ideally associative, because partition order may vary. If result order matters, indexed output or a separate ordering step is usually clearer than locking around append order. I would also estimate memory: per-partition buffers can improve contention while increasing allocation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define determinism and partial-result behavior explicitly. Floating-point sums can differ by grouping order, duplicate keys need a merge rule, and a failure halfway through may leave a concurrent collection full of results that should not be published. I would benchmark local reduction against concurrent structures and sequential aggregation because the merge can erase the speedup. Cancellation should stop new work and prevent an incomplete aggregate from looking final. I would include skewed partitions and duplicate-heavy input in tests because those cases expose merge contention and ambiguous conflict rules. For large output, streaming partitions to bounded downstream consumers may be safer than retaining every result in memory.

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

Writing to List<T> or a normal dictionary from parallel iterations.
Putting one lock around every result update and eliminating useful parallelism.
Using a reduction whose result changes unacceptably with partition order.
Publishing a partially built aggregate after cancellation or failure.

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

Details

The computation is parallel but the aggregation has no thread-safety story.
Ordering requirements appear only after an unordered collection is chosen.
Memory cost of local buffers is ignored.
No sequential aggregation baseline is measured.

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 a concurrent collection the right answer?
Why does associativity matter for parallel reduction?
How would you preserve output order efficiently?

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.

Interlocked vs lock

Concept questionHard~9 min

Interview question

How would you collect or aggregate results from parallel work without introducing a new race condition?

Aggregate results from parallel work safely

Uses reduction, thread-local state, atomic scalar updates, or indexed output instead of mutating a shared collection from parallel workers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Parallel reduction, thread-local accumulators, concurrent collections, indexed output, Interlocked, associativity, determinism, and merge overhead.

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
Parallel computation is often correct until every worker writes into the same result object. The aggregation strategy is part of the algorithm, not cleanup after parallelization.
I would avoid calling List<T>.Add or mutating one normal dictionary from multiple workers. If every input has a known output index, workers can write distinct slots in a preallocated array. For a scalar counter or sum, an Interlocked operation may be enough. For richer aggregation, I would prefer local accumulators per partition and combine them at the end, or use a supported PLINQ aggregate. A concurrent collection is useful when unordered item collection is the real requirement, but it still has synchronization cost.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, Parallel.ForEach supports thread-local initialization, a local update for each iteration, and a final merge under a narrow synchronization boundary. That avoids one global lock on every item. The combine operation must be safe and ideally associative, because partition order may vary. If result order matters, indexed output or a separate ordering step is usually clearer than locking around append order. I would also estimate memory: per-partition buffers can improve contention while increasing allocation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define determinism and partial-result behavior explicitly. Floating-point sums can differ by grouping order, duplicate keys need a merge rule, and a failure halfway through may leave a concurrent collection full of results that should not be published. I would benchmark local reduction against concurrent structures and sequential aggregation because the merge can erase the speedup. Cancellation should stop new work and prevent an incomplete aggregate from looking final. I would include skewed partitions and duplicate-heavy input in tests because those cases expose merge contention and ambiguous conflict rules. For large output, streaming partitions to bounded downstream consumers may be safer than retaining every result in memory.

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

Writing to List<T> or a normal dictionary from parallel iterations.
Putting one lock around every result update and eliminating useful parallelism.
Using a reduction whose result changes unacceptably with partition order.
Publishing a partially built aggregate after cancellation or failure.

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

Details

The computation is parallel but the aggregation has no thread-safety story.
Ordering requirements appear only after an unordered collection is chosen.
Memory cost of local buffers is ignored.
No sequential aggregation baseline is measured.

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 a concurrent collection the right answer?
Why does associativity matter for parallel reduction?
How would you preserve output order efficiently?

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.

Interlocked vs lock

How would you collect or aggregate results from parallel work without introducing a new race condition?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

How would you collect or aggregate results from parallel work without introducing a new race condition?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper