The reason I asked him to explain sync.WaitGroup was because we were trying to discuss the homework problem which was intended to demonstrate knowledge of concurrency. "His" code used WaitGroup correctly throughout! But he wasn't able to explain how the code worked... like at all... so after 5 minutes of getting nowhere I tried to narrow down the problem space a bit and asked about WaitGroup specifically.
When I interview for C# candidates, I have a series of questions that I like to ask 1) what are `Func<T>` and `Action<T>` 2) write a function that takes a `Func<T>` or an `Action<T>` (any function; can be trivial), 3) write a function that returns one of `Func<T>` or `Action<T>`.
The reason is that over various interviews, I've noticed that candidates that can answer and write the code are going to be able to read, understand, and write the level/type of code that I expect.
I bring this up because I think when teams use projects for assessments, there are clearly certain things that you look for or you would see and be able to tell that this candidate knows what they are doing.
Rather than doing all the extra work, to me it seems like you can short circuit that process by just directly focusing on the 4-5 things that -- if you saw them while reviewing the code -- would tick the right boxes. My point here isn't necessarily `WaitGroup`, but that maybe there are some topics that the process could be reduced down to that would yield the same learnings.
