• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

What is the real value of 3hr basic coding tests for experienced hires with MS/PhD - please explain?

Mathchismo

Joined
6/11/17
Messages
40
Points
28
You spend 4-5 years doing a tough STEM degree. You did tons of internships. You did research at a postgraduate level.

After years of slaving away working and trying to stand out you finally have a profile recruiters at banks say is good. Heck the only people you are competing with seem to be those Mathematical Olympiads you read about all the time on the blogs.

You get excited. They tell you they want to hire you in NYC/London/Paris/Chicago as soon as possible but first of all you need to spend our weekend taking 3-8 hours of coding tests on basic year 1 level computer science concepts to see if you are up to scratch.

Wait what? How is Quick/Bubble sort going to help me perform in a Quant Dev role at a bank in NYC working 12-14 hours a day. What does that tell you about my work ethic/coding experience or ability to perform under pressure. Who even thought of this?

I really have to ask - What is the real value of 3hr basic coding tests for experienced hires (1-3+ years experience) with MS/PhD - please explain?
 
Because 1. a lot of people think they can code, but reality is different. And more importantly 2. you need to weed out the people unwilling to eat shit: A big part of the job is, after all, doing dull tech stuff or desk support and nobody wants to hire people who somehow think they are above it all. Finally, 3., because you need to ask something at an interview and maybe the yardstick is partially based on some standardized test that you give to almost all applicants and then have a feel for how well people usually do. When you're asking CV specific stuff, you can't recycle the questions and it's not always clear how well the interviewee should've done when there are no peers to compare to.
 
I really have to ask - What is the real value of 3hr basic coding tests for experienced hires (1-3+ years experience) with MS/PhD - please explain?

Anecdotal evidence suggests [60,90]% of quant life spent programming(?)

Besides, if you have a new bootiful model, how do you test it?
 
Andy Nguyen said:
Because they can, given how many applicants they can get for any open spot. The appearance of an extremely tough passing bar is part of the allure as well.
I do think the IT industry is similar where the Facebooks, Googles of the world use those exams to thin the herd.
Click to expand...
Very true. Even Facebook do it.

Can you tell us the complexity of Bubble Sort vs Quick sort?
When would you use a dictionary?
Can you give a program to recursively print out the Fibonacci sequence?

It's a complete waste of time in my eyes. If they person is already intelligent with experience you are better off finding out if they would fit in the firm culturally or if they are someone people can get along with for 12+ hours a day.

But hey time for me to get on HackerRank + Kaggle. I'm not going to avoid these tests any time soon...
 
OP, I understand your grievance as it appears others in less technical careers get an easier ride. And when it comes to companies with big names like FB, Google, GS etc you have a point. With them it is for show and to get a 'hard to get into' tag so more people apply, and I have experienced that in the past.

BUT, and this is a big but, a swallow doesn't make a summer and get a few years under your belt in industry and you may change your tune and realise how many crap programmers there are out there, even when doing experienced hires. For starters you might realise that even when you have 300+ applying for a job usually 1-3 actually have the stuff, even though 10-20 may have the MS/PhD + experience. Many of my classmates wanted to be quants, had excellent math skills and the personality to be in a trading environment, but hadn't done more than learn off design patterns and/or copy and past code and manipulate it.

On top of this, some of the coding practices I've seen from people with 5-10 years experience are appalling. Large 1000-2000 line routines (instead of broken down), deeply nested if statements, meaningless single letter variables, no ability to debug (a lot of "lets see if this works" instead of methodically printing to console) and programmers that are at sea if you ask for tiny changes. This all makes life difficult and starts fires for better programmers to fight. These bad practices seem to correlate to roles where psychometric testing and/or competency based interviews are used instead of coding interviews. Remember you also can do the 'whole tell me about yourself' stuff aswell in a seperate stage or in another part of the interview, which is what companies tend to do.

Unless someone is working for a company where I know the standard is high, or are a former client where we've seen their work, I have no other way of vetting them. I've also had too many clashes with people from well supposedly high standard companies to just pass people from their company through without vetting e.g. where they appear to not know the difference between when someone is being technical and when giving business analysis, not have a clue about bottom line and just generally do due diligence and other work the wrong way.

Finally, it's NOT a coding test. It's more about seeing your reaction. From my own experience, even after filtering out irrelevant CVs, most candidates can learn off design patterns and problems but can't handle it if I make tiny changes or if I deliberately throw in something no candidate will know. The thing is in any coding job using your math skills, the model will be nothing like what you studied, edge cases will arise routinely and if you don't speak up and ask questions (out of fear of losing face) you will piss your manager off.

