Hey. Could experienced folks participating in SRE interviews frequently share how often they encounter algorithmic stages? I struggle in this area and plan to invest time in system design, behavioral questions, and fundamental topics like Linux, networking, operating systems, and scripting.<p>I suggest skipping the company if an initial interview mentions an algorithmic part.<p>What implications might this strategy have? I'm not particularly interested in FAANG companies and would be satisfied with a slightly above-average salary for an SRE role.
What is your location? Personally, I've never been asked about this stuff in an interview. I think I've been asked about big 0 notation a few times and some patterns but none of this pure leetcode stuff. This is one good thing about AI is it might end this regurgitation of patterns which can be looked up if required.<p>Assuming you can cobble stuff together and are organised, I would suggest reading stuff like Designing Data Intensive applications. What sort of roles are you going for, assume you are in web or backend dev, not something more low level?
SRE is an overloaded term to the point that even at Google it can mean vastly different things.<p>Google has two kinds of SRE interviews - SWE SRE and Systems Engineer SRE. The former is basically a SWE interview, the latter is more traditional "systems engineering" type interview but also an emphasis on distributed systems.<p>I've seen smaller companies use SRE to mean an infrastructure software engineer who also does oncall, I've seen it used to mean a K8s bitch, i've seen it used to mean someone who does DevOps/CI/CD coding, or it can mean a new name for a traditional System Administrator.<p>Basically, I'd practice coding, maybe simple algorithms just in case, along with all the rest, but be aware of the vastly different job duties that title might actually have.
Anecdotally, I've worked in non FAANG orgs for like 15 ish years (just web dev though). Never once been asked an algorithm question.<p>A few years into one job, my coworker (the one who interviewed and hired me) asked me over lunch "remember fizz buzz?", and I was like "No, what's that?" He explained the problem and I wrote a simple script with modulus and nested ifs that seemed to work. I asked him what the point of it was and he didn't know either. Then we went back to work and never talked about fancy algorithms again...<p>But the flip side of this anecdote is that I'm still just a web dev. I would never call myself an engineer, software or otherwise. I also don't get paid much (by tech standards), even though my salary is high by my own standards ($25 to $50 an hour, hacking together PHP and now JS scripts). Terrible for an ivy league comp sci grad, not too bad for a self taught high school dropout.
I expect them to die out quickly now that AI can do algorithms effortlessly. It'll be like how those sine tables were replaced with calculators in exams. The questions will be less about how to find the optimal movement of a chess knight, and more of build a full chess board with 6 knights.<p>We do algorithms in a sense, but it's more real world stuff like being able to understand the Byzantine generals problem. Not explaining the term, but rather questions where if you were familiar with the concept, you could diagnose the given problem. If you're not familiar with it, you might not know with why it's happening and you might not be able to google it or ask AI what the problem is.
I worked for a company that really focused on a specific algorithm question in the interview. The correct solution required solving a pretty complex indefinite integral, which basically selected for people with a math or physics background (I was cut some slack for not solving it because I was an intern). Hence, the company was full of really smart physicists who didn't know modern software practices. Eventually they folded because even though they had really impressive demos, they couldn't scale and produce a working product.
Its pretty common to see "easy" algorithm problems or potentially build a small simple app as a way to test that you can actually code. I'd say 75% of companies I've interviewed at have at least one algorithm interview with hands-on coding. This seems to be even more true at big tech companies because you're likely debugging software written in multiple languages.