What is the interface these things must have in common if they are going to be used in the same way?
If you can answer that then you are on your way to design and using the interface properly in real life scenarios.
Use interfaces when you have several things that can perform a common set of actions. How they do those actions can be different, but when as far as using the classes they act the same.
A good real world example is like a network drive vs a regular hard drive. Either way you can perform basic file operations. How they're actually done is different, but most of the time when you want to do something on a drive you don't care if it's a network drive or a physical one. That's an interface.
In hardware, different keyboards are designed differently, they (could) have buttons in different locations, but none of that matters to the computer. The computer's view of a keyboard's interface is the same regardless of any aspects other than it sends key strokes.
The goal of interfaces is to reduce coupling between components of your application. By using interface, you are binding to a contract instead of an implementation. This means that you can change the implementation as you see fit, provided you follow the same contract.
For example, it is considered good practice to use IList<T> instead of List<T>, because IList<T> only states that you need something that acts like a list. This way, other implementations of lists can be substituted without affecting your code. (For example, NHibernate, an object mapping and data access library, uses this to allow lazy loading of collections.)
Excellent candidates for interfaces are classes that interact with external systems (File system, database, network, web services, etc...). If you directly use those systems in your code, you will have trouble testing and refactoring.
I personally find interfaces especially useful in dependency injection and testing scenarios. Since you already understand what interfaces are, you should be able to understand dependency injection. Reading on those concepts will help you recognize good candidates for interfaces.
It's really something that you learn to use with experience.
I've found understanding how interfaces are used in plugin architectures really helpful.
Lots of links out there, e.g. : http://www.codeproject.com/KB/cs/c__plugin_architecture.aspx
Try to imagine how you might write that sort of architecture without using interfaces - then you might fully appreciate what they bring to the table.
If using a a TDD-like workflow, interfaces are often used to define the requirements an object has of another object that it will eventually use. Using interfaces in this fashion allows them to be used to create 'seams' in your application where logic can be replaced/inserted/etc.
One way of thinking about interfaces in this fashion is to think of your objects as sending messages to one another, and that the interfaces are the definitions of the messages that can be sent.