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

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.