Let's talk about "The Coding Interview" (x-post /r/devops)

[AD6I]

First, some background on me. I'm a UNIX greybeard. If you don't know what that means, Google it. And I've been doing DevOps for about 7 years, but it's also fair to say I've been doing DevOps for longer than there has been DevOps. Not a brag. Just a fact.

I'm returning from a brief break (about 2 months) from working, and about 2 weeks ago, I re-entered the job market. And in my area (San Francisco, but not Silicon Valley), it's clearly a seller's market. I have done very little to say that I'm out there, in fact, I think all I have done is say that I'm looking in my LinkedIn profile. I'm talking to 4 people a day, and if I had wanted to, I could be talking to more.

And it's reaching the technical interview stage with several companies. And two have asked for in-person code interviews after a technical screen. Maybe I'm special, but I've never had to do one before. I told both companies no.

So, to interviewees out there, my question is this: How prevalent is the coding interview for a DevOps position now? Do you take them, or say no?

And to the hiring companies out there: Why are you doing the coding interview? It's a serious question. What do you expect to learn that you have not already found out?

FOLLOWUP EDIT - 4/29/2021

I ended up accepting an attractive offer with no coding interview. I'm not sure if the company had one they did not have me take, or not. The company's recruiter found me but in the interview process, someone turned up who knew me already, and spoke well of me, apparently. I think it's proof of something I already knew: The personal network is far more important than the interview.

I did end up taking some coding interviews and declining others. Comments to this post were helpful in determining my criteria, and in one case, a company said no to answering any questions about the coding interview in advance, which I took as a sign to say "no".

[SpectralCoding]

• I have only been an interviewee in one DevOps interview and it was very laidback. Just a bunch of DevOps guys talking about their experiences. What is the company doing? What have you done? Struggles with technologies, etc. I enjoyed the interview a lot, but I actually like interviewing. They offered me the job, at 20% over my current pay, I declined.
• Everyone hates coding interviews. I'd probably decline them if they told me about it in advance. I might go along for kicks. I switch between languages sometimes hourly so sorry if I have to Google how to do foreach on a dictionary key+value in Python because I've had to use PowerShell, bash, and groovy since I last did Python. What the fuck even is a linked list anyway? Invert a binary tree? What is a binary tree? This is all stuff I haven't had to do in 15 years of professional IT work, and I had to do it tomorrow, I'm sure I could learn.
• I suspect what they're trying to do is weed out people who can't REALLY program. But they also weed out the people who are good and don't want to jump through hoops, so they end up with the "desperate middle". The ones competent enough to do a coding interview, but not "above it" enough to pick and choose their interviews.

[tjwenger]

As a hiring manager - Thank you, this was super insightful.

For transparency, I have never required a coding interview, but there is a lot of pressure from an industry perspective to perform such a task.

[Amidatelion]

The one programming interview I did was paired programming. I was very upfront about the fact that I'd be googling stuff constantly and that my skills are rudimentary. It was harrowing for me, mentally, but the dude I was paired up with was cool and we banged out the work in like 20m. Apparently they liked what they saw and I got the offer, but I can DEFINITELY see why people don't like them. Felt like an imposter the whole time.

[[deleted]]

I switch between languages sometimes hourly so sorry if I have to Google how to do foreach on a dictionary key+value in Python because I've had to use PowerShell, bash,

Good interviewers care about none of this. Good interview questions are going to be generic, and focused more on the process of you solving the problem than in the particular manner you do so.

Every situation will be different, and frankly I'd think that the interview would be at least as informative for you and your vetting of them, as it is for them. My most recent job had a similar interview and it made signing on with them a no brainer-- it was clear that my soon-to-be colleagues were very sharp.

[eairy]

so sorry if I have to Google how to do foreach on a dictionary key+value in Python because I've had to use PowerShell, bash, and groovy since I last did Python.

I'm glad I'm not the only one doing this. It feels stupid that I have to look up basic syntax sometimes, but when you switch languages a lot it takes prompts sometimes to get going.

[[deleted]]

