neuronsguy

If you have the option then the country is not your primary concern. The quality of your PhD experience is 95% determined by the quality of your supervisor and lab-mates. So you should judge based on that irrespective of the country. How much attention can they give you, how successful have previous students been, etc?

My recollection is that I usually found the lectures to be as exciting as the lecturer did. So if he was excited, so was I.

Are you perhaps not sufficiently conveying your interest in the topics to the students?

I think it means Individual Contributor work, so he's coding stuff not managing people

Trading. Check out firms like Optiver, Jump Trading, XR, etc. Big bucks for FPGA devs

I think that term encompasses a wide range of designs.

The article seems to be describing a particular style of event-driven architecture, used to organize code within a single process.

First thing is you need to actually be a good engineer. No point optimising if you suck, just put your head down and learn.

Next thing you need to know is the rules of the game in YOUR organisation. Every company is different and the rules are different. Google is unique, so at other companies the game is very different.

Then you need to move the needle on whatever matters. That might be improving metrics, that might mean becoming drinking buddies with the right people, it might be purposefully going to work for a failing team so you can be given the chance to take it over and prove yourself.

You are correct about the tech industry here (low salaries relative to US) but developers working in finance in London make comparable money to Bay Area tech firms.

People routinely get paid £100k straight out of university to write code in London, just not in the tech scene. Total comp in the financial sector with 5 years experience is commonly £200k.

Which is not 'ludicrous' but more than you might imagine from seeing £40k job postings in the web dev sector.

Here's a great idea: bitcoin settlement, custody, and clearing for institutional investors. There is a huge first mover advantage to be had signing up to prime broker every hedge fund's bitcoins and help settle OTC transactions. I know people who need this. Good luck.

Some things to avoid early on so you can get a working app out quickly:

1. Don't build OO abstractions, just use structs as data and operate on it with free functions.

2. Don't be afraid of long argument lists with lots of references, where the last one is possibly mutable, C-style

3. If something needs e.g. 2 different structs as inputs and mutates a third one, make it a free function, don't impl it on any of the structs.

4. Don't overdo it trying to use the functional idioms for options and results like and_then or_else etc. Just use match and eventually it will be obvious where those fit.

5. Don't worry too much about error handling, just use expect and explicit panics

6. Don't implement your own data structures, compose the std lib ones

7. Get good at using match and enums to represent state and transitions

Once you've got some more experience and you want to try to write more elegant code, you will run into ownership issues.

1. Use guard types. Basically a struct that owns a pointer into some larger data. Write a lot of these with useful utilities for manipulating that data

2. Use guard types for mutating data as well. I tend to have a type which is a big bag of data (often carefully laid out in memory for performance), and then separate types whose only purpose is to contain references to e.g. 2 or 3 different pieces of data that need to be simultaneously used. That type allows you to do whatever that operation is. This saves a lot of borrow checker fighting.

3. Think in a data centric way. What data do you need? What operations need to be performed? Then design your ownership hierarchy such that that can happen.

Finally you will run into frustration structuring large projects.

1. Use cargo workspaces. Isolate self contained chunks of functionality into crates.

2. Implement stdlib traits like Iterator, From, Into

3. You can use associated types to do statically checked dependency injection. In combination with default trait implementations it's a decent way.

4. Use free functions liberally inside modules, but export mostly traits, data structs, and operation structs.

5. Use rustdoc comments in your code and refer to them.

A lot of the above is opinion and might not work for everyone. I submit that it's "a path" of many for getting productive quickly and then scaling up to writing larger systems.

(Crosspost of a comment I made on Reddit: https://www.reddit.com/r/rust/comments/6rxw21/comment/dlb048...)

Which did you prefer?

I currently work in the former environment (but everyone is like that guy), and it's super noisy and distracting but also fun.

This sounds cool. Two questions:

1. Without giving away secrets, how do you find such clients?

2. You must have some great stories. Would you care to share any?

I'm including the Gryadka author's rebuttal here, for completeness:

Thank you for the analysis of my post but it seems that you didn't get it correctly. Even to read a value you have to execute the full cycle (prepare, accept) of consensus (in the case of the stable leader we can skip prepare), so when you read the nil value the state of the system will be:

A: (value=foo ballot=1 promised=2) B: (value=nil ballot=2 promised=2) C: (value=nil ballot=2 promised=2)

Not the one you mentioned in the post:

A: (value=foo ballot=1 promised=2) B: (value=nil ballot=0 promised=2) C: (value=nil ballot=0 promised=2)

So the counter example is incorrect.

I proved the algorithm mathematically by hand and used very aggressive property based testing with fault injections so I'm pretty confident in its correctness.

No. I think he understands exactly what the article means, and is correctly stating that it is not necessarily foul play at all.

Yes that's what I worked out as well. That's not doing any operations just storage.

That is specifically if you want to get a job as a trader.

The best way is by spending time playing poker, bridge, etc. Sports betting is also good. Any game where you are making decisions facing asymmetric payoffs under uncertainty.

Trader interviews for students tend to focus on whether the candidate can be rational and self-consistent. "How much would I have to pay you to not wear a seat belt on the ride home?" "You roll a 100,000-sided, and if it's a 6, you die. How much would you pay not to play that game?" Your answers to both questions should be self-consistent.

Asymmetric payoffs: tell me an interval around the number of bus stops in Taipei, where you'd be willing to bet 20:1 your interval contains the true answer. People make the interval way too tight. The interviewer chose this question to ask you. He knows the answer, and since he asked you this question, he probably also knows it's something surprising that people get wrong. 20:1 is a huge asymmetry. You should be afraid of making this bet.

That said I'm not the best person to ask about this, it's not my strong suit.

Depends what your goals are.

If you want to get a job at an HFT e.g. Jump: as a student you're not expected to know much about finance or trading, the prerequisite knowledge is similar to getting hired at eg Google. I work at one of these firms, when we hire people we have them come in and code in an IDE of their choice on a problem of our choice for about 2 hours, and we watch them do it and discuss it after. We also do algorithm interviews, and try to find people who are demonstrably smart and also excited to work with us (note this is for dev roles. If you want to work on trading roles you need to have a strong intuitive grasp of probability, games and asymmetric payoff situations, these will come up in interviews).

If you want to get a job as a quant: other comments here have addressed this.

If you want to learn about algorithmic trading from a tech perspective: go read some exchange specs (BATS, CME, Eurex tech specs and market model). That's the nitty gritty and you'll learn more about trading from that than anything else you can do if you're not employed in trading.

If you want to learn about machine learning in the context of finance: get a job at one of the quant hedge funds like Two Sigma. You do not have access to the data you would need to learn on your own, and you cannot afford to get it yourself.

In general to learn about modern algorithmic trading you have to work in the industry, there is almost no public information of any value (maybe read the Sniper in Mahwah blog if you haven't, he's pretty smart).

If you want to get a job you do not need to learn about this, you just need to be worth teaching it to.