[Kurgan]

I'm in the field of Banking and I've been enhancing my skills through learning coding from codeacademy. I recently taught myself SQL from there and am doing the Business Analytics part which is a struggle.

Are there any specific languages banks look for in regards to programming? It seems most of them require knowledge of Word, Excel and Access (I'm relearning the latter two). I know that VBA is also needed as well. I'm looking to get more into an Analyst role.

[cibo]

For the standard analyst role in banking. Excel, VBA and maybe SQL.

For additional analysis involving statistical modeling for certain types of risk management or trading, SAS. More recently, R and python have also become popular in stats roles. But big companies tend to use SAS first due to legal and compliance reasons.

If you want to do more high speed algo trading, C++ or java starts becoming more popular.

Get good with Excel first. Pivot tables and Vlookups are both simple and powerful. SQL is simply programming what you did in excel by hand or formulas. Learn how to make charts with 2-4 variables. When you feel comfortable enough, start using SQL more.

If you understand both excel and SQL, you can do 75-80% of what analytics jobs require. The remaining bits are analysis tools and presenting. VBA is good for automading some of the stuff you where doing but honestly, you can get by with formulas and a few macros. I've had few reasons to really use VBA in my work but it comes up more in banking from what i hear.

You can get by with excel to do some basic regression analysis but its kind of shit for more advanced things unless you feel comfortable enough to fit a curve by goalseek. Thats where you using stats programs to handle the stats and machine learning calculations.

After you get your outputs, you'll have to present your findings somehow. And its usually going to be in either excel or in powerpoint. So get good at presenting shit.

No one is perfect at all the skills, which is why finding someone that is good or above average at most of the skills needed is super employable. Most cases you start off with your core skils and build outwards and deeper.

Also if you want to improve and convince someone you're qualified for the job, build something on the side. It shows you know how to actual do what you say and show and tell goes really well with many types of interviewers. When you build something you also see where the gaps in your knowledge is.

[Kurgan]

(12-05-2016 12:57 AM)cibo Wrote:  

For the standard analyst role in banking. Excel, VBA and maybe SQL.

For additional analysis involving statistical modeling for certain types of risk management or trading, SAS. More recently, R and python have also become popular in stats roles. But big companies tend to use SAS first due to legal and compliance reasons.

If you want to do more high speed algo trading, C++ or java starts becoming more popular.

Get good with Excel first. Pivot tables and Vlookups are both simple and powerful. SQL is simply programming what you did in excel by hand or formulas. Learn how to make charts with 2-4 variables. When you feel comfortable enough, start using SQL more.

If you understand both excel and SQL, you can do 75-80% of what analytics jobs require. The remaining bits are analysis tools and presenting. VBA is good for automading some of the stuff you where doing but honestly, you can get by with formulas and a few macros. I've had few reasons to really use VBA in my work but it comes up more in banking from what i hear.

You can get by with excel to do some basic regression analysis but its kind of shit for more advanced things unless you feel comfortable enough to fit a curve by goalseek. Thats where you using stats programs to handle the stats and machine learning calculations.

After you get your outputs, you'll have to present your findings somehow. And its usually going to be in either excel or in powerpoint. So get good at presenting shit.

No one is perfect at all the skills, which is why finding someone that is good or above average at most of the skills needed is super employable. Most cases you start off with your core skils and build outwards and deeper.

Also if you want to improve and convince someone you're qualified for the job, build something on the side. It shows you know how to actual do what you say and show and tell goes really well with many types of interviewers. When you build something you also see where the gaps in your knowledge is.

Thank you for your help, I have codeacademy and decided to get some books from Barnes and Noble to increase my knowledge on those languages in the future.

[Easy_C]

Just to make 100% are we talking about investment banking, commercial banking, or speculative jobs like trading/hedge funds?

The answer's going to be very different. Commercial banking and credit tends to rely on R* to build their statistical models. Investment bankers...you don't really need to know code, but VBA will make your life much easier. Speculative jobs like trading and hedge funds are generally more C/C++ focused judging by postings.....however those jobs generally prefer to hire people with masters level math backgrounds.

[JohannesAusPrag]

COBOL, Java.
SQL, soap, xml and excel

Speaking from personal experience in czech banking environment as developer.

[Vincent Chase]

Mastering Excel and learning the basics of VBA and SQL will help you go a long way. Those are used across front, middle and back office.

Depends what you mean by an analyst role. There are dozens of languages used across banks but it's mostly restricted to IT/quant side of things.

[Kurgan]

I've decided I'm going to relearn Excel, VBA, SQL and Access. It seems to be the most required skills. I know a bit of SQL from CodeAcademy but I need to relearn VBA.

[xiagox]

Adding to the previous posts. If you want to go beyond SQL and vba, Python is amazingly popular in a variety of domains. It has libraries for handling Csv files (pandas) and most stats, ml modeling can be done with scikit learn and numpy.

[polar]

Don't touch Access until you understand SQL, or better yet, skip Access altogether. It's crap for anything that's not small business size, and the time you spend learning its quirks is better spent elsewhere.

If you grasp SQL you can do Access fine, but not vice versa.

[joehoya]

(12-13-2016 07:37 AM)polar Wrote:  

Don't touch Access until you understand SQL, or better yet, skip Access altogether. It's crap for anything that's not small business size, and the time you spend learning its quirks is better spent elsewhere.

If you grasp SQL you can do Access fine, but not vice versa.

For commercial banks, I have to disagree. I started working as a database developer in banking 15 years ago, and still consult/freelance in the field today. There is a TON of money to be made simply taking access databases (and oftentimes excel spreadsheets) normalizing them, then transferring them to SQL Server (or occasionally another DBMS).

You would be shocked at how many departments within large multinational banks store a ton of critical data on Access. Eventually, when some higher up decides to move that data from a department computer to more centralized servers they call someone like me. This happens even more when banks either acquire other (usually smaller). This also happens when banks start consolidating redundant divisions within the same bank.

For example, the first bank that I worked at had a US division and a division in a foreign country. We had departments that were mirror images of each other, doing the EXACT same job, but in different countries. When we shut down the foreign country's department and consolidated it into the US department (my department) all of that data had to be merged. It was all stored in 4 different Access databases.

I spent multiple years at the bank doing just that. When I decided to go freelance, jobs like above were a HUGE part of my business. The only reason why I don't do as much of it now as I did is because I got bored with it. I still do some (about 15%-20% of my business) just to keep my skills sharp and my feet in the industry.

[Kurgan]

(12-15-2016 12:39 PM)joehoya Wrote:  

(12-13-2016 07:37 AM)polar Wrote:  

Don't touch Access until you understand SQL, or better yet, skip Access altogether. It's crap for anything that's not small business size, and the time you spend learning its quirks is better spent elsewhere.

If you grasp SQL you can do Access fine, but not vice versa.

For commercial banks, I have to disagree. I started working as a database developer in banking 15 years ago, and still consult/freelance in the field today. There is a TON of money to be made simply taking access databases (and oftentimes excel spreadsheets) normalizing them, then transferring them to SQL Server (or occasionally another DBMS).

You would be shocked at how many departments within large multinational banks store a ton of critical data on Access. Eventually, when some higher up decides to move that data from a department computer to more centralized servers they call someone like me. This happens even more when banks either acquire other (usually smaller). This also happens when banks start consolidating redundant divisions within the same bank.

For example, the first bank that I worked at had a US division and a division in a foreign country. We had departments that were mirror images of each other, doing the EXACT same job, but in different countries. When we shut down the foreign country's department and consolidated it into the US department (my department) all of that data had to be merged. It was all stored in 4 different Access databases.

I spent multiple years at the bank doing just that. When I decided to go freelance, jobs like above were a HUGE part of my business. The only reason why I don't do as much of it now as I did is because I got bored with it. I still do some (about 15%-20% of my business) just to keep my skills sharp and my feet in the industry.

That's a good idea. Thanks!

[polar]

(12-15-2016 12:39 PM)joehoya Wrote:  

(12-13-2016 07:37 AM)polar Wrote:  

Don't touch Access until you understand SQL, or better yet, skip Access altogether. It's crap for anything that's not small business size, and the time you spend learning its quirks is better spent elsewhere.

If you grasp SQL you can do Access fine, but not vice versa.

For commercial banks, I have to disagree. I started working as a database developer in banking 15 years ago, and still consult/freelance in the field today. There is a TON of money to be made simply taking access databases (and oftentimes excel spreadsheets) normalizing them, then transferring them to SQL Server (or occasionally another DBMS).

You would be shocked at how many departments within large multinational banks store a ton of critical data on Access. Eventually, when some higher up decides to move that data from a department computer to more centralized servers they call someone like me. This happens even more when banks either acquire other (usually smaller). This also happens when banks start consolidating redundant divisions within the same bank.

For example, the first bank that I worked at had a US division and a division in a foreign country. We had departments that were mirror images of each other, doing the EXACT same job, but in different countries. When we shut down the foreign country's department and consolidated it into the US department (my department) all of that data had to be merged. It was all stored in 4 different Access databases.

I spent multiple years at the bank doing just that. When I decided to go freelance, jobs like above were a HUGE part of my business. The only reason why I don't do as much of it now as I did is because I got bored with it. I still do some (about 15%-20% of my business) just to keep my skills sharp and my feet in the industry.

Joe,

I was admittedly a bit harsh in my first post to make a point.

You're deeper into Access and SQL than I am (or possibly will ever go) and your perspective is valuable. That being said, it doesn't sound like OP has much of a background and probably isn't worried about what he will do fifteen years from now. I still think that someone who's a complete newbie to SQL and database theory should first become familiar with SQL and how queries and table joins work prior to getting distracted by the fancy wrappers put in place by Access. OP may not have the choice of which database software to use within a bank - but even if he has to use Access, he would greatly benefit from an online SQL tutorial or two. Even a three hour investment in SQL will pay off when he picks up Access.

I was in a similar place not too long ago, and wasted lots of time on Access when I could've gone to SQLite much earlier. The difference in query speed and ability to work with tens and hundreds of thousands of rows was night and day.

OP - as for VBA, it is great, but you should be moderately proficient at Excel first (for instance, do you know your way around IF, VLOOKUP, INDEX, MATCH, OFFSET? You're probably ready to make the jump). Think of VBA as a way of writing specific instructions to Excel (go to this cell, do X, rinse, repeat).

[roid]

(12-04-2016 08:01 PM)Kurgan Wrote:  

I'm in the field of Banking and I've been enhancing my skills through learning coding from codeacademy. I recently taught myself SQL from there and am doing the Business Analytics part which is a struggle.

Are there any specific languages banks look for in regards to programming? It seems most of them require knowledge of Word, Excel and Access (I'm relearning the latter two). I know that VBA is also needed as well. I'm looking to get more into an Analyst role.

Word, Excel, and Access skillsets are implied for most of the white collar jobs these days. VBA is used less in banks nowadays. They are being re-written into .NET or Java/J2EE web applications. I assume you want to get the IT department back office of a bank, if that's the case... you need .NET or Java/J2EE skillsets.

Source: I worked for 1 investment bank IT back office, and have close friends working in investment banks IT back offices.

[lazariuskriss]

I would agree with roid,i would also add c++ (but only if You have some knowledge in financial instruments and a strong background in mathematics) for some "front office dev" role, at least in Europe.

[ivansirko]

COBOL is still used today in banking often. Dont touch it.

SQL, ORACLE, MYSQL, C++, Office Applications, etc. Oracle is nice because of its Transaction model. Also learn the idea of NoSQL (such as MongoDB)

[RatInTheWoods]

I have made a metric shit ton of cash with access knowledge.

Its pretty hard to learn (SQL gives you a head start) and it has VBA in its engine. So if you learn VBA and master access, porting over to any high level language is just syntax then.

[xmlenigma]

If you are young and want to make Good Quick Coin and then figure out what you want to do in life.. Later.. (just what I'd suggest even for I Banking)

.. Algorithmic Trading