No, programming against interfaces has nothing to do with whether or not you use header files.
Defining an interface explicitly will allow evolving the program on both sides independently. The 'interface' of a code body denotes the contract to which it obeys.
Programming languages never fully support interface definitions, they merely have some syntactic sugar to handle the type-correctness aspect. Performance aspects, for one, are most of the time unspecificable, just like complexity rules etc... (C++ standard defines some complexity requirements for the containers and algorithms).
This limited support has left Java with the keyword
interface: since object orientation is about grouping functionality into classes, it made sense to couple the concept of an 'interface' to something that groups member function definitions. Several classes can implement a given interface, and a class can implement many interfaces as well.
In C++, they didn't even bother to explicitly add 'interface' to the language. The thing that comes closest to the 'class interface' of Java is a pure abtract class: a class with only pure virtual member functions. Since C++ supports multiple inheritance, classes can implement multiple of these 'interfaces'.
When it comes to the separation of your code into headers and source files, that's totally irrelevant to the interface concept. But indeed: in C++, the 'calling contract' is mostly specified in a header file. And indeed, that makes for shorter compilation times (less IO). But that's a compiler-technical aspect.