I believe your line of thinking is wrong.. interfaces are meant to act as "interfaces" in the traditional definition of the word, they are for providing an interface between groupings of code (for lack of a better phrase) that are mean to be loosely coupled from one another. They are defining a contract between these groupings so that the one grouping that uses the object implementing the interface doesn't have intimate knowledge of the other grouping of code. For example, if a project uses a 3rd party library, of which only a few features are being used, yet they know they are most likely going to replace this with another 3rd party library at some point, it would make sense to write an interface that wraps around this library. Then, it is easier later on to replace the 3rd party library by simply writing a new implementation wrapper.

I can understand that you don't like candidates not going into detail but I have worked on projects where using interfaces, even if there is not more than one implementation is still best practice as otherwise you are just hard-coupling your dependencies.