> Its a finance firm - i.e scam firm. "We have a fancy trading algorithm that statistically is never going to outperform just buying VOO and holding it, but the thing is if you get lucky, it could".
> Scammers are not tech people. And its pretty from their post.
It would be great if you included any sort of evidence or argument.
Reading on to the other comments, it looks like you're throwing out a lot of accusations and claims. I don't know what you think you know, but from the looks of it, you don't really know HRT's business. I don't really these days, but I knew it years ago, and it's not from taking client money or arbitrage or some weird scam. It's not magic but the world of algo trading isn't a ponzi scheme.
What I was actually thinking about was the infamous Payment for Order Flow, where your broker doesn't actually send your orders to an exchange, but gets paid to send them to a giant HFT firm which can do whatever it wants with no oversight, including using the information that you are about to place an order to inform their algorithms which may result in them putting out a similar order before yours.
FYI, this is false. These HFT firms are subject to the same regulation as other brokers, which is extensive. In particular, it's explicitly forbidden to front-run pending customer orders, or to share any information about them with the proprietary side of the firm. In my experience, these firms take these rules very seriously.
How far have you tried to tell, and do you buy/sell stocks?
There's someone on the other side of your trade when you want to trade something. You're more likely than not choosing to interact with an HFT player at your price. If you're getting a better price, that's money that you get to keep.
*I'm going to disagree on "free pass" also. HFT is pretty often criticized here.
Hard to speak for HFT in general. Like in software, different firms have different levels of hygiene. About half of your bullet points were true of my previous employer, at my time of leaving.
I can see how you can come to this conclusion from this sentence, but it's a vague sentence with slightly-wrong premises, which leads you to this conclusion. If you're a programmer, I think you may appreciate this situation when others talk about your work.
I can address some parts of this.
"HFT works by reacting faster than another market participant"
- There are a bunch of different HFT strategies. In this case, we're usually talking about market making, which means you are placing limit orders at a price where you don't believe it will execute immediately. You can react to many things - price movements, events, anything.
- In placing a resting order, where is there an assumption that another participant was willing to do the same trade? Sometimes (pretty often) all the orders on a price level are HFT participants, and if you look at the market feed it's pretty easy to tell.
- In that case (which I claim is pretty common), the liquidity was not already there.
- If we consider that average spread sizes have reduced significantly with electronification and HFT, then you also disprove this assumption that "the liquidity was already there". Liquidity is not just the willingness to buy or sell, it's also the willingness to buy and sell at a competitive price. Otherwise, I mean, I'm always willing to pick up TSLA at $.01, and I'm always willing to sell TSLA at $500k. Doesn't mean I'm providing liquidity.
"They won't do a trade if there's no one to instantly sell to"
- That's simply not true. If you've taken a look at the order book, the fact that an HFT order is resting on the book (and not executed) means that there was nobody to instantly sell to.
- Are you suggesting that HFT firms all know that someone is going to come through and buy at a price level, and hop in? Flash Boys suggests this (and it's possible to infer some "whale" actions if they route their orders poorly), and that type of inference is possible sometimes, due in part to the way the US Equities ecosystem is set up. But I'll also ask you - have you thought about the order of operations in which someone might "know that there is someone to instantly sell to?" Consider the CME (futures exchange), where there's a ton of HFT, and for which there are no other markets. How is your sentence supposed to work?
- Also, perhaps empirically, that was simply not true for my firm, which was (and still is) a pretty successful one.
> I think you may appreciate this situation when others talk about your work.
Yes, I'm very much a layman on this topic.
> placing limit orders at a price where you don't believe it will execute immediately.
Isn't that a "SFT" strategy? Why do you need super low latencies for something like that?
> Are you suggesting that HFT firms all know that someone is going to come through and buy at a price level, and hop in?
That's how I've commonly seen HFT being described, that these companies would see an order on exchange A and faster than anyone else would bid on exchanges B and C accordingly.
I'm going to have to jump in here and say, no, HFT can and does not front-run your trade. There are reasons why your execution on RH is not as good as professionals, but it's not because of front-running.
Agreed with the rest, you should just look at job descriptions. Different firms use different technologies, but a devops person will probably be building tooling for monitoring live trading, or GUIs for themselves and traders. These tend to not be as performance-sensitive.
If you want to work on the trading systems, you should be good OS-level and network-level things. And you should probably know C/C++. I think some firms might still use Java.
Good firms have probably been around for a couple of years, so it's unlikely that they'll use the cool new languages of the day.
That's not true. Source: I work at an HFT. Rust is very interesting for Greenfield work. The major down side is millions of lines of legacy C++, the more useful already using C++17 or C++2a, which typically provides a lot of what you'd get out of Rust's stdlib and ecosystem but already packaged and integrated. When you choose Rust at an HFT you have to worry about integration with codegen tools (generating efficient Java/C++/$HDL and reasonable throughput Python for protocol definitions is table stakes at any HFT I've heard of) and build pipelines (which might already have distributed building/caching infrastructures and fancy packaging/deployment.
Rust has some benefits (and still integrates reasonably well at the ABI level), but modern C++ compilers are no slouches. Rust provides a friendly dev experience, which is a valuable thing, but a lot of the ecosystem advantages are old hat at companies with mature codebases.
I think Jane Street is using OCaml I’m not sure why did they decided to go with functional programming even though most popular firms are still using C/C++
Do you think using functional programming might have advantage over these programming languages
Jane Street has some blog posts talking about why they chose OCaml.
I'm very torn on this. I've used Rust to quickly prototype things that I think could be used I prod. It's fine. In some places it is better than what we had for C++, in most places it is very similar for experienced devs. I don't think Rust let me complete my code any quicker than if I had done it with standard C++ tooling.
The main issue I see with something other than C++ is compiler maintenance. gcc and clang generate very good code. There exists a good body of well optimized C++ for various use cases (various kinds of latency and throughput). It takes a lot of commitment to maintain and extend a compiler to keep it on par with gcc/clang and also still maintain a good stdlib for trading.
I think a huge benefit of owning your compiler in a functional language would be easier/better codegen, particularly the ability to sidestep some of the shittier hardware languages with a better DSL (since you already have some compiler and tooling expertise in-house). This matters at lot for HFT since at the most critical places, you want to use FPGAs or better.
I see. They are the only firm is pushing so hard on the use of functional programming. Everytime you do a google search related to FP you'll see them on the top
You were replied to, but I'm going to ask some questions of this moralizing.
> Many HFT jump out when things get volatile, when liquidity is actually required.
This feels almost like a "no true Scotsman" situation. Why is liquidity not "actually required" when volatility is low? Is it a moral obligation for any trader to catch a falling knife? I see this condition of "when liquidity is actually required", but I never understood why there was such a strong feeling for it. Why do you believe this?
> Ultimately HFT is doing nothing of societal value, the race down to zero is never-ending and we are wasting huge amounts of resources on a totally pointless march towards zero.
I don't know, I could probably take a similar view of so many jobs in tech. What does society really get from Snapchat, what do they get from HQ Trivia, what do they get from people making powerpoint presentations with arrows that point to synergies. What's the point of any job with some amount of abstraction?
> Exchanges should introduce random delays to allow market participants who really want to hedge / buy / sell, then we can shift some of the resources to the real world.
Why?
> The system is hugely inefficient
Do you know how efficient the system was before HFT started up? And, do you know how many people were working in trading before, and how many are, for a similar fraction of stock volume?
> Do you know how efficient the system was before HFT started up? And, do you know how many people were working in trading before, and how many are, for a similar fraction of stock volume?
Again this weirdly mixes HFT with electronic automated trading, which I really don't think anyone in the domain would readily mix.
HFT by arbing over latency is entirely different to the automation of boring trader tasks that see less people employed to do the same thing in the front office.
I can't continue this more, it's just blind allegiance from people who are clearly not in the domain.
It would be great if you included any sort of evidence or argument.
Reading on to the other comments, it looks like you're throwing out a lot of accusations and claims. I don't know what you think you know, but from the looks of it, you don't really know HRT's business. I don't really these days, but I knew it years ago, and it's not from taking client money or arbitrage or some weird scam. It's not magic but the world of algo trading isn't a ponzi scheme.