1. The solution to a problem should only be OOP if the problem calls for OO solutions. Don't fall into the trap of sledge-hammering everything with objects. A classic example is logging: debug logging is generally best left to free functions rather than objects, for example. Some of this will vary with individual tastes, and you will find people rabidly arguing for one way or another, but in general your best bet is to just do the simplest thing that you think will work. As you gain experience and work on ever-larger code bases, you will discover for yourself a good set of instinctive rules for when to use what kind of solution. Always be mindful of that itch in the back of your brain that says "there has to be a better way" - it's usually right.

2. "Paradigms" are as numerous as political opinions and just as difficult to discuss in civilized company without devolving into heated screaming matches. I'm a big advocate of the "just get shit done" paradigm. Think about how to build your code in a way that solves the problem at hand - again, don't fall into the trap of smacking everything within reach with a single hammer just because that's the only tool you know. Worrying too much about whether or not you're conforming to a "paradigm" is wasted time.

3. Most shops have gone to C++ these days. There are still places where C is king, but they are dwindling. Mixing the two is generally a sign of bad technical leadership.

4. See answer to #3.

5. There are often limitations imposed - either by the tools being used, or artificially by the team leadership. For instance, heavy use of template metaprogramming is often forbidden, either because the platform's compilers can't cope with it, or (more commonly) because most programmers have better things to do than wade through a bunch of template errors every time they spell something wrong.