
I got asked LeetCode questions for a dev-ops systems engineering job today - dionmanu
https://www.reddit.com/r/cscareerquestions/comments/c017up/i_got_asked_leetcode_questions_for_a_devops/
======
caymanjim
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.

~~~
pault
> My resume speaks for itself.

At the time of this writing, I am working with someone who has 10+ years of
experience, including former positions as a lead developer. I was involved in
the interview process and made the recommendation to hire, as they were able
to answer a lot of domain-specific questions very well and had a good
knowledge of the ecosystem. Fast-forward three months, and I am spending hours
per day sending changes back on code reviews for features that would have
taken me 30 minutes to implement. Every review has at least one conditional
that always evaluates to true. Yesterday I found a try/catch block that always
throws inside of the try block. The crown jewel was the following for-loop
(psuedocode):

    
    
        for i=0; i<=3; i++:
          try:
            doSomething();
          catch:
            if i<3:
              continue;
            else if i==3:
              break;
    

And the best part is because of political reasons and difficulty hiring a
replacement, we can't fire this person. I now include coding exercises in my
interviews. I typically focus on reviewing code with bugs and refactoring bad
code instead of forcing them to whiteboard.

~~~
onlyrealcuzzo
Entrepreneurial engineer here...

If I ever hire an engineer for my business -- I hope it'd be someone I've
already worked with and know -- but if it had to be someone random, I'd pursue
this method:

1) Solicit Resumes

2) Pick N candidates

3) Phone screen to make sure they aren't complete assholes

4) Stack rank & pop top candidate

5) Pay them to develop a feature on contract

6) If satisfied, repeat step 5 until ready to hire; else repeat step 4.

I think it'd be important from the start to let candidates know they might
need to do a week or more of work (for pay) before getting a final hire. Some
people would be put off by this, sure.

But I suspect the people put-off would be people desperately seeking full-time
employment. I think it might attract a lot of talented people that don't want
to go through a 4-week long ceremony of an interview process that takes up
days of time with no pay, though.

~~~
kevstev
This seems good on the surface, but I can't imagine top tier talent at a FANG
or equivalent ever leaving their job to do this.

I feel this filter will only leave behind those who are currently contractors
that are interested in maybe going full time, and the unemployed/employed who
are desperate enough to go along with such a scheme. Foregoing the typical
crappy interview process is one thing, but working, even for money, without
any certainty as the end outcome would certainly turn me off.

To be honest, this setup seems like something that would be hatched by a
scummy company to constantly string you along with a carrot that will never
come. I am not implying that you are that type, but there are enough horror
stories out there that I would avoid ever getting myself put into that
position.

~~~
mixmastamyk
> top tier talent at...

Must be looking to get out for some reason. Doing a small side-project
shouldn't be a big impediment.

> I would avoid ever getting myself put into that position.

Extreme risk-averse behavior can cause problems on the other side. Easy enough
to give a small-project a try and cut out early when red-flags are actually
encountered.

Just the cost of doing business, IMHO.

~~~
kevstev
They may be looking to get out, but you are essentially asking them to leave
their current job so they can spend a month (or whatever) on a paid interview
at your company. You are not only giving up your previous job, you are
essentially giving up your ability to interview elsewhere as well. If this
doesn't work out, either because you don't like me, or I don't like you, your
business, the tech stack, whatever, I am now in a really shitty position, I am
giving up what little leverage an employee has in the labor market- the
ability to look for a job and say no without worrying about paying his bills.

If you are doing well at a company, I am not sure how you make this seem like
a good value proposition, especially in this tech job market. Another way to
put it, with a personal spin- I don't work at an actual FANG, but a company
that arguably pays better, and their would have to be a very large upside at
the other end of this process to make it worth going through. Things would
have to be very bad for me to give me up my deep in the six figure job to
spend a month interviewing at some place unless it had some legendary track
record.

This is all theoretical though and not really worth arguing over. I'd like to
see OP try this out and report back the results, good or bad. I could be
wrong, but I would be willing to wager that you get a lot more resumes just
out of a bootcamp as opposed to people with proven track records currently at
prestigious companies.

~~~
mixmastamyk
Not sure what the other guy implied, but that’s not what I had in mind. Rather
a side project type of thing. Little risk for anyone. No one has to quit.

------
scottLobster
In a few months I'm going to be sniffing around for embedded software
engineering positions (c on microcontrollers, DSP, maybe even some PCB or FPGA
design).

I'm still buying a copy of cracking the coding interview and doing leetcode in
the weeks leading up to applying for precisely this reason. It's dumb but I'm
not going to give up an otherwise promising opportunity in protest, although
in the interview I might politely ask (after solving the problem) what
relevance it has to the job, just to make the point. ("I thought I was a
applying to do _X_ , and this doesn't seem to fit the job description. Does
the job involve a lot of work like this?")

~~~
libria
> although in the interview I might politely ask (after solving the problem)
> what relevance it has to the job, just to make the point.

I highly advise you don't do this, because I don't consider it polite.
Everyone tries to be objective in final review, so don't jab them with
something snarky they'll remember about you while discussing your performance.

It's an exercise, it's artificial. Can you convert an abstract idea into code.
Yes there are bad questions and bad interviewers, that doesn't mean wanting to
see you write code is bad. You don't want Microsoft's new "real world, from
the job" style questions [1] because I've had a few of those and they're
misguided. Way too much internal domain knowledge is missing and I spend too
long trying to get it out of them.

That said, DP in a phone screen for devops is a little tough.

[1] [https://www.businessinsider.com/microsoft-new-developer-
inte...](https://www.businessinsider.com/microsoft-new-developer-interview-
process-2018-12?IR=T)

~~~
scottLobster
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.

~~~
diminoten
There's literally no way to not ask that snarkily. Don't do it.

Also, it _reeks_ of "justice driven opinion having" which is scary beyond
reason for an employer, e.g. "They didn't ask for this feature the right way
so I'm not going to deliver it/deliver it in a way that makes them unhappy."

~~~
scottLobster
I know it's the internet, but you seem to projecting a certain tone onto my
statements that wouldn't be there. I don't know where you got "justice driven
opinion having" from, it's mission-driven opinion having. They need to know I
can code my way out of a shoe-box, and in return I need to know they can lead
a team of engineers through a Chuck-E-Cheese ball pit.

Someone who gets defensive about an honest, neutral-tone question about their
interview process is likely going to be defensive about more important
decisions, which means they take feedback poorly and are likely a poor leader.
This is assuming I'm talking to a hiring manager and not an HR rep.

I don't apply to missions I'm not willing to work overtime for. If I'm going
to make sacrifices for whatever my employment does, I require that my
leadership shares my commitment and is fundamentally competent such that they
don't needlessly waste my sacrifices. In any interview I'll be probing for
that as respectfully as I can, just as they'll be probing me for technical
aptitude and whatever character profile they're looking for.

~~~
diminoten
But that's not what you're accomplishing by asking that question, you're
taking a moral position beyond your role on a topic you're not an expert in.
What you're demonstrating is your lack of perspective and a hubris that can
poison a team, turning it into a snake put where people "neutrally" question
every decision.

The mere fact that you think you can neutrally ask a question like that is a
red flag.

~~~
scottLobster
Or I'm just politely asking for confirmation of what I'm interviewing for, as
I'm participating in said interview. You sound like that proverbial manager
who refused to hire someone because at the lunch interview the candidate put
salt on his fries before trying them, and the hiring manager extrapolated that
to mean he doesn't properly analyze situations before acting.

As for "role" and "expert", you seem to think that in an interview my job is
to be subordinate. Quite the contrary, at present I'm not unemployed and my
bills are paid. I'm looking for an upgrade, not a necessity. So in an
interview I'm still deciding if the company is worthy of my subordination/my
making them more money. I may not be leadership, but I can pick which leader
to support. Leaders who are oversensitive to basic, polite questioning during
a job interview clearly don't want/need help that badly.

Now once a subordinate, obviously there are times/places for questions and
times/places when they are not helpful. But if you consider questioning
decisions in general "poison" for your team, and you fear your team turning
into a "snake pit" if someone starts asking questions, then that points to a
severe lack of trust and/or poor communication between you and your
subordinates. Either of which would turn me away even if you offered to double
my salary.

~~~
diminoten
It's not honest. You're not asking the question to better understand the
situation, you're asking the question to make a rhetorical point. You're not
expressing your opinion, you're hiding your opinion, and setting up a "trap"
for the employer to possibly fall into if they answer "incorrectly". You think
you know better.

Asking questions doesn't create a snake pit, not being straightforward with
your opinions does. Asking leading questions that force people to not trust
your motivations will certainly create a toxic work environment.

Related, I don't think you actually believe I was genuinely putting forward
the idea that you shouldn't ask questions in your interview. I have some not-
great theories about why you chose to do that, but this probably isn't worth
the time it'd take to figure it out with you...

~~~
scottLobster
It is honest, it's just not 100% blunt. I'm saying a professional version of
"Now that I've proven my resume isn't a complete lie, you know these problems
are irrelevant and non-representative, right?" and gauging their reaction with
a plausible out that I was just confirming basic information if I need it. I
can even throw in that anecdote about my previous job where I was hired for
one thing and pushed into another. Hell if there's another engineer in the
room we might even bond over it. If I was 100% blunt I'd be guilty of the very
snark you say is impossible not to have and likely get less information about
them thanks to pushing too hard. I have to pass their "is he completely full
of shit?" test, why shouldn't they have to pass mine? Ideally we both pass our
respective tests and both sides become much less guarded as the interview goes
on.

As for "knowing better", in the past I occasionally have known better than
some of my bosses, as born out in money lost (once to the tune of millions of
dollars) doing it their way until they (miraculously and of their own accord,
of course) came around to doing it the way some of my co-workers and I had
been promoting. Was a minority of cases, but often enough that I don't assume
competence or honesty from strange managers without at least some indirect
verification.

As for not asking any questions in interviews, I didn't mean to insinuate you
meant that exactly. But from your statements it appears you would have issues
with non-technical non-job-specific questions, because I'm an engineer and
such questions would be "taking a moral position beyond your role on a topic
you're not an expert in.". Which to me sounds like "Engineers shouldn't judge
businesses beyond their immediate role because they don't have business
degrees". To which I'd say I don't need to be an "expert" to judge
interviewing techniques any more than I need to be a licensed auto-mechanic to
change my oil and brake pads. Likewise I've learned the hard way to examine a
business's financial incentives/disincentives, business model and direct
competition more closely than the job descriptions, because those factors will
determine the nature of the job I'm applying for a lot more than any given
mission statement or brief description in an interview. So I may ask questions
about those topics as well, despite being "beyond my role".

Since you value direct honesty about intentions: this conversation is
beneficial to me in forcing me to explain/defend these perspectives in greater
detail than I usually have the opportunity/need to. So for whatever it's worth
I thank you for that. It's clear we both come from very different experiences
in approaching this scenario, and I'm sure your experience bears out your
arguments just as mine does my arguments. I doubt we'll come to an agreement
here, but part of me wonders how I'd do in an interview with you if I wasn't
aware it was you and you weren't aware it was me, from this thread. Probably
never going to find out, but would be interesting.

~~~
diminoten
I can't honestly said I read this. The fact that you're writing this much to
try and justify something so simple and unimportant should be a red flag to
you.

------
opportune
I guess if you don't like the company's interviewing process you don't have to
work there. Unemployment rate for software engineers is pretty low these days
so just go with somewhere else. I'll keep working at places that ask
programming questions because basically all the highest-paying places do that
these days. And as snobby as it sounds, I want to keep working with other
people who can pass algorithms teasers

Also, yeah probably no dev-ops position really requires knowledge of DP. But
they generally do require programming knowledge and probably an algorithm here
and there so it's not entirely inappropriate

~~~
shepardrtc
> they generally do require programming knowledge

Yes

> probably an algorithm here and there

No

Even Amazon doesn't ask about algorithms for DevOps. When I interviewed with
them for a DevOps position, they asked me to write a Python script to parse
logs files. They also asked about various linux commands that you would use to
work with those same logs. Pretty relevant. But the interviewer never once
asked about algorithms or anything like that.

My current company gave me a take-home test to build out a solution that
deploys a code package. Best interview question/task I've ever had. It was
hard, but I got to show off my real skills.

Companies that ask leet coding questions for DevOps probably have no idea what
they're looking for and probably don't know what they're doing.

~~~
52-6F-62
Hm. I spoke with Amazon (AWS) recently (haven't interviewed yet), and they
made the express point that if I were to accept an interview that I should
brush up on my algos and HackerRank questions because they _loved_ HackerRank
and would surely use a series of those-style problems throughout the interview
process.

My last in-depth interview was a take-home/collaborative project (paid) for a
smaller company here in Canada. It was a great experience. So good on you.

~~~
diminoten
It's probably per-team, someone on here mentioned that's how Google works at
least.

Someone I know did an AWS interview round during business school, and they do
this thing called "bar raising" (IIRC) that involves one of the interviewers
literally doing something unpleasant to see how you react (e.g. picking their
teeth in the camera, cutting you off when you speak). Very odd.

~~~
BryantD
That is not what bar raising is intended to be. There's always a bar raiser in
an Amazon interview loop who is not affiliated with the hiring team. They ask
the same kinds of questions as the rest of the interviewers in the same way,
but they're not influenced by how much the team needs to make the hire, which
in theory prevents the team from lowering the bar just to get a warm body in.

I'm not saying your friend didn't get a bad interviewer. It's just an
interesting demonstration of how risky it is to generalize from anecdotes.

~~~
diminoten
It was a generally accepted practice based on talking to the folks who
interviewed with Amazon during my wife's time at Kellogg that one interview
would be conducted by someone (an interviewer who had done 100+ interviews)
who would be unpleasant in some way.

I'm guessing the way Amazon interview for business roles is somehow different
than how they interview for specific team positions. As I understand it, MBA
hires aren't filling specific gaps on teams, since the hiring process is so
long and involves an internship. There wouldn't be a "team" to lower the bar
for, in other words.

------
kache_
The reason that people still ask algorithmic questions is because they work
for avoiding false positives. False positives are a lot more damaging to a
company compared to false negatives. While algorithmic questions can get many
false negatives, they don't get much false positives.

What does it mean for a software developer? Spend a few hours a week doing
leetcode questions. They're really not that hard.

~~~
coleifer
Yeah, I studied for an interview and it paid off huge. Just treat it like a cs
exam and you'll be fine.

~~~
collyw
I did that nearly 20 years ago. Why do I need to do it now?

~~~
jahewson
Why did you do it 20 years ago?

~~~
collyw
I was in University and had exams.

------
docker_up
I am preparing myself for a week of onsite interviews as we speak.

Of course I hate them, but what other choice do I have?

The biggest problem is that the questions are so random and span almost
anything.

Will I get asked:

a pthread question?

implement mergesort or quicksort?

implement a Read/Write lock?

implement a smart pointer?

a bit manipulation question?

topological search?

dynamic programming?

graph question?

backtracking question?

What the default timeout for TCP/IP is?

a Java internals question?

best practices about Cassandra?

N-ary tree search?

linked list?

b-tree?

Paxos vs Raft?

What is the access time for an SSD vs spinning disk?

How does Hadoop work?

Design Netflix

various random programming questions, as evidenced by Leetcode's 1000+
questions

It's impossible to know everything and yet this what people expect and ask.
I've been asked those questions above over the last 6 years. It's utterly
insane the expectations that interviewers have.

I personally also interview candidates, I've done hundreds of interviews
throughout my career. These days, I do about one interview a week, and often
2.

My coding question is a simple recursion question, with a for loop and some
basic knowledge of data structures. It's not hard, but I look for perfect
code. If you can't code a bug-free 15 line function in 45 mins, that's my red
flag. I don't think that's unreasonable. As long as the person asks good
questions, we work together well, and they can code in a sane way, to me
that's a pass. Interestingly, 70% of the people fail the interview because
they can't code properly, even after the phone screen. I think because people
are expecting a hard leetcode algorithm question, they can't think properly
when someone asks them a simple question.

~~~
hjk05
> It's utterly insane the expectations that interviewers have.

Not really though. They always manage to fill the position. Interview’s see
the system as unfair because they think their interview happens in a vacuum.
You get x questions answer all correctly and your awarded with a job. So
naturally you complain when you feel half the questions are too advanced or
that more brain understanding is enough. In reality the interviews are just a
sorting, and when everyone can answer the relevant questions you start asking
harder ones because “we picked a candidate at random from those who got the
questions right” is just not a satisfying endstate.

~~~
blub
> In reality the interviews are just a sorting, and when everyone can answer
> the relevant questions you start asking harder ones because “we picked a
> candidate at random from those who got the questions right” is just not a
> satisfying endstate.

That's just silly. If they can answer the relevant questions, they're
qualified period.

~~~
hackinthebochs
Generally people don't just want to know that they got a qualified candidate,
they want to know that they got the best candidate available. And so having a
more sensitive differentiator than 'passes basic qualifications' is important
to most people.

------
icedchai
_Good_ DevOps engineers are software engineers that can also do infrastructure
work. They should be able to code. Unfortunately, many are "cloud sysadmins",
for lack of a better term.

~~~
dijit
_Good_ DevOps engineers are anyone on either side of the discipline spectrum
who can work with the other side.

DevOps are teams, not people.

[https://devops.com/is-devops-a-title/](https://devops.com/is-devops-a-title/)

~~~
icedchai
And people work on those teams. We are talking about the expected abilities of
such individuals. How do you assess these abilities? What is expected?

~~~
dijit
The whole point is to make your team heterogeneous*, so in terms of skills you
need to staff for all your needs.

"We'll use python on GCP with PostgreSQL as a backing database"

Well, then you need an expert in GCP, Python and postgresql. This can be as
many people as it takes to have those skills covered.

As for responsibility, well, that goes for where your skill is. If you're the
resident postgresql expert then you're expected to be responsible for
supporting people with it.

It's likely you'll need to worry about patching the OS and stuff like that,
but I don't think you need a dedicated person to be responsible. The point of
DevOps is mostly to bring down the silo'ing, not to eliminate a particular
role.

But it certainly appears employers are salivating over the idea of hiring less
specialists, or simply rebranding sysadmin to "devops".

~~~
dragonwriter
> The whole point is homogeny,

I'd rather say the point is the opposite; devops teams are (even moreso than
agile dev teams) heterogeneous (or “cross-functional” or “multi-
disciplinary”).

There's basically a continuum where assembly line analysis / dev / test in
separate teams (and security, operations are separate higher level
organizations with the technical area, and business is separate from
technology) is one extreme, then agile dev teams unifying the
analysis/dev/test functions, then devops, then devsecops, then maybe the other
extreme is some thing that goes beyond devsecops where also domain expertise
(and not just the system analysis skills that interface with domain experts to
elicit requirements) are an organic part of the team.

But each step along the line _does_ increase the expected range of skills of
an individual team member, because you need also to avoid any team member
being a single point of failure _and_ you have to keep teams in manageable
sizes (e.g., 5-9).

~~~
dijit
> The whole point is homogeny,

Whups, I used a very wrong word here, I meant to use the word "heterogeneous".
My apologies :S

------
Stronico
When interviewing people I usually push until I get the candidate to answer "I
don't know" on SOMETHING, just to see if they can do it. Not everyone can, and
a lot of people will happily come up with a technical word salad to hide their
perfectly understandable ignorance on some obscure technical problem I just
came up with. That way you get to hear how they ask technical questions.
Asking questions is a valuable (and largely separate) skill too.

It's important to have someone who is able to stop and ask for help instead of
going further down a blind alley. I've found it filters out a lot of the know
it all types who never mange to get anything done.

I doubt that was the intent of the OP's interviewer, but you never know.

~~~
skrebbel
That's a trick question. Trick questions are bad because they test
interviewing skill and not programming skill.

It's a trick question because you want the interviewee to answer something
different (I don't know) than what you're asking them to answer. Confident
applicants might feel up to saying they don't know, but nervous people who are
very self conscious in an interview setting may respond completely differently
than they would if they were asked the same question on the job by the coffee
machine. Their mind would be racing "oh no, I'll look so bad" and they'd go
into full panic mode.

Don't ask trick questions. It's smug and useless. Plus you'll be missing out
on great smart colleagues who happen to stress out about job interviews.

~~~
jstanley
It's not quite the same as a trick question (which I agree you should avoid).
He's not looking for the interviewee to say "I don't know" to any particular
question. The correct answer is a perfectly acceptable answer too. The
_unacceptable_ answer is to make up bullshit, which is precisely what he's
trying to filter out.

~~~
mondoshawan
In the process you are pushing the candidate to the breaking point and
eliminating any confidence they may have had in their abilities. They will end
up demoralized and most likely fail the following interviews if they're the
nervous sort. If they're smart, they'll bid you goodbye and you end up with a
black eye reputation.

~~~
Stronico
Any interview (of mine) is a conversation - they're not something you pass or
fail - it's just a way for a potential employer and employee to get to know
one another so they can make better decisions. Nobody won, lost, passed or
failed. The interview is just there to provide more information to determine
if the potential employer and employee would fit well together.

If I were in an interview that was presented as a zero sum game I would walk
out too.

~~~
Balgair
> Nobody won, lost, passed or failed

I mean, like, yeah they did. They either got the job or they did not.

~~~
Stronico
The interview is there to provide more information about a possible
relationship. Winning an interview is like winning a date (assuming you want a
relationship with the other person.).

~~~
varjag
A special kind of dating where money are involved.

------
cryptozeus
They can, it depends on the role. Not referring to you but I have never
understood why DevOps at many companies can’t program and are just hired to
copy paste files.

“DevOps is a set of software development practices that combines software
development and information technology operations to shorten the systems
development life cycle while delivering features, fixes, and updates
frequently in close alignment with business objectives.”

~~~
opportune
Most of the devops (side question, is SRE technically devops?) people I work
with are programmers who know a lot about test+build frameworks, CICD, cloud
resource management, etc.

I don't think it would be appropriate to call someone copy-pasting templates,
manually adding VMs, etc. "devops"

~~~
dijit
SRE is a way of implementing devops. It's pretty broadly mentioned in the
first pages of the SRE books that google put out.

[https://cloud.google.com/blog/products/gcp/sre-vs-devops-
com...](https://cloud.google.com/blog/products/gcp/sre-vs-devops-competing-
standards-or-close-friends)

------
rjf72
This is a natural consequence of an increasing supply of qualified labor. Do
you need a college degree to serve coffee? No. Does it have anything at all to
do with serving coffee? No. Yet, it's now something sought after among new
baristas, who generally earn a hair more than minimum wage. [1] Why? Because
there enough people who have a degree that be willing to do this job at these
wages to make it a requirement.

The consequence of 'get [anybody with a pulse] into coding' is to help
increase the supply of people with some coding ability. Out of curiosity I
just searched for 'QA job listing' and found stuff like this [2]. A 'senior QA
engineer' requires, among other things, a masters in computer science
alongside a willingness for unanticipated travel/relocation for "long and
short term assignments at client sites." Starting salary? $73k. That's
probably an H-1B angle-shoot (H-1B employment requires not displacing American
workers, and if nobody applies you're obviously not displacing anybody!) but
even then they still have to be able to argue that their request was not
entirely unreasonable.

[1] - [https://www.inc.com/suzanne-lucas/why-that-barista-has-a-
col...](https://www.inc.com/suzanne-lucas/why-that-barista-has-a-college-
degree-grade-inflation.html)

[2] -
[https://www.indeed.com/rc/clk?jk=5d42d374514328da&fccid=d045...](https://www.indeed.com/rc/clk?jk=5d42d374514328da&fccid=d0458096ad5f3137&vjs=3)

------
marcinzm
That depends on what is expected of the DevOps position I feel.

If you're going to need to dig into the source code of infrastructure pieces
to find/fix bugs or write your own infrastructure pieces then a SE interview
makes sense. If you're doing things at scale or using newer technologies then
these come up often enough and resolving them can have significant business
consequences (not getting into if choosing that path was a good business
decision or not, separate topic).

~~~
xfitm3
Being able to read and debug code is a different skillset from first hand
development.

~~~
marcinzm
If you're depending on open source software then you also need to be able to
fix the code in question. And do so in a way which the project would accept.
Otherwise, your bug report may linger until the end of time.

~~~
toomuchtodo
Then hire for software engineering. Don't lie to candidates that it's a
systems admin or devops role.

It's pathetic employers keep demanding more skill and free work for the same
pay.

~~~
marcinzm
>It's pathetic employers keep demanding more skill and free work for the same
pay.

In my experience DevOps pays better than SE (and much better than sys admin)
because it requires a diverse set of skills. DevOps in that context is not
just a new term for sys admin.

~~~
toomuchtodo
I have yet to see DevOps roles that require "diverse set of skills" beyond
sysadmin skills, very basic knowledge of at least one language such as Java,
Go, or Python (occasionally only PowerShell if its a Microsoft shop) and
either Terraform or Cloudformation for IAC. The pay delta between the two
roles is less than you think (excluding SF/BA market, but that market is
always an outlier).

DevOps is sysadmin with more scripting, more infrastructure as code, and more
expectation that you're an underpaid SRE. It also seems like DevOps role
demand more unpaid on call responsibilities, where this is usually not the
case with traditional sysadmin roles (or it's spread across a much larger
team, negating the pain). YMMV.

Disclaimer: 20+ years in tech, the majority in ops roles.

------
matz1
Complaining about leetcode is unproductive. Leetcode is not even that hard,
tons of material and key to the answer is on the internet.

Another benefit is, its streamline job searching. You practice once and you
can use the same skill to interview for many companies.

~~~
arnvald
It doesn't matter whether it's hard or not, it's at best a mediocre tool to
determine programming skills. Also, it leads to a spiral of becoming worse:

1\. being able to solve LeetCode tasks doesn't mean you're a good developer

2\. not being able to solve these tasks doesn't mean you're a bad developer.
So we have a tool that has a certain (IMHO high) rate of false positives and
false negatives.

3\. people start realising that LeetCode is becoming a go-to tool for
recruiters, so instead of studying to become better developers, they study to
become better at solving LC exercises, which increases the rate of false
positives

4\. with developers becoming better at LC, the bar is set higher and higher
(because people spend time learning LC), so people who do not study LC
exercises become far behind those who do, which also increases rate of false
negatives

5\. repeat points 3. and 4. until mastering LC exercises becomes more
important than being a good engineer

This is a ridiculous trend which in my opinion only emphasises how screwed up
is hiring in our industry.

~~~
rjf72
You have to consider the perspective of a company or a recruiter. Their goal
is not to simply find somebody who is capable, it's to take the hundreds if
not thousands of prospective applicants they have and then cull that down to
the tiny handful that they advance along for the openings that they have
available. You're not looking for reasons to accept people, but for reasons to
reject them. It's just the nature of employing for positions when with a large
pool of interested and qualified labor.

Should movements such as 'get [anybody with a pulse] into coding' succeed, you
can expect to see an ever increasing absurdity in requirements. The reason is
not to try to be elite or whatever, but because the reality is you have to get
rid of of > 90% of applications, for larger companies it may be > 99%. And so
as the number of applications increases, you get an ever larger quantity of
people with at least the minimum requirements and so you are _forced_ to be
increasingly selective.

Does passing some leetcode task mean you're a good developer? No, of course
not. But if you take 100 passable developers and you're looking for the best,
are they more or less likely than average to be able to pass such a test? It's
the same reason that even though a college degree has absolutely 0 relevance
to serving coffee, you're increasingly seeing companies "preferring" college
degrees for their barely above minimum wage baristas. [1] If you take 100
potential baristas is that best of the best of those 100 more or less likely
to have a college degree? Even though it has nothing to do with the actual
job, it's just a decent way to filter 100 down to 1.

[1] - [https://www.inc.com/suzanne-lucas/why-that-barista-has-a-
col...](https://www.inc.com/suzanne-lucas/why-that-barista-has-a-college-
degree-grade-inflation.html)

~~~
mgoblu3
I feel this perspective gets lost a bit. Big companies don't roll through 1000
applications with 50 open spots and try to hire the best 50 candidates. They
want to find maybe people in the top quartile of that, while spending the
minimal amount of time on costs to find the adequate fits, and the cost of a
false positive is way higher than the cost of a false negative.

Is the process great? Absolutely not, and I'm sure that these places miss out
on qualified candidates because of the process and hire some people who gamed
the process. Things like degrees and LeetCode tests and other screening
methods are just ways to reduce cost and risk to get that "good enough"
threshold.

~~~
rightbyte
It is no self evident fact that false negatives are less costly than false
positives.

Understaffed projects might lead to failures, people quitting, expensive
consultant aid etc.

Hireing a bad programmer and two good and ending up giving the poor one easy
tasks or letting him go might be cheaper than hireing two good more slowly.

In general I feel the recruitement process is so random anyway that employers
should just get it done and pick someone after throwing darts at a billboard
with resumés for picking some to interview.

------
closeparen
Isn’t the point of DevOps that you’re a software engineer who happens to work
on infrastructure automation code? If they wanted someone who only knows how
to _operate_ systems they would have called it “sysadmin.”

~~~
mac01021
Yes, but a single dynamic programming exercise is not a great test for the
sort of programming experience you want your devops engineer to have.

~~~
sockgrant
Well it sounds like a phone interview. One goal of the phone interview is to
not waste people’s time with onsite if it’s determined the candidate couldn’t
pass onsite.

If their onsite has more leetcode coding questions, then the interview served
its purpose.

------
ronsor
LeetCode is like the CAPTCHA of hiring

~~~
ilikehurdles
Makes sense. I generally fail both on the first try, despite being both a
software engineer and not a robot.

------
40acres
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.

~~~
abc_lisper
Yeah, they should be able to code. However a DP question is a bad one to ask,
for it is not representative of the kinds of problems they solve day to day.
This is like asking a programmer about deep security questions related to ssl
or the details of the latest kernel bug or spectre. It is good to know those
for a programmer but it is a poor signal for the job at hand. Light on my
front porch might illuminate my backyard, but nobody chooses a bulb on that
basis. I would use another light for my backyard.

------
gwbas1c
I once was in the interviewer seat in a similar situation.

We (my company) were interviewing a DBA. He listed C# on his resume. We
develop C#, so I was brought in to evaluate his C#.

He flat out refused to answer my questions.

(In general, if you don't want to work in XYZ, or don't want to be asked XYZ
in an interview, don't list it on your resume. That's why I don't list
Installshield and Visual Source Safe, even though I've done them and can do
them.)

------
devonkim
The issue I have with this interview style is that there’s no data to suggest
that this results in selecting for engineers that can do the job best.
Furthermore, it tends to leave rather little time for the candidate to ask
many questions to the interviewers about things that may matter more such as
“what does your code review process look like?” and “how are tests done?” Far
too many times I’ve gone through these kinds of interviews and wound up in a
horrendous codebase anyway, so fat good hiring for all these people that can
do programming puzzles alright in an interview has done for an end result. The
better indicator I’ve seen for that is a matter of culture and testing for
that is really hard either direction.

I’m pretty happy with how my company does it now. A code sample on a fairly
simple problem designed to determine how their pull requests would look as
well as how much direction they need. On-site is a series of design
discussions with algorithmic questions about data structures to use and the
tools / services that make sense. Primarily meant to hire senior engineers
rather than juniors, but that’s our objective now.

------
kd5bjo
The actual question involved:

> So basically it was a variation of the exact change problem (I realized
> afterwards). You had to validate a string of size n. 1 chunk of 8 characters
> could have 1 format, 1 chunk of 16 characters another, and 1 chunk of 24
> characters another. You essentially had to determine if the string was
> valid. So in other words, find a combination of these sizes in which the
> string could be validated. I had 30 minutes

> It can be a string of size n. It needs to form a valid combo of 8, 16, and
> 24 char strings - each of which have an expected format. Result is T or F

This sounds like a pretty basic parsing problem to me, not dynamic
programming, and likely to be a regular language. There’s a standard tool for
this sort of thing, a “regular expression”. Not recognizing this much is a
huge red flag for any kind of systems/integration role, like DevOps.

The answer here is just matching against this regex, with “fmt1”, “fmt2”, and
“fmt3” replaced by regular expressions for the different packet formats:

    
    
      ^(fmt1|fmt2|fmt3)*$

~~~
SubuSS
The problem is that is bound by your regex implementation and how it handled
overlaps the search strings :). Fwiw many places will just go the next step of
- well implement the regex parsing then!

But this is a dev perspective though. Am assuming a scripting answer might be
good if the candidate knows about the actual regex behavior for devops.

------
phreack
Best interviewer I ever had for a development role gave me a sheet detailing a
(terrible) high level implementation of a ticketing system, gave me an hour to
look at it and then asked me what I thought about it and what I'd do
differently. It got us talking for a long while and both of us learned a lot
about how the other thought and worked. I still think about it, and found it
brilliant. Downside is you can't have an HR clerk do the interview but I think
that's actually a positive thing in the long run.

------
OldFatCactus
90% of my devops interviews have included a tech screen with some
whiteboarding of a fundamental CS problem

------
bcp2384
I am a recent graduate of a well known bootcamp in SF, and impressed there are
a decent number of graduates from last 2-3 cohorts that have landed jobs at
Google. The only trick is knowing how to land an interview in the first place.
If you can do that, succeeding at the technical interview can be easily
taught/learned.

I think it's great that the interview process is so learnable. Why wouldn't
you be happy knowing pretty much what to expect going in when for most roles
that isn't the case at all?

------
peterwwillis
Some thoughts:

1) if the employer thinks DevOps is all about knowing how docker and k8s work,
it's not a DevOps role ( _which doesn 't actually exist by the way_). a lot of
employers think DevOps means "sysadmin in the cloud that can follow an sdlc",
so you have to ask lots of questions to find out just wtf they're actually
looking for.

2) if they ask stupid questions and generally don't seem invested in finding
the right candidate, it was a crap job and you dodged a bullet.

------
jlengrand
I got into the habit of answering those questions orally, and then directly
asking when was the last time it has been used by the person interviewing. In
some cases the interviewer didn't quite like it, but most of the times it
actually led into interesting discussions (finding questions is hard, what
they are trying to gather as info ...). I'm based in Europe though, so YMMV

~~~
deminature
It's frustrating for the interviewer, because they usually need to photograph
your working out to allow others to independently check it later, and
insisting on verbally solving a problem denies that.

~~~
officialchicken
I'm not afraid to hire people who challenge and ask great questions. I ask
that question all the time. The interviewer should be involved with improving
the hiring process, not following the cargo cult of "hiring process".
Obviously if that question comes up more often, they might start asking "why
are we doing X?" and "does X provide better outcomes?"

~~~
jlengrand
Amen! Since I've been involved in hiring and recruitment, I stopped seeing
interviews as a validation of invalidation of my worth and rather more as a
discussion where we are both trying to see if what we have to offer matches
what the other needs. Based on this, most of the interviews are not interviews
anymore, but open discussions.

------
0xEFF
I expect a person in a devops role to not just write code, but write code with
unit tests, integration tests, documentation, deployment automation, to the
style guide etc...

I also expect them to work well on a team, especially in design reviews and
code reviews.

The main difference between a software engineer and a devops engineer isn’t
writing code, it’s the kind of code they write.

~~~
aiisjustanif
> The main difference between a software engineer and a devops engineer isn’t
> writing code, it’s the kind of code they write.

The other main difference is on your team. At my company we would expect that
from a software engineer working on the platform, creating tools or shared
libraries. A DevOps Engineer at my company would handle the orchastration of
shared tools, (i.e. where is Jenkins hosted (VMs or Docker), how it scales,
upgrades from Nexus to Artifactory, setting Dynatrace on prem with hooks into
multiple cloud providers, the list goes on forever.)

Let's not assume all companies are the same, when probably half of DevOps
roles are not about programming in an OO language and you can't easily or
usefully unit test something that is like a configuration for mount locations
across cloud provider

------
vinceguidry
> It really feels like there’s no connection to the reality of the role
> whatsoever anymore.

There's not going to be any reality to your role once you start either. Your
devops role might suddenly become an IC role on their line of business app. It
might become a support role. You might be asked to skill up on a stack you've
never even considered without any notice or slack before you're expected to
produce results in that stack.

The tech landscape changes too often these days. I have a friend of mine who
was hired for his Magento experience but soon found himself learning Java
after Adobe bought Magento. The things department heads think they want are
rarely what they still want by the time you get hired.

It's ridiculous but there really isn't anything anybody can do about it right
now. Tech is eating its own tail, the pace is accelerating, soon there won't
be any snake left.

~~~
toomuchtodo
> It's ridiculous but there really isn't anything anybody can do about it
> right now.

This is patently false. If your role changes drastically, and you don't want
to stay in it, quit. But it does a disservice to workers to say, "You're
trapped and this is just the way it is". It is not "just the way it is" unless
you tolerate it.

Always Be Interviewing. Always Be Ready To Walk. You are a mercenary, and your
job is to command top dollar for your skills while building your network so
you always have your next opportunity at the ready.

~~~
vinceguidry
Sure, walk away. How sure are you that the next role is going to be better?
Another friend of mine changed jobs six times in two years. Now he's having
trouble getting taken seriously.

~~~
toomuchtodo
You're not. You have no guarantees. Is staying in a volatile role where you're
not sure what your job will be next week better? You are in control of your
own destiny. Don't let someone else be.

~~~
vinceguidry
The only thing that puts you in control of your destiny is not having a job at
all.

------
alpha_squared
I might be able to shed some light on one possible way this ends up happening
because I was on a team that did exactly this.

The team/manager probably doesn't know what they want or does and has the
budget for only a single hire. Their expectations are completely disconnected
from industry/reality because they just don't know any better and probably
lucked out getting into their position. They want a strong developer because
the team needs one (or several), but they desperately need ops to keep their
project afloat. So, sure, OP has all the right ops keywords on their resume,
but can they also be that developer we really need?!

I butted heads constantly with my manager who had that mentality because of
things like that. We rejected great DevOps candidates because we wanted them
to be developers and good developers because we wanted them to know ops.

------
starpilot
Isn't this a good thing though? It shows that the competency of candidates has
increased so that harder tests are needed. It used to be that 99% of
programmers failed FizzBuzz:
[http://wiki.c2.com/?FizzBuzzTest](http://wiki.c2.com/?FizzBuzzTest)

------
k_sze
Can we fix the industry by collectively saying no to nonsense/irrelevant
interview questions?

~~~
danmg
A trade union perhaps.

~~~
k_sze
Is IEEE currently the closest thing we have to a trade union?

~~~
danmg
No. They're a professional and standards organization. They are very much
supported by large industry.

The teamsters are a trade union.

------
mixmastamyk
It's a cargo-cult disease, now spreading to other realms.

I don't write code with a gun to my head, clock ticking next to $100k in a
suitcase, swordfish style, and not about to start now. ;-)

------
xorand
From the thread of reactions on reddit, I got this gem:"And finally, the
realistic problems we have at work typically take 6 months to explain to new
people."

------
kjgkjhfkjf
My guess is that whoever was organizing the interviews couldn't find a devops
person to do the interview. They found a regular dev to do it instead, and
that interviewer was inexperienced and asked one of the only questions they
knew.

Moral: Take interview training and make yourself available to do interviews,
especially if you're in a relatively niche role. Make this attitude the norm
in the industry.

------
jshowa3
I've always wondered what the attrition rate is for these types of interviews.
I know I'd probably fail them and I've been writing software professionally
for a while. And this is with me regularly practicing these types of problems
because you simply just can't know. Often solving them takes the entire
interview time in itself.

------
drugme
_What does this have to do at all with the job at hand?_

Nothing whatsoever.

 _It really feels like there’s no connection to the reality of the role
whatsoever anymore._

You got that right. Basically what's going on here is that the people running
these interviews don't really know what they're doing -- and are secretly
terrified of being "found out". So in a desperate attempt to compensate, they
lunge for whatever technique they vaguely heard about being used at, you know,
"leet" companies. And (as others have pointed out) at (apparently) very little
cost or risk to themselves.[1]

Because that way... even though basically don't know _why_ they're asking that
question of you... and not only that, most likely would not be able to answer
an analogously difficult (and unrelated to their own problem domain) question
themselves! --

if you do manage to make it through, they'll at least know that you're "leet".

[1] Except of course, the opportunity cost of false negatives, and the
reputation risk (and damage to recruitment prospects) that inevitably ensues
once your company becomes widely known for mindlessly cargo-culting outdated
and discredited interview techniques. Which they would know about, if they
knew that they were doing. But then again, apparently they don't.

------
rifung
Potentially unpopular opinion..

If companies don't have strong enough incentives to change their interview
processes, doesn't that kind of imply that it is working for them, at least to
a certain extent? At least it doesn't seem to be the case that they are hiring
so many bad candidates they are forced to change.

~~~
jahewson
Actually, yeah, I think that the current hiring process is pretty good at
avoiding false positives. But at the expense of a huge false negative rate.
I'm seeing a lot of roles in SF sit open for months (even > 1 year!) - plenty
of companies just aren't hiring anybody. The best I can tell is that a lot of
engineers looking for jobs are young and relatively inexperienced?

------
stlava
Is the problem that leetcode questions were used or that coding was a hard
requirement for a devops position? I do screeners for my team and being able
to write code is a hard requirement for us. If you can't reason through and
write the equivalent of fizz-buzz it's a problem.

------
pnathan
from the comments:

> I'm not trying to defend all current interviewing practices, but Leetcode-
> style interviews became popular because they're designed to find people who
> are good at programming without requiring overly specialized knowledge about
> specific tools that are popular right now but may not be in a few years. The
> idea is to find someone who can reliably learn what they need to know for
> the job rather than finding someone who's an expert in X and Y which you
> currently happen to be using.

I use synthetic / algorithmic questions for this purpose. I don't need tool
specialists, I need people with wider skills.

I also like concocting fizzbuzz variants as a high pass filter. Some people
fail them...

------
oblio
Heh. I got the full HackerRank/LeetCode/whiteboard shebang for several
interviews at well-known companies, for Release Engineer positions (which
basically fall into the realm of what hype today calls DevOps).

------
NikolaeVarius
I find it much easier to just study those problems when I interview versus
complaining on the internet. The bar is damn low for most leetcode problems
and refreshing is not that hard.

~~~
dbancajas
not when the interviewer wants you to know every corner case of a string
reversal problem.

------
wolco
Graphic Designers are getting these. It's a bit crazy.

------
gregoriol
One time I was asked to match a list of firstname/lastnames with the framework
or tool they created.

So I'm not surprised anymore.

------
walshemj
Hasn't anyone else commented this is for devops FFS

------
Circuits
I think I got lucky. I landed a job at the first company I applied too about 6
months before graduating. I was asked only two technical questions neither
required a white board. The first was about how to deal with a temperature
sensor which was giving erratic readings. The other was about sorting arrays.
Since then I have participated in about 5 interviews of other hopeful
candidates. My company's approach to the interviewing process seems to be
rather straight forward:

* Does the interviewee have a basic understanding of what we do? * Does it seem as though they will fit well here? * How do they deal with failure? * Are they excited about working for us?

and the one thing that seems to be most important:

* If they don't know how to do something are they willing to put in the time to learn?

It seems to have served us well. I am always surprised when I read stories
like this where candidates are turned away for not being able to build a quad-
tree on a white board in 5 minuets whilst hanging upside down by their toes
and repeating the alphabet backwards...

------
0x54D5
What bothers me about all these is how irrelevant they all are to actual day
to day programming on a project. Like okay cool you know how to do the
Fibonacci exercise. What now?

Do you know how to write SQL queries? Have you ever mapped an ORM to a data
store? What about rate limiting an API? Ever had to setup Single Sign On? Have
you ever scaled anything from 100 users to 100,000 users? How do you handle
job running? Concurrency? How would you debug your server locking up due to
100% CPU usage? Ever configured a dev environment on local with xdebug?
Breakpoints? Command line tools? Ever normalized data between multiple third
party APIs? What does normalization even mean to you? What about unit testing?
Mocking data pre-test and cleaning up after test? How do you make it fast?
What's the autoloader? How do you properly setup composer? Tabs or spaces?
Why? Windows, OSX, or Linux? Why? Favorite IDE? Why? Are their opinions so
strong they can't work with others? On and on it goes.

In the past 6 months at my job I've dealt with all of the above issues and
more. I would still probably fail most of the exercise in your Github repo.
Mainly because all of them are irrelevant to the actual work and honestly I
can't be bothered to sit here and memorize various math algorithms that have
quite literally nothing to do with the work.

PHP comes with with 13 different sort functions. None of them test you for how
to write a bubble sort. I'd rather a candidate know when to use one over
another instead of knowing how to write just one or two of them from scratch.
Here's the thing though. I've written bubble sorts before. In college. When
learning C & Java. In no way shape or form do I ever practice them or actually
remember them at a moments notice. I look them up like a normal person if I
ever actually need them.

When I interview a candidate I don't use any of these nonsense exercises. I
have one small code exercise at the end which makes use of recursion. The rest
of the interview is an open ended series of questions on systems and just
basic "shooting the shit" style questions. The nuance of how you answer the
questions tells me everything I need to know about a candidate.

On the flip side if I'm the candidate and someone asks me one of these I know
they actually suck at interviews and my immediate instinct is to walk out. I
try anyway to be polite and not burn any bridges and most of the time I'll
come up with a correct solution but again my initial instinct is "I don't
actually want to work here anymore".

So what do you do instead? Be creative.

Have fill-in exercises. Write an abstract class and an interface and have them
build you a class that implements both.

Write some code with obvious mistakes. Have them fix it.

Build a full from scratch login system. Have a user already in the database
with a hash already there. Make them fill in the authenticate function. Watch
them not use password_hash and ask them why. Make them use Google.

No exercise should take more then 15 minutes. The majority of the interview
should be you digging deeper into their previous roles. Have them tell you
success stories or cool hacks they've put together. You'll learn way more
about them both as a person and as a developer.

------
GhostVII
I feel like interviews are more of a legal IQ test than anything else. If you
are smart and spend a couple weeks grinding LeetCode, you should be able to
solve most of those types of problems pretty quickly, so those types of
interviews filter out those who either aren't willing to spend time on
LeetCode to get the job, or those who aren't smart enough to quickly match up
the interview problem with the ones they have seen before. And of course it
also filters out people who get really nervous during interviews, or who just
happen to get a problem they haven't seen before, but if you are a big tech
company you can generally afford false-negatives. IQ is a pretty good
predictor of job performance, so from the employers perspective it makes some
sense imo, and it also avoids a lot of room for bias accusations.

~~~
ilikehurdles
Ignoring all the false assumptions you make about IQ, the couple of weeks I
could have spent grinding LeetCode I instead spent applying and interviewing
at other companies. Maybe I could have had 3 rather than 2 offers by the time
I made my decision if I didn't ignore Company X, but I also might not have, as
my focus on LC would have taken away focus from preparing for interviewing
with companies who know how to hire engineers.

In my experience, a company using LC usually means that, if hired, 95% of your
coworkers will be young 20-somethings fresh out of college. Generally, that is
who has the time and lack of self-worth to put themselves through this
process.

But the often-mocked LC interview wasn't as prevalent as I thought it would
be. As a senior+ engineer I generally saw some system design whiteboarding and
some take-homes, with a lot of engineer-run companies proudly proclaiming
during the interview process that they don't interview that way. So I get it,
LC is the standardized test for college grads entering the real world who have
no professional experience to demonstrate. And that's fair, you gotta vet
junior engineers somehow, I guess.

The one company that asked me straight-from-the-book LC-style puzzlers was an
established SF-based startup that opened an office locally. Luckily it was a
puzzler I had already watched someone solve on youtube and had memorized so
thanks for testing nothing about my technical ability I guess.