And also as another poster said, they want to see if you will eat shit e.g. in my first role I did Excel work and risk reporting - many wannabees rabbit on about 'wanting self respect' and many modellers bitch if they aren't programming 200% of the time. If you huff and scoff while answering tiresome questions, you won't happily do all your tasks. You're there to drive the business forward, not for your amusement.
 
Last edited:
On top of this, some of the coding practices I've seen from people with 5-10 years experience are appalling. Large 1000-2000 line routines (instead of broken down), deeply nested if statements, meaningless single letter variables, no ability to debug (a lot of "lets see if this works" instead of methodically printing to console) and programmers that are at sea if you ask for tiny changes. This all makes life difficult and starts fires for better programmers to fight. These bad practices seem to correlate to roles where psychometric testing and/or competency based interview are used instead of coding interviews.

How did it get this far? Here is my two cents:

1. People don't learn real computer automation (notice I avoid the words IT and CS) at university. In fact, it's discouraged.
2. CS is not science; it should be a part of engineering.
3. OOP has destroyed Structured Analysis. OOP is bottom-up, leading to spaghetti code in many (not all) cases.
4, Indiscipline; cool features are done first.
5. Have you read "Mythical Man Month"?
6. The Gamma/GOF patterns have not kept pace with new language developments. They are OK but almost deprecated. (Others have turned most of them into multiparadigm versions).
7. No one writes in-line docs; top-level design blueprint missing.
8. An MSc/PhD does not necessarily mean you will be a good programmer. It is a skill as well.
etc.

 
Last edited:
Liam said:
OP, I understand your grievance as it appears others in less technical careers get an easier ride. And when it comes to companies with big names like FB, Google, GS etc you have a point. With them it is for show and to get a 'hard to get into' tag so more people apply, and I have experienced that in the past.

BUT, and this is a big but, a swallow doesn't make a summer and get a few years under your belt in industry and you may change your tune and realise how many crap programmers there are out there, even when doing experienced hires. For starters you might realise that even when you have 300+ applying for a job usually 1-3 actually have the stuff, even though 10-20 may have the MS/PhD + experience. Many of my classmates wanted to be quants, had excellent math skills and the personality to be in a trading environment, but hadn't done more than learn off design patterns and/or copy and past code and manipulate it.

On top of this, some of the coding practices I've seen from people with 5-10 years experience are appalling. Large 1000-2000 line routines (instead of broken down), deeply nested if statements, meaningless single letter variables, no ability to debug (a lot of "lets see if this works" instead of methodically printing to console) and programmers that are at sea if you ask for tiny changes. This all makes life difficult and starts fires for better programmers to fight. These bad practices seem to correlate to roles where psychometric testing and/or competency based interviews are used instead of coding interviews. Remember you also can do the 'whole tell me about yourself' stuff aswell in a seperate stage or in another part of the interview, which is what companies tend to do.

Unless someone is working for a company where I know the standard is high, or are a former client where we've seen their work, I have no other way of vetting them. I've also had too many clashes with people from well supposedly high standard companies to just pass people from their company through without vetting e.g. where they appear to not know the difference between when someone is being technical and when giving business analysis, not have a clue about bottom line and just generally do due diligence and other work the wrong way.

Finally, it's NOT a coding test. It's more about seeing your reaction. From my own experience, even after filtering out irrelevant CVs, most candidates can learn off design patterns and problems but can't handle it if I make tiny changes or if I deliberately throw in something no candidate will know. The thing is in any coding job using your math skills, the model will be nothing like what you studied, edge cases will arise routinely and if you don't speak up and ask questions (out of fear of losing face) you will piss your manager off.

And also as another poster said, they want to see if you will eat shit e.g. in my first role I did Excel work and risk reporting - many wannabees rabbit on about 'wanting self respect' and many modellers bitch if they aren't programming 200% of the time. If you huff and scoff while answering tiresome questions, you won't happily do all your tasks. You're there to drive the business forward, not for your amusement.
Click to expand...

Thanks so much for the time. I appreciate it - really great post
 
Here are the questions which you are evaluated on:
Will your program compile?
Will your program run?
For expected data, will your program return the expected results?
Have you selected the appropriate data structures to use in your code?
Does each method perform a single task?
Does your code adhere to coding standards and naming conventions?
Does your program handle edge cases?
How will your program handle bad input data?
How will your program handle null input data?
Have you written unit test cases?

