Spotting and fixing errors is obviously an important part of a developer day-to-day, but shouldn't be used alone for the purpose of technical evaluation.
Fixing errors (or bugs) can be hard and tricky, but we can split them in 2 main types:
- Compile time
- Runtime
If you have a solid understanding of the language in question, you should be able to quickly figure out most of the compile time errors, mainly in a small snippet.
Runtime errors are generally trickier, but in C you should be able to spot a simple index out of bound, a NULL (or dangling) pointer dereference, double frees, infinite loops, wrong conditionals, and so on. Of course, here we're not talking about gigantic complex code. Even though snippets can be extremely complex, I don't expect it in a interview. Mostly because I would reject any employer that prefers small-complex over simple-readable code (except when it comes to performance).
The best way to get better is practicing. I learn something nearly every day at StackOverflow, and I think the time I invested here has been reciprocated. As an example, I recently started querying the standard because it's cited so many times in questions & answers that it became impossible to get involved in some discussions without a solid reference to back me up.
To conclude, I seriously doubt this "interview method" is effective, unless the employer looks for someone to fix bugs exclusively. Otherwise, restricting the technical evaluation to such test means the employer is ignoring more important skills.