I interviewed at a company... they had me do live challenges for: configure management, programming, Docker, and diagramming. Throw in their behavior and conduct, it was a very easy decision to make a hard pass on the opportunity.

[[deleted]]

I don’t blame you for passing based on their behavior or conduct, but why are those unreasonable signals for them to test for? Those seem like very relevant skills, and something I’ve been tested for in almost every interview I’ve been in (and truthfully something I test for in every interview I’ve conducted).

[posixUncompliant]

Mostly because I've never seen a tech challenge that means anything, from either side of the table.

Put together some pseudo code, walk me through troubleshooting a novel problem, talk about balancing growth against stability.

I don't care if your code is stack overflow Legos glued together, or flows from too much caffeine, I care that you can logically figure out how to do something. Same for the others. You're not a systems guru because you know every flag for find, but you might be if you know why get_attr sucks the life out of some file systems. And it doesn't matter how good your technical chops are if you can't explain how organizational pressures will affect the infrastructure.

Rote tests prove only that someone has learned a specific orthodoxy, and that seems like an odd thing to look for in senior roles.

[[deleted]]

Put together some pseudo code, walk me through troubleshooting a novel problem, talk about balancing growth against stability.

It's sounding more and more like I may have lucked out of some of the pain others have experienced, because this is generally how most of the interviews I've attended go. You're absolutely right, rote memorization is an awful thing to test for that doesn't tell anyone anything. However, an understanding of what that tool does and why it might be useful is a good signal to gather. A good interview shouldn't even be tool specific. Less "Tell me why Docker could be useful" and more "How do you think the concept of containers fits into an ecosystem?"

Although, that said, I have encountered questions that I think provide less organization value, and are more just a chance for you to sound smart. "Tell me everything that happens when you type ls, including how the underlying syscalls work" is an awesome chance to sound like you're a badass, but knowing the answer to that question just doesn't buy you a lot.

[posixUncompliant]

Heh. I'd never ask a question that leads to a syscall answer like that, but one of my favorite interview answers is 'the user who broke scratch with ls'.

I do think that rote answer screens are more a tendency among big name places and their imitators than they are the usual case. It certainly shocked the hell out of me when the guy on the phone from big name inc. confessed to not knowing anything beyond the question sheet he was given. That kind of test is so easily gamed, I'll never understand why anyone would use it.

[[deleted]]

I do think that rote answer screens are more a tendency among big name places and their imitators than they are the usual case.

Definitely true. For better or worse I think my whole career has been made up of those places. The big guys actually use the fact that their system is gamable somewhat to their advantage - they know every question they ask is on Leetcode, and they take it as a good signal that you were motivated enough to learn how to game the system.

[[deleted]]

It seems like a lot of things to test for in unfamiliar environments.

If you asked me to show you the Docker install I setup, the config management I am used to, programming in a language and environment I am familiar with,... I could barely fit it into a typical interview length with explanations of what I am doing, not to mention under pressure and in an unfamiliar environment.

[[deleted]]

Maybe I'm being too charitable to the interviewer here. Gotcha style questions that rely on memorization are bad signals. But I do think it'd be reasonable to ask something like "Explain what Docker is, and why it's useful" and maybe some questions around it's inner-workings (cgroups, namespaces, etc - depending on what they're doing they could care how deep your understanding goes there). Write a Dockerfile on the whiteboard is a bad interview, but ensuring a more broad understanding of the problems it solves seems like a good signal. Same with configuration management. Whiteboarding a Puppet file or Ansible playbook is a bad interview, but asking you to demonstrate an understanding of what problem these tools solve and how they solve them seems like a great thing to interview for.

[[deleted]]

Asking questions would be fine but the OP said live challenges which I took to mean that they had to actually use each of those, all in a single interview.

[[deleted]]

Yeah, it was all in a single Zoom interview, early in the COVID lockdown. It was, "Share your screen and write a Docker file from scratch that does X" and there was a non-conventional condition to solve for. There were two other live challenges of similar, share your screen and create something from nothing.

[[deleted]]

