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

https://www.reddit.com/r/cscareerquestions/comments/c017up/i_got_asked_leetcode_questions_for_a_devops/

by dionmanu • 7 years ago

292 481 7 years ago

marcinzm5• 7 years ago

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).

doitLP2• 7 years ago

Doesn’t sound like that’s what happened. Seems like they have standard questions and phone in the interview process by trying to apply it to every “tech” position they hire for.

marcinzm5• 7 years ago

I don't see anything to indicate one way or the other myself.

There are also companies which want DevOps to know SE simply because they believe that such people create better infrastructure. Better in this case means more automation, code versus todo lists, understanding the SE users, etc.

xfitm3• 7 years ago

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

marcinzm5• 7 years ago

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.

opportune4• 7 years ago

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

itake• 7 years ago

I'd be frustrated for wasting my time. The recruiter should have better explained the review process.

opportune4• 7 years ago

Palantir is pretty well known for giving algorithms problems so it would have likely been solved by a cursory google "palantir software engineering interview"

scardine• 7 years ago

Check glassdoor for this company/position, looks like most people think it is a difficult interview process:

https://www.glassdoor.com/Interview/Palantir-Technologies-De...

shepardrtc• 7 years ago

they generally do require programming knowledge

Yes

probably an algorithm here and there

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.

reallydontask3• 7 years ago

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.

I think it's a more a case of cargo culting rather than not necessarily knowing what they are doing, although that might also be the case in some instances.

52-6F-622• 7 years ago

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.

threwawasy12283• 7 years ago

Can you or anyone cite where you have read that the unemployment rate for software engineers is low? I'd love to see it but I'm not able to find much trying to search for a citation on this point. I'm not sure that it is actually low, but this seems to be a common parlance amongst recruiters.

peterwwillis• 7 years ago

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.

cryptozeus3• 7 years ago

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.”

opportune4• 7 years ago

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"

simplyinfinity• 7 years ago

In my previous job we had hired a windows system administrator with no coding/scripting skills whatsoever with title as DevOps engineer, he didn't know anything about what developers do and CI & CD practices. So he ended up just managing updates (manually) on vms and restoring backups . But i see this more of a failure of management rather than the guys fault. Management heard a buzzword, and hired based on what they have hired before.

dev_dull• 7 years ago

Most of the devops (side question, is SRE technically devops?)

In my experience a “good” SRE, devops engineer, or software engineer is difficult to distinguish in skills. It’s more about responsibilities. This is especially true of the folks I’ve met from FANG.

dijit4• 7 years ago

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

cryptozeus3• 7 years ago

This is exactly the kind of role my company has. They didn’t even know how to restart web server from command line.

liveoneggs• 7 years ago

yeah it's weird. I never understood why we hire developers to copy and paste stackoverflow all day either.

cryptozeus3• 7 years ago

Ha its a good point but hey atleast they build and publish files.

namdnay• 7 years ago

I always thought that the whole point of DevOps was to stop having dev and ops and just have engineers who can do it all from A to Z

notabee• 7 years ago

Specialists still exist in DevOps, and it was never supposed to be a singular role. It's a major holistic cultural change that's intended to integrate dev, ops, and other specialties into a shared sense of ownership of the entire software lifecycle instead of sitting in silos and blaming each other for systemic problems. Turning it into a single role without all the major cultural changes is just yet another hunt for heros and silver bullets.

scottLobster9• 7 years ago

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?")

zrobotics2• 7 years ago

Although embedded is possibly one of the few software positions where these questions might be somewhat relevant- aside from embedded who is writing a sort by hand anymore; although even in embedded it isn't that common of a problem. I just find the questions especially egregious for an average software dev working on something like a web app, since in that case hand-coding something like a sorting algorithm or BST is almost always the wrong thing to do.

scottLobster9• 7 years ago

Oh I completely agree, but like it or not such questions have become the unofficial Software Engineering SAT. Part of being an engineer is working with/around other peoples' bullshit. If the furthest that extends is a dumb interview question or two, that's a dream job. :)

emilecantin• 7 years ago

I'm a Web developer, and I did hand-code the Dijkstra path-finding algorithm recently. Granted, it's not common, and I didn't do it from memory, but at least I knew what to Google.

I needed to represent the shortest path between nodes on a map, so I needed the internal data from the algorithm, thus the need to whip out my own version.

woodrowbarlow• 7 years ago

actually, i would think leetcode interview problems would be more relevant for embdedded development jobs. in embedded, you're less likely to have access to libraries that implement advanced data structures, sorting and searching, string manipulations, etc. so you'll need to do more of it by hand.

scottLobster9• 7 years ago

To a point, but like most things in software my experience is you look up someone who's already figured it out and copy them :) Granted you have to understand the code a little more and be able to apply it to whatever system/hardware constraints you're working with.

But just as higher level Software Engineers rarely have a need to implement recursion/graph traversal/etc, in embedded its even rarer due to the relative expense of such operations. I'd say knowledge of signal processing and how to power/performance/memory-optimize code would in general be much more valuable.

maxxxxx• 7 years ago

That’s my impression too. I would expect more handcrafted code on embedded systems and you need more awareness of computational complexity and memory needs.

Isamu• 7 years ago

For embedded programming you are more likely to be asked questions that require bit manipulation, shifting, masking, etc. Maybe low-level C, mapping structs to memory locations, etc. Maybe how you might go about implementing hardware interrupt handlers, or how you could put a microcontroller into low-power sleep and then wake up, etc.

It is common for embedded software engineers to come from electrical engineering, and they are maybe less likely to ask CS-type questions.

scottLobster9• 7 years ago

Hopefully. But I've heard from people who got asked leetcode style stuff in addition to those kinds of questions because it was company policy for anyone interviewing to be a "software engineer".

Best to be prepared.

scarface7422• 7 years ago

