How do we think in terms of interfaces for everything when we are writing code?
Some of the other answers have touched on proper courses of design, but the unstated assumption in the question is subtle and flawed and deserves to be dragged kicking and screaming into the harsh light of day.
YOU WRITE THE TEST FIRST
It's common to read about TDD and think 'yeah that is a great idea' and then not do it. Instead, it's easy to fall back into code-first habits, and then wonder how you're supposed to think of all of the required and convenient interfaces as you're writing the code. Ya don't!
NO, SRSLY, WRITE THE TEST FIRST
Writing the test first forces you to invent the interface before you write the code. So you're not thinking about the code at all, you're thinking about the interface to test the code.
TDD IS NOT UNIT TESTING
TDD tests features, not units. Feel free to add unit testing and code coverage et al if you want, but all TDD requires is that every feature has automated tests. [But look into BDD for even easier test specification]
This process will create the interfaces, get the code working, then refine the interfaces and the code, incrementally.
If you find during the refactoring step that, say, dependency injection (DI) would simplify the design, great, use it. But don't start with DI or any other tactic/technique as a preferential hammer. Let the code be your guide, and let the design evolve naturally, one test at a time.