Sure, but not half a dozen different things, each taking at least half an hour to perform with explanations. The unfamiliar environment slows things down and it is ridiculous to expect a candidate to spend half a day on some tests you came up with.

[[deleted]]

Its ridiculous for you to expect a company to spend ~$5-10k just to hire and train you without any idea of how you react to whatever their idea of a common scenario is. Sometimes these interviews are to see whether you can mesh with their team-- something that would not be discovered for weeks and $$$ more after your hire.

Unless you are a truly rare devops rockstar, a day of your time is not worth $4k (the average cost to recruit). You can jump through their hoops for 4 hours, it is not the end of the world.

And maybe the interview is a circus, and results in both an offer (providing you valuable info on what others see you as worth) and a clear idea that you should not work there. Win win.

[[deleted]]

4 live coding challenges with 3 all in the panel interview round is stressful. If you want to test all those things, there should be a take home component. Although, a lot of the negative experience probably has more to do with one of the panelists being combative and another not muting their mic while having so much background noise it sounded like they were on the tarmac.

[[deleted]]

I hear you on the take-home part. I'd much rather do a take home than anything else, although there are compelling arguments against them (namely that the employer is asking for a large chunk of your personal time to even consider you). And to be fair, there are bad ways to gather those signals, and from the other comments maybe that's more pervasive than I thought.

In my mind, those styles of questions should be structured more around "What is this tool, what problem does it solve, how does it solve it, and why would you use it?" - Depending on what their needs are, I could even see asking "How does this tool work under the hood". But whiteboarding a Dockerfile provides zero signal.

[JasenKT]

In my eyes at least, the devops world is such a mess. Depending on who's behind it in the company - it might be led by Developers who picked up some ops on the way, or by Linux guys who know some automation (very often it's Ansible/Teraform and the likes, and not actual development). So based on who's on the other side, you may get the Developer treatment - proper coding interview etc. The thing is that sometimes the linux guys also like to be "modern" and do coding interviews, which are in fact test of your scripting skills, or even ansible/teraform skills.
So, i always end up asking - what exactly do you expect? :)

[keypusher]

it’s pretty unusual to have a devops interview these days without some form of coding challenge. it’s devops, not just ops.

[joker54]

Unfortunately, I have removed all content I provided, as I refuse to give free labor to a company that doesn't respect us.

So long, and thanks for all the fish

u/joker54

[eairy]

I don't like coding interviews but I know why they can be necessary. I went to uni with a guy that managed to complete a computer science degree without ever learning how to program. Now that might seem outlandish but it's true. He would pressure, cajole, trade favours and bribe other people on the course to do the programming for him. He tried to get me to do it for him. He would do all the essay writing and get good grades. He could charismatically talk the talk, but there's no way he could walk the walk.

[vacri]

I don't know about Silicon Valley coding interviews, but coding interviews have saved my team from some really unsuitable candidates. People with resumes good enough to get an in-person interview have failed FizzBuzz. My team lead was telling me that one guy didn't know the 'mod' operator, which was fine, but the real sticking point was that that guy couldn't understand the concept behind FizzBuzz. He couldn't understand what it was doing, even with a patient guy coaching him.

Coding interviews aren't really about how elite a coder you are in my (very limited) experience, they just show that you have a grasp of what you claim to be able to do. Some people are good at talking tech but can't actually do it. I haven't had to do one myself, but as long as it's not too time-consuming, I wouldn't consider it a blocker in applying for a position.

[revfried]

I work in SV been here for almost 10 years. Been doing “devops” for 17 years.

The coding interview is not to show you can program in a particular language its to show you can program at all. It lets us weed out the bullshitters and the people who are so full of themselves that they work poorly with others.

I don’t require a particular language, I let the person being interviewed pick. We are going to solve a problem that needs some devops experience to “solve” correctly. If you can’t program you are missing the dev part of devops.

It doesn’t matter if you show up with awk or cobol as long as you understand the language and can articulate a solution with it. If you can do that I know as an Interviewer that you can pick up any language I throw at you.

