Correct. From what I've seen, at large IB settings, perl's popularity primarily stems from it success in handling large files. If I were preparing for an interview, I'd pay special attention to these topics.
I would also chime in that if they're looking for a developer who specifically knows perl well, this job may not involve a lot of financial work. Be sure to ask exactly what you'll be doing. If you are interested in financial/quantitative development, I would recommend steering towards the pricing systems and a little more away from booking and more typical client-side Windows interfaces. Some of these are very cool systems that use cutting-edge technology, but there's not a lot of exposure to finance.
Quick reference on what major programming languages are used for by banks:
C++: Actual pricing engines.
Java: Gathering data to send to pricing engines and handling economics of trades. (Also a less frustrating language).
C#: User interfaces.
Perl, ksh: Processing large files and handling infrastructure stuff.
If you are very familiar with Awk or regex AND scripting languages (bash, sh etc), then you can get away with just reading the man pages. Sections of the O'Reily book are lifted directly out of the man pages.
If you know some scripting and regular expressions, it is not too difficult to deal with perl. Read any book or tutorial on the basics - scalars, arrays and associative-arrays and print the perl quick ref card. perldoc, perlfunc and perlre manpages are your friends. If you need some fancy module, go to search.cpan.org and you will find a lot of modules on a variety of additional functionality.
No matter what people say, it is always good to master one scripting language. It doesn't have to be Perl. But, Perl in my opinion covers a wide base and very well supported. It will make you so much more productive by not having to deal with a different syntaxes and limitations of separate tools.