One of the things I like to do is ask a factual question about a technology listed on the candidate's resume that isn't required to know in order to hack something together, but is something that "you should know" if you've been working in a particular technology for a few years.
These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions.
Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.)
These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.
As someone who has worked in C# for about 8 years: you can't.
You can call `GC.Collect()` and hope. But far as I know the GC will do a best effort and gives no guarantees.
Of course that's besides that fact that I would need strong arguments to accept a `GC.Collect()` anywhere in the code. But to call it just to ensure an object is collected? Oh boy..
Depending on the case you could add some code to the `Dispose(bool)` method to know when your object is collected, but also in that case you risk flipping a Bozo bit.
These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions.
Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.)
These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.