I would love to hear about some recommended reading and other sources which could help hobby traders like me to develop their own algorithms.
If you want to know what it's really like to be a quant, review stuff from the ARPM; everyone I hire goes through their 6 day bootcamp but they have other materials as well:
And as for books, Algorithmic and High Frequency Trading covers the foundations:
https://www.amazon.com/Algorithmic-High-Frequency-Trading-%C...
Those are pretty good sources to get an overview of what actual quants at successful firms know.
Quantitative trading is technical, I don't want to give the impression that it's not technical... but it's not "fancy" technical. It's more along the lines of rigorous and iron clad instead of flashy and sophisticated. Every strategy is built up step by meticulous step in precise detail and every step needs to be rigorously justified and experimentally verified.
Generally the thought process starts from the assumption that there is no money to be made on the stock market, either due to perfect efficiency or things like fees eating up any potential profits... when we talk about models, the models we construct describe how the stock market would behave if it were perfectly efficient, ie. free of any arbitrage opportunity.
Then given our model of a perfectly efficient stock market, we simulate what we should expect to observe in such a perfectly efficient market... we then investigate empirically whether these observations happen in reality. Is the market genuinely efficient all day every day across every security.
For some phenomenon it really is, but sometimes the market deviates from the model, so our model is either incorrect or an arbitrage opportunity has presented itself. If an arbitrage opportunity presents itself, we investigate how feasible it is to capture it, things like engineering effort, risk factors, profitability etc...
If all of that works out, then we get to work constructing a state machine for an algorithm to capture that opportunity. We implement the state machine, write tests for it, run it through our backtester, then run it through our live simulator, and after everything checks out we deploy it live.
Every algorithm is treated like a person, it's given its own human-like name, has its own account, its own set of permissions, capital allocated to it, risk profile, and algorithms are evaluated on a daily basis to reallocate capital to them and modify their risk profile.
Not that I know, how they actually do it.
We do prevent this by using a fairly standard component called an internalizer. Almost all of our orders go through such an internalizer and if it sees that two orders are matching one another, the internalizer will perform that match directly instead of having it go to the market.
This happens quite frequently in fact, and it's good to be able to catch it beforehand, avoids paying fees, having any kind of market impact, as well as obviously complying with regulations.
Our interview process involves data structures, algorithms, probability and statistics.
For example if I asked you to write an algorithm to generate 4 random uniformly distributed positive integers (that means excluding 0) that sum up to 100, could you do it? That question or a similar one like it will eliminate about 80% of applicants, including those with PhDs, who are unable to produce an even remotely viable solution even after considerable assistance is given. Then you have the remainder who can produce a competent solution but it's not exactly uniform, there's some small bias in the answer but it's good enough and I can usually walk them through it to work out the kinks, and then maybe 5% or less are able to work out a perfect solution.
Some other questions you should be able to handle confidently would be... how many times should I expect to flip a coin before I see heads 3 times in a row?
More challenging questions will be about Markov chains, optimal stopping, random walks. All questions can be solved either by writing an algorithm, or providing a mathematical solution.
Then just go over your resume and ask you technical questions about it... usually I will find something you worked on, you will describe it casually and then I will ask a technical question about some specific area you bring up that you seem interested in.
Are these questions asked on a computer? As in do you allow the applicants to program it up and show you a working version, or do you have to perform it there on the spot on the blackboard?