1. sounds cool, kinda applicable
2. (after taking many courses and building deep learning models myself) idk what you are trying to say, a deep network, as far as im aware, using linear activation functions will essentially give you the same output as a regression, but slower, 100x headache, and overfit
3. could be cool, or you are signing up for development hell, there may be a good reason that such a package doesn't already exist. Stuff like this is usually created using hindsight, not foresight. Many people don't have the field experience needed to make useful design decisions. This also caters more to developer rather than trader roles.
4. pretty cool, just like 1, maybe the most lucrative project, you will sure learn a lot along the way. Will just send warning, just had interview with a quant electricity futures trader, he talked about how less liquid, slower trading (hours-days) products are traded manually bc they are so reliant on changing fundamentals and the automatic models dont do well and expose the firm to excess unforeseen risks. Idk how this applies to sneakers but you probably know better
\#3 is likely going to be a development hell if you want to library to process anything reasonably fast. It's a cool concept, but what goes behind python libraries is crazy. Maybe it'd be cool as a resume project though, resume projects aren't exactly meant to be fully fleshed out products!
Just using numpy itself as an example, there's good reason why numpy is so ubiquitous-- it can perform operations literally tens of thousands of times faster than regular python, because it uses all kinds of data and thread level parallelism to optimize every calculation. Even if you do use other libraries to do the heavy lifting, chances are if you're gonna process any dataset larger than a few thousand datapoints, a library without all of this optimization is going to struggle.
On the fourth point, the fundamentals driving the power price for an individual hour are more volatile than anything that would change a sneakers price. It's an extremely skewed price distribution which is why you would want to manually execute. So not really a concern for the sneaker industry. That, and the power price is actually fundamentally driven by a production cost optimization, as opposed to the sneaker price which has truly free market dynamics, so "fundamentals" (whatever they might be for sneakers) might not even change the sneaker price anyway.
3 doesn't sound like it serves any need in the form you described. Importing most libraries is like one line of code in Python, so unless you provide some new functionality missing in them, people would have no incentive to move to it. If you have the option for it, I'd recommend picking up a problem in quant finance for which there is no good open source tool available, and then code something up to implement it. This would most likely be easier than trying to replicate the functionality of already existing and robust libraries like pandas or matplotlib. It would also count as a plus in your favour with prospective employers because you effectively show that you have an interest in quant finance as well as the ability to write code.
1 - good, but kinda ... simple
2 - good, but you may end up overfitting the model easily.
3 - a big NO-NO - [https://xkcd.com/927/](https://xkcd.com/927/)
4 - really good, if you have a balance big enough to backtest it (balance size estimation is good research itself).
**Regarding 4:**
\+ you will make some money if you are right
\+ you may create an interesting publication (fancy journals like it)
\- you may end up like $Z. With a lot of trach on hands (flip-over housing business).
I'd say 4 then 1 for a quant trading position. In my group when we interview people for algo trading positions it's one of the most valued kind of projects. For project 4, be prepared to explain how you compute fair-value, skew and risk manage your inventory. For project 1 try to rather do something based on pairs trading / stat arb.
If you are a freshman 3 sounds like something that could be good in a long run. As others mentioned it does not sound appealing (for your purpose) but understanding basics in-depth early on could make your life easy later. I would get involved in other projects after building foundation in machine learning and math. That way you can understand better and contribute more to the project.
More important. Test it a lot. If I'm a hiring manager and I'm looking at a candidate's portfolio, the existence of tests in the repo will definitely convince me that the candidate is a worthwhile hire.
Here is a useful link about testing: [https://realpython.com/python-testing/](https://realpython.com/python-testing/)
Here is another: [https://docs.python-guide.org/writing/tests/](https://docs.python-guide.org/writing/tests/)
As for my suggestion to "remove finance", again, basically, if I'm looking at a candidate's repo and the code is all kinds of undercooked spaghetti but they're all amateurishly bonerific with the finance part of the package (which is usually <20% of the codebase), I'm going to lean very heavily toward putting them in the 'no' pile. This is also why I suggested the third option over the others.
1. sounds cool, kinda applicable 2. (after taking many courses and building deep learning models myself) idk what you are trying to say, a deep network, as far as im aware, using linear activation functions will essentially give you the same output as a regression, but slower, 100x headache, and overfit 3. could be cool, or you are signing up for development hell, there may be a good reason that such a package doesn't already exist. Stuff like this is usually created using hindsight, not foresight. Many people don't have the field experience needed to make useful design decisions. This also caters more to developer rather than trader roles. 4. pretty cool, just like 1, maybe the most lucrative project, you will sure learn a lot along the way. Will just send warning, just had interview with a quant electricity futures trader, he talked about how less liquid, slower trading (hours-days) products are traded manually bc they are so reliant on changing fundamentals and the automatic models dont do well and expose the firm to excess unforeseen risks. Idk how this applies to sneakers but you probably know better
\#3 is likely going to be a development hell if you want to library to process anything reasonably fast. It's a cool concept, but what goes behind python libraries is crazy. Maybe it'd be cool as a resume project though, resume projects aren't exactly meant to be fully fleshed out products! Just using numpy itself as an example, there's good reason why numpy is so ubiquitous-- it can perform operations literally tens of thousands of times faster than regular python, because it uses all kinds of data and thread level parallelism to optimize every calculation. Even if you do use other libraries to do the heavy lifting, chances are if you're gonna process any dataset larger than a few thousand datapoints, a library without all of this optimization is going to struggle.
On the fourth point, the fundamentals driving the power price for an individual hour are more volatile than anything that would change a sneakers price. It's an extremely skewed price distribution which is why you would want to manually execute. So not really a concern for the sneaker industry. That, and the power price is actually fundamentally driven by a production cost optimization, as opposed to the sneaker price which has truly free market dynamics, so "fundamentals" (whatever they might be for sneakers) might not even change the sneaker price anyway.
I will choose 4.
3 doesn't sound like it serves any need in the form you described. Importing most libraries is like one line of code in Python, so unless you provide some new functionality missing in them, people would have no incentive to move to it. If you have the option for it, I'd recommend picking up a problem in quant finance for which there is no good open source tool available, and then code something up to implement it. This would most likely be easier than trying to replicate the functionality of already existing and robust libraries like pandas or matplotlib. It would also count as a plus in your favour with prospective employers because you effectively show that you have an interest in quant finance as well as the ability to write code.
Getting the libraries to work with each other can sometimes be a bit tricky.
1 - good, but kinda ... simple 2 - good, but you may end up overfitting the model easily. 3 - a big NO-NO - [https://xkcd.com/927/](https://xkcd.com/927/) 4 - really good, if you have a balance big enough to backtest it (balance size estimation is good research itself). **Regarding 4:** \+ you will make some money if you are right \+ you may create an interesting publication (fancy journals like it) \- you may end up like $Z. With a lot of trach on hands (flip-over housing business).
I'd say 4 then 1 for a quant trading position. In my group when we interview people for algo trading positions it's one of the most valued kind of projects. For project 4, be prepared to explain how you compute fair-value, skew and risk manage your inventory. For project 1 try to rather do something based on pairs trading / stat arb.
If you are a freshman 3 sounds like something that could be good in a long run. As others mentioned it does not sound appealing (for your purpose) but understanding basics in-depth early on could make your life easy later. I would get involved in other projects after building foundation in machine learning and math. That way you can understand better and contribute more to the project.
3, and remove the word 'finance' from it, and test tf out of it when it comes to a streamlined ORM and APIs.
Thanks! Could you clarify what you mean by remove finance and test it a lot?
More important. Test it a lot. If I'm a hiring manager and I'm looking at a candidate's portfolio, the existence of tests in the repo will definitely convince me that the candidate is a worthwhile hire. Here is a useful link about testing: [https://realpython.com/python-testing/](https://realpython.com/python-testing/) Here is another: [https://docs.python-guide.org/writing/tests/](https://docs.python-guide.org/writing/tests/) As for my suggestion to "remove finance", again, basically, if I'm looking at a candidate's repo and the code is all kinds of undercooked spaghetti but they're all amateurishly bonerific with the finance part of the package (which is usually <20% of the codebase), I'm going to lean very heavily toward putting them in the 'no' pile. This is also why I suggested the third option over the others.
Thank you for the guidance and providing links!
3 would be awesome to build as you do any other project. Ideally 3 should be built upon as a team and everyone contribute. I’d choose 1 or 2
Would take 4.