24 ms·
I got asked LeetCode questions for a dev-ops systems engineering job today
- deleted 7y ago[deleted]
- marcinzm 7y agoThat 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).
- doitLP 7y agoDoesn’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.
- marcinzm 7y agoI 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 7y agoBeing able to read and debug code is a different skillset from first hand development.
- marcinzm 7y agoIf you're depending on open source software then you also need to be able to fix the code in question. And do so in a way which the project would accept. Otherwise, your bug report may linger until the end of time.
- toomuchtodo 7y agoThen hire for software engineering. Don't lie to candidates that it's a systems admin or devops role. It's pathetic employers keep demanding more skill and free work for the same pay.
- dbancajas 7y agothen they can't pay you little. LOL. I'd end the interview right there especially if the salary is low.
- marcinzm 7y ago>It's pathetic employers keep demanding more skill and free work for the same pay. In my experience DevOps pays better than SE (and much better than sys admin) because it requires a diverse set of skills. DevOps in that context is not just a new term for sys admin.
- toomuchtodo 7y agoI have yet to see DevOps roles that require "diverse set of skills" beyond sysadmin skills, very basic knowledge of at least one language such as Java, Go, or Python (occasionally only PowerShell if its a Microsoft shop) and either Terraform or Cloudformation for IAC. The pay delta between the two roles is less than you think (excluding SF/BA market, but that market is always an outlier). DevOps is sysadmin with more scripting, more infrastructure as code, and more expectation that you're an underpaid SRE. It also seems like DevOps role demand more unpaid on call responsibilities, where this is usually not the case with traditional sysadmin roles (or it's spread across a much larger team, negating the pain). YMMV. Disclaimer: 20+ years in tech, the majority in ops roles.
- 7y ago
- opportune 7y agoI 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 7y agoI'd be frustrated for wasting my time. The recruiter should have better explained the review process.
- opportune 7y agoPalantir is pretty well known for giving algorithms problems so it would have likely been solved by a cursory google "palantir software engineering interview"
- vonmoltke 7y agoWhy would I search for software engineering interviews if I'm applying to be an IT systems engineer?
- NikolaeVarius 7y agoBecause these days "IT Systems Manager" are expected to know basics of coding.
- vonmoltke 7y agoTo me, there is a pretty large gap between "interview questions to test the basics of coding" and "software engineer interview questions". Searching for the latter to find the former is like search for copywriter interviews to study for questions on basic English proficiency.
- peterwwillis 7y agoSome 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.
- cryptozeus 7y agoThey can, it depends on the role. Not referring to you but I have never understood why DevOps at many companies can’t program and are just hired to copy paste files. “DevOps is a set of software development practices that combines software development and information technology operations to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.”
- opportune 7y agoMost 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 7y agoIn 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 7y 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.
- dijit 7y agoSRE 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-competing-standards-or-close-friends https://cloud.google.com/blog/products/gcp/sre-vs-devops-com...
- scottLobster 7y agoIn 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?")
- zrobotics 7y agoAlthough 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.
- scottLobster 7y agoOh 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 7y agoI'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 7y agoactually, 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.
- NikolaeVarius 7y agoI find it much easier to just study those problems when I interview versus complaining on the internet. The bar is damn low for most leetcode problems and refreshing is not that hard.
- dbancajas 7y agonot when the interviewer wants you to know every corner case of a string reversal problem.
- OldFatCactus 7y ago90% of my devops interviews have included a tech screen with some whiteboarding of a fundamental CS problem
- closeparen 7y agoIsn’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 7y agoYes, 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 7y agoWell 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 7y agoI 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 7y 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 7y agoGraphic Designers are getting these. It's a bit crazy.
- matz1 7y agoComplaining 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 7y agoIt 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.
- matz1 7y agoThese are more of the problem for the employer.
- icedchai 7y agoGood DevOps engineers are software engineers that can also do infrastructure work. They should be able to code. Unfortunately, many are "cloud sysadmins", for lack of a better term.
- dijit 7y 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/ https://devops.com/is-devops-a-title/
- icedchai 7y agoAnd people work on those teams. We are talking about the expected abilities of such individuals. How do you assess these abilities? What is expected?
- dijit 7y agoThe whole point is to make your team heterogeneous*, so in terms of skills you need to staff for all your needs. "We'll use python on GCP with PostgreSQL as a backing database" Well, then you need an expert in GCP, Python and postgresql. This can be as many people as it takes to have those skills covered. As for responsibility, well, that goes for where your skill is. If you're the resident postgresql expert then you're expected to be responsible for supporting people with it. It's likely you'll need to worry about patching the OS and stuff like that, but I don't think you need a dedicated person to be responsible. The point of DevOps is mostly to bring down the silo'ing, not to eliminate a particular role. But it certainly appears employers are salivating over the idea of hiring less specialists, or simply rebranding sysadmin to "devops".
- dragonwriter 7y ago> The whole point is homogeny, I'd rather say the point is the opposite; devops teams are (even moreso than agile dev teams) heterogeneous (or “cross-functional” or “multi-disciplinary”). There's basically a continuum where assembly line analysis / dev / test in separate teams (and security, operations are separate higher level organizations with the technical area, and business is separate from technology) is one extreme, then agile dev teams unifying the analysis/dev/test functions, then devops, then devsecops, then maybe the other extreme is some thing that goes beyond devsecops where also domain expertise (and not just the system analysis skills that interface with domain experts to elicit requirements) are an organic part of the team. But each step along the line does increase the expected range of skills of an individual team member, because you need also to avoid any team member being a single point of failure and you have to keep teams in manageable sizes (e.g., 5-9).
- ronsor 7y agoLeetCode is like the CAPTCHA of hiring
- ilikehurdles 7y agoMakes sense. I generally fail both on the first try, despite being both a software engineer and not a robot.
- vinceguidry 7y 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.
- toomuchtodo 7y 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.
- vinceguidry 7y agoSure, walk away. How sure are you that the next role is going to be better? Another friend of mine changed jobs six times in two years. Now he's having trouble getting taken seriously.
- toomuchtodo 7y agoYou're not. You have no guarantees. Is staying in a volatile role where you're not sure what your job will be next week better? You are in control of your own destiny. Don't let someone else be.
- rjf72 7y agoThis 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-college-degree-grade-inflation.html https://www.inc.com/suzanne-lucas/why-that-barista-has-a-col... [2] - https://www.indeed.com/rc/clk?jk=5d42d374514328da&fccid=d0458096ad5f3137&vjs=3 https://www.indeed.com/rc/clk?jk=5d42d374514328da&fccid=d045...
- GhostVII 7y agoI 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 7y agoAt 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.
- ilikehurdles 7y agoIgnoring 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 7y agoHeh. 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_sze 7y agoCan we fix the industry by collectively saying no to nonsense/irrelevant interview questions?
- jlengrand 7y agoI 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 7y agoIt'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 7y agoI'm not afraid to hire people who challenge and ask great questions. I ask that question all the time. The interviewer should be involved with improving the hiring process, not following the cargo cult of "hiring process". Obviously if that question comes up more often, they might start asking "why are we doing X?" and "does X provide better outcomes?"
- jlengrand 7y agoAmen! Since I've been involved in hiring and recruitment, I stopped seeing interviews as a validation of invalidation of my worth and rather more as a discussion where we are both trying to see if what we have to offer matches what the other needs. Based on this, most of the interviews are not interviews anymore, but open discussions.
- pnathan 7y agoHa, 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 7y agoInterviewing 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.
- ryandrake 7y agoWhen 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.
- 40acres 7y agoAgree 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 7y agoYeah, 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 7y agoOne 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 7y agoI 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 7y agoI'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.
- kd5bjo 7y agoThe actual question involved: > So basically it was a variation of the exact change problem (I realized afterwards). You had to validate a string of size n. 1 chunk of 8 characters could have 1 format, 1 chunk of 16 characters another, and 1 chunk of 24 characters another. You essentially had to determine if the string was valid. So in other words, find a combination of these sizes in which the string could be validated. I had 30 minutes > It can be a string of size n. It needs to form a valid combo of 8, 16, and 24 char strings - each of which have an expected format. Result is T or F This sounds like a pretty basic parsing problem to me, not dynamic programming, and likely to be a regular language. There’s a standard tool for this sort of thing, a “regular expression”. Not recognizing this much is a huge red flag for any kind of systems/integration role, like DevOps. The answer here is just matching against this regex, with “fmt1”, “fmt2”, and “fmt3” replaced by regular expressions for the different packet formats: ^(fmt1|fmt2|fmt3)*$
- SubuSS 7y agoThe 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 7y agoI'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.
- Stronico 7y agoWhen 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.
- malvosenior 7y agoDoing 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).
- Stronico 7y agoSo 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.
- kache_ 7y agoThe 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.
- deleted 7y ago[deleted]
- andrei_says_ 7y agoSurely 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.
- coleifer 7y agoYeah, I studied for an interview and it paid off huge. Just treat it like a cs exam and you'll be fine.
- bcp2384 7y agoI 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 7y agoWhat 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 7y agoBest 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 7y agoThe 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 7y agoI 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 7y agoIsn't this a good thing though? It shows that the competency of candidates has increased so that harder tests are needed. It used to be that 99% of programmers failed FizzBuzz: http://wiki.c2.com/?FizzBuzzTest http://wiki.c2.com/?FizzBuzzTest
- rifung 7y agoPotentially unpopular opinion.. If companies don't have strong enough incentives to change their interview processes, doesn't that kind of imply that it is working for them, at least to a certain extent? At least it doesn't seem to be the case that they are hiring so many bad candidates they are forced to change.
- jahewson 7y agoActually, 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?
- drugme 7y agoWhat 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.
- gwbas1c 7y agoI 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.)
- pnathan 7y agofrom 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 7y agoI am preparing myself for a week of onsite interviews as we speak. Of course I hate them, but what other choice do I have? The biggest problem is that the questions are so random and span almost anything. Will I get asked: a pthread question? implement mergesort or quicksort? implement a Read/Write lock? implement a smart pointer? a bit manipulation question? topological search? dynamic programming? graph question? backtracking question? What the default timeout for TCP/IP is? a Java internals question? best practices about Cassandra? N-ary tree search? linked list? b-tree? Paxos vs Raft? What is the access time for an SSD vs spinning disk? How does Hadoop work? Design Netflix various random programming questions, as evidenced by Leetcode's 1000+ questions It's impossible to know everything and yet this what people expect and ask. I've been asked those questions above over the last 6 years. It's utterly insane the expectations that interviewers have. I personally also interview candidates, I've done hundreds of interviews throughout my career. These days, I do about one interview a week, and often 2. My coding question is a simple recursion question, with a for loop and some basic knowledge of data structures. It's not hard, but I look for perfect code. If you can't code a bug-free 15 line function in 45 mins, that's my red flag. I don't think that's unreasonable. As long as the person asks good questions, we work together well, and they can code in a sane way, to me that's a pass. Interestingly, 70% of the people fail the interview because they can't code properly, even after the phone screen. I think because people are expecting a hard leetcode algorithm question, they can't think properly when someone asks them a simple question.
- hjk05 7y 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.
- 7y ago
- mixmastamyk 7y agoIt'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 7y agoMy 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 7y agoFrom 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 7y agoHasn't anyone else commented this is for devops FFS
- stlava 7y agoIs 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.