I got asked LeetCode questions for a dev-ops systems engineering job today

>DevOps are teams Despite having worked on a DevOps team in the past, I would disagree, in favor of "DevOps are companies". A DevOps team is just another silo, while the DevOps approach should be implemented at a company level to be most effective.

The first and foremost purpose of practicing let code is to get the job, thats the benefit.

You do it in addition of learning skills you use on your job.

Interviewing people is hard. Most people suck at it. I've interviewed over 100 people in my life, and I've been interviewed about ten times. I know I still suck at it.

The code test is one of the more annoying facets of interviews. On the hiring side, it's an efficient way to screen and vet candidates for basic skills. It's relatively low cost to the employer to have a recruiter issue the test.

If you come up with your own in-house code test, it still requires time to evaluate and grade the submissions. There's also a fairly large cost to creating an in-house code test (I know from experience). You have to balance complexity so that it requires enough skill to pass, but isn't so onerous that it puts off too many candidates.

Using something like LeetCode removes all the cost from the employer side. Someone else maintains it for you, and you get a canned score at the end. It also depersonalizes it, and provides an opportunity for people to game the system by memorization. The same applies to using canned whiteboard/algorithm questions.

I think most of this is a colossal waste of time. It turns away people who don't want to spend hours (or days) on each interview. Imagine applying for even a handful of jobs where each one expects you to do a take-home test that can take a full day. Who has time for that? There's the "if they really want to work for us, they'll take the time to do it" argument, but let's face it, most people are not that passionate about where they work until they actually work there.

As a candidate, I am loath to spend my time on these. As someone who's been doing this for 30 years, I'm also a bit insulted by having to do the monkey dance over and over again. At this point in my career, I don't bother applying to places like this. My resume speaks for itself.

Of course it makes sense to vet the technical skills of candidates, but you can learn a lot more from 15 minutes of questions than you can from a code test. If you present a candidate with some abstract questions and a couple of targeted detailed technical questions, you can tell if they've got the right problem-solving mind and if they've had experience with the technology you're working with. It's also a much more personal experience.

Agree that LeetCode style questions aren't the best way to interview candidates but with "infrastructure as code" ruling DevOps shouldn't your Ops people also be expected to code? Does not seem to be an unreasonable assumption.

What does concern about some DevOps interviews is the sheer level of knowledge some companies expect up front. I brushed on everything from the Linux kernel, ops techniques, distributed systems and programming to prepare for an Ops interview.

I wouldn't ask it snarkily. I've been hired for jobs before and then asked to work on stuff that, while related, was nowhere in the job description. Got hired to do Java/C++ development, was pushed into being part-time sysadmin for our primary test environment because my team had spare capacity and our dev-ops team didn't. There were times I went 6 months without touching a line of Java or C++. Another guy I worked with said he got hired for real-time c development and then got pushed into Java development shortly after arriving.

Some managers embrace the notion that all software engineers are basically the same and you can shuffle them around outside their area of expertise and then complain when efficiency goes down. Now granted there are probably more strategic ways to ask about that then the direct method I originally posted, but if I'm interviewing with one of such managers, I want to know.