The reason they ask these questions is very simple. The real question they are asking is this:
Is this candidate going to commit shit code into my precious code repository which I will have to clean up later?
 
TraderJoe said:
Here are the questions which you are evaluated on:
Will your program compile?
Will your program run?
For expected data, will your program return the expected results?
Have you selected the appropriate data structures to use in your code?
Does each method perform a single task?
Does your code adhere to coding standards and naming conventions?
Does your program handle edge cases?
How will your program handle bad input data?
How will your program handle null input data?
Have you written unit test cases?

The reason they ask these questions is very simple. The real question they are asking is this:
Is this candidate going to commit shit code into my precious code repository which I will have to clean up later?
Click to expand...
This is an excellent answer. What you've described above is what an engineer or analyst does, which is a much scarcer resource than a coder.
 
What's the definition of the term coder? I have never heard this used or on a business card. Real programmers know TJ's list.

In some software organizations you have the domain expert who writes the basic alpha code and then testers and integrators make it into production code. It's an organizational problem. Who does what? Delegation?
 
Last edited:
Daniel Duffy said:
What's the definition of the term coder? I have never heard this used or on a business card. Real programmers know TJ's list.

In some software organizations you have the domain expert who writes the basic alpha code and then testers and integrators make it into production code. It's an organizational problem. Who does what? Delegation?
Click to expand...
I've never seen it defined strictly speaking or heard it used in a formal sense.

Most contexts I've heard it have been as a loose substitute term for 'programmer'. But in some contexts I've heard programmers use it as a pejorative/denegrating term for someone who just codes/doesn't follow TJ's list, or simply writes the basic alpha code, as you say.

Many non-programmers use the term 'coder' to describe programmer - it's not a big pet peeve if I'm being asked to help with networking. It's certainly not as bad as when people think actuary/quant/accountant/risk assessor are interchangeable terms (another story...)
 
Last edited:
"quant" is a yugely overloaded word. But "actuary" and "accountant" are well defined and have professional bodies.

I once met a HTML programmer whose business card was "enterprise architect".
 
51FUYfErOXL._SX408_BO1,204,203,200_.jpg
 
Daniel Duffy said:
"quant" is a yugely overloaded word. But "actuary" and "accountant" are well defined and have professional bodies.

I once met a HTML programmer whose business card was "enterprise architect".
Click to expand...
Spot on.

The reason I mentioned it is because of the amount of times I talked about being a quant and been asked 'is that actuary?'. One of Paul Howard's books on Ross O'Caroll Kelly captures this perfectly where Ross seems confused about a risk assessor. He calls him an actuary (which is correct) but then an accountant other times and various other distinctively different titles. I've met people that do this routinely.
 
You would be absolutely amazed at how many people have 10 years of experience, all sorts of fancy degrees (even from top schools) in computer science, physics, math, but can't code their way out of a paper bag. I have interviewed many of these people and they would not even be hired as entry-level analysts in most quant teams.
 
OP, I've just accepted an offer for a statistical modelling grad scheme to start after I finish my MSc. All 3 companies I interviewed, including the one that hired me, gave technical interviews. It's not a performance test, it's about seeing how you think and interact with others as you solve problems i.e. how you will work with people.

According to any senior statistical modellers or quants I've met through college or events, even after the CV filter usually only 5-10% of candidates can code to an entry level standard. Also many people have fancy sounding degrees with maths/physics/economics in the title but where their mathematical training or relevant industry training isn't actually very extensive or rigourus.

There may be some firms where they do coding tests for pomposity's sake but mostly I get the impression that if you have rigorous math skills and can code in the manner others have described you're actually hard to find/sought after. This may vary with quant roles, but the impression people give me is that technical interviews are more about the difficulties in firing someone, even in the US, i.e. ensure there are no passengers hired.

Obviously take this with a pinch of salt as I haven't started working, but the process seemed very logical to me.
 
Last edited:
If one wants to learn "coding", there aren't that many books around. There are lots of books on the syntax of any language -- C, C++, Python, Ruby, etc. But few book on interesting and engaging coding problems with detailed solutions. Books on coding interviews are one source and there are a handful of others, including some on the code behind numerical analysis algorithms. There isn't one single book on how to code a chess engine.
 
Back
Top