Writing a C compiler seems like one of those standard undergrad activities. If a programmer can make that work, they probably have sufficient organizational skills. It seems like real-time, distributed, multi user app development is a separate filter.
I guess it's the distinction between looking for someone who is capable of solving those problems vs looking for someone who has solved those problems.
If the threads have to stop, it's still concurrency in the sense that threads are stopped in arbitrary places (just like an interrupt can stop a task at any point in its execution and dispatch another task or whatever).
But the garbage collector isn't running concurrently with the threads.
I.e. I think the term "concurrent garbage collector" is understood to be in contrast with "stop-the-world garbage collector" not with "synchronous garbage collector as a library function in a single-threaded virtual machine".
But there are a number of algorithms that most people would probably consider "real GC" that don't stop the world. Modern Java GCs use the train algorithm [2], which bounds pause times to some arbitrarily-sized constant. Erlang per-process heaps [3] also give good soft-real-time characteristics.
It is theoretically possible to run the whole GC in a background thread (eg. while a GUI is idle). Both the JVM and the CLR have options for this [4][5], but they're only useful for workloads with large pause times (eg. GUI apps, lightly-loaded servers) and so aren't enabled by default.
[1] http://researcher.watson.ibm.com/researcher/files/us-bacon/B...
[2] http://www.ssw.uni-linz.ac.at/General/Staff/TW/Wuerthinger05...
[3] http://prog21.dadgum.com/16.html
[4] http://www.oracle.com/technetwork/java/javase/gc-tuning-6-14...
[5] https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110)....
Compilers have been developed by lone developers in isolation. Some compilers are only a few thousand lines of code.
Someone who can demonstrate knowledge of making a compiler could well be completely behind in their knowledge about language design. He or she shows how calculations are turned into a tree and then into code on a register machine (i.e. "for-mula tran-slation"). But no idea how to compile exception handling, closures, and doing advanced things with type (beyond just checks) and such.
That is to say, the bar for what can be legitimately called a compiler is quite low.
On the topic of languages, I'd rather interview someone who knows about a lot of modern language features and how they can contribute to the improvement of program organization, yet is foggy about the details of how some of them are might be compiled to machine code.
There is still "compiler worship". On a previous job, I fixed a code generation bug in gcc affecting MIPS targets. Everyone was talking about that: "like wow, he fixed gcc".