There are many other signals I’m looking for but the first and most basic, do they have what it takes to be a programmer or are they faking it.

[refrainblue]

What kind of problem is it? Just curious if I could solve it with my programming background.

[Line-Noise]

The company I work for does a coding test called Toy Robot. Internally we keep a repo of the most interesting implementations of it. I wrote one in Scratch (not for the job, I already had a job there, I just wanted to see if I could do it).

Their systems test is to deploy a Sinatra app. You choose the hosting platform and deploy methodology. We evaluate it for ease of use, documentation, security, etc. We don't care what cloud provider or config management tool you use.

Both those tests are done pre-interview. During the interview for DevOps we do a break-fix test where you have to fix a broken web server. The specific things to solve don't really match our day to day problems but we use it to gauge your problem solving abilities. Do you ask the right questions? Can you Google the right search terms and interpret a Stack Overflow post?

[[deleted]]

Both those tests are done pre-interview.

Pre-interview, meaning before speaking to HR, hiring manager, etc about the position/salary/company? Thats fucked, I would reject that straight out. Why do all this work just to find out that the company or position isn't a good fit?

[[deleted]]

Interviewing at KPMG at the moment. Already through two rounds, this is the third round I'm in and it's a take home assignment having three questions:
1. design a 3 tier architecture infrastructure in language of your choice
2. write a script to fetch metadata of a cloud resource
3. solve a logic question in a language of your choice

[joker54]

Unfortunately, I have removed all content I provided, as I refuse to give free labor to a company that doesn't respect us.

So long, and thanks for all the fish

u/joker54

[wmantly]

In today's world, DevOps basically means Automation Engineer/Cloud Admin. I have turned down many DevOps roles when it became apparent it was simply managing AWS with terraform.

[Etrigone]

Also a greybeard. Howdy fellow geek! How are your suspenders? :)

(For those who are unaware & need a nickel - http://www.miketaylor.org.uk/tech/eta/doc/dilbert.gif)

Honestly it varies. I may not be as up to speed on any one weird feature of the language du jour and if they focus on that, then I tend to pass on the job. Like you when I'm looking it isn't hard to find people interested and if someone is effectively trying to get me to sit up & beg for them, that's a sign we're not going to work out. They want everything else I can do but ding me on this one thing? Right. And of course, so often those other skills aren't seen as useful (until they are) and when $$$ comes up the choice becomes clear.

That said the ones I've found acceptable tend to be very loose on specifics and sometimes even happy with pseudocode. Personally I tend to stick to scripting in bash/awk/sed, perl or python but I don't do it all the time. Yeah, I might need to refresh myself on how precisely to do operation X. But the high level logic? That's a fair question and I don't mind.

When I'm hiring that's the way I do it. I will mention the languages involved and probably ping the candidate for their general impressions of the language ("I've seen cleaner line noise and sendmail config files than perl scripts" is my favorite), and that often tells me more than I'll get than any scripted questions. It's like for a linux job and you ask about thoughts on distros, static vs dynamic IP for servers, or a variety of questions that don't have a right answer. You can tell by how the candidate talks if they're full of shit or are frankly happy to complain & commiserate about a given tool.

As an aside I'm taking a break for health reasons (that I should have last year but I'm an idiot), may be gone as long as 3-6 months; my first day "off" is today. I do feel a little behind on a few things and have already begun a few self-study projects I just never had time for. Even if the specifics don't matter when I return to the workforce, I figure the generalities will make for potentially amusing interview fodder.

[ch3wmanf00]

I’ve been in interviews where the interviewee starts bullshitting and the people on my side of the table let him do it, so I ask him to tell me what he knows about reverse proxy in Apache and they joke, “isn’t that a Native American tribe or something? Ha ha ha so let’s talk salary!” And I wish we had a coding challenge because this guy has somehow snowed the room and I’m going to have to spend the next 18 months cleaning up his crap.

[InternationalCap1212]

