At my job we're disqualifying candidates who don't use enough unnecessary classes. I didn't use them, but they proceeded with my interview because I happened to use some other tricks that showed good knowledge of C++. I think the candidate who just wrote the code to solve the task was the best solution, but I'm not in charge of hiring.
Without revealing the actual interview task, let's pretend it was to write a program that lowpass filters a .wav file. The answer we're apparently looking for is to read the input into a vector, FFT it, zero out the second half, unFFT it, and write the output file. And you must have a class called FFT, one called File, FrequencyDomainFile, and InverseFFT. Because that's simple logical organization of code, right? Meanwhile, the actual simple way to do it is to open the input and output files, copy the header, and proceed through the file one sample at a time doing a convolution on a ring buffer. This latter way involves less code, less computation, less memory, and is all-around better. If you think the ring buffer is too risky, you can still do a convolution over the whole file loaded into memory, and still come out ahead of the FFT solution.
But if you do it this way, we think you didn't use enough abstraction so we reject you. Which is insane. Some time after I got this job, I found out I would have also been rejected if not for a few thoughtful comments, which were apparently some of the very few signals that "this guy knows what he's doing and has chosen not to write classes" rather than "this guy doesn't know how classes work."