zlacker

>>moored+(OP)
Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues.

"But what about using a message queue.."

"Candidate did not use microservices.."

"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).

>>anothe+Jm
In my most recent role, everyone interviewing me gave me a thumbs up. Except one engineer.

I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.

Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).

Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.

>>btreec+xp
> Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues.

There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.

To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.