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

Cool, congrats and wishing you good luck and success!

> monthly "who wants to be fired" thread Reminds me of Mad Fientist blog.



It doesn't look like a leak but a misdeployment.

Same service wrappers from two years ago: https://github.com/googleapis/google-api-php-client-services...


Feel free to just share the details in an email as suggested above.


Details of what??! Things you already know you "Directors" (really they're just managers) do, with approval or instruction from the CEO?

You at Serp API took applicants for granted.

Now we'll reduce the flow of applicants.

What kind of game did you think you all were playing? "Screw these engineers, we can just kick them to the curb like trash. Hahaha! Who cares? They're disposable, they can't do anything about it."

See how that works? Ohh how the tables turn...

Don't worry-- You guys don't value job applicants anyway, as demonstrated by your behaviors. You won't miss them.

Note: I am choosing to treat your leadership like they treat job applicants: I am not giving you feedback.

Instead, I am giving feedback to everyone-- right here in this thread. And in next month's thread. And the month after that. This is what happens when you disrespect people with whom you share a open, public forum.

I think it's best if we all learn together.

Does Serp API provide feedback to rejected applicants, when those applicants put hours into their take-home project or test?

Given that no answer has been given on this, I assume the answer is No.

That was my experience and the experience of 1 person who commented, and possibly the 7 people who upvoted the initial reply I made.

That's basically punishing engineers-- disincentivizing them from applying to your company (and other companies who do this).

So, I am just here to let all Engineers know:

Serp API will not respect the time you put into applying to their company.

As is the case with many companies.

We engineers should all speak up about these practices. Companies will change if it effects their brand.

You negatively effect my resources? OK, I'll do the same back to you. Let's all play the game of not respecting each other and see where it gets us.


> I have high confidence that I could accomplish this task using a lower end model with a high degree of accuracy.

Cool, cool. I'm super interested. Please share the process and the results.


Reminded me the the Kasada VM reverse-engineering article: https://news.ycombinator.com/item?id=34285747


Monobank was under attack as well: https://t.me/s/OGoMono/1456


I recently wrote a blog post where I take a deep look into Playwright’s locators, specifically comparing the Page#getByRole locator with CSS selectors in terms of performance.

Playwright’s getByRole is 1.5x slower than CSS selectors because Page#getByRole uses querySelectorAll('*') and matches elements by the accessible name.

The post breaks down how `getByRole` works under the hood, how it stacks up against CSS selectors performance-wise, and what this means for your testing suites.

Would love to hear your thoughts!


Thanks to `@Freaky` from Reddit for the wonderful feedback which led him to significantly improving `String#count` which be potentially included to Ruby: https://www.reddit.com/r/ruby/comments/16d4ha6/comment/k1f5m...


tl;dr: str.count($\) was 1.5x faster compared to str.lines.count and didn't allocate additional memory.


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

Search: