The wider problem is that to do a thing you have to start thinking about the design of IDoAThing and a implementation ThingDoer before you've even worked out exactly what to do yet.
C# does want to have interfaces though, and gravitates to the common interfaces - core services - composition/DI root architecture, with lots of projects in the solution to provide separation of concerns. I think it works very well generally for business software at least, but I hear plenty of grumbling about 'complexity' so it's not for everyone.
There is no requirement to define new interfaces except for a specific coding style in a team. It is best for most components to stay as plain and simple as possible, and for the module and component level testing to be applied with as little mocking as possible (because, most of the time, it is an anti-pattern imposed on us by what is sometimes named "London's school of testing" which is just bad practice and whoever perpetuates it should apologize).