Functional programming is a declarative paradigm. One of the strenghts with FP is that side-effects are avoided. It's said that for some problems FP isn't a good fit.
For what common problems isn't functional programming a good fit?
Applications that are very stateful in nature. Video games are a good example because they model the real world. It makes much more sense to think about modifying the state of the world instead of rebuilding from the previous state every time something changes.
A concrete example would be changing the health of a monster after it gets shot. It's a lot more sensible to simply alter its health than to replace it with an entirely new monster that is the same in every way except now it has less health. These kind of changes make up just about everything in a game world, and doing this in a pure functional manner is not very intuitive. I imagine there may be some significant performance penalties, at least if you're doing it in a purely functional language.
(As a side note, some problems in games are very well suited to functional programming, such as AI. A hybrid functional/imperative language would be an excellent fit for those cases.)
Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports, everything interesting is done by calling functions with side efffects.
I'd argue that GUI programming is not a good fit for functional programming. GUIs are generally very stateful, and it's a lot easier to model/manage them using state rather than using a side-effect free. It's certainly possible to use a functional programming language for GUIs...but it's probably not a good idea.
As noted in another answer, games are often easier to manage by tracking state, and while you can write a game in a functional language, it's often easier and more efficient to do so in a "stateful" language (i.e., an object-oriented language).
Data-driven business applications. User interface and simple data operations don't need FP.
You can't easily dismiss any problem set for not suited for functional programming per se.
Much depends on the actual language used for functional programming and its features.
One example is the already mentioned Erlang for realtime embedded-systems.
State-fullness is also not a good criterium against functional programming, there are several successful ways implemented in functional programming languages to deal with this.
Side effects are also often mentioned against functional programming. Every program that is not totally solipsistic has side effects. So every real world FP language has some way to deal with this, its only a matter how elegantly to encapsulate the world side effects.
There is no need for arbitrary side effects like global variables at all.
But there are problem sets that make it easier to get into functional programming because they don't twist your familiar way of looking at the problem as much. But once you manage to think functional more and more problem sets are open to less side-effects.
Even when programming C it is always a good idea to reduce arbitrary side effects like global variables as much as possible.