Hacker Newsnew | past | comments | ask | show | jobs | submit | dgroshev's commentslogin

Hey fellow failed applicant!

I had a very similar experience, except I got the automated email after two months, not three — you sound like a stronger candidate, so maybe that's why I got rejected sooner, which'd be fair enough. Still, spending about a week's worth of evenings between the suggested materials, reflecting, writing, and editing 15 pages for one job application and having zero human interaction feels uniquely degrading.

I disagree with your point about that being fine. I think it's not good enough to replicate the bare minimum of what the rest of the industry does while asking for so much more from candidates.

A standard custom, well researched cover letter takes an order of magnitude less effort. When it's cookie cutter rejected by someone spending a few seconds on the CV, it's at least understandable: the effort they'd spend writing a rejection (or replying back) is higher than the amount of effort they spent evaluating the application.

With Oxide however, Brian made a point that they "definitely read everyone's materials" [1]. Which means reading at the very least five pages per candidate. If that's still the case, having an actual human on the other side of the rejection would add a very small amount of time to the whole process, but the company decided to do the absolute least possible. It's a choice, and I think this choice goes against their own principle of decency:

"We treat others with dignity, be they colleague, customer, community or competitor."

I wish Oxide best of luck. They have lots of very smart, very driven people that I'd love to work with, and I love what they are doing. Hope this feedback helps them get better.

[1]: https://youtu.be/wN8lcIUKZAU?t=1400

P.S. Don't you dare, dear reader, consider the emdash above an LLM smell.


I understand your disappointment; we are very explicit about why we provide so little feedback.[0] I disagree that it's indecent; to the contrary, we allow anyone to shoot their shot, with the guarantee that they will be thoughtfully considered.

[0] https://rfd.shared.oxide.computer/rfd/0003#_rejection_of_non...


Indeed, I understand your reasoning, you talk about that in the podcast in the RFD. This is why I wasn't talking about the lack of feedback, but the lack of human interaction. While there is nothing constructive to be done about the disappointment of rejection, this part is very much in your power to change, and that's why I think it's constructive feedback and not just venting.

That said, the RFD does say this:

> Candidates may well respond to a rejection by asking for more specific feedback; to the degree that feedback can be constructive, it should be provided.

Even just replying with refusal to provide feedback would still be more humane and decent.


Please DM me and I'll let you know if there's constructive feedback to be provided.


Hundreds of us!

I adore VyOS


I'm not sure about exquisite and small.

Bun genuinely made me doubt my understanding of what good software engineering is. Just take a look at their code, here are a few examples:

- this hand-rolled JS parser of 24k dense, memory-unsafe lines: https://github.com/oven-sh/bun/blob/c42539b0bf5c067e3d085646... (this is a version from quite a while ago to exclude LLM impact)

- hand-rolled re-implementation of S3 directory listing that includes "parsing" XML via hard-coded substrings https://github.com/oven-sh/bun/blob/main/src/s3/list_objects...

- MIME parsing https://github.com/oven-sh/bun/blob/main/src/http/MimeType.z...

It goes completely contrary to a lot of what I think is good software engineering. There is very little reuse, everything is ad-hoc, NIH-heavy, verbose, seemingly fragile (there's a lot of memory manipulation interwoven with business logic!), with relatively few tests or assurances.

And yet it works on many levels: as a piece of software, as a project, as a business. Therefore, how can it be anything but good engineering? It fulfils its purpose.

I can also see why it's a very good fit for LLM-heavy workflows.


I can't speak as much about the last two examples, but writing a giant parser file is pretty common in Zig from what I've seen. Here's Zig's own parser, for example[1]. I'm also not sure what you mean by memory unsafe, since all slices have bounds checks. It also looks like this uses an arena allocator, so lifetime tracking is pretty simple (dump everything onto the allocator, and copy over the result at the end). Granted, I could be misunderstanding the code, but that's the read I get of it.

[1] https://codeberg.org/ziglang/zig/src/commit/be9649f4ea5a32fd...


It used to be arena-allocated but now it's using a different technique which I outlined in this talk: https://vimeo.com/649009599


As it happens, the commit I linked fixes a segfault, which shouldn't normally happen in memory-safe code.


I mostly agree, but it also depends on the size and the shape of the fillet. Large sweeping curves that stay close to horizontal for a long distance are bad, but a tight corner can still look better in G2/G3 than just G1. On the top at least, because fillets on the bottom create sharp overhangs that don't print well.

Also, if you have that option, filler + sanding + paint can hide the layers completely, but preserve the overall shape.


It seems small in absolute terms, but it's suprisingly visible, even to "normal" people, which was the entire point of making a physical object!

I gave that object to a dozen people without explanation. Only one of them was a designer. All of them preferred G3 after comparing corners by look and touch for a few seconds. Honestly, I was surprised that it was this unanimous; I deliberately made the difference small.


Did you have the labels hidden? Even with that having single shape with corners sorted by the continuity degree might influence the result towards choosing last as best.

For a proper blind test it would help to have separate physical objects. Maybe even with varying corner sizes so that you can't easily rely on bigger=better intuition for comparing two corners of different objects.


It's a lovely video! I linked it in the description, and I strongly recommend the other videos too.


Another alternative is Rhino+Grasshopper with direct g-code generation, which allows for some wild tricks, including full colour printing: https://www.instagram.com/medium_things/

You can read more here:

https://controlmad.com/en/training/10h-grasshopper-g-code-fo...

https://interactivetextbooks.tudelft.nl/rhino-grasshopper/Gr...


I think it shouldn't be too hard to just output g-code via a Python program?

That is the direction I will probably first look into when I get to the g-code level of my 3d-journey.



There is nothing stopping the industry from standardising on an alternative form of expressing consent, for example on browser installation. GDPR is agnostic to the form the consent takes, as long as it's informed and freely given.

However, by far the biggest browser is funded by a corporation that wants tracking data across the web. I'm not very surprised that the corporation haven't made it easy to refuse just once.

Thanks Google.


No pop-ups on apple.com!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: