I have two of em-- They’re pretty good! Definitely not perceptibly laggy or anything, at least to me.

Probably just outed myself as a casual.

Yeah, I get that. Do you have any sense of whether that’s a limitation of the ESP32, or with your implementation?

If anyone else was wondering, I found this neat data table of controller latencies to compare:

https://rpubs.com/misteraddons/inputlatency

It looks like 18.35ms is not really among the best, but there are still lots of products in that range.

I dunno if I’d say your project didn’t work out… Maybe more like you succeeded but still have work to do. Do you think you’ll try swapping the Bluetooth for a 2.4Ghz module or something and see if that performs better?

Interesting, thanks. Do you give them any ideas or guidance as to what they should whip up? Or just leave it totally open-ended for them to figure out?

That sounds like a good plan in many situations… But how do you handle candidates who say something like “look, there’s heaps of code that I’m proud of and would love to walk you through, but it’s all work I’ve done for past companies and don’t have access (or the legal right) to show you?”

You might just say “well the ideal candidate has meaningful projects outside of work,” and just eliminate the others… But it seems like you’d lose out on many otherwise great candidates that way.

Pretty questionable take IMO:

The truth is, there are typically a bunch of good candidates that apply for a job. There are also not-so-great candidates. As long as a company hires one of the good ones, they don’t really care if they lose all the rest of the good ones. They just need to make sure they don’t hire one of the no-so-great ones.

That’s actually a pretty bad thing. Like you could say the same thing about rejecting applicants who didn’t go to a certain set of schools, or submit a non-PDF resume, or who claims to have experince with a library/language that you don’t like (I had a colleague who said that he’d reject anyone with significant PHP experience because they probably learned “bad habits”) or any number of arbitrary filters.

If “good at leetcode” was a decent proxy for “knows how to build and scale accessible web UIs” or whatever, then okay great… But it’s not, as the author admits in the conclusion:

Coding interviews are far from perfect. They’re a terrible simulation of actual working conditions. They favor individuals who have time to do the prep work (e.g., grind leetcode). They’re subject to myriad biases of the interviewer. But there’s a reason companies still use them: they’re effective in minimizing hiring risk for the company. And to them, that’s the ball game.

So it’s unclear to me what they mean by “effective.” Are they good at evaluating how good a candidate will be at the job? No. Are they good at identifying talent that hiring teams might otherwise overlook? No. They are good at “minimizing hiring risk” by setting up another arbitrary hoop to jump through.

Let’s just call a spade a spade and admit that our hiring processes are so bad at evaluating talent that we settle for making candidates “audition” to prove that they can code at all, and then decide based on whatever entrenched biases we’ve decided constitute “culture fit.” Then the title could be “Coding interviews are the most effective tool we have, and that’s kind of a disaster.”

Thank you for reading my rant. I am available for podcasts and motivational speaking appearances.

I hear you-- Just saying, once you get a few kids in there, it’s going to be four wheels carrying some very sophisticated sensor and communications equipment. Sounds like a rover to me. Still early in R&D though, I get it.

Awesome! Which Mars rover are you gonna name the wagon after now?

Yeah…I don’t think he was talking about “distributed monolith” in that instance, but he does talk about it in the article. It’s weird, cause he obviously knows why it’s an antipattern, and why microservices are a categorically different thing, but then says stuff like that, with what I can only assume is a straight face.

I think maybe he’s trying to bolster his point that “it’s not a binary distinction, and you’re trying to achieve the same things with either architecture,” but you gotta be careful to not accidentally say “mix and match, anything goes!” And IMO he’s not that careful, lol.

My test is always “What is my hypothetical simple-but-pushy CTO going to latch onto and how annoying would that be for me?”

I think there’s alot of good wisdom and perspective in this article, but man he has some weird takes, lol… e.g.:

A microservices application is just a monolith, but with the number of services dialed up and the sizes of the services dialed down.

Like… There’s a charitable interpretation, I guess, but that’s such an odd way to put it.