any position requires combination of knowledge both in Database (Oracle,SQL) and FA

[stevepham]

Dear All,

I have some working experiences as Database Architect, Admin, and PL/SQL developer. I happened to know about MFE degree and feel very interested.
However, I am NOT clear if there is any position that requires combination of knowledge both in Financial Engineering and Database.
If Yes, could you tell me more details about such positions?

Thanks.
Steve

 

[Ken Abbott]

quant + database

I'm surprised to hear your comment. Market risk teams at big firms rely squarely on both - it's what we look for in candidates. Every day, we collect hundreds of millions of records (yes, that's right, hundreds of millions). Many quants use market risk as the stepping off point of their careers. There are also other positions that rely on database skills, including those in financial controller jobs, including quant price validation, which is another great place to start.

I see way too many people saying all they want to do is trade. Those spots are few and far between. They also must be earned. Meanwhile every major firm is looking for risk and price validation people.


Ken Abbott
Managing Director
Morgan Stanley

 

[Andy Nguyen]

I echo Ken's comment that there are many critical roles in any firm. So often, people coming into this field with a delusion that they will be a trader and nothing else. Trading is only one part of the big machine and it's not be all, end all as many seem to think.

Data skill is pretty important and increasingly so. The number of data to analyze is just going to grow exponentially and people are going to get paid a lot of money to extract/analyze these. In almost any position in this field, you would need to work with data on a daily basis, using anything from Excel to DB GUI to command line.

If I were you, I would stress that skill as a very good strength to have on the resume.

 

[stevepham]

Thank Ken and Andy very much for the replies.

Knowing that database skills will be useful for some kinds of quant jobs is an important factor for me to decide to get a FE degree since I am not young enough to completely switch to a new field.

My question is actually nothing to do with whether or not quants can become traders (this point you might have misunderstood me).

Btw, Could you please advice that: In your hiring experience, is it possible for a firm to accept a candidate with pure computer science background (Database,C++,Linux), then provide him/her with necessary training in finance/math to become a quant?

I feel that is a good shortcut, faster than a formal MFE study :D

Thank you!

 

[elliot]

I'm surprised to hear your comment. Market risk teams at big firms rely squarely on both - it's what we look for in candidates. Every day, we collect hundreds of millions of records (yes, that's right, hundreds of millions).

You must be talking about storing tick data or something similar. You must be using a high performance database like kdb+. Working on these types of databases like is totally different from working on databases like Oracle. Most of them have their own properitery language to query them. You don't write stored procedures in PL/SQL to query the database.

 

[stevepham]

yeah, thank elliot for reminding that important point. I did come across some job postings mentioning kdb which is much different from traditional RDBMS like Oracle,SQL ...

 

[Andy Nguyen]

Btw, Could you please advice that: In your hiring experience, is it possible for a firm to accept a candidate with pure computer science background (Database,C++,Linux), then provide him/her with necessary training in finance/math to become a quant?

I feel that is a good shortcut, faster than a formal MFE study :D

Don't you think the firms would feel it's more cost effective to hire MFE grads rather than training some programmer?
That's not to say it will never happen. It happens quite often. You just have to be really good in something for people to feel it's a good investment to train you.

The finance part isn't terribly bad, it's much harder to train someone on the job to become an expert programmer.

 

[Ken Abbott]

tick data????

no, no, no. Hundreds of traders * thousands of positions + hedges + currency data + legal entity data+ security master info...

We store gigbytes every day.

Many risk people feel that it's easier to train an IT person in finance than to train an finance person in IT.

 

[elliot]

no, no, no. Hundreds of traders * thousands of positions + hedges + currency data + legal entity data+ security master info...

We store gigbytes every day.

Many risk people feel that it's easier to train an IT person in finance than to train an finance person in IT.

This type of information is generally stored in relational databases like Sybase. But I have not seen a dedicated person maintaining these database. Each group (equities, derivatives ..) generally takes care of maintaining these database.

 

[Lecter]

To know database concepts and SQL is very useful, however, never try to do an entire system database by yourself, this is best done in team with software engineers, often the database is on a server and feed many users, it must be done with utmost security and modularity, reading a basic book on software engineering would be useful, for its related to management in a more technical way.

Also it will make it much easier to work with the IT guys.

 

[Stefan Zota]

To know database concepts and SQL is very useful, however, never try to do an entire system database by yourself, this is best done in team with software engineers, often the database is on a server and feed many users, it must be done with utmost security and modularity, reading a basic book on software engineering would be useful, for its related to management in a more technical way.

Also it will make it much easier to work with the IT guys.

Databases are a broad branch of Comp. Sci. There is plenty of theory behind constraints optimization, optimal table design. There are hundreds of books on database structure, indexes, store-proc design. These are not relevant in this discussion.

Relevant part is data-mining.
Can you write a reasonable size SQL query to fetch some data?
What do you need to run quickly a query against a few tables with 100 million rows each?
Can you talk to a DBA/database design person, explain requirements and understand the setup?
Similar other questions.

In all such cases, SQL knowledge is a must. It's not so difficult, we are not talking about a full programming language.
SQL has some simple paradigms, it can be grasped in a few days.

 

[kirylm]

You must be talking about storing tick data or something similar. You must be using a high performance database like kdb+. Working on these types of databases like is totally different from working on databases like Oracle. Most of them have their own properitery language to query them. You don't write stored procedures in PL/SQL to query the database.

While it is slow, Oracle is very versatile. I for example use it for processing a lot, while prefer actual queries run against analytical columnar-based engines. Oracle is used a lot in financial sector. I did not understand your last sentence. PL/SQL is not a query language, it's a programming language.

---------- Post added at 12:43 PM ---------- Previous post was at 12:42 PM ----------

yeah, thank elliot for reminding that important point. I did come across some job postings mentioning kdb which is much different from traditional RDBMS like Oracle,SQL ...

Hmmm... efficient? It depends. Yes, some query with piped sessions that takes 8 hours on Oracle - will run in no time on columnar engine (actually depends which kind). But try to write some parsing/processing/metadata generation on such a database - it's a pain.

---------- Post added at 12:46 PM ---------- Previous post was at 12:43 PM ----------

This type of information is generally stored in relational databases like Sybase. But I have not seen a dedicated person maintaining these database. Each group (equities, derivatives ..) generally takes care of maintaining these database.

i cannot follow your comments. what are you trying to point out?

---------- Post added at 12:49 PM ---------- Previous post was at 12:46 PM ----------

Databases are a broad branch of Comp. Sci. There is plenty of theory behind constraints optimization, optimal table design. There are hundreds of books on database structure, indexes, store-proc design. These are not relevant in this discussion.

Relevant part is data-mining.
Can you write a reasonable size SQL query to fetch some data?
What do you need to run quickly a query against a few tables with 100 million rows each?
Can you talk to a DBA/database design person, explain requirements and understand the setup?
Similar other questions.

In all such cases, SQL knowledge is a must. It's not so difficult, we are not talking about a full programming language.
SQL has some simple paradigms, it can be grasped in a few days.

i doubt you can grasp SQL knowledge in a few days and run a query against relatively large/wide table and do it quickly. this requires much deeper knowledge, and understanding of specifics of the database. sql is an art.

 

[Stefan Zota]

I doubt you can grasp SQL knowledge in a few days and run a query against relatively large/wide table and do it quickly. this requires much deeper knowledge, and understanding of specifics of the database. sql is an art.

If SQL is an art then you have to be a genius to use LISP or C++

Seriously, the thread is about SQL knowledge for quantitative finance positions. It is very important to know the basis, core statements and concepts, however I doubt that you will get questions about setting up cursors and transaction controls.
If the interview is for a development position it varies quite a bit. If you interview for database developer position then your statements are 100% true.

 

[kirylm]

If SQL is an art then you have to be a genius to use LISP or C++

Seriously, the thread is about SQL knowledge for quantitative finance positions. It is very important to know the basis, core statements and concepts, however I doubt that you will get questions about setting up cursors and transaction controls.
If the interview is for a development position it varies quite a bit. If you interview for database developer position then your statements are 100% true.

Stefan, so the message to original poster of this thread is: no, Steve, there are really no positions that require deep knowledge of the database combined with quantitative skills. All database knowledge that you will need for "quantitative finance positions" is basic and can be easily picked up in a few days. is that right?