I have been using the product for a while and I’m a huge fan. At least for solo/side projects it helps me get reviews in an easy manner similar to what I’m used to at $dayjob and the SNR was good enough that I find myself reaching for it regularly.

It also did find bugs in code I shipped professionally (I back tested on my public commits) and also OSS code shipped by meta (which I found surprising at first)

Hoping to see this and similar tools develop further.

(Disclaimer; I know one of the founders well, though they didn’t ask me to comment here)

> Please explain exactly how you managed to put together a test suite that costs up to 50€ to run.

I'm not OP but have worked with them: have you considered a repo that might have tents of thousands of committers over decades? It's very easy to just have an insane amount of tests.

In large mono-repos, like this one is presumably targeting, running all tests in the repo for a given PR would take years (maybe even decades/centuries) of compute time. You have to do some level of test selection, and there are full time engineers who just work on optimizing this.

The test runtime argument is the main one IMO.

(source: while I did not work on this at a prior job, I worked closely with the team that did this work).

> In large mono-repos, like this one is presumably targeting, running all tests in the repo for a given PR would take years (maybe even decades/centuries) of compute time.

No, not really. That's a silly example. Your assertion makes as much sense as arguing that your monorepo would take years to build because all code is tracked by the same repo. It doesn't it, does it? Why?

How you store your code has nothing to do with how you build it.

Being a monorepo is typically about more than just how code is stored, it leads to very different practices about dependency management, building, etc. On the monorepo I work on, the fact it is a monorepo is intrinsically linked to the build, testing, and deployment processes in many ways.

The ideal is that your build system by-necessity contains the data to be able to selectively test – typically the case if you're linking code in some way. You import a library, now your tests get run if that library changes. As the article suggests, this breaks down over service boundaries, but as you suggest, you still hopefully have modules you can link up.

The problem is when you have hundreds of services, maintaining those dependencies manually could be hard. When you have thousands it may be nearly impossible. When you have hundreds of thousands it may be impossible. I think applying ML to that problem so that you can incrementally understand the ever changing dependencies across services.

I can also assure you that however smart the build system is, there will always be spooky action at a distance between components.

yeah. I am talking about repos with hundreds of thousands (probably millions) of tests. Here's just one example of the scale: https://engineering.fb.com/2018/11/21/developer-tools/predic...

if you change a low level library that's the equivalent of the C++ standard library and you want to test the changes, you effectively have to rebuild the world. And you don't want to.

Exactly, or when "one" build rule connecting a service to another is actually a hundred deeply nested build rules doing a lot more work, and every one of those code paths would need to correctly convey whether a dependency is required at the test level or not.

I built the same for my browser extension (effectively dead product) -- would love to see if this pattern has a name so I can share it more widely!

I was at meta. What do you mean? It’s how we used to define staff in our cross company leveling docs.

This is a great idea! I remember facing similar pains when applying to dozens of companies last year and talked about a similar idea with a friend - glad to see someone building it. Wishing you the best of luck, and I’ll hopefully try and provide feedback soon

It does show up on mobile; but only at the top and it’s easy to miss

I filtered companies down to places where I felt I had a good chance of success, and applied to jobs within my comfort zone - this was a very biased sample. I don't think this generalizes unfortunately

I was between jobs so I had the luxury to do this - I wouldn't recommend this heavy a schedule for people who already have a job. It's impossible.

I've generally had bad experiences with third party recruiters so I try to avoid them when I can. in your position I'd probably be upfront and mention the ranges you are OK with in the different situations.