use of vba on trading floor

Joined
9/5/09
Messages
2
Points
11
hi,

I have seen a few job descriptions which states that familiarity with vba modeling is required for many trading/less quant jobs. What exactly is the difference between using c++ and vba and why do they prefer vba over C++ or C#?

Also, i have seen from the masters reading list there are quite a number of books on excel. Can anyone recommend how i should go about doing this?

Thanks in advance
 
vb has come up in interview questions for me and my fellow alum.

trader!=programmer

most traders use excel to do basic stats and look at ratios they feel are important (assuming no automated/prop interface to do this for them).

best way i would say to learn vba is by example. try and solve some basic operational/computational goals. its not very tough if you are familiar with concepts in every language.
 
There are N different modes for Excel use:

Firstly, since it's a good environment to teach basic numerical techniques for finance, simple, ubiquitous and cheap.

VBA is for traders.
C++ is for programmers.


Althoughthat's a nice line, I'm a VBA programmer, the two words are are not contradictory, but I find myself using a different mindset than when I write C++.

My VBA code is vastly less reusable than my C++. Things get hard coded, and typically I don't bother making things generic. Often I reuse code by cut& paste rather than creating library quality routines.
That's because I want the result now and typically either don't care about performance, or the performance is limited by another component. I'd guess 25% of the VBA I've ever written was never used after the day I wrote it.

My mindset is more like navigating' rather than building. As a C++ programmer I expect to do the hard stuff, as a VBA programmer > 70% of the work is done "by the system". A typical lump of my VBA code is responding to a work process, ie loading data in, re-forming the spreadsheet, or calcs that are not heavy enough to justify C++ XLL or DLLs to be written.

As a headhunter I'm here to tell you that VBA is on the same ( value / effort ) curve as C++

Most good quant jobs won't even ask if you know VBA, if you're smart enough to do the other stuff, it is perceived that you will hack VBA.
That nearly true.
But VBA can give you that most precious of things visible productivity. Some people I've worked with never saw some really cool stuff I did, but remember me as "the guy in the suit who sorted out the shit with my yield curve", where the "sorting out" was to write a macro that re-started a badly defective spreadsheet every time it went wrong. I didn't 'solve' any problem at all, but hid it so well they were deeply impressed.
If you're a newbie that's worth it's weight in diamonds.

Of the complaints I get about newbies, easily the top one is "he's smart but doesn't seem to really do much". That may or may not be accurate, but it hurts the newbie big time.

As a C++ programmer, sometimes the result of a week's work has been to find out that what we thought was one bug in the code was three, and since I only fixed one, the number of bugs has actually gone up.

So my advice is to learn VBA, it can make you look good in a suit.

Also it is a survival skill...

One of the reasons I so arrogantly dispense career advice on the web and elsewhere is that I've made some impressively bad decisions in my own career, and Excel has always been there for me to pay the rent. A competent Excel programmer always has a job to go to, and since it is used by a range of people whose salaries range from the absurdly high to the merely adequate at banks, you can get to places you want to be, or at least avoid the places you don't.
 
Back
Top Bottom