How to avoid the quant/developer black hole

In some ways a quant is just an overpaid programmer, the standard seems to be that you spend an average of 60% of your time writing some sort of code, be it C++,C#,Matlab,R, F# or even Java.
If you've been to a CQF info session then you may have heard me explain that even if your job title is "developer" the % of your time spent actually coding will go up, the more you move in a quant direction.
Within that of course are quant developers, but if you have good programming skills and haven't yet established your direction firmly, then it is very easy to get sucked into housekeeping IT development roles, pumping data around, reformatting it and knocking up data entry and report screens.
So here's a rough guide on how to spot the housekeeping black hole.

Firstly there is the interview process, the things they ask about are a good predictor of what you will be doing, in theory of course they should be an excellent predictor, but this blog is about the real world of banking careers.

SQL : Quants use SQL, but if they go on about it a lot then there is a good chance they want you for IT and as a rough guide, the harder the SQL questions the more housekeeping they want. If they ask about the specifics of a particular DBMS like Oracle then be worried. If they like Crystal reports move from worried to scared because a) it's generic IT , b) it's not a good IT job and c) I have seen the most gentle people I know launch into spiteful obscenities whilst talking to Crystal reports tech support.

Version Control: Of course you use version control, but if they seem surprised and mark it as a note in your favour then it's a good sign. IT shops will assume it, quant and front office often think of version control as a cool new idea, except those who don't do it at all.

HR : If your first interview is with HR then it's a crap job with 95% certainty. At some point a meeting with HR is almost inevitable, but it's a strong sign that the wrong people are making the decisions and that you are being hired for a menial job.

Maths: Of course the higher the % and level of the maths questions correlates with the nature of the job, but a bad sign is if you can answer them all, unless you are really quite gifted. A proper quant interview tries to find the point at which you hit a wall, quant dev roles look for being "good enough" and housekeeping IT are happy if you can count without using your fingers.

UML: Really a bad sign, 50% of quants don't even know what it is, but 50% of the output of some IT departments is UML diagrams. Some younger quant types have a basic understanding but if they value expertise then it's a very bad sign, ditto refactoring.

Java: Housekeeping IT in banks includes a lot of Java, certainly more Java than C++ so they may try to suck you into IT. If you are a C++ guy and they ask about Java, increase your worry level.

Indians: Many of the smartest people in this game are Indians, but they are not in India. If it is mentioned that part of the work is being done in India then it means they are doing grunt programming.

Perl: A fine scripting language for pumping data around so if there is a lot of that, it is a bad sign.

VBA: Most IT departments despise VBA, enough that it is worth putting it on your CV to help deter them.

C# : Is not a clear sign either way as far as I can tell.

Weird Programming Languages: A very good sign. If they like F#, ASM, Haskell, CUDA, VHDL, Lisp or other non-mainstream language it means they are doing interesting things.
Except... If JP Morgan asks about your knowledge of SmallTalk, then you should run not walk, ditto Cobol at Merrill Lynch. Yes they are there and no, you don't want to be part of that.

Money: It's not just the objective, it is a signal. If you can't tell which of two job offers is furthest from IT the one with the higher base is almost certainly it, even if the difference is otherwise negligible. Also quant pay is usually negotiable within bounds but IT pay is more often set in stone, so asking for a small amount more can yield useful data. Ask what the average % bonus was in that group was last year, yes do it, you will learn a lot from the result, the less they want to tell you, the more you need to know.

Weasel Words: "we work with the quants". You can only work "with" a group that you are not part of, similarly "a lot of contact with front office" means you aren't in it, you get the idea.

Who interviews you ? Points gained for interviews by traders of course but the relationships are important. In any interview process there is usually one person who is in charge of running it, you must find out what group he works for because this is the best predictor of where you are going.
He may pull in an IT guy to check your skills and you should try to spot whether they seem to be in the same group, ditto risk.

Where will you sit ? There is a great divide between those who see this question as irrelevant or critical. It may sound like a small thing but physical location is critically important to the reality of your job. If they don't know, that is a very bad sign since it means you are joining a big team and they "will fit you in somewhere", quant teams are rarely big, in fact getting places for people to sit sometimes sucks up a depressing % of quant management time.

Putting that in perspective....
These are all signs, OK mostly negative signs but you should not take any one of them as proof.