Why is an interleaver often placed between an outer block code and an inner convolution code?
As the other answers mention, the use of FEC results in post-decoding errors occurring 
in bursts. Indeed, this happens regardless of whether the code is a convolutional code
or a block code.  With a $(n,k)$ block code, the decoder output ($k$ bits)
from the decoding of one 
received word is (hopefully with high probability) completely correct, or it has 
an unknown number of errors in it that can be regarded as a burst error of length $k$.
With a convolutional code, the decoder output is mostly correct as the decoder
finds the correct path through the trellis, but occasionally the decoder's
chosen path deviates from the correct path and later rejoins the correct 
path during which time there is a burst of errors. In contrast to
block codes, there can be multiple
isolated burst errors (of variable lengths) in a single transmission
using a convolutional code. Also, the number of data bits in a single
transmission is far larger than the typical values of $k$ for a
block code.

The idea behind a concatenated
coding scheme is that with an inner code suited to the physical channel,
and an outer code over a very large symbol alphabet, we can make
the burst errors in the inner decoder output look like a single
symbol error to the outer code.  This is important because the
outer code should be a very high rate code because the net rate
is product of the inner code rate (more or less determined by
the channel and the link budget) and the outer code rate. 
Unfortunately, outer codes over very large alphabets are very
expensive to implement, and so interleaved Reed-Solomon codes
over smaller alphabets (often GF$(2^8)$ ) are used (with 
interleaving at the symbol
level, as Jim Clay points out). Because of the interleaving, the burst
errors in the inner decoder output become single symbol (byte) errors in the
received words of the interleaved Reed-Solomon code.

All the above is mostly a rehash of what the answers by Bryan and
Jim Clay have already said, but I wish to point out the following.


  Interleaved Reed-Solomon codewords can be decoded much more
  efficiently and with smaller delay if they are not de-interleaved
  first.


A Reed-Solomon decoder that can decode interleaved codewords is different from
the off-the-shelf standard Reed-Solomon
decoders that are available, and the use of such a decoder might not be
feasible if the development team does not have control of this aspect of
the design. But, if such a decoder is used, the de-interleaver
can be moved from the between the inner decoder and outer decoder to
just after the outer decoder. The de-interleaver is also smaller since
it has to deinterleave a $K\times L$ array instead of a $N \times L$
array (for a $(N.K)$ Reed-Solomon code interleaved to depth $L$.


  If a delay-scaled Reed-Solomon encoder is used along with the
  Reed-Solomon decoder for interleaved codewords described above, the interleaver
  at the transmitter and the de-interleaver at the receiver
  can be eliminated entirely.  


The output of the delay-scaled
encoder (see also 
this paper 
which is unfortunately behind a paywall)
is a set of interleaved Reed-Solomon codewords, but
is not the same sequence of bytes that one would get from
doing a standard Reed-Solomon encoding followed by interleaving.
So, no further interleaving is necessary.
The output of the interleaved Reed-Solomon decoder is the
same byte sequence in the same order that went into the delay-scaled
Reed-Solomon encoder, and so no de-interleaving is necessary
at the decoder, either.