arohner

Griffin Bank | Engineering | REMOTE (UK) Company: We are Griffin Bank. We are a fully authorized, API-first bank; we bank fintechs and startups. We built our own core banking system from scratch. Experience: We are hiring across broadly across engineering. The things we work on include onboarding and KYC, payments rails, accounting, billing and reporting. We are hiring backend and frontend engineers. We are currently about 80 people, with 30 of them in engineering.

Tech: Clojure, FoundationDB, Bazel, CLJS, Svelte

https://jobs.ashbyhq.com/griffin/c8eaae48-e84f-4dae-8c34-099...

The Clojure version is not AOT'd, so it's measuring startup + compiler time. When properly compiled it should be comparable to the Java implementation.

It's fairly strictly enforced. The reason is that in many jurisdictions, you can accidentally create employment tax liability by working remotely for too long in the country.

Griffin Bank UK uses it for our entire system (https://griffin.com)

Griffin Bank | Engineering | REMOTE (UK) Company: We are Griffin Bank. We are a fully authorized, API-first bank; we bank fintechs and startups. We built our own core banking system from scratch.

Experience: We are hiring across broadly across engineering. The things we work on include onboarding and KYC, payments rails, accounting, billing and reporting. We are hiring backend and frontend engineers. We are currently about 80 people, with 30 of them in engineering.

Tech: Clojure, FoundationDB, Bazel, CLJS, Svelte

Apply: https://jobs.ashbyhq.com/griffin/8d98eb78-e281-4860-b578-fc1...

Griffin Bank | Engineering | REMOTE (UK)

Company: We are Griffin Bank. We are a fully authorized, API-first bank; we bank fintechs and startups. We built our own core banking system from scratch.

Experience: We are hiring across broadly across engineering. The things we work on include onboarding and KYC, payments rails, accounting, billing and reporting. We are hiring backend, frontend and design system engineers. We are currently about 80 people, with 30 of them in engineering.

Tech: Clojure, FoundationDB, Bazel, CLJS, Svelte

Apply: https://jobs.ashbyhq.com/griffin/8d98eb78-e281-4860-b578-fc1...

Clojure does have stateful quickcheck library now: https://github.com/griffinbank/test.contract

Parallel testing is interesting, but hasn't been a large source of pain yet.

We could in theory bank other banks, but that's not our focus. Our current customers are mostly regulated non-bank financial institutions, E-Money and Client money. As an American analogy, think Square Cash, Venmo, Paypal.

Longer term our aspiration is to also be the business bank for technology companies e.g. Apple or AirBnb or Uber. Currently Goldman is a big player in that space.

It is a tall order, but but it's doable. The most important thing is to reduce the surface area of your application. Our business logic is almost entirely pure. The 'procs' have no side effects, except for things that happen on the other side of a clojure protocol (java interface). That means all side effects can be stubbed out during tests.

Our "user" code has no access to threading libraries. Threading happens in "kernel" code.

Watch https://www.youtube.com/watch?v=4fFDFbi3toc for a good example of how this has already been done in practice.

What is the performance problem?

Griffin (https://www.griffin.sh) | UK, Ireland, Germany, Sweden, Portugal, Estonia | Full-time | Remote | Engineering

We're a new Banking as a Service provider (think AWS for financial services) currently seeking authorisation to become an API-first, fully regulated UK bank.

We believe that in the future, most financial innovation will happen outside banks rather than inside them, and Griffin will be the platform that all future fintechs use rather than the legacy big banks.

And a bit more about us: https://griffin.sh/culture We're looking for thoughtful people who strive to be kind in their words and actions. As product designers, we are always looking for ways to simplify complex things and we take security very seriously. As a financial institution, we believe that our customers' trust is our single most valuable asset and we will go above and beyond to earn and keep it.

Our backend stack is Clojure, FoundationDB, Kubernetes and AWS

Our frontend stack is CLJS, Reframe, Reagent, React, Stitches, Storybook, and Playroom.

Our build system is Bazel, CircleCI, AWS CDK We have an office in London but our team are distributed throughout the UK, Ireland, Germany, Sweden, Portugal and Estonia. See our jobs page for more info: https://griffin.sh/careers

We're hiring for this role in the UK and parts of the EU: https://boards.greenhouse.io/griffin/jobs/5252742003

Revolut is not a bank in the UK

Griffin (https://www.griffin.sh) | UK, Ireland, Germany, Sweden, Portugal | Full-time | Remote | Engineering

We're a new Banking as a Service provider (think AWS for financial services) currently seeking authorisation to become a fully regulated bank, so that we can provide safeguarding and client money bank accounts to our customers. We believe that in the future, most financial innovation will happen outside banks rather than inside them, and Griffin will be the platform that all future fintechs use rather than the boring big banks.

And a bit more about us: https://griffin.sh/culture

We're looking for thoughtful people who strive to be kind in their words and actions. As product designers, we are always looking for ways to simplify complex things and we take security very seriously. As a financial institution, we believe that our customers' trust is our single most valuable asset and we will go above and beyond to earn and keep it.

Our backend stack is Clojure, FoundationDB, Kubernetes and AWS

Our frontend stack is CLJS, Reframe, Reagent, React, Stitches, Storybook, and Playroom

Our build system is Bazel, CircleCI, AWS CDK

We have an office in London but our team are distributed throughout the UK, Ireland, Germany, Sweden and Portugal.

See our jobs page for more info: https://griffin.sh/careers

Griffin | Senior Engineers | London | REMOTE (UK, Ireland, Germany, Portugal, Denmark, Netherlands)

Griffin is building an API-driven online-only UK bank. Think AWS for financial services. We're building APIs to create bank accounts, make payments, issue cards. We believe that in the future, most financial innovation will happen outside banks rather than inside them, and Griffin will be the platform that all future fintechs use rather than the boring big banks. Our tech stack: Clojure, ClojureScript+React, Kafka, Datomic, Kubernetes, AWS. We're hiring for backend, frontend and infrastructure engineering. See the complete list of jobs at https://griffin.sh/jobs

Griffin | Senior Backend and Infrastructure Engineers | London | REMOTE (UK, Ireland, Germany, Portugal, Denmark, Netherlands)

Griffin is building an API-driven online-only UK bank. Think AWS for financial services. We're building APIs to create bank accounts, make payments, issue cards. We believe that in the future, most financial innovation will happen outside banks rather than inside them, and Griffin will be the platform that all future fintechs use rather than the boring big banks. Our tech stack: Clojure, Kafka, Datomic, Kubernetes, AWS.

We're hiring for engineering, VPE and more. See the complete list of jobs at https://griffin.sh/jobs

Griffin | Senior Backend and Infrastructure Engineers | London | REMOTE (UK and anywhere supported by boundlesshq.com)

Griffin is building an API-driven online-only UK bank. Think AWS for financial services. We're building APIs to create bank accounts, make payments, issue cards. We believe that in the future, most financial innovation will happen outside banks rather than inside them, and Griffin will be the platform that all future fintechs use rather than the boring big banks.

Our tech stack: Clojure, Kafka, Datomic, Kubernetes, AWS.

https://griffin.sh/jobs

Griffin | London, UK | Engineering & Product | REMOTE UK/Ireland | Fulltime | https://griffin.sh

Griffin is applying for a UK banking license, and we're going to be AWS for financial services. We make it 10x easier for fintechs to launch new financial products.

Our tech stack is Clojure, Datomic, Kafka, Kube, AWS.

In Engineering, we are hiring for Infrastructure, Frontend and Backend. We are also hiring for Product Manager.

Apply at https://www.griffin.sh/jobs We are remote friendly, but limited to UK and Ireland right now

Griffin | Engineering & Product | London | REMOTE UK/Ireland | Fulltime | https://griffin.sh

Griffin is applying for a UK banking license, and we're going to be AWS for financial services. We make it 10x easier for fintechs to launch new financial products.

Our tech stack is Clojure, Datomic, Kafka, Kube, AWS.

We are hiring for frontend engineering, backend engineering, SRE and Product Manager.

Apply at https://www.griffin.sh/jobs

We are remote friendly, but limited to UK and Ireland right now

In my experience, STM isn't used because it's very rare to have situations where you need STM but don't need durability. In most production situations, you need to record state changes in a DB or an event log. In that case, the source of truth is now the DB, and your in-memory values are immutable snapshots.

The other reason is that Clojure code is usually well-factored, and most clojurians have listened to Rich and simplified their programs. Not many problems require STM transactions across multiple refs. If you don't have multiple refs changing transactionally, you can use atoms instead for a performance benefit.

Griffin | Senior Infrastructure Engineer | London, UK REMOTE USA,EEA | Full-Time | https://griffin.sh

We are building an API-first white-label bank in the UK to be the partner bank of choice for fintechs. We want to make it easy for startups to launch prepaid cards, run brokerages, start insurance firms, and more - all over API. We just closed a £3M seed round. We've got a team of senior banking execs and two engineers already onboard and are looking for a third engineer with strong devops experience. Our CTO was the CTO and co-founder of CircleCI. Stack is Clojure[Script] / Kafka / Kubernetes / AWS A complete list of all of our open roles with a bit more detail is here: https://griffin.sh/jobs Email jobs+hn@griffin.sh to apply

To expand on your example:

I invest $100 for 20% of your venture, implicitly valuing the company at $500 . You sell for $200.

- Standard preference: I get $100 or 20% of the company ($40)

- 2x preference: I get $200 or 20% ($40)

- Participating preferred: I get $100 and 20% of the company ($140)

IMO, 1x preference, non-preferred is entirely fair. In the event the company sells for lower than the valuation, the investors get their money back first. The vulnerability it protects against is that I found a company for $0, you invest $100 for 20%, then I immediately turn around and sell for $101. You get $20.25 and I get $79.75.

Participating preferred and >1x preference are unconscionable.

Griffin | Senior Backend Engineer | London, UK | Full-Time | Onsite or remote UK | https://griffin.sh

We are building an API-first "platform" bank in the UK to be the partner bank of choice for fintechs. We want to make it easy for startups to launch prepaid cards, run brokerages, start insurance firms, and more - all over API.

We just closed £2.3M in seed financing. You'll be joining an engineering team of 4.

Stack is Clojure[Script] / Kafka / Postgres / Kubernetes A complete list of all of our open roles with a bit more detail is here: https://griffin.sh/jobs Email jobs+hn@griffin.sh to apply

Brave is great for those "it only works in Chrome" sites

Is there any Emacs-based solution to access a GMail account with 2FA, without enabling "insecure access" on Gmail?

I've looked at a lot of solutions, and AFAICT:

- SMTP + app-based passwords require "insecure access" being enabled

-Using the GMail HTTP API does not require insecure access, but none of the standard CLI email tools support it.

That link no longer loads for me.

AIUI, Spectre can be used to attack the kernel, only if you can get code running in kernel-space, via, e.g. eBPF.

Having done multiple K8s migrations, I can tell you that many of the problems around migrating to k8s have little to do with actually setting up the cluster. There's dockerizing all your apps, setting up the build->deploy pipeline for each app, and fixing all the hardcoded hacks where your apps aren't properly 12-factor (failing to take config from env vars, assuming you "always" deploy to a specific cloud, etc).

The other main component of my time in a k8s engagement revolves around logging, monitoring, alerting and backups of the k8s cluster, which hopefully EKS handles for you.

All told, actually starting the k8s cluster is probably less than 10% of my time.

I upvoted this, but agile and "release early and fail often" aren't necessarily the same thing. For example, they could have iterated quickly during the draft phase, come up with a proposed implementation, have the security researchers review it, and iterate.

Read the leangains links elsewhere in the thread. In those, Berkham recommends high protein,medium/high carb, low fat on weightlifting days, and high protein, medium fat, low carb on non-weightlifting days.

The VCs aren't the investors here.

There are 3 parties, the startup, the VCs and the LPs. The LPs are generally pension funds, college endowments, and sovereign wealth funds, i.e. institutions who can write $10M-$100M checks. The VCs are their agent, like a real estate agent helping you buying a house.

While VCs put their own money into the fund, generally the vast majority of the fund money comes from the LPs. The VCs get paid 2 and 20, 2% of the fund per year for things like salary and rent, and the first 20% of profits from the fund when it ends, in 10 years. Because of this structure, they don't get to treat the fund money as their own personal piggybank.

No matter who pays, the cost of a deal is going to be <money startup receives> + <startup legal costs> + <VC legal costs>.

Raising the cost for the VCs, without changing 2 and 20 just results in increased costs for the VC. Paying their own legal costs means they'll do fewer deals, with larger check sizes.