I interviewed for a position (and got the job) about four years ago for a C#/Angular senior developer and I was suppose to be “speaking my architectural experience into the team”. At the time, the only way I could document 10+ years of development experience was by putting a job I had worked at for a decade doing cross platform C and C++ with a little bit of assembly.

Out of nowhere, after I thought the interview was over, one guy kept drilling me on that type of low level stuff that had nothing to do with the job just to prove how smart he was. I remembered all of it thanks to a decade of dealing with it and too much time on comp.lang.c but it was still off putting.

I’ve since cut all of that stuff off my resume.

rswail4• 7 years ago

If I was hiring for this sort of position, I'd want them to talk about the difference between hard and soft real time. I'd want to know whether or not they were familiar with embedded software development standards and what sort of things are restricted from "normal" environments when you are working in the embedded environment.

The last thing I would want to see is lines of code on a whiteboard. I'd want to see how they'd structure their code, not whether or not they remember C/C++/Rust/language-de-jour syntax.

All of the proposals for questions that I've seen in this thread are for basic programming skills. Not whether or not the person knows the environment we are hiring for.

libria2• 7 years ago

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

scottLobster9• 7 years ago

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.

wayoutthere• 7 years ago

The problem with tech interviews is that it’s super rare to find the right combination of elite technical skills and emotional intelligence required to properly assess a candidate. Those people are usually busy.

What you end up with is someone who is either a mid-level engineer and almost totally green to recruiting or an HR drone with zero technical skills who is liable to believe a bunch of bullshit. Both tend to ask stupid interview questions they learned from a book because they’re out of their depth in some way.

This is not a situation unique to software either; it affects nearly every professional specialization (especially ones where the pay gap between an HR role and a functional role is as big as it is in tech). You’re right, it makes zero sense to put your interviewer on the defensive — being likable is almost always more important than being good.

SkyBelow3• 7 years ago

It is all about phrasing. If you ask it like "I thought this was a X position, doing Y isn't something I expected to be related. I can do it, but I was hoping you could clarify if the expectation was the ability to do X, Y, or both?" you will likely have a far better outcome than if you come off as challenging them.

Kurtz79• 7 years ago

As much the current interview process is broken, I honestly believe this is the best attitude.

In a way, it's nothing more than studying for some goal you think it will improve your current situation, and the good news that it is pretty much a solved problem, with plenty of information online that can be used to practice.

Just take into account that for an embedded position you might actually be asked more domain-specific questions.

I wish you the best in your seearch!

gwbas1c3• 7 years ago

I interview A LOT of candidates.

Don't bother with books about how to get a job. You're wasting your time.

Instead, spend more time with books about hiring. How to run an interview, what to look for, ect.

The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.)

At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you.

BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."

ubercow13• 7 years ago

You are still asking the leetcode question, and no matter how fairly you explain it the candidate who practised those questions will probably do better.

NikolaeVarius2• 7 years ago

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.

dbancajas4• 7 years ago

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

OldFatCactus• 7 years ago

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

closeparen• 7 years ago

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• 7 years ago

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• 7 years ago

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.

0xEFF• 7 years ago

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• 7 years ago

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

wolco• 7 years ago

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

matz18• 7 years ago

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• 7 years ago

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.

matz18• 7 years ago

These are more of the problem for the employer.

rjf722• 7 years ago

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

avgDev• 7 years ago

Honestly, I pass on companies that do leetcode, I'm simply not going to do it.

In my day to day I am working on mission critical applications, creating web applications that rely on legacy databases, writing SQL SPs. I'm decent considering my short career, i try to improve on every previous project. However, when I go home I'm not wasting my time grinding leetcode, even though I was top of every class in college, algorithms, data structures, theory of computation and so on. I'm competent and pick up new stuff very easily. I tell recruiters I will pass on an interview if they are doing leetcode/hackerrank. I'm okay to solve some coding problems that they have day to day, talk about architecture/design, talk about what I'm good at and where I want to improve. I also wish other people would stop grinding leetcode and that everyone was realistic about the job at hand. Most developers won't be writing the most efficient code, but start easy and refactor if certain part of the application becomes a bottleneck.

ThrowawayR22• 7 years ago

2. not being able to solve these tasks doesn't mean you're a bad developer.

Half of those questions are based on sophomore-level data structures and algorithms classes, the same concepts that operating systems, compilers, and most libraries/frameworks are based on. I would certainly hope that an experienced developer could effortlessly relearn basic concepts taught to college sophomores long enough to pass an interview.

projektir• 7 years ago

I find things like Leetcode very hard and my memory on it does not keep at all. I have to relearn all the relevant things every single time I start studying for interviews.

Don't assume something is easy or straightforward for everyone because it was for you.

matz18• 7 years ago

As with anything, its hard in the beginning but with practice, it get easier.

CBLT• 7 years ago

I agree. I was pursuing an SRE position at Google but their interview prep material was a lot of nitty-gritty "What does it mean when this syscall returns this integer?" questions that I didn't consider worth memorizing. In addition to the syscall questions, linux internals question, the bit of leetcode sprinkled in, there was also the practical exam of diagnosing a problem in a live system - I felt pretty confident in that however since it was my everyday for the last 3 years.

I switched tracks to the normal software engineer with only-leetcode interview questions. Spent 3 weeks studying and last week I went in and had an easy time because it was exactly what I studied for. Also applying to a few other dev shops was effortless because they asked the same stuff.

cloverich3• 7 years ago

Leetcode is not even that hard, tons of material and key to the answer is on the internet.

Doesn't that support the argument a bit? Its "not that hard" -- so even someone who _doesn't_ have the requisite experience could learn it? So its just another hoop to jump through, _before_ they validate whether you are a good fit for the job in the first place. That's what people are complaining about.

matz18• 7 years ago

Yes, it is another hop to jump through.

so even someone who _doesn't_ have the requisite experience could learn it?

