Pave | https://www.pavefi.com | Data Scientist | Backend Engineer | Remote (US or Canada) | Full-time
I’m the Director of Engineering at Pave, a rapidly growing startup revolutionizing financial access for underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
50+ risk teams use Pave to reduce defaults, provide the optimal loan amount/credit limit, and maximize collections success.
- We’re hiring Software Engineers in Backend, Full Stack, Data and ML to scale our data processing platform to 100M+ users: https://wellfound.com/l/2BmPpa
- We’re hiring Data Scientists to ship models that will redefine the US credit system, making it fair and inclusive: https://wellfound.com/l/2AqFf9
Shoot us an email at howdy@pave.dev and let us know you found us on HN!
Pave is backed by Better Tomorrow, Bessemer, 8VC, and other top funds and angels from Coinbase, Chime, SoFi, CashApp, and Plaid.
Pave | https://www.pavefi.com | Data Scientist | Backend Engineer | Remote (US or Canada) | Full-time
I’m the Director of Engineering at Pave, a rapidly growing startup revolutionizing financial access for underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
50+ risk teams use Pave to reduce defaults, provide the optimal loan amount/credit limit, and maximize collections success.
Pave | https://www.pavefi.com | Data Scientist | Backend Engineer | Remote (US or Canada) | Full-time
I’m the Director of Engineering at Pave, a rapidly growing startup revolutionizing financial access for underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
50+ risk teams use Pave to reduce defaults, provide the optimal loan amount/credit limit, and maximize collections success.
Pave | https://www.pavefi.com | Data Scientist | Backend Engineer | Remote (US or Canada) | Full-time
I’m the Director of Engineering at Pave, a rapidly growing startup revolutionizing financial access for underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
50+ risk teams use Pave to reduce defaults, provide the optimal loan amount/credit limit, and maximize collections success.
Pave.dev | https://www.pave.dev/ | Full Stack Engineer | ML Engineer | Remote (US or Canada) | Full-time
I’m the Director of Engineering at Pave.dev, a rapidly growing startup revolutionizing financial access for 100M+ underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
- If you’re a Full Stack Engineer passionate about building analytics products with a strong affinity for data and visualization, please see: https://wellfound.com/l/2AG7WF
- If you're an ML Engineer passionate about building end-to-end, scalable machine learning systems, please see: https://wellfound.com/l/2AtUvk
Shoot us an email at howdy@pave.dev and let us know you found us on HN!
Pave.dev is backed by Better Tomorrow, Bessemer, 8VC, and other top funds and angels from Coinbase, Chime, SoFi, CashApp, and Plaid.
Pave.dev | Data Scientist | Data Analyst | ML Engineer | Remote (US) | Full-time
I’m the Director of Engineering at Pave.dev, a rapidly growing startup revolutionizing financial access for 100M+ underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores.
- If you're an ML Engineer passionate about building end-to-end, scalable machine learning systems, apply here: https://wellfound.com/l/2AtUvk
- If you’re a Data Scientist passionate about cutting-edge credit risk modeling, apply here: https://wellfound.com/l/2AqFf9
- If you’re a Data Analyst passionate about conducting analysis on massive and diverse datasets, apply here: https://wellfound.com/l/2zJxJp
Let us know you found us on HN when you apply!
Pave.dev is backed by Better Tomorrow, Bessemer, 8VC, and other top funds and angels from Coinbase, Chime, SoFi, CashApp, and Plaid.
My company’s product is an API and Postman has been a key tool to test it, collaborate internally on requests and share it to the external world. Our ecosystem is also very API intensive and we also use Postman to discover other companies APIs.
We use all those features:
- HTTP requests
- Mock servers (to test async requests which call back a webhook endpoint)
- Workspaces: private and public
- Monitors, alerts and integrations
I’m excited by the direction Postman has been taking over the years.
Most of commenters in the thread seem to think that Postman is still in the “lightweight cURL replacement GUI” market, like so many of the alternatives mentioned. I think this is wrong - Postman has now has moved to an upper market where requirements are more advanced and complex.
We face a similar situation and we sometimes introduce API changes that break the monitors, which then requires to manually fix the testing script. The pain hasn’t been big enough yet to make us search for a different solution. Note that we are using Monitors mostly for end to end, user like tests, which represents a small fraction when compared to our unit test suite covering the API (where tests tend to be quite E2E as well).
We do use the one way Postman -> Github integration though. Every time a change is done, it is committed to a dedicated Github repo. We use it as a backup in case anybody messes up the scripts
We introduced two-way sync with GitHub, GitLab, BitBucket etc recently so you can keep your Postman collections inside version control while being able to work with them inside Workspaces. Details here: https://blog.postman.com/the-reimagined-api-first-workflow-f...
Thanks for sharing! We are a small company and right now we release (from our monorepo) on every PR merge to main. As the engineering team continues growing, we anticipate this approach will become unsustainable soon, and are looking for alternatives.
I wonder if the tag based release is a widespread industry pattern (especially for growing monorepos)? Would be curious to learn more about it
I was honestly shocked that I couldn't find many blog posts or articles about managing this process. The tag based mechanism was one I came up with on my own because we needed something. We're also a small team of 5 engineers, with many small microservices that each have their own pipelines. The problem with main being the release tracker is that it doesn't work if you have multiple environment stages. Stage specific branches work, but then you don't get history.
I'm on a team that implemented a hybrid tag-based release system on a monorepo and it is working well.
External releases are built on release branches off of main with their own git tag rules, but I want to touch on internal releases off of main.
Between feature branches and main we have GitHub status checks that gate bad PRs from getting in. Once the PRs are in main, we build a nightly full suite of components and put them through various levels of interop testing. Once our system receives the signal that all builds and interop testing had passed, it applies a Last Known Good (LKG) tag to the git commit the components were built from.
After that, various systems including artifact links for QA and auto-merge jobs from main, are set to use the LKG tag to ensure they are getting good builds and code.
Glad to see all the innovation happening in the IaC space.
I like the multi-language premise of Pulumi but I have the feeling that over time one of the languages will gain a significant advantage over the others (better supported, more features, native...) and thus will become the primary language for Pulumi package authors and users (similar to HCL for Terraform and TypeScript for CDK).
Meaning that eventually all the "serious" Pulumi users will end up converging on one single language (similar to this comment of a CDK user migrating from Python to TypeScript). Feedback loops will only help amplify this effect (e.g. more Pulumi users on language A -> more examples online -> more package authors working in this language -> better established best practices -> more submitted issue tickets for language A -> language better supported by Pulumi -> more users...)
Curious about how Pulumi multi-language components [0] work under the hood. Isn't writing a "Pulumi schema" describing resources the same as writing declarative HCL at the end of the day?
Indeed what you say is true of many other "multi-language" platforms. I was an early engineer on .NET at Microsoft, and although it was multi-language from the outset (COBAL.NET was a thing!), the reality is most folks write in C# these days. And yet, you still see a lot of excitement for PowerShell, Visual Basic, and F#, each of which has a rich community, but uses that same common core. A similar phenomenon has happened in the JVM ecosystem with Java dominating most usage until the late 2000s, at which point my impression is that Groovy, Scala, and now Kotlin won significant mindshare.
I have reasons to be optimistic the infrastructure language domain will play out similarly. Especially as we are fundamentally serving multiple audiences -- we see that infrastructure teams often elect Python, while developers often go with TypeScript or Go, because they are more familiar with it. For those scenarios, the new multi-language package support is essential, since many companies have both sorts of engineers working together.
A "default language for IaC" may emerge with time, but I suspect that is more likely to be Python than, say, HCL. (And even then, I'm not so sure it will happen.) One of the things I'm ridiculously excited about, by the way, is bringing IaC to new audiences -- many folks learn Python at school, not so much for other infrastructure languages. Again, I'm biased. But, even if a default emerges, I guarantee there will be reasons for the others to exist. I for one am a big functional language fan and especially for simple serverless apps, I love seeing that written in F#. And we've had a ton of interest in PowerShell support since many folks working with infrastructure for the Microsoft stack know it. And Ruby due to the Chef and Puppet journeys.
I also won't discount the idea of us introducing a cloud infrastructure-specific language ;-). But it would be more general purpose than not. I worked a lot on parallel computing in the mid-2000s and that temptation was always there, but I'm glad we resisted it and instead just added tasks/promises and await to existing languages.
As to the Pulumi schema, you're right, that's a step we aim to remove soon. For TypeScript, we'll generate it off the d.ts files; for Go we'll use struct tags; and so on. Now that the basic runtime is in place, we are now going to focus there. This issue tracks it: https://github.com/pulumi/pulumi/issues/6804. Our goal is to make this as ridiculously easy as just writing a type/class in your language of choice.
> There might be "a default language" but I suspect that is more likely to be Python than, say, HCL. One of the things I'm ridiculously excited about is bringing IaC to new audiences -- many folks learn Python at school, not so much for other infrastructure languages.
As someone that has worked largely on backend systems and infra for a long time, are colleges actually training these infra skills? Some app engineers at a place I consult for was just having this conversation last week, interested in how to train infra skills and pretty much everyone had sort of fallen into infra roles over their careers, with no formal training in it. Most of us were just *nix hackers as kids, learned to program at some point, and now we’re here. Working on infra is quite a lot more than just knowing the language.
I’m not mad at having something other than HCL — years ago when I worked at Engine Yard we developed a cross platform cloud library that let us write things in Ruby which was nice. But when thinking of solving infra problems I’ve never once thought “you know, if I could just write this in Python these problems would go away”. Actually I personally hate Python as a language, I’d much prefer to write Go or Rust or TypeScript, and it does feel like a bonus that everyone touching infra sort of just has to use HCL which removes a lot of bike shedding.
Totally open to improvements! More isn’t always better though.
I couldn't agree more. In my company we've decided that everyone will use Typescript with Pulumi because we believe that the developer experience (IDE, code autocompletion, etc) will be the best + it's a language that arguably is more used here as frontenders will know it too + providing examples, etc.
When I first started using Pulumi, I was using Python and it seemed like the Pulumi team focused on JavaScript and the rest of the languages were afterthoughts. But they’ve improved a lot on this front, so if anything the trend is in the opposite direction.
They are separate, but we all sit in two person offices along one long hallway. This allows us to quickly talk through issues or bounce ideas off someone, then go back and spend long stretches implementing. It’s about 2/3rds researchers, 1/3rd devs.
I’m the Director of Engineering at Pave, a rapidly growing startup revolutionizing financial access for underserved consumers and small businesses through AI-powered Cashflow Analytics and Scores. 50+ risk teams use Pave to reduce defaults, provide the optimal loan amount/credit limit, and maximize collections success.
- We’re hiring Software Engineers in Backend, Full Stack, Data and ML to scale our data processing platform to 100M+ users: https://wellfound.com/l/2BmPpa
- We’re hiring Data Scientists to ship models that will redefine the US credit system, making it fair and inclusive: https://wellfound.com/l/2AqFf9
Shoot us an email at howdy@pave.dev and let us know you found us on HN!
Pave is backed by Better Tomorrow, Bessemer, 8VC, and other top funds and angels from Coinbase, Chime, SoFi, CashApp, and Plaid.