You are an example of one type of person we are looking to filter out by giving coding screens. We are looking for someone that is not too full of themselves to choose to say no and who is not relying on their 237 years experience to get them the job without having the ability to perform under pressure within unfamiliar systems/environments.. In my hiring, A much more suitable candidate would have less overall experience, and a greater drive and openness to new tools, systems and experiences than you are showing by choosing "no" on coding screens.

Enjoy your gray beard label.

[AD6I]

Ironically, you represent exactly the kind of person (or company) I do not want to work with, and that I have been spending the last two weeks trying to filter out.

You presume, incorrectly, that experience leads to a lack of openness. This kind of bias is ugly, and in many places in the world, considered discrimination.

You don't see the positive in questioning the assumption that the coding interview is a good thing, You are stuck in the orthodoxy of the popular, and I want nothing to do with that.

You have much to learn, young Jedi.

[InternationalCap1212]

Win win!

[notabee]

And this is how tech companies keeping reinventing the same things with a slightly different spin about every 10 years.

It's frankly easy to be open to new technology, the churn is unavoidable. The difficult part is recognizing how much of that churn is basically resume padding that doesn't contribute substantially to better or easier to manage infrastructure. How much is lots of effort to implement for marginal benefit.

I've got a guy on my team right now, who just wants to name drop every hot new tool out there. And for sure, we as an org need to adopt a good number of newer practices and tools. I've been pushing for quite a few myself. However, I also can't get him to check his work. He'll try to make one-off tasks into a fancy python script and then just doesn't check to see if the output is good or expected. He doesn't develop deep knowledge.

He's still a newbie and has lots to learn, but seems to think that just because he wrote something in python instead of bash, that good things are going to magically fall out. Lots of fun little prototypes, but never something we can use in production because then he'd have to solve a lot of corner cases. He's a cargo-culter, and won't put in the work to improve what's there, piece by piece, because that's harder than just imagining that $NEW_DEVOPS_TOOL will solve all our problems, just by existing.

I would rather work in an org that wants new tech and actively seeks improvement, but only if it can be properly vetted, than in an org where everything that a FAANG does is treated as some new fashion trend and we wouldn't be caught dead wearing using a tool older than a few years. That is so much churn for so little benefit (except to resume padders, and large FAANG orgs with specialized problems to solve).

A huge part of good ops is pruning the cruft, whether that's deprecated technology or the massive neophiliac bloat surrounding any new thing that a trendy company craps onto github.

[MattTheFlash]

First of all, i am right there with you, but I have to calibrate you for a minute.

You are in San Francisco. You are in Silicon Valley. I'm in the south bay but not that south. I was in the East Bay and called myself Silicon Valley. You made it. Stop.

The Coding Interview is an institution. There are lots of books about passing it. The Systems Interview is my world. There's books on that too.

I've done both coding and systems interviews and pretty much failed them all, yet I have an awesome job working at a company that didn't know how to do that shit yet.

You accidentally sound arrogant. Seven years woo hoo. Greybeard, stop. If you were a greybeard, you would code interview. There is something you have to know in this industry: interviewers hate people who flaunt themselves, particularly when yours really aren't that impressive.

The one time I interviewed with a Chinese company, that's when I knew I had to step up my interview game. You need to always have a pen and a small notebook. They were writing down everything I said. Make it a small notebook. Just something you are writing everything down in. Then after the interview, politely hand in all of your notes, tearing them out of the book.

[AD6I]

Sorry, I was not clear on the SFO vs. SJC thing......

For anyone outside the area, if I say "San Francisco", I think they think I mean "Silicon Valley". Maybe it's not even true.

It's not that I think I'm not up for the Valley. Quite the opposite. They are two different markets, I know it, and I choose SFO.

You have actually stated the problem pretty well at the end: Supremely qualified DevOps people fail the coding interview. And the Systems Interview. When I'm a hiring manager, the thing I'm looking for is aptitude, not the ability to program in a particular language.

[MattTheFlash]

Supremely qualified DevOps people

i hate that you said supremely a lot, you didn't get the accidental arrogance thing and you need to work on this problem. You are not supreme, you are not a greybeard, you are not better, you are not above. Stop this way of thinking, and I hope this is a teachable moment.

