I typed in a bit of an answer, there's not a whole lot to go on, there's no room for me to ask questions about this scenario or get data.

When I filled out an answer it just told me I was useless. I don't really get the point. What was I supposed to learn?

The issue is you're given 5 minutes to write a solution, and then criticized for the lack of depth (mercilessly and hilariously, granted). This is actually great practice for interviews, but not great at determining technical depth.

At the level of "five minutes to describe the entire system and its response to the worst confounding factors imaginable" it is not fair to say "You used keywords but didn't describe in detail how ... ".

It also guessed wrong that I'd never done any of this before, probably b/c of above issues.

As a way to belittle someone who self-selected into a skills review in the middle of a workday, probably so that they'll sign up for your training curriculum, then man, I gotta say it's probably going to work well. Especially once it's not an obvious snark generator and learns to cut a little deeper.

It must be hitting a nerve if people use it and it's getting overloaded (or they're cheap w/r/t API budget).

Firmware Resilience for a Voice-Activated Device The home assistant prototype just hit the lab, and its latest voice command triggers a rare crash—barely reproducible, but critical. Debug traces hint at a race condition when processing real-time audio and sensor interrupts under low-power standby. Today, you examine how the interrupt service routines interact with the scheduler, ensuring audio capture stays seamless even as the device maintains privacy guarantees and maximizes battery life. Firmware must not leak sensitive audio fragments after a crash. The hardware platform is arm-cortex based and will see hundreds of millions of users relying on every subsystem working as one.

> [...] after noticing how hard it is to get honest feedback when applying to a YC startup or something else entirely.

> It's a custom 5-minute challenge that roasts you after.

That's OK.

I've been working long enough in software engineering, to see the interviews turn... from collegially getting a sense of what it would be like to worth together, on the product and as part of the team... into frat hazings, negotiation negging opportunities, general corporate dysfunction, and fluffing some incumbent's ego.

So I think workers are all set, without roasting.

You know who could use a dose of humility, though?

I often have to coordinate with multiple technical and customer facing teams.

This system does not seem to evaluate rapid situations like that very well. I was surprised by the results.

The question was loaded as it told me that "stakeholders want to know whether it's your autoscaling script you wrote last week", it gave me the context of "alerts firing off at 2:43 am, nobody knows why" and then afterwards implied I should have replied with a very specific plan to code-review and debug my script... at 2:43 am in production with "catastrophical failures coast to coast". I have the feeling it wanted me to use all the available information to reply, rather than follow a sound plan to respond to an emergency.

Without a doubt I should have hotfixed with root cause analysis in 1m in production at 2:43 am after being thrown off the bed, and simply stared at the application recovering for the remaining 4m.

I really don't understand what's the point of this LLM-backed roaster, and if there is one, it doesn't seem to close to achieving it.