I consider it a plus. Every company use different technology and different way to do things. Not to mention it keep changing all the time. With a standardize test, even though I don't have the experience with the technology they use, i can still have have a shot.

icedchai4• 7 years ago

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.

dijit4• 7 years ago

_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/

icedchai4• 7 years ago

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?

freehunter• 7 years ago

Exactly. A devops team has a spectrum of people. Some who only do dev, some who only do ops, with plenty who can do both occupying the space in the middle. There is room on a devops team for people who can't code, and there is room for people who can't be trusted to sudo to root.

Not every person on the devops team needs to be a perfect 50/50 split of dev and ops.

falcor84• 7 years ago

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

majkinetor• 7 years ago

I know that everybody say this, but my experience in real world tells me differently. DevOps is a skill, beside being anything else.

Good DevOps engineers are above everything else good developers. Those kind of developers like to control every aspect of the final product so then they enter system administration, networking, deployments, metrics etc.

On the other hand there is DevOps culture and teams and that is something else and can be reasoned about separately.

reallydontask3• 7 years ago

I think that devops engineer is a misnomer as devops is a cultural movement, but such is the industry.

There are software engineers, there are deployment automation engineers and there are people that do both to a greater or lesser degree.

From a recruitment point of view, it seems devops engineer = deployment automation engineers

Thus the expectation from a coding POV for a devops engineer is low, i.e. only scripts.

As ever, there are nuances here that can't really be captured in a post but you get the idea

jcadam• 7 years ago

I can certainly do infrastructure work. You better believe I hide that fact from my employers :P

icedchai4• 7 years ago

You are wise. I made this mistake early on, now I always wind up doing a bunch of extra work.

bionsystem• 7 years ago

I don't do code, though I'm sure you would like me on your team :)

(BTW I have the exact opposite opinion, I think devs should stick to code and not try to setup infrastructure for themselves)

scarface7422• 7 years ago

Can you do Python scripting? I’m a software engineer but also the resident “AWS Architect”, there are plenty of times I need to throw together a script to automate something or glue things together.

icedchai4• 7 years ago

Can you write shell scripts?

chupasaurus• 7 years ago

I've yet to see a developer who knows simultaneously the least privilege principle, a minimal object for a deploy process and what is a Linux container (it's 2019 after all) without having a sysadmin background.

You don't need a cloud to implement DevOps culture to development process, yet you need people who know their shit when they do Ops work (i.e. Poor Yorick incident in Gitlab).

ronsor• 7 years ago

LeetCode is like the CAPTCHA of hiring

ilikehurdles3• 7 years ago

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

vinceguidry3• 7 years ago

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.

toomuchtodo4• 7 years ago

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.

vinceguidry3• 7 years ago

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.

rjf722• 7 years ago

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

[2] https://www.indeed.com/rc/clk?jk=5d42d374514328da&fccid=d045...

GhostVII• 7 years ago

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.

jartelt• 7 years ago

At the same time big tech companies are always complaining about not being able to find qualified engineers.

A portion of those people who were filtered out because they get nervous during interviews or got stumped by a riddle or esoteric question, could have been entirely qualified to be a good or great engineer.

Big tech companies should be designing interviews that don't find just people who are awesome at interviews and riddles.

ilikehurdles3• 7 years ago

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.

oblio• 7 years ago

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).

k_sze2• 7 years ago

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

danmg2• 7 years ago

A trade union perhaps.

k_sze2• 7 years ago

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

jlengrand2• 7 years ago

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• 7 years ago

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• 7 years ago

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?"

pnathan2• 7 years ago

Ha, I'm up front: "this is a synthetic question, which has the purpose of x,y,z". Synthetic questions don't rely on specific tools, or specific problem framings, it can be thought of in isolation.

E.g., I usually put a database question on interviews, for the purpose of seeing what and how much the candidate knows about databases.

I also like doing a design question regarding handling larger data and doing back of the envelope complexity analyses of the solutions they come up with. I.e., what I expect a colleague to be able to do when we're working at our desks.

caymanjim• 7 years ago

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.

raiflip• 7 years ago

Sounds interesting, could you expand some of the abstract and targeted technical questions that you find effective?

balls187• 7 years ago

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.

I agree with you in principle for a programming job, but from the post, this was a dev ops job, and the candidate was asked a dynamic programming question. There was no link to the JD, but I suspect it had little by the way requiring a CS degree.

tomp• 7 years ago

Everything you say sounds extremely reasonable... but still, there are plenty of stories (mostly online, so they might not actually be true) of people hiring a person that aces (mostly non-technical) interviews only to show absolutely 0 actual technical skills on the job.

malvosenior5• 7 years ago

In my experience (also interviewing hundreds of people) this is totally an urban (internet) legend. Not once has someone been able to talk intelligently and at length about a project they built and the underlying technology choices and then been unable to deliver. Once you gain experience building things yourself, it's pretty easy to suss out whether someone is any good just by talking to them. No coding tests needed.

SubuSS5• 7 years ago

I agree with the urban legend guess.

Yeah it happens, but not as often as you think.

cloverich3• 7 years ago

The problem with non-coding interview's is its very dependent on the interviewer to determine their capacity, and _many_ people are bad at that. I think if you are good at it, its pretty easy to tell (like < 5 minutes) if someone can do the job. But I've seen very poor candidates get past this screen many times, even when screened by people I otherwise trust. So I know its not a common skill.

jasonpeacock• 7 years ago

I've had interviews start very positively with such an approach of questions, but then "just to be thorough" I have them code something simple on the whiteboard and they completely fail.

Some of them couldn't even get nested for loops to work correctly.

If you're hiring someone to write code for you, you need to have them write code in the interview. There's no substitute for it.

Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem.

ConcernedCoder• 7 years ago

