Why Interviewers Insist on High‑Concurrency Questions

Some programmers complain that when they interview at a company whose business appears to have little high concurrency, the interviewers still keep asking about high concurrency.

This has nothing to do with whether the company actually has concurrency scenarios. One reason is the interviewer's own knowledge base; moreover, even simple business logic can contain concurrency situations.

Therefore, concurrency scenarios may exist and must be considered, otherwise failures can occur. Because concurrency is inherently difficult to grasp, it is a normal and important assessment point.

For example, consider a low‑traffic store receiving goods. Although there are few stores, when a supplier delivers, both the store manager and other staff can receive the goods.

This creates a problem: two staff members might try to receive the same shipment simultaneously. Should you account for this?

Do you use a lock, or a sequential table with a unique index, and also consider front‑end user experience?

Product managers typically do not address this; they focus only on functionality.

As a programmer, shouldn’t you think about it?

Remember, due to business nature, even very low‑traffic situations have concurrency scenarios.

Thus, interviewers need to examine this aspect.

Moreover, because concurrency itself is hard to understand, it becomes a required knowledge point.

Can you understand concurrency‑related knowledge?

If your previous projects were high‑concurrency, interviewers may ask how you handled concurrency in practice rather than probing theory.

If your past projects had low traffic, they will dig deeper into concurrency knowledge; this is a fact.

This serves as a differentiation factor: among many candidates, a solid grasp of concurrency is an important distinguishing metric.

When I lead a team and interview candidates, I always ask about concurrency. It has been a constant practice.

Here is a simple thread‑safety example focusing on locks:

Me: When multiple threads enter a synchronized block, how are they handled?

Candidate: The thread that acquires the lock can enter.

Me: What about threads that don’t get the lock?

Candidate: They are suspended.

Me: Is there a way not to be suspended?

Candidate: By spinning?

Me: Spin forever?

Candidate: There is a timeout; after it expires, the thread is suspended.

Me: … keep asking.

Candidate: Until they can’t answer.

If a candidate can answer all these questions, it’s a plus.

I also frequently ask about read‑write locks, which are not easy to understand. If you don’t study concurrency regularly, how can you master it?

This highlights an important point:

Do you regularly research technology?

This is crucial; merely delivering daily requirements is not enough. Do you have the interest to explore further?

Pay attention to your interest—have you ever tinkered with it?

The experts I have encountered love to tinker and research. Remember that.

Finally, even if a company’s business never presents concurrency, I will still ask because my own knowledge base is solid.

Besides concurrency being a mandatory assessment item, it also reflects the interviewer's personal style.

Summary: Treat concurrency as a focused interview topic and prepare thoroughly—one month is insufficient, aim for three months, or even half a year. Gradual understanding is definitely achievable.