This but unironically. If you can't do a simple programming task, (we can argue over what text justification is, because "left-pad" could qualify, as could a full TrueType renderer) you don't belong in SRE - Much of the point is to have cross-functional people, who can interface with developers on their level, and do the math and grunt work around operating a database cluster.
I once met a man who was intimately familiar with the details of the linux kernel and how the new chiplet architecture in AMD processors resembles a NUMA architecture and thus impacts VM performance. He was well versed in shell scripting, k8s, docker, the principles of observability, and infrastructure as code. He could explain the difference between READ COMMITED and REPEATABLE READ or LSTMs or distributed consistency models off the top of his head. He didn't have a CS degree so obviously he wasn't as intelligent as me, but even so I found him a little intimidating for some reason.
But then I asked him -
"Given an array of positive integers target and an array initial of same size with all zeros.
Return the minimum number of operations to form a target array from initial if you are allowed to do the following operation:
Choose any subarray from initial and increment each value by one.
"
He was stumped. As I had suspected, he wasn't quite up to the job of an SRE. I immediately failed him and returned to editing my networking.yaml file. Someone has to maintain the bar around here..
I am emphatically not saying you shouldn't tailor your technical questions to your audience. Commits to the kernel can be prime-facie evidence that someone can code. A good shell script can be the same.
I have no degree. I don't write code for a living. I'm actually almost precisely the opposite of the stereotype of the stuck up software engineer, aside from being a white dude in my early thirties.
What I am saying is: I have met many people who can configure a database, but cannot talk to developers as equals about how to write code about it, and there's really an interesting split of reasons why that doesn't work. The fact remains that it doesn't. You can build operations teams for some tasks, and you should - you can't run your own large hardware or compute or database clusters without having some entirely operations focused people. You should not ignore their opinions or pain points. You shouldn't call them SRE, though. The point of SRE is to build systems and run them, and you want them to have feet on either side of that line.
I understand and agree - im sorry i don't mean to attack you personally, its more of a satire about FAANG interview processes. My first comment was responding to the quote about difficulties hiring SREs at Google and their interview process in particular (the quote in the parent comment came from Google). It wasn't intended to be read as a position one way or the other on any and all coding questions or interviews - I don't think there are any simple black and white rules there. The text justification question is listed somewhere on leetcode as being commonly asked by Google and is a bit more involved than a simple leftpad or "do you know how to code" sort of question.
Apropos of nothing, I went and did that leetcode problem - Getting the algorithm took me about 10 minutes, figuring out how I'd messed up my fenceposting took another 25, and figuring out what they wanted for the last line took me about an hour. Ugh.
When did he stump in your fictional scenario? When you asked him to prove that the number is indeed minimal? It's trivial too but may be an unreasonable thing to ask during SRE interview.
I'm sorry that's impossible. As you know, all candidates sign NDAs and FAANG tier developers have only the highest standards so they would never reuse a question - they would just make a new one.