This disproportionally filters for those who can think/code and perfom while under pressure/observation... i.e. the "porn stars" of software development, if you will.

Similar to how not everyone is able to perform well while having sex-on-demand in front of a camera -- these same people are more than likely able to have sex when not under pressure and observation, and probably are quite adequate while doing it.

My personal experience in software development spans decades, I'm quite competent and I have definitely "choked" at the whiteboard, just like you're describing -- for the same reasons I don't do well speaking in public, I'm not comfortable doing it, and I'm just not cut-out for it... I don't think it's a good measure of actual problem solving and/or software development competency.

ilikehurdles3• 7 years ago

Years ago, I definitely was one of those people who completely bombed a code-on-a-whiteboard problem. It was exactly that - a nested for loop problem. It was one of the first real interviews as I was in a new geographic area and previously I had moved into jobs by being recruited by my professional network. This was before I started specifically studying the patterns used for engineering interviews.

Thing is, I still had a good 3-4 years of professional experience with stellar reviews, some hackathon wins, on top of having coded throughout my entire life prior. But when I was up on that whiteboard, I pretty much froze for that entire segment. Whiteboards are just a different skill and if you don't regularly code on them at work, you better buy one and practice at home because using an editor does _not_ translate to coding on a whiteboard.

I'm glad you mention this: "Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem", because I did better in interviews that followed which allowed for coding in my usual working environment. Heck, I even passed a technical screen before this company brought me on-site where I live-coded some elevator problem they asked me to implement. After bombing the whiteboard, I wouldn't blame them if they thought I had paid someone else to solve the tech screen.

fhbdukfrh• 7 years ago

This doesn't Test if they can develop software; this tests if they can diffuse a bomb.

Also there's no point in bringing someone in for an interview before they've shown any coding experience. It's a colossal waste of time for everyone, including the candidate

Balgair3• 7 years ago

To be fair, the reddit post was about a DevOps applicant being asked a single dynamic programming questions for the interview.

It's as if you asked an auto repair mechanic about designing involute tooth profiles on fishbone pattern gears in a transmission. Sure, if they could do that, then yes they'll be a great technician, but it has nothing to do with brake jobs and oil changes.

EDIT: Per the responses in the reddit thread, the question was: "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."

scarface7422• 7 years ago

Yes but I’m not writing code everyday on a whiteboard, I’m writing it in an IDE with access to Google.

When I am at a whiteboard I am drawing very crude architectural diagrams.

seanmcdirmid• 7 years ago

Nested loops are difficult to code up on a whiteboard, much easier to do on a computer with a code editor. It’s just difficult to manage the real estate, while fixing edit errors on a whiteboard is super messy (I’m left handed and constantly smudge also), easily throwing me out of my code think.

Who the heck writes code on a whiteboard for production anyways?

granshaw2• 7 years ago

I went through a similar interview once - bring your own laptop, and code-up a bowling scorer which spanned two sets of interviewees. Was not the worst interview experience I've had.

SubuSS5• 7 years ago

The coding is to get a sense of how they write code, how rusty they are, how many good habits they've picked up relative to their experience, how do they think about validation/testing of it, how the go about building it (ad-hoc vs top down), their problem solving skills when faced with an unknown problem and so on.

There will always be unknown unknowns. We are just trying to cover the known variations and if he has any unknown knowns[1].

1 -https://academic.oup.com/jxb/article/60/3/712/453685

pault20• 7 years ago

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.

jimcsharp• 7 years ago

At least you have a constant source of code for interviewees to fix.

HorizonXP• 7 years ago

Would a better interview test be to ask the candidate to review code rather than write it themselves? That is, give them a code sample, describe what it aims to do, and ask:

1) Does this code accomplish the goal? 2) How would you improve this code to make it more readable? More efficient?

Personally, I think I'd rather work with people that know how to review code and provide feedback/commentary, since that usually means they can write good code themselves. It should lead to a better team dynamic.

sokoloff4• 7 years ago

Is this person doing (valuable) work that would even require hiring a replacement? If not, fire them. If so, lobby to secure a backfill and then fire them.

doitLP2• 7 years ago

I do the same for a “senior” developer with 20 years more experience than me and a bafflingly appalling understanding of how to write basic code.

Bless you sir, you are keeping the code legible and clean for everyone else on your team and doing a great service for your company — even if they don’t appreciate it.

e40• 7 years ago

So, the developer is overconfident. Have you tried coaching this person into understanding this? I feel that is part of good management.

threwawasy12283• 7 years ago

I think a bigger problem is that they probably weren't lying or fabricating their resume. They probably weren't trying to trick you in some way, they probably just have actually programmed like this for the last 10 years! In a lot of work environments especially in the midwest, it isn't surprising to encounter people like this that don't know basic best practices.

The standards for what a company wants from their programmers can vary wildly depending on the location. This speaks to a broader problem of not having consistency across the industry and various locales.

ubershmekel• 7 years ago

This person is so convinced that they are a good developer that they refuse to take direction or ask questions

While I agree a coding exercise is valuable - this is the actual problem. The way I test for that humility is by asking "tell me about a time you personally did a poor job." I then follow up by asking for a time they identified a failure of a colleague. I look to see if they're empathetical, open to being wrong, and declaring they're always trying to improve.

dbancajas4• 7 years ago

what was wrong with this code? I don't deal with exceptions a lot so not familiar with the idioms here. Is it because the catch is not doing anything at i<3? And then at i==3 it just breaks from the for? So rendering the whole thing useless ?

onlyrealcuzzo• 7 years ago

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.

zerr2• 7 years ago

I typically focus on reviewing code with bugs and refactoring bad code instead of forcing them to whiteboard

This is a completely different (and actually relevant) thing compared to leetcode/hackerrank riddles.

naveen992• 7 years ago

For loop syntax is unnecessarily complex when you first encounter it. A simple if then control flow is much easier to understand and is how it’s done in assembly anyway. Unfortunately he used both. Maybe an opportunity to teach him about goto and labels...

