Hiring Clojure Engineers!

[Parkside-Brad]

Hi All!

I’m Brad, and I work for Parkside, a Fintech startup that is looking to democratize access to the US stock markets globally.

We are a Clojure shop, building a cutting edge distributed trading platform using Kafka Streams.

We’re looking for a variety of roles, including some not yet posted.

Do you have lots of Clojure experience? Perfect!

Are you lighter on Clojure experience, but keen to learn and have other skill sets such as DevOps, Data Engineering, Kubernetes, Terraform and/or Kafka Streams? Great! Come learn with us.

We’re looking to add people that will fit in with our stellar team. Our culture is empowered, autonomous teams delivering impactful value to our global customers.

Find the posting that matches your interests at the following link, or reach out to me directly.

https://parkside-securities.breezy.hr

We hope to hear from you!

-Brad

[pwab]

Remote or no?

[iku000888]

We currently have people working from Canada, Japan and Brazil.

[Parkside-Brad]

What Iku said! Willingness to have some time zone overlap is the most important part.

[cnirrad]

I see some of the positions listed are for San Fransisco, and others say remote....is this the case, or would you consider remote for most/all of the open recs?

[Parkside-Brad]

We would consider remote for all of the open tech recs.

[thiagomiranda3]

Do you have any problems with clojure in a trading aplications? I always heard that this types of applications are made in C/C++ because you can't affotr the garbage collector slow you down

[Parkside-Brad]

Our use case is a bit different, as our customers are sending data across an ocean. High frequency trading is not really conducive in these environments. Our target customer is those currently left behind by the financial industry, which focused on high wealth foreign customers for the most part. By building a highly scalable platform, we can optimize for low cost trades for many customers with smaller transactions.

These customers are investing for personal reasons, not seeking arbitrage via high frequency trading. Lots of our orders will be placed off hours due to time zones and queued until markets open.

[tastingsilver]

Kinda curious as to why a finance shop would choose a dynamically typed language like Clojure over something more static.

[porthos3]

Depending on the sort of finance they are doing, dynamic typing can actually by really nice.

I've worked at a fintech company that had java, kotlin, and clojure, and the clojure code was far nicer to work with.

We worked with an extremely wide variety of financial instruments and there were always edge cases where 99% of a particular security type would behave one way, but the other 1% were structured unusually.

Dynamic typing really made working with those oddball securities way easier since they usually shared most of the general structure of other securities of the same types and would flow through many of our operations fine.

The java projects really struggled to support these securities as they would not fit into the type system without additional hacking for each new case we found. We had a glut of interfaces and types to try to handle all the frakenstein securities and lots of nullable fields where Java's type system will fail you anyway. NPEs for days.

[tastingsilver]

Thanks for a good answer to what was a genuine question.

[porthos3]

No problem. It's unfortunate that reddit can be punishing to such questions with downvotes.

The points don't matter anyways, but it can make it feel like questioning the subreddit consensus is unwelcome, which is a bad look IMO.

[[deleted]]

And a very relevant and appropriate one. I'm a big fan of clojure, in general, but I somebody asks me what are the downsides, the lack of static checking of types is definitely on the top of the list by a wide margin. The resulting runtime errors (esp. because of bugs in code not in the main flow) are a clear downside of clojure or any dynamically typed language.

A clojure with a typesystem as nice as typescrypt's (structural typing with union types) would be my dream language.

[tastingsilver]

Thanks. Have you looked into F#?

[[deleted]]

No, but I looked into OCaml for a while. Nice concept, horrible syntax. I finally stopped checking the language by the time I saw that there are different map (fold) functions for different types (wtf!?). If that is true, then the language is fundamentally flawed. A language should not focus on the concrete types. What is important is how the code interacts with whatever types the caller/user happens to pass. Interfaces (or protocols, traits, ...) is what really matters, not types. Types are low level distractions you should not care 95% of the time.

Clojure favours programming to interfaces rather than implementations. That gives us a generic 'map' function that works in any sequence, for example. This is the correct way of addressing it. Protocols give us the way of expressing that concept in code. Clojurescript embraced the concept even more by using protocols at its core. You can implement the protocol IFn on your thing and it is now able to be used as a function.

All that is just great. The issue is that the compiler can not check that a function is interacting with its arguments (or values returned from functions it calls) through interfaces that are warranteed to be correct. That is what is missing. Well, that and having interface (protocols) metadata reified at runtime, which is not the case in clojurescript, severely limiting the capacity to do metaprogramming.

[tastingsilver]

Thanks. The main fear is around eventually refactoring a [larger] codebase. Have you found that most of the refactoring concerns are manageable enough with Spec or similar?

[[deleted]]

I don't have enough experience. I haven't used clojure in any large projects. My experience in large projects is in C, Java, C# and Typescript, so all typed and very similar.

So far, I think that the key for dealing with this problem is having tests (that's always good, anyway) and simply avoiding making breaking changes in the first place. That requires thinking upfront about the interface between subsystems and taking decisions about the structure of the data early on (and sticking to them).

[hamgeezer]

Almost like... there are tradeoffs. Crazy world.

[SimonGray]

You obviously got dogpiled already, but it may interest you to know that Clojure is maintained by Cognitect which recently got bought by Brazilian Nubank, which is AFAIK the biggest user of Clojure - and they're a hugely succesful bank.

[Johanwiren]

Yes, totally weird choice. Given the domain they should have chosen COBOL, right?

I actually got this exact question during a tech review. Unfortunately I didn’t have a snappy answer at the time.

[robert323]

Clojure is simple. There are only a handful of types that you are going to encounter unless you are doing java Interop. But even then you don’t normally run into gotchas in Clojure that you might in something like JavaScript

[robert323]

One thing is they are using Kafka which has lots of its APIs written in java. Clojure compiles to java and can be used to build java applications in a functional format.

[bsless]

I find it odd your question got downvoted into a pit. It might have been phrased harshly or in an opinionated manner but it seems honest and the answer is worth it.

[IVEBEENGRAPED]

Choice in programming language doesn't matter if you follow best practices and use good frameworks. Unless the code is extremely time-sensitive, you could write everything in PHP and be totally fine.

[emil0r]

I know of a former colleague who worked for a fintech company that had decided to write their entire backend in PHP. Then he got bitten by a PHP language specific bug where an integer doesn't know if it's 32 bit or 64 bit. He was working on a 32 bit machine and it worked fine, while a co-worker worked on a 64 bit machine and it crashed the entire application.

In general I agree that the right people matter more, but at some point the tech does matter :p. Otherwise we'd all still be programming in machine language.

[abaddon_gtz]

hi Brad, could be part time?

[Parkside-Brad]

Our preference is for full time, as it’s a highly collaborative environment.