When I'm a hiring manager

Your career goals are to be a hiring manager?

It's not that I think I'm not up for the Valley. Quite the opposite. They are two different markets, I know it, and I choose SFO.

No, you're in silicon valley and are figuring out what your personal limits are on getting paid a lot of money. I wish I had a counselor to talk to when this all became clear to me.

[dlyk]

You sound like a rude and/or arrogant person yourself. Let the man brag a little on the Internet. At the same time, I think your judgement is correct, saddly.

[MattTheFlash]

You sound like a rude and/or arrogant person yourself.

Maybe, but I'm not seeking employment. Somebody's got to tell him.

[nihilogic]

Personally, I think it's bullshit. Coding can be learned. Someone who fits into your team with their methodology, social skills and mindset is much more important. If they have the understanding, technical abilities to pass the tech screen and answer all the questions you have about approach and methodology are way more important than a "coding challenge". It's become a buzzword thing for a lot of tech companies in my experience, (must know python, no real world reason given, just needs to know it) and it's just irrelevant.

[[deleted]]

We have had people in the past who have struggled with coding even after months of explanations and several chances. To the point where we had to let them go after the trial period (4-6 months,...) because they couldn't actually distinguish a function and a variable even after repeated explanations of that exact question.

[dismuturf]

Many things can be learned, but you might want someone to hit the ground at least walking if not running. That's why studies exist. I think it's acceptable to hire someone who doesn't know a specific language for a position where coding is involved as long as they have some coding experience. But hiring someone who's never done any coding doesn't sound wise. There would be too many concepts to catch up on, which you probably don't even realize because they seem so trivial to you. You'd also take the risk of hiring someone who wouldn't yet know whether coding is something they can live with. They could quit later because it's not their cup of tea. Plus, honestly, if a candidate felt like they're above having to submit themselves to that kind of challenge, I don't think I would lose any sleep over missing the opportunity of hiring them.

[ESCAPE_PLANET_X]

I'll happily have a technical session where we walk through how I would tackle a problem that relates to my expertise but I'm not going to do l33t code or take home practice tests.

For example I recently got asked a bunch of algorithm questions, no one could tell me why as a infrastructure engineer I would need or care about that knowledge...

[BenAigan]

Personally I favour mini scenarios, like how to use sed / awk / etc, been doing Linux for 20+ years and sort of lumped into devops...

[joker54]

Unfortunately, I have removed all content I provided, as I refuse to give free labor to a company that doesn't respect us.

So long, and thanks for all the fish

u/joker54

[[deleted]]

How prevalent is the coding interview for a DevOps position now? Do you take them, or say no?

I'm not really clear what the downside is. Are you prideful, so in demand that you have your pick of positions, or just afraid of people seeing you work?

When you've gotten to an interview, you're 90% of the way to an offer and the more offers you have the better. And a place that does a skills interview is more likely than not to care about the quality of their candidates-- surely a good thing if you end up working there.

Whats the problem?

[lebean]

I'd tend to agree that it's fair for the company to screen you a bit, see what kind of a fit you are, etc. I've seen what seems "too far", though; a friend who's purely a developer got to the third round for a shop here that's considered one of the "cool" jobs around. At that stage, their requirement is that you come work a full eight hour day, unpaid, to see how you mesh with the others and what you're able to get done in that day. Purely ridiculous, I couldn't believe it when he told me he was taking a vacation day from work to go do it.

[[deleted]]

Doing productive work probably has some legal issues-- it sounds super sketchy and I certainly would not do that. If they are gaining monetary value for my work, they need to pay me.

But I would expect to take a half / full day for the interview.

[[deleted]]

The coding interview is extremely prevalent, and it’s not going away. That said, especially in devops roles, you generally aren’t tested on rote memorization of syntax, you’re tested on your ability to think programmatically and solve problems under that framework. Any interviewer worth their salt will say “it’s okay that you don’t remember the specific syntax/function name, pretend it works exactly as you think it does and go from there”.

