Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mrkurt
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
91.
▲
by
mrkurt
3y ago
Yeah it probably does sound that way.
92.
▲
by
mrkurt
3y ago
We're actually selecting for experience. One way submissions demonstrate experience is if they account for the big issues that come up in real life. I don't think you can spend more hours and get these criteria.
93.
▲
by
mrkurt
3y ago
I'm not completely following. Can you be more specific?
94.
▲
by
mrkurt
3y ago
I hope my responses don't come across as damage control. Talking through this stuff is super valuable, we tweak our hiring process almost continuously based on feedback. Sometimes when people have a bad experience, we've just fuck
95.
▲
by
mrkurt
3y ago
Yeah you should not work here. That's a completely reasonable stance.
96.
▲
by
mrkurt
3y ago
No that's not how ours works. We have, basically, 20 checkboxes for "things that are good about this work". These range from "strong user focus" to "logic to prevent <some problem we've previously had w
97.
▲
by
mrkurt
3y ago
If it takes more than 2 hours, there's a pretty good chance it's the wrong job for the person doing the challenge.
98.
▲
by
mrkurt
3y ago
Most of our jobs are ~$120-215k base salary. The equity compensation is typically 3-4x that.
99.
▲
by
mrkurt
3y ago
We design these so people with relevant experience can bang them out in about two hours. They're not trick challenges, though, they're very straightforward. Getting people to believe they should only spend two hours on them is t
100.
▲
by
mrkurt
3y ago
We're not. We've had issues losing track of candidates over the last year. This is one of those all or nothing problems, a 0.5% failure rate is pretty bad for many human beings.
101.
▲
by
mrkurt
3y ago
This is the one: https://github.com/fly-hiring/infraops-challenge Here's another: https://github.com/fly-hiring/platform-challenge
102.
▲
by
mrkurt
3y ago
We don't really give individual feedback on the take home challenges. Where we struggle is explaining this to people, it's not obvious to every dev _why_ we don't give specific feedback. Here's what we send: --- Unfortun
103.
▲
by
mrkurt
3y ago
I went and looked at your submission, and I am comfortable with how we handled it and the level of detail we gave you. Would you mind sending me an email so I can hear a bit more? It sounds like we might've implied something we didn&#x
104.
▲
by
mrkurt
3y ago
Hi Martin: I'm really sorry we ghosted you. That's not good, and it's happened more often than I'd like. We struggled with this in March, especially, because we were dealing with reliability issues. I'll make sure w
105.
▲
by
mrkurt
3y ago
Was this us (Fly.io)? I'm not sure how many companies give the 2 hour guideline, but we definitely do. We don't fail take homes because of edge cases though. There are things we expect people to handle in the challenges that are i
106.
▲
by
mrkurt
3y ago
Not really, but we might've just implicitly designed around it. Continuously aggregating smaller windows and sending them off is roughly how we send usage to Stripe right now (which, let's be clear, is not working for us AT ALL).
107.
▲
by
mrkurt
3y ago
I may not be interpreting your question right, but most of our metrics are counters. It doesn't matter how often they get scraped, or if they get scraped twice, because we only care about the increase. Almost everything we track is agg
108.
▲
by
mrkurt
3y ago
We're neck deep in figuring out usage based billing for Fly.io. What we're doing is pretty extreme, and may not be representative of many other people, but it feels like no one's really solved this in a way that makes sense f
109.
▲
by
mrkurt
3y ago
This was a bug, I'm sorry we broke your app. We stopped migrations when we hit this issue and wrote a bunch more tests. I know this doesn't help you specifically, though.
110.
▲
by
mrkurt
3y ago
You can test soft skills. Evaluations don't need to be objective, they just need to be consistent.
111.
▲
by
mrkurt
3y ago
They do, actually. We don't say anything about running our own infrastructure. And every time someone finds out, they're like "why didn't you lead with that?" I'm surprised how much people care about what'
112.
▲
by
mrkurt
3y ago
Ok that's a silly thing to say. Nowhere on our site do we say we offer serverless anything . When you provision a Redis, we offer you a selection of plans, you pick the one you want, and off you go. I don't understand why you
113.
▲
by
mrkurt
3y ago
Upstash on Fly.io is not serverless. You provision the RAM + connection counts you want, and then pay for that capacity. This is not what all our customers want, but it is much cheaper to run this way for most fullstack frameworks. It'
114.
▲
by
mrkurt
3y ago
I don't know of a single ISP that gives /48s out to customers. Maybe a /56, but I think even that is rare. IPv6 is way better than cgnat, but ISPs are still doing their own internal routing for much smaller blocks. Meaning th
115.
▲
by
mrkurt
3y ago
IPv6 addresses are effectively the same as shared IPv4 addresses in anti-abuse systems. All anti abuse systems treat a /48 or /56 level the same as a single IPv4 address. It's the only way to actually detect one system doing
116.
▲
Copyright lawsuits pose a serious threat to generative AI
(understandingai.org)
3 points
by
mrkurt
3y ago
|
1 comments
117.
▲
by
mrkurt
4y ago
I appreciate it. I do struggle with focus. Thank you for giving me a nudge.
118.
▲
by
mrkurt
4y ago
Would you mind sharing specifics about the first bullet? What's the last post you read you thought could have gone deeper? We definitely want to go deep, some of our posts are better than others.
119.
▲
by
mrkurt
4y ago
Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though. The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. Th
120.
▲
by
mrkurt
4y ago
If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.
More ›