This is a response of sorts to the position that "this is a code for programmers who work close to the metal and is OK in a management context" seen in some of the other answer and comments.
I'd argue that even that interpretation should be taken with care.
Starting by at least the mid '90s if you wanted a C++ programmer and someone who described themselves as a C programmer applied you'd have had to ask how much they know about object oriented design, how much experience they have with debugging in an object oriented context, and about their ability to use template libraries. You'd want to probe exactly those issues during the interview and hiring process.
On the flip side, it has now been more than a decade since C++ gurus started pushing "modern C++" meaning a emphasis on moving away from bare pointers to safer pointer objects and iterator-based idioms. With the emergence of C++11 there is now explicit support for multi-paradigm programming and the push toward code that exhibits no bare pointers is very strong. What that means is that if I interviewed a C++ programmer for a C position today I'd be very concerned about checking how familiar this person was with actual, foot-shooting-enabled pointers.
I'm not in the business these days (even to the degree that I was when Stack Overflow was in its infancy), so I won't venture a guess at how often either imaginary interviewee would not have the cross-over skills, but I think that as most often applied the languages are now very different indeed.
In short "C/C++" should be dropped not only in technical contexts but in most business contexts as well.