lysdexic

This is a ridiculous definition of “real-time”. To accomplish this you’d need to subvert the kernal’s scheduler (...)

You missed the whole point of the article.

It makes no sense to read the article and arrive at the conclusion that "I need to subvert the Kernel's scheduler". The whole point of the real-time analogy is that handlers have a hard constraint on the time budget allocated to execute each handler. If your handler is within budget them it's perfectly reasonable to run on the UI thread. If your handler exceeds the budget then user experience starts to suffer, and you need to rework your implementation to run stuff async.

Keep in mind that each mouse click/hover/move/sneeze triggers a handler on GUI applications. Clicking on a button can trigger small, instant changes like updating UI, or can trigger expensive operations like running an expensive task. Some handlers start off as doing small UI updates but end up doing more and more stuff that ultimately start to become noticeable.

Maybe I’m dumb because I’m a backend dev, but if we can’t offload these tasks to Async tasks and we need to block the main thread, why can’t we just put up a loading screen?

That's not the problem. These tasks can be offloaded to async. The underlying issue, and the reason why I think this is an outstanding article, is that running code on the UI thread straight from handlers is easy and more often than not it goes perfectly unnoticed. Only when the execution time of those handlers grow do these blocking calls become an issue.

There's a gray area between "obviously we need to make these calls async" and "obviously we can run this on the main thread", and here's where the real-time mental model and techniques pay off.

“Don’t turn off the application we are saving” games have been doing this for a decade and you can’t convince me that your enterprise application is heavier than a AAA game.

You're missing the whole point.

The point is that running handlers in the main thread leads to far simpler code and, depending on the usecases, is adopted in scenarios where the approach works well with 99.9% of the conceivable usecases. But then the software starts to be modified and get features added, and some of these code paths start to do more things and take more time to run. When this happens, the 99.9% starts to shrink and some main thread blockages start to become more and more noticeable.

The article does a very good job in underlying the mental model that needs to be in place to avoid this slippery slope to become a problem.

Now you mention it, maybe people with a better interview/offer rate are also doing a better job on not wasting time with positions they aren’t a great fit?

Yes, that's indeed a key factor. However, I should stress that some of these adverts simply do not have a position to fill. Recruiters post these ads, they go through candidates, sometimes they even line up some interviews, but ultimately they do not have a job to fill at all. In my experience this is the norm with staffing agencies.

If you're applying for positions posted by staffing and recruiting agencies, I believe you should set your expectations so that you expect nothing to come out and, even though you should do your best when applying, you should take a fire-and-forget approach to them.

I think my interview/offer ratio is somewhere below 1%.

Keep your spirits up, and be mindful that there are tons of job adverts out there that don't actually have a real job position to fill, and are only used by recruiters and consulting companies to harvest CVs and meet their internal quotas. 1% sounds about right

My workplace has the opposite problem.

I don't see that as a problem. The job description of an engineer includes dealing with new problems and onboarding onto new things. So you never wrote a parser and now you have to. That's ok, just go ahead and start from the ground up.

What I perceive as a major problem is the utter disconnect between what companies test for, and what companies actually do.

It makes no sense at all to evaluate candidates on obscure trivia questions no one will ever care about or use, let alone reject an applicant because they mixed up O(nlogn) with O(logn). It matters more if you know a good, healthy answer to tabs vs spaces.

I once was a part of an hiring loop where we assessed a candidate, and one other fellow assesser wanted outright to reject the candidate because he failed to answer one of his questions on data structures. Everyone in the meeting voted in favour of that hire, except that one guy. When we asked to reconsider his position, he threw a tantrum because he felt that it was a matter of principle that we had to not hire a candidate that didn't knew trivia. The hiring manager asked if that info was important, and in case he felt it was whether it could be looked up online in a matter of minutes, but the assesser tried to argue that it was besides the point.

Data structures and algorithms trivia feels like ladder pulling.

Why are you applying to that soulless shitshack??

If you automatically rule out companies that either do their own coding assessments or offload them to third parties, you'd rule out most of the potential job market.

But since then, i came to a revelation, than it takes years of experience to knw which wire to touch

Might be, might not be. A popped capacitor doesn't require a lot of skill to spot.

Not all jobs are rocket surgery.

your 2 decades of experience mean much more than memorizing algorithms, you know how to produce real value

That's all fine and dandy but the HR recruiter that can't tell apart git from grunt needs to cross boxes in the skills assessment section, and if you don't ace coding challenges you are as good as dead to them.

A few years ago I was in a hiring loop where four interviewers grilled me on a number of subjects, including algorithms and data structures. They asked me all sorts of trivia questions on assimptotic complexity of this and that algorithm, how to implement this and that, how to traverse stuff, etc. As luck would have it, I was hired. I spent a few years working for that company and not a single time did I ever implemented a data structure at all or wrote any sort of iterator. Not once.

I did spend months writing stuff in an internal wiki.

I can't help but feel that those bullshit leetcode data structures computational complexity trivia are just a convoluted form of ladder-pulling.

Thanks for all the proactiveness. We'll see how this group pans out.

Is it just me or is this a nightmare implementation in terms of software maintenance and operations? Each state transition requires a database trip, state machine transitions are determined at runtime and there's no simple way to reproduce them locally, and in the case of the state machine database going down the system simply cannot work.

What exactly is the selling point of this approach?

Style points for the a-bun-dance of puns.