Just had the realization that Starfighter believes there's a huge market for the sort of talent matching they want to do in finance. Why else would they pick this topic?
Networks. Compiler theory. Language design. Web APIs. Caching layers. Core algorithms. Packet switch microcontrollers. FPGAs. CRUD apps. Big Data. Anti-abuse tooling. Application security. Machine learning. Any topic you possibly want to throw an engineer at, an investment bank is already throwing a team of engineers at.
Our Chapter 1 release includes levels which have you jailbreak multiple chips (AVR microcontrollers) on a custom handheld device given to minimally trusted gophers to own up a stock exchange through their REST API. And that isn't even a theoretical attack.
Additional factors which tipped the scales include "finance has a default goal function which is really easy to understand", "some subsets of financial work are surprisingly easy to model" (like a stock exchange is), and "finance has narrative choices which allow us to excite people without getting typecast as A Video Game For People Who Played Dungeons and Dragons In High School" (which is, for a variety of reasons, important to the team, including to me, the ex-DM).
Other strong contenders for our first game were "Like Dwarf Fortress but with code" (harder to build than a stock exchange; includes the word "dwarf") and "a nuclear power plant" (slight problem: we know nothing about nuclear power plants).
This comment makes me feel that I must live in an alternate universe of software engineering. I've spent 99% of my career working on things that would be of no interest to an investment bank: GUIs, graphics, video, audio, GPU rendering, mobile platforms, CAD, content creation tools...
(It's not the first time I've had this feeling. At one point years ago, when I had been doing professional programming for maybe 3 years, a friend and colleague asked me a question about databases. I had to confess that I had never worked on software that interfaced with one; that all my work exclusively dealt with local files and network streams. He almost wouldn't believe it.)
One of the many interesting conversations I've had over the last few months is with a guy who leads a team of X00 developers out of one bank's 1X,000 developers, which does minimally GUIs, graphics, GPUs (for rendering and simulation), mobile platforms, and content creation tools. His #1 problem right now is that you are representative of many, many developers who don't know that his sort of group exists. I think he'd describe his job as "We're the thin edge of the wedge hitting the really hard problems so that our customers in the bank can focus development on the really valuable problems."
(I don't know if I'm cleared to talk about them until contract negotiation wraps. Sorry, not trying to be coy here. Take it on faith that many of the big guys run shops which have those needs and more besides.)
I'd like to provide a data point for this, btw. There are exchanges for sports gambling (we run one), and some of the most succesful betting syndicates run clusters of hundreds or even low thousands multi-GPU servers to crunch the incoming data on their real-time simulations. The results of this type of crunching are feeds, signaling and strategy shifts for their market makers.
I have no doubt investment banks, who operate on an order of magnitude more data, would have something similar. Even if majority of it was used for backtesting.
Now that I think about it, I have no idea what investment banks are really like as work environments. The caricature in my mind is a rigid hierarchy populated by career-minded sycophants who judge people based on the college they attended; bosses that would be played by Alec Baldwin in fiction; software stacks sold by Oracle salesmen on golf courses; senior architects who manage via UML drawings; workdays that extend to 9pm just because; and for a touch of fun, brokers who throw half-eaten lobsters at each other on Friday nights.
In all, the kind of place that would have absolutely no interest in hiring me and where I would never imagine working... Maybe my prejudices would need a reality check.
Tech in investment banks is full of, well, developers. I'm currently working on stuff that has X0,000 cores, X00 GPUs (compute though not rendering), web UI, large data aggregation and visualisation (around 1bn data points moving in near real time). I don't do fpga work but I sit near some chaps that do.
In fairness, I haven't done any CAD or audio at a bank. However, I did design sonar absorbing materials prior to working in finance and there's a surprising amount of similarity in the engineering I did then and the statistical sims we do now.
Oh, and lobster night is Tuesday night.
Isn't that a problem in Silicon Valley too?
If that's the case, why are you having to post about it on HN? Why isn't he out here proselytizing?
It sounds like an interesting field. Needs some better marketing. :-)
Also Patrick has shown skill at marketing to the folks he wants to market to, so why not outsource it?
Mobile platforms: ...and they want to do this all from wherever they are. :)
Starfighter is divided into N tech trees, where as of the Chapter 1 release N = 2. Each has a distinct player-facing UI and, generally, some specialized backend systems, but they're all a part of the same product, behind the same login, running off the same message bus. Each tech tree has a series of levels: start at level 1, beat it and unlock level 2, etc. The levels do not necessarily progress linearly and trees can interact with each other in terms of level requirements, although I don't know if any levels requiring, etc, "passed $FOO in algorithmic trading and either $BAR or $BAZ from low-level programming" will ship in Chapter 1.
Each level has its own goals/victory conditions/etc. There may be interplay between levels, such that your past/simultaneous performance on one allows you to do X, Y, or Z advantageous thing in the other. Those interactions might happen across tech trees. I am saying "might" here because I haven't coded any level which actually does that but it came up at design meetings and our systems support it -- not sure if it will happen in Chapter 1 but I'd rate it as "highly likely" it happens in Chapter 2.
Chapters: we intend on doing a new content release (which adds to, rather than replaces, existing content) every 6~8 weeks, with a new tech tree introduced roughly every 2~3 chapters.
Would love anyone's thoughts on "How do I explain this succinctly such that I don't turn-off anyone who is less interested in a particular tech tree?"
I think I get what you mean by "tech tree", it's a phrase borrowed from real-time strategy games, yeah? Some of your other descriptions sound a little bit like what someone might find on a Steam game. If I hadn't played Sins of a Solar Empire (very occasionally, I don't have much time for it anymore), I think I'd be pretty lost.
Your current terminology is probably fine, it just needs some graphics to go along with it -- a basic chart or something. I bet you've already got such a thing in progress and it'll all make sense on launch.
> How do I explain this succinctly such that I don't turn-off anyone who is less interested in a particular tech tree?
Any chance you can partition your newsletter subscribers into "low level programmers" and "wannabe market hackers"? I think the misunderstanding is that you only talked about stock market concepts to an audience that included people that are only interested in low level programming.
Not a fan of "worlds" as proposed below. I have a feeling we're all just projecting our own favorite genre conventions here, but your different approaches remind me of different characters more than anything else. Ever play a game where you had a choice of approaches with different characters? Or had to switch between them and coordinate action or share information?
I'm sure there's plenty of people who possess the union of these skill sets (and of course, there will be plenty of actual human players that will), but you could describe your trees more as character growth/background/capabilities/backstory.
You would then have interesting story possibilities here—I would love the idea but I suspect you guys might consider story elements as potentially distracting.
Starfighter is a game with lots of worlds. In each world there's a whole bunch of levels. Finish one level, move to the next. There's no "last level" or "final boss" because every few weeks new levels appear. Sometimes whole new worlds are created too. Each world is totally different and getting good at one might not help you in another (think of it like a video game, where in some worlds you walk on land but in some you have to swim, and in some you have to walk upside down). If you finish all the worlds you might get offered a job so you can do more levels in real life.
Or lots of other games. The tech tree metaphor seems a lot better game-jargon metaphor than the worlds-and-levels alternative you propose.
I've worked with tons of extremely bright, well credentialed people who get lost in the weeds of analysis paralysis or trying to build the world's most complex model. Many fail. The best hires I've made internalize the nuts & bolts quickly, work hard to try many ideas, and are "smart enough." They're probably just as smart as the other guys actually but use intelligence as a tool rather than an end unto to itself.
That said there is also one other thing that prevents me from looking at a career in that kind of business: I imagine the traders as the kind of people with no empathy who are just looking to metaphorically stab you in the back the second they get a dollar in bonus for doing so.
Further, the very concept of what a "trader" is has fundamentally altered in the last 15 years. A trader is just as likely to be a physicist or hold a PhD in signals processing today as they are to be your typical "Tall Guy With Aggression issues".
I'd also point out that lots of people co-mingle different industries. Trading is not investment banking, which is not asset management. There are interesting software problems and good people working in all those fields.
Aside from systematic errors like Knight, market-makers rarely blow up due to competition or a bad model, they just fade away. They make or lose money pretty slowly, they just do it consistently over time.
Aside from the most basic strategies there isn't one "right" way to price a market. It's an engineering problem like any other. How much risk do I accumulate? How should I manage this risk? How far apart should I set my bid and offer? Do I use a simplistic model with lower latency or a more complex one that's slower? Is it better to be more accurate and avoid bad trades or less accurate and build up priority in the order book by staying on a price longer?
A market-maker's objective function is to maximize total profit (turnover * average gain/$ traded) while controlling risk (volatility of P&L over time). Usually changing your answer to questions like the ones above will shift turnover one way and profit per trade & risk in the opposite direction. For example, if you quote your bid and offer very close together, you'll trade large market share and have less risk exposure since you get in and out of positions very quickly, but your profit per trade will be low (if traders arrive randomly, at best you will make the small spread between your bid and offer, in reality a fraction of that since they usually have a reason to trade against you). If you set your quotes wider, you'll make more per trade on large dislocations, but do less volume and hold more risk.
There are a lot of efficient points along this continuum and traders play to their strengths. Someone with little capital/risk tolerance, top-tier infrastructure, and forecasting models for the next price tick should play very differently than someone with a lot of capital, average infrastructure, and models that can forecast the next 10 minutes.
And you are right regarding bonuses, but all team efforts have this problem. Who creates value and deserves the best compensation in a SaSS startup? Is it the salespeople who get clients? The engineers who build the software? The Ops team that keeps it running reliably? I actually find trading to be a bit more meritocratic than other tech jobs: either you make money or you don't, and teams are smaller so it's easier to assign reward (or blame).
I can't think of many options with all of these properties that also require the particular technical skills they're looking for. It feels like doing a market simulation reasonably well is actually easier than their other track (a security CTF).
One particularly nice aspect is how many skills an exchange simulator can test. You have low-level programming and optimization, interesting algorithmic problems and high-level data analysis. That's applicable to a lot of jobs outside of finance. As a game, it's surprisingly open-ended.
Personally, I'm glad they chose this. I actually wrote a market-making bot for a mock exchange as part of an internship. It was fun and a great learning experience and not just for finance. I'm glad somebody is bringing this experience to the public at large.