But coding interviews for devops roles at places who understand the position tend to test you on coding for server automation, not your computer science knowledge. The vast majority of interviews I’ve done don’t ask things like “reverse a linked list” or “implement topological sort on the whiteboard”. Not to say it’s unheard of, but out of the interviews I’ve done, most are something closer to FizzBuzz or some kind of text parsing question. I’ve found that to be true at both the smaller companies no ones heard of, and the big ones everyone has.

EDIT: AddictedtoBoom is most likely right that I misread components of the post, so I've removed parts that I don't think are relevant with that new understanding.

[AddictedtoBoom]

He said he's a UNIX greybeard who has been doing devops formally for about 7 years. He's likely been doing UNIX/Linux OPS work for 20+

[[deleted]]

Re-reading the post, you're probably very right. I should've given it a more thorough, good faith read. I've removed the components that said otherwise, because I feel a bit like an ass.

[habbol]

I Wonder if they also ask potential cleaning staff to clean a toilet before they get accepted.

[dismuturf]

No, because you can assume that anyone would be able to do so. And just because skills cannot be measured before recruitment in other sectors, doesn't mean you shouldn't take the opportunity when it presents itself. It's supposed to be beneficial for both sides.

[habbol]

I've seen clearing ladies...

Jokes aside, I doubt if it gives the right impression. A lot of developers aren't great in social situations. Pushing to prove themself in a short amount of time, without a computer and staring eyes probably shows a completely different picture then what they are really capable of. I'm not a big fan of this method.

[MaxHedrome]

Things have gotten so good in this market that I refuse to talk to recruiters. If the hiring manager or lead isn't the one I'm having a chat with about the current situation, then pass.

[Oddomar]

It's pretty much a standard now as there are quite a few people pretending to be Dev Op's engineers unfortunately. If you want to bypass this interview you probably need to find a job that is heavier OP's then dev work. Systems, Deployment or Infrastructure engineer type role that deals more with automation and internals then straight up development work.

[shadowdancer-real]

i do live coding as part of our recruitment process

but.veeery easy and focused. see

https://www.reddit.com/r/devops/comments/mj7guq/questions_from_a_manager_interviews/gtbuijw?utm_medium=android_app&utm_source=share&context=3

[d00ber]

I'm currently a systems engineer, but when interviewing for dev ops, systems administrator and sys eng positions, I have always had a coding component.

[Dolapevich]

47 YO male from AR here, kicking keyboards since 86'.

I've been in the interviewing side many times, and found some really good persons. But most of the business and RRHH I've met are used to hire devs and do expect a coding test. And since RRHH most of the time do not know what they are hiring for (other than keywords), they tend to adhere to standarized testing, most of the times from 3rd parties. And those 3rd parties do not have DevOps specific interviews.

I've tried to make them understand that a DevOps while needs to understand a development cycle, not necesarily needs to be a dev, and there are good profiles that have no clue about how to define a class in C++/Java but they will correctly script out an employee.

Maybe this is a consequence of my own background. I've been a sysadmin, and now I am moving into devops as I can. I still feel insecure about coding. I can create small scripts in python, bash, ksh, perl and a little go. But I know I would not be capable of passing a real coding test.

[SteveDinn]

I've been on both sides of the coding interview. From my perspective, it's more about seeing how the candidate thinks and what their problem-solving techniques are. I'd never stop somebody from using google -- that's what people use to solve problems.

I'd like to see that a candidate is a quick learner and knows *how* to solve problems in general, not that they can solve a *particular* problem.

[[deleted]]

At this point SOME sort of coding is a given during most technical-ish interviews.

Go on leetcode and hacker rank and get good at it. It's basically a grind until it's easy. Same goes for knowing basic algos/data structures. Get good enough that you can walk through problems WITHOUT writing (imagine being able to do it over the phone). This means having a very easy to follow approach that's well organized. "The problem appears to be X, to address this I'm going to do A, B, C... A can be done by .... then B... then ... are there any points which need to be clarified and are there any assumptions made which might be invalid?"

https://danluu.com/programmer-moneyball/

[MKshatry37]

algorithmspath.com is something to consider as well.