siscia3• 7 years ago

But code like that pass your unit tests, integration test, CI, and LINT?

If it does, you may consider to improve the quality of your tests.

If you don't have all of those it is your fault since you are cowboy coding instead of doing engineering and at this point he is playing along.

mixmastamyk12• 7 years ago

political reasons and difficulty hiring a replacement, we can't fire this person

Believe that's the root problem, right there. Gun-to-head coding problems aren't the solution.

achenatx• 7 years ago

ok Im stumped :) Would be interested to read some clarification on this.

the try always throws an exception, and if i<3 resumes the code. But on the last iteration through it breaks so will not execute code after the exception is thrown. The first 3 times it will execute code after the exception is thrown. Does continue return to the beginning of the for loop or resume execution where the exception was thrown?

If continue returns to the beginning of the for loop then I could see that the code is pointless. But if continue resumes execution inside of dosomething the line after the exception was thrown, then it could actually be useful.

Is your issue that the code does actually work, but conceptually it is horrendous to implement the branching in that way, or is it that the code doesnt work at all, or is that it actually does nothing?

When I see things like this I integrate them into our interview process.

Kuraj• 7 years ago

Since they are knowledgeable about your domain, maybe there is a position at your company that they would be able to fill better?

Edit: I apologize - I wrote that comment before reading the rest of the discussion, after which I had more context.

Consultant32452• 7 years ago

Some people have 10 years of experience, others have 1 year of experience 10 times.

This is a very hard thing to really make a part of your thinking process, in particular because nobody wants to come to terms with the fact that they might be in the latter group.

geebee2• 7 years ago

Wow. That's a hell of a loop.

That said, this does seem like another reiteration of the "senior engineer couldn't write fizz buzz" story, though this particular example is amusing.

I can write fizz buzz. Hell, I've interviewed enough that I can print all permutations of a string (or all permutations of a set and/or subsets of that set). I used to be able to implement merge sort in 45 minutes at the whiteboard, but I can't now, and I never want to be able to do this at 45 minutes at the whiteboard again. I could certainly detect a cycle in a linked list, and I could do DFS and BFS on a binary tree. I might be able to reason through how to find the last common ancestor of two nodes, or find all matching subtrees in a binary tree if I could hack around for a while, but at the whiteboard, in 45 min? Nah. So, no-hire.

It's time to stop pretending these tests are about weeding out people who lack very basic coding skills. Tech interviews are one of the reasons I'm not enthusiastic about recommending a career as a software developer.

confusedcoder• 7 years ago

Forgive me because I have used a similar idom when dealing with io.

I do something like:

  for i=0; i<3; i++:
    try:
      doSomeIoWork()
    catch:
      if i<3:
        # maybe some network/disk issues retry?
        sleep SOME_TIME * i;
        continue;
      else:
        # tried too many times now quit
        raise

Am I doing something stupid here?

kamaal2• 7 years ago

Every body writes something like this. Every body. Just because some devs don't write this in a single block of code, and scatter them across program logic doesn't make them any better.

I've had developers balk at other developer's code for writing a series of like 100 if-else's until I show them, they do it themselves only that they scatter it. You could say this thing about nearly every OO programmer out there.

Everybody writes code that mutates state in a way that produces the kind of code you mentioned as an example.

It's only that some developers think they can never write bad code, while thinking other's almost always do.

This is one reason why some shops hire only OCaml, or Haskell or Clojure devs because bad devs tend to use those languages less. So you buy into a great community by default.

hackinthebochs3• 7 years ago

I... never thought to use a continue inside a catch block. Points for creativity at least....

hlindwin2• 7 years ago

I am kind of new to all coding. Can you explain what is wrong with that code?

wutbrodo2• 7 years ago

I think it's a holdover from hiring more junior candidates: after a few years interviewing and sitting on HCs at Google, I hired for a tiny startup that had tons of trouble sourcing candidates. My interviews at the latter place eventually devolved into basic IQ tests. Simple coding problems are pretty ideal for this, since they also lightly test necessary domain skills.

The problem is that this doesn't scale with talent and/or experience: I certainly wouldn't be better at coding interviews than I was out of college. People who aren't great at hiring take an approach that's valid at the low level and extrapolate it well beyond the bounds where it makes sense.

On the other hand, this only works if the pedigree is recognizable and reliable. I can be pretty confident that I don't need to test basic coding literacy of someone who was an engineer at Google for four years, but I've interviewed people with ten years experience and great references who were clearly dumb as a brick during the interview. In one case, we hired the guy over my objection and spent the next year fighting the fires he'd set whenever he touched anything (the founder eventually found some relatively unimportant, isolated niche for him to keep busy in).

It's a really hard problem, and most complaints I've come across are generalizing from their skewed view of what the candidate pool is like (usually assuming that most candidates are roughly as talented as they are, when the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter)

[1] ie, practically everyone

dcolkitt• 7 years ago

My interviews at the latter place eventually devolved into basic IQ tests... The problem is that this doesn't scale with talent and/or experience.

Industrial psychology has consistently found that IQ is a better predictor of job performance than experience.

The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skill acquired by a low IQ in five years is often surpassed by a high IQ person with a few months of experience.

[1]https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_co...

perl4ever4• 7 years ago

"the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter"

I think people genuinely experience this but are unwilling to consider that their pool is not the random sample they expected. Something subtle is filtering out (nearly) all the non-dumb people.

Have you ever seen a personal ad with a long list of characteristics that are unwanted?

ryandrake2• 7 years ago

When you need a doctor or lawyer or pilot, because they are certified, you at least know that they all have at least a bare minimum amount of competence. You may not know if they are elite ninja skilled, but you know they know the basics. Literally anyone can say they know how to program, and there is nothing on the resume that can confirm or deny this. I’ve interviewed Senior Software Engineers with years of experience who couldn’t complete a FizzBuzz-like task. Software engineering unfortunately does not have its own “bar exam” or board certification, so it has to be “Monkey Dance” over and over no matter how much experience you have. It’s frustrating both as an interviewer and as an interviewee, but until there exists a verifiable signal of competence for one’s resume, basic skills need to be tested over and over and over.

fizzbuzz1232• 7 years ago

I'm sorry but this is such BS. There are what, a dozen other engineering industries out there? EE, Civil, Mechanical, Aeronautical etc. and in not a single one of them do they do this monkey dance. It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard and its equally absurd to play the same game with SWE's, you all have just been bamboozled and strong-armed by employers into accepting it as a valid practice. I doubt you would be willing to say that those other industries are failures or hire low quality engineers because they don't torture their employees with essentially pointless trivia games.

In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day.

chimpburger• 7 years ago

What about github projects? Can't you ask for examples of code they have written?

mangatmodi• 7 years ago

most people are not that passionate about where they work until they actually work there

I do like coding a lot, but these home tests can never excite me. I have a family. I can't do it after office. In office I want to work honestly on my job. So frustrating!!

tptacek• 7 years ago

The problem is, your resume doesn't speak for itself, or, more accurately, resumes in general don't speak for themselves. It's not because people lie on their resumes, but because there's a pattern in this industry of people failing laterally and upwards.

It takes much longer than people assume to get a dysfunctional team member off the payroll. In most shops, new hires spend months in a (reasonable!) reduced-expectation state of on-boarding and ramping up, during which their performance can't readily be measured. It then takes several engineering cycles to figure out that they're not working out on a particular project, after which the normal response is often to try moving them to another project. You can be more than 6 months in with an employee before there's a confident assessment in engineering management that someone isn't working out. In many shops, at that point the next step is to begin the process of "managing them out" (often with multiple stages of PIPs), which includes a fig-leaf premise that performance can be fixed and the team member retained.

And that's if things are carefully managed. Lots of teams, even good teams, aren't carefully managed, and it can take more than a year to detect and propagate the signal that someone isn't working out.

The net result is that people can accumulate impressive-looking resumes without ever effectively delivering for any team, and because resumes get more impressive over time, the roles people get offered improve as well, compounding the effect.

I'm an evangelist for evidence-based hiring techniques and a fierce critic of standard interviewing practices, which I agree are dehumanizing and unreliable. But we started our hiring practice[1] not because we wanted to include more people, though that was a happy result of it, but rather because we'd been burned repeatedly by good resumes and strong interviewing skills.

At this point in my career, for a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk. Their absence would make me suspicious (though perhaps not dispositively so) about the technical ability of the team I was considering joining.

[1] https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

wyclif2• 7 years ago

For a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk

Agreed, and let me offer an anecdotal, real-world example. Before I was in this racket, I used to be a land surveyor. Because it's both technical and licensed (and btw, I'm not going to make an argument for licensure, just mentioning it as a qualifier), you had to take a written test and pass a rigorous interview before you were accepted as an apprentice land surveyor. The test involved trigonometry, plane geometry, algebra, property law, and basic statistics. The sit down involved attempts to surface red flags all the way down to testing if the candidate was afraid of dogs.

And after passing that, then you were hired on as an apprentice which meant that all your work had to be reviewed and signed off on by a licensed PLS while you learned on the job and could eventually take the PLS exam yourself.

Too often in software engineering, a candidate can jump through the hoops and get hired but even if their role is junior, they're essentially on their own except for code reviews. There's very little mentoring, because senior people are neck deep in work and nobody's got time for that. The company has to be committed to mentoring and carve out space and money for it in order for it to happen.

andreareina• 7 years ago

How do you assess juniors? I feel like the desired quality there is how coachable they are and their capacity to develop said technical chops, but that feels even murkier to suss out, especially in the time-limited recruitment/interview process.

scarface7422• 7 years ago

Resumes lie. You can’t imagine the number of times I’ve interviewed someone with $years of experience who were actually no more than “expert beginners”.

Older developers come in two forms. Those who aggressive learn, have matured beyond “just developers” and those who are set in their ways. I’m 45.

40acres• 7 years ago

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• 7 years ago

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.

gregoriol• 7 years ago

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.

alpha_squared• 7 years ago

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.

jshowa3• 7 years ago

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.

kd5bjo2• 7 years ago

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)*$

SubuSS5• 7 years ago

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.

ummonk• 7 years ago

I'm not sure they were going for the regex answer - it seems like they expected the DP answer since they're using multiples of 8, which allow you to do it as a DP problem quite easily.

Stronico11• 7 years ago

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.

malvosenior5• 7 years ago

Doing this during a job interview is not going to give you the results you expect. For every person like you who wants to hear "I don't know" there are 10 people who will pass on you for not knowing something. People's expectations are set by the worst interviewers they experience, not the best (and honestly, trying to trap people isn't the "best" anyway).

Stronico11• 7 years ago

So far it's worked very well for me. Since I've started using it (admittedly my sample size is small) I've found some very effective programmers, and automatically filtered out a lot of egotistical types. Software is usually a collaborative effort and this technique helps in that regard.

rifung3• 7 years ago

I once told an interview I didn't know something and they told me that I should never say I don't know something and just try to make something up.

I don't really agree with him and just kept doing it though and things seems to be fine.. If anything I would say that interview was successful for both parties because we probably wouldn't get along and that is totally fine.

skrebbel• 7 years ago

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.

Stronico11• 7 years ago

Saying "I don't know" is an accurate answer.

The ability to ask meaningful questions is a big part of any programming job. And (in my opinion) harder to learn than any particular technology.

notyourwork3• 7 years ago

It’s not a trick question. Saying I don’t know is a perfectly acceptable answer. The follow up should be questions to clarify or reduce complexity. I interview a lot and this is something I expect out of candidates.

jstanley• 7 years ago

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.

wool_gather2• 7 years ago

You make a fair point, but an interview is not solely about programming skill. It's also about being a co-worker. And the question "what does this person do in X situation", where X is "they don't know the answer to something they need to know'" is highly relevant. So there may be a better way to go about it, but the parent's desire is reasonable.

ViViDboarder• 7 years ago

It’s not a trick question. I am expecting them to answer the questions honestly. If they know the answer, go ahead and answer correctly. If not, don’t pretend.

I don’t want to hire someone who isn’t going to admit the limits of their abilities, for whatever reason. Could be smugness or lack of confidence, either way it’s a bad signal.

positivejam• 7 years ago

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.

This part is crucial. If an interviewee is pushed to the brink but doesn't say, "I don't know," that does not imply they will not say, "I don't know," once they've secured a position.

mondoshawan5• 7 years ago

This will easily pitch you into an adversarial position and give you and your company a black eye. Remember: interviews are bidirectional. If I was pushed to the breaking point like this in your interview, I'd walk out without saying a word.

You're only going to be selecting candidates who can handle pressure -- not skill or ability with this.

Stronico11• 7 years ago

Interviews are certainly bidirectional - and should be conducted as conversations, not third degree interrogations. I would walk out on that too.

How is being asked something you don't know the answer to being pushed to the breaking point? Do we expect to learn nothing on our jobs?

chucksmash• 7 years ago

You're already treating it as adversarial if you're thinking of it in terms of your "breaking points" and "walking out without saying a word."

Back in the day I had an interview for a business position where the interviewer's personal printer mysteriously started printing documents part way through. I'd just read "What Does Somebody Have To Do To Get A Job Around Here?" which listed that among other tactics a company might use to see how you handled distractions. I've suspected it was on purpose ever since. Even were it intentional though, it would be more of a gimmicky ploy than an adversarial thing to do.

An interviewer should be able to modulate the difficulty of a question without making you feel uncomfortable.

Also the job isn't done in a vacuum - being able to remain calm when you don't know the answer is an ability all its own. Interviewers shouldn't be creating artificially stressful situations but you've also got to be able to manage your own stress response!

whymauri• 7 years ago

My favorite interviews are the ones that have pushed me to the edge of my knowledge and had me derive things that were completely new to me. I love interviews that are genuinely enlightening, which is the opposite of regurgitating Leetcode.

Truly, the best interviews I've had have also been the hardest. Different strokes for different folks.

diminoten11• 7 years ago

Haha, I usually say "I don't know" right away, I feel like I'd short circuit this test.

drugme3• 7 years ago

When interviewing people I usually push until I get the candidate to answer "I don't know" on SOMETHING,

"just because I can". To me this technique comes off as condescending and manipulative, and smells like a power play basically. Not to mention - the better candidates will pick up on it, and your company will eventually get a reputation it doesn't want to have.

And really there's no need for it. Time and time again, I find that just by having a normal technical conversation with someone, on virtually any topic that they claim to have expertise in -- they will show their strengths and weakness (and propensity for BS, if any) very, very quickly.

Stronico11• 7 years ago

Not just because I can - interviews are always time limited, and technical conversations always (pleasantly) meander across many topics, usually the strengths of the people talking. It's easy to for someone to spend an hour talking about their strengths - interviews usually need some sort of direction to get useful information.

And it would be manipulative if there were some answer I was going for that wasn't true - I'm trying to elicit an honest response.

charlieo88• 7 years ago

You seem like a person that has never had to deal with someone that is incapable of saying "I don't know." It is incredibly frustrating to project manage a team like that. It is tantamount to lying.

g-clef• 7 years ago

As a lot of other commenters are pointing out: there's an adversarial and a non-adversarial way to do this.

When I'm interviewing someone I will often preface groups of questions with "have you worked with {x}?" or "are you comfortable answering questions about {x}?" before asking the actual questions covering that area. A simple intro question like that goes a long way towards keeping an interview friendly. The interviewee can say "no" to a small-sounding question without feeling like they're embarrassing themselves.

For example, they may be comfortable with Python but not super-comfortable with the GIL/multiprocessing/multithreading. If I ask "have you worked with Python's multiprocessing or multithreading before?" that comes across as much less adversarial than asking them to describe Python's GIL and forcing them to say "I don't know."

Doing an intro question also allows them to give a partway answer like "I've touched it before, but I wouldn't call myself an expert". If they say something like that I can re-focus my questions to another area, or just ask higher-level questions, rather than hitting them over the head with a deep question about something they've just told me they're not an expert in.

You do want people to be honest about their own limitations, but you don't want your interviewee to think that your organization is driven by macho posturing about being King Nerd.

mrunkel• 7 years ago

I do something similar, I ask the candidate what they do when three different people come to them with urgent needs that must be done immediately and there is no way that they can do them in the time given.

The answer I’m looking for is “I ask for help.” Or “I talk to my manager.” They don’t fail if they don’t answer it that way, but it’s a good starting point for a conversation about why they didn’t say that.

For me, interviewing is more about getting to know someone and how they think than checking off various skill boxes.

kache_2• 7 years ago

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.

andrei_says_• 7 years ago

Surely urgent care nurses can spend time prepping for dental assistant interview questions, but they usually don’t because ER interviewers don’t go on irrelevant tangents.

Suggesting that they do would not address a glitch in the interviewing process but rather try to accommodate it at the cost of the interviewees’ time.

coleifer2• 7 years ago

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

collyw3• 7 years ago

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

daveFNbuck3• 7 years ago

Getting past the interview isn't the only step to being fine. I also want to work at a company where my co-workers know what they're doing. When the hiring process uses an irrelevant filter, you end up filtering out qualified people and letting in unqualified people.

scarface7422• 7 years ago

But I don’t think I would want to work for a company full of people hired via that process. I’ve met too many smart people(tm) who spend more time arguing about how many angels can dance on the head of pin than they spend figuring out how they can ship software faster/better/profitably.

jpeterson2• 7 years ago

That 90%+ of the hiring signal can be projected onto "hours spent on leetcode" is exactly why this process has become a parody of itself.

malvosenior5• 7 years ago

False positives are a lot more damaging to a company compared to false negatives.

This is accepted blindly as dogma in our industry but in my experience it's only the case if the company is dysfunctional and management is too weak to let poor performers go quickly. Being an effective leader means being able to hire and fire quickly. If you're open and honest about it, you don't have to do as much as much intense vetting up front which costs your team's time and filters out potentially great hires.

HillaryBriss• 7 years ago

But, at least in California, don't employment laws make the firing process kind of slow and expensive?

yoz-y• 7 years ago

Depending on the country that might not be that easy (in France you have basically 4 months to fire somebody and then you are screwed). Also, you have to include cost of on-boarding.

sethammons2• 7 years ago

I disagree. We had a candidate talk the talk when we were experimenting with different interview methods. They came in and used a lot of team time to start learning the system and stack. And continued to use the team's time, costing real productivity. They lasted a quarter or so. Not only did the team lose out on productive time, they lost morale by having to support a team member who was not getting up to speed and had to have their work redone and an couple members lost more morale when the newer person was let go. It was a net loss to bring in the new poor performer. I've seen it play out similar more than enough to be convinced that the adage is accurate.

vorpalhex• 7 years ago

Or the software company can spend a few hours actually building a real interview process instead of making ridiculous interview projects. I have no problem proving that I can code (whiteboarding, pairing, etc), but I refuse to do stupid college-esque programming assignments on my own time unless they're paying me for it.

jpeterson2• 7 years ago

"they work for avoiding false positives"

Citation needed. I have many years of experiential evidence that suggests otherwise.

joeax• 7 years ago

The whole "false positives" narrative is an example of the "saying something enough makes it true" fallacy.

I've interviewed dozens of people, and you can easily root out false positives by asking about their prior experience. Simply probing about things like design patterns to challenges with Javacript front-end coding is enough. If the candidate can go into explicit detail about past projects including bugs they fixed and limitations they came across in a Angular 6 project (as an example), then that's usually a good sign they know what they're talking about.

scarface7422• 7 years ago

The one whiteboarding code review I had was to pseudocode a merge sort on the board. I knew the question he was going to ask because I had two coworkers who had gone through the process previously, one had worked with the company and the other declined the offer.

I already had an offer by then but I did the interview for grins and giggles and didn’t try to remember what a merge sort was. I actually wanted to test the culture of the company. If they ask me to write a merge sort and I don’t know the algorithm, will they describe it on a high level or will they look at me derisively? That would tell me a lot about the company.

Well anyway, the guy was nice enough, I did the mergesort on the board, got an offer but decided if their interview for “senior engineers” consisted of the ability to do a merge sort instead of deeper architectural questions, that wasn’t the company I wanted to work for.

When I conduct interviews, I have a simplified non working (but compiling) class that is a sample of the types of problems we solve everyday with a set of failing unit tests. We pair program and they have to see if the tests pass.

daveFNbuck3• 7 years ago

How does answering tough algorithmic questions avoid false positives for roles that don't require algorithmic skills? I can breeze through an interview like that but I'd be a terrible hire for a role requiring skills in Kubernetes, Docker, AWS, Terraform.

WhompingWindows• 7 years ago

Can you explain that? Wouldn't being skilled at algorithms be a false positive at times for dev-ops skills in OP's scenario? Maybe the algorithmic knowledge is simply rote and practicing, as opposed to skills and knowledge in dev-ops specifically.

sbov2• 7 years ago

Then companies should stop talking about this shortage of qualified software engineers.

kache_2• 7 years ago

There is a shortage of qualified software engineers. The whiteboard interview has spawned out of necessity. There is no good formal examination like an MCAT that companies can rely on.

zerr2• 7 years ago

Spend a few hours a week doing leetcode questions

There is no persistent storage in humans - people forget things, and it is quite annoying to do this again and again for every new job.

conanbatt• 7 years ago

This math doesn't check out: a false negative allows a follow-up false positive. And without that effect, you also have that each one costs thousands of dollars.

coffeefirst• 7 years ago

False positives are a lot more damaging to a company compared to false negatives.

People say this, and then they whine about how they can't find good candidates, can't find diverse candidates, etc.

They could, of course, study interviewing, treat it with the same level of seriousness you might apply to other skills, and actually learn how to evaluate people with a pretty good level of accuracy so you can avoid both problems.

bcp2384• 7 years ago

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?

0x54D5• 7 years ago

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.

phreack• 7 years ago

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.

devonkim• 7 years ago

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.

Circuits• 7 years ago

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

starpilot• 7 years ago

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

rifung3• 7 years ago

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.

jahewson2• 7 years ago

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?

drugme3• 7 years ago

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.

gwbas1c3• 7 years ago

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.)

pnathan2• 7 years ago

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

docker_up• 7 years ago

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.

perrygeo• 7 years ago

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

Exactly. I have no problem coding up a solution if I have an hour to do some research. Either give the topics ahead of time or ask it as a homework assignment.

If the job requires hurry-up coding solutions to whatever crap falls on your desk without any design, research or discussion of alternative, the quality of their product and codebase probably reflect this.

hjk052• 7 years ago

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.

blub9• 7 years ago

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.

mixmastamyk12• 7 years ago

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. ;-)

kjgkjhfkjf• 7 years ago

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.

xorand• 7 years ago

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."

walshemj• 7 years ago

Hasn't anyone else commented this is for devops FFS

stlava• 7 years ago

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.

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

Related Stories