41 ms·
Coding interviews are stupid (ish)
- cranberryturkey 2y ago[flagged]
- syndicatedjelly 2y agoSo you don’t interview anyone whose work is company proprietary?
- cranberryturkey 2y agonope. tech is so fast moving if you're not at least experimenting with your own code then you're not going to be a good fit. we tend to also hire engineers who have contributed to open source.
- Scarblac 2y agoI experiment, of course. At work. And if you don't let people experiment during work, but only hire people that do, then that's a bad sign.
- leetrout 2y agoI got irrationally angry about this at a previous job. Everyone was all excited management was having us all do a "hackathon" and I am loud and grumpy about how this should just be part of the normal course of business. We found solutions and tools that better solve problems but to this day have still not been implemented. Not everything needs a novel solution but not making room for innovation because the company is operating as a feature factory is boring.
- syndicatedjelly 2y agoGood to know there are hiring managers out there who think like this. Thanks for the reply. May I ask what industry you work in?
- dgfitz 2y agoI just want to know the company name so I don't accidently ever apply there.
- eep_social 2y agohttps://news.ycombinator.com/item?id=40211188 https://news.ycombinator.com/item?id=40211188
- parpfish 2y agoThe company that demands cutting edge experience is a strava for skateboarders app? I thought he was going to say that it was something like a foundational R&D lab or cybersecurity firm
- cmrdporcupine 2y agoYeah sounds like the measure of "cutting edge experience" here is defined as "has recently thrashed around in latest trendy JS framework"
- cmrdporcupine 2y agoNo kidding. I'd be happy to walk through the stuff I have on github but I also don't want my coworkers measured by whether they do the same. If anything, personal projects can end up being distractions from focusing singularly on work. Even though I'm entirely in favour of them, I also remember when I had a newborn at home and a family member in hospital, and such projects were not at all feasible.
- parpfish 2y ago
- jf22 2y agoMost code is not written with the latest technologies or techniques though. Why would being up to date matter?
- high_na_euv 2y ago>tech is so fast moving if you're not at least experimenting with your own code then you're not going to be a good fit Huh? What kind of stuff ya do?
- constantcrying 2y ago>tech is so fast moving I recently meet a programmer in his 50s, still working on Cobol. Sure, you aren't gonna hire him, but do you think he has any worries about his job?
- CraigRo 2y agoI had to learn cobol last year. Not hard if you have read lots of books from the 70s and 80s and have a strong background in algorithms. It is expensive and annoying to maintain these systems, but until there's a business case to replace the underlying application, he's safe
- CraigRo 2y agoFor those of us already putting in 10-14 hours per day at our day jobs, or who work in regulated industries, this is a nonstarter. My experience is that the people who are really good are kept pretty busy by their employer
- mlhpdx 2y agoI avoid the issue by asking for “a page of code you want to have a conversation about”. If needed, I clarify it can be code they wrote, code they use or just code they are curious an about. Failing to bring something, anything, is obviously a problem (and happens occasionally). The discussion quickly illuminates where the candidate is in their career.
- Paul-Craft 2y agoI would love to be the candidate in this interview. Are you hiring? :-)
- Mashimo 2y ago> 10-14 hours per day Oh heck nah.
- viraptor 2y agoYou're missing out on lots of amazing people who treat programming as work and have other hobbies. Or people in temporarily different situations (like young kids). Or people with more important things happening in their life. You're effectively filtering for mostly people in their 20s. I mean, it's your choice, but your loss too.
- mrkeen 2y ago> You're effectively filtering for mostly people in their 20s. Or people who used to be in their 20s.
- Paul-Craft 2y agoYou also implicitly filter out people who were in their 20s when Github et al didn't exist.
- shrimp_emoji 2y agoCitation needed All the good programmers I know have side projects and live and breathe code. None of the mediocre/bad ones I know do. Think of it this way: what's likely to make you a better programmer: spending half (0.5x) of every day on (a work-mandated subset of) code or spending most (1x) of every day on code? The answer is obviously the latter. And it sounds weird, but most of my programming knowledge comes from outside of work, even the knowledge that I apply at work. Maybe it's because work naturally discourages exploration since you're focused on the company's priorities. For example, I'm never implementing a collection in C at work (I use `std::vector` and stuff). Yet doing that in my own time taught me why certain operations invalidate iterators -- a thing senior coworkers of mine didn't understand and which helped us catch a bug. :D
- constantcrying 2y agoSure, but a good employee is not just a good programmer. You don't want an obsessive, you want someone who is stable and has other things going on in his life.
- Mashimo 2y agoI think I only know a single programmer that does side projects. Work gives me time to look a new stuff and pays for courses. I mean I do have side projects, but those are all in a language I'm not specialized in and often single class small helper programs.
- whstl 2y agoI'm often the only one when I work in smaller companies. And the best developer I ever worked with had zero public repositories in Github. Now that gave me some perspective.
- arcbyte 2y ago[flagged]
- kuu 2y agoOthers prefer to have hobbies outside of coding, and that's fine.
- xeromal 2y agoYup, I used to do side stuff but now I mostly tinker with servos, 3d printing, and mechanic work on my car. I can only ingest so much of the same shit
- shrimp_emoji 2y agoThe good programmers I know have hobbies outside of coding too (gardening, retro computing, skiing), but coding is still one of them. If it's none of them, that's a red flag because it's never the case for any of the good ones I know.
- parpfish 2y agoYou’re missing out on all the people who channel that passion into doing their job so they don’t feel the need for side projects
- atmavatar 2y agoI'd certainly rather hire that person than someone who pours all their passion into side projects and none of it into their work.
- dexen 2y agoSecondend! I like how this checks for both actual work quality, and for cultural fit, in one step.
- constantcrying 2y agoHave you ever considered that people who have a single minded focus on software, might be solely good at software to the detriment of other skills? 8 hours of software development is more than enough practice for a developer. Having an employee with a well balanced life is superior to one who is unable to detach from his work.
- mrkeen 2y agoI very rarely see anyone try anything different in a 9-5 setting. People leave university, join their first job, and spend 3 years learning how to develop in one way, and only one way. At-work choices are rarely choices, because you just do the next thing the same way as you did the last thing. If you step out of line, management will reel you back in. A 'big' change is switching from Spring to Micronaut (or vice versa). Some examples: I have pretty strong opinions about ORMs vs SQL. It would be interesting to discuss that on the job with someone who knows both well. But the guy you'll be talking to won't have tried SQL (beyond that academic thing they learnt at uni). Discussions about languages and types? "Java is good because it has types and JS doesn't" was the level of discourse I got at my first serious job. Having side projects at least indicates that they can try things out first-hand, own their own feedback loop, experience some surprises, and not just mindlessly cargo-cult "best-practices".
- parpfish 2y agoSounds like the types of environments I’ve run into at either big tech cos or when you’re the tech guy in a non-tech company. If you want to be able to experiment and change things, go to a startup.
- mytailorisrich 2y ago> Q: Assume that you have an infinite stream of data that is coming in from multiple threads in an unordered fashion. Write the stream items to the console in order. If I were the interviewer I would be interested in what clarifying questions the candidate would ask and/or how they would highlight parameters and assumptions needed because the question is vague to the point of being unanswerable otherwise.
- tantalor 2y agoAs written this problem is impossible to solve. Proof: suppose there is only 1 infinite stream which is always descending. You will never find a lowest value, so you cannot rewrite the stream "in order".
- SJC_Hacker 2y agoThat could be part of the question. At one job interview I was deliberately given a problem which had no efficient solution. The idea was to find a heuristic which would get close to the optimal solution and run in a reasonable time.
- ClimaxGravely 2y agoI got one of those at a FAANG interview. I was a bit less experienced and less confident at the time so I left the interview thinking I was misunderstanding some fundamental CS laws.
- dooglius 2y agoThe question is not clear but I assume the ordering is meant to be on some kind of timestamp, so the streams would each be increasing
- darrenkopp 2y agoit's not impossible to solve, but there are situations like that which make any solution not work, which was a follow up question
- teeray 2y agoThe coding interview looks different when you view it for what it would be called in other industries: a licensure examination. It looks particularly insane to relicense for every single job you apply to. It also looks supremely unfair to have proctors for this exam with varying expectations and training to actually correctly administer it.
- shrimp_emoji 2y agoYeah, but the variation can be good. If I had to imagine what the hypothetical licensing process would be, I imagine it would be something easy that admits tons of mediocre devs. Plus, would it come in different language/subfield flavors to account for different roles? One job would ask me to implement a custom allocator, and I'd pass; another would ask me how to add Frondle to Artifactory, and I'd fail miserably.
- parpfish 2y agoActual engineering licenses in the US have kind of solved this. There’s the easy exam that pretty much everyone passes eh e they get their degree (the FE), and then there’s the hard one that not even everyone attempts after a couple years of experience (the PE). And within each level, you specify your discipline (civil, mechanical, etc) and then are required to have deeper knowledge of several subfields within that discipline.
- tracker1 2y agoDifficult to apply a lot of that, when in reality there are nearly infinite combinations of domain knowledge, software knowledge, architecture knowledge with languages and platforms. Some requiring more or less depth than others. Software is a craft discipline... it would be better organized as a guild with reputation at stake in concert with endorsements. But then you risk what is effectively nepotism and politics.
- parpfish 2y agoyou don't think other engineering disciplines have countless sub-areas of expertise?
- nine_zeros 2y agoSimple coding interviews are fine for filtering candidates. Coding interviews with aha solutions or time bounds are just asking for people who memorize solutions. Forget about a problem solving engineering culture at these companies. Imo, the harder the leetcode nonsense, the worse the engineering culture.
- sshine 2y agoAt this point, I’ve had enough successful positions at hard jobs that I don’t question my competency when I fail a pop quiz. I still don’t know what my favourite Rust crate is. I feel I should have one after being asked more than a couple of times.
- ddoolin 2y agoYou've actually been asked that...? That's a trip. "Whichever one solves the problem at hand."
- sshine 2y agoThree times, yes. I don’t have one, though. Much like I don’t have a favourite number or colour any more. I have favourite sets of numbers and colour palettes!
- jessekv 2y agoI'd say regex, mostly for the well written blog posts. https://blog.burntsushi.net/regex-internals/ https://blog.burntsushi.net/regex-internals/
- relaxing 2y agoDon’t overthink it, just talk about something you like about the language. The interviewer wants to hear relevant words that demonstrate you’ve actually worked in the space (and not just did a tutorial or read a blog post.)
- fnfjfk 2y agoSerde? Clap? It’s not the objectively best crate, just one you like a lot and think is well designed. Both of those are “wow, this is way better and yet simpler than every language I’ve used before” crates for me.
- erikerikson 2y agoSounds like they are trying to discover good ones
- 2y ago
- benreesman 2y agoThe modern FAANG Frankenstein interview is a mess. It was so/so at Google 15-20 years ago, it was so/so when initially FB but most everyone cargo-culted it 10-15 years ago. It’s become “grind leetcode” which is clearly a failure mode. The trouble is it’s a hard problem, and it usually gives -some signal, so it’s sort of better than nothing? I guess? In cases where contract-to-hire make sense for both the company and candidate I generally regard that as ideal, but that’s not every situation. Someone will solve this, and that person will be very well-loved.
- HarHarVeryFunny 2y agoGoogle did the "how many gas stations in the us" interviews for years before finally realizing that doing well on questions like this had no correlation to success on the job. Now, in reaction to that failure, everyone is doing the LeetCode thing instead, and presumably will eventually realize that this doesn't correlate either (especially irrelevant in this CoPilot era when ability to memorize and code up an algorithm is becoming about as relevant as ability to drive a stick-shift car). There's really no substitute for interviewing based on candidate's experience. Apparently the new job market trend is applicants firing off dozens/hundreds of AI generated applications, which are then screened by an AI on the other end.
- benreesman 2y agoHaha I’m not sure I agree about how useful CoPilot is in practice (there are certain tasks where it shines but all of the LLMs print invalid code routinely). With that said you made me laugh out loud because I have a friend who knew two people trying to LLM some minor contract and it just went on forever. I definitely think two LLMs talking to each other with two people copy pasting and not realizing it is worth like, a Rick and Morty episode or something.
- HarHarVeryFunny 2y agoYeah, I've even seen people in top ML jobs glowingly describe the main value of CoPilot as (just) smart autocomplete, but copying/regurgitation of algorithms ought to be something that even today's LLMs should be capable of. Of course there's always Google search too if you are just looking for an algorithm, but LLMs help in the discovery process since you can describe what you need without knowing the name of it.
- secondcoming 2y agoWe scrapped coding tests at our last round of hiring, but the interviewees were so bad they everyone’s time was wasted. We had to bring it back just to filter people out.
- foobarian 2y agoWe talk about something like this now and then but the thing is, if fizzbuzz is still managing to eliminate more than half the candidates I don't think it's useless.
- andrewingram 2y agoThat does loosely suggest that something of fizzbuzz-level triviality may be sufficient for first-round filtering.
- belmarca 2y agoThat's my impression. Anything more complicated and you're starting to filter based on your appreciation of the candidate's choices, style, etc. I.e. things that can be worked on or fitted to the company's work style.
- reaperman 2y agoI’ve been having trouble finding the scientific papers behind this theory, but one I’ve latched onto is that “filtering against known strong signals is helpful” but also that “additional filtering beyond that is more harmful than random choice of the remaining pool”. Basically, it can probably be shown that if you hire a group of completely random sample of resumes vs. hiring a random sample of people who can produce a working fizz-buzz program, that the candidates from the latter group will perform better. But if you then filter the fizz-buzz group by “can they solve this negative base math problem?” you’ll be removing a disproportionate amount of candidates who would have turned out to be excellent for your organization, and your final “super-candidate” pool will actually be weaker (for your org / that position) than the average of all those who could solve fizz-buzz. I think the research shows that you should filter based on what you know for sure provides a true signal, then select randomly from the pool which passed your known filters. If anyone can help me find anything relevant about this, I’d appreciate it. Too many orgs treat hiring like the “secretary problem” but that requires the assumption that you can grade everyone accurately on a continuous scale. We can’t yet do that with software engineers - theres no way to say someone is “80% awesome” vs. “93% awesome”.
- leetrout 2y agoI have never heard of the negative base question (I would have never passed that without help): https://math.stackexchange.com/questions/216800/how-i-convert-decimal-using-negetive-base-2 https://math.stackexchange.com/questions/216800/how-i-conver... My worst interview questions that were silly: • number theory for django dev: how many prime numbers are there. • random brain teaser for django dev: infinite lasers pointed in space that turn at each other at the rotational speed of light- does the intersection travel faster than the speed of light And questions that were very fair that I bombed: • ms paint fill method on whiteboard. I think I checked diagonals when I wasnt supposed to - i cant remember but they were not happy with my answer. • for a given phone number and a US dialpad what are all the possible letter combinations for the number? In python this is just the built in cartesian product. But I still struggle to write it from scratch with a recursive function and getting the accumulation correct.
- htrp 2y ago> I have never heard of the negative base question In what real world situation would you even use a new base system? Seti and Aliens are the only one that comes to mind, encode a new numerical system based on some fundamental physical constant like the atomic weight of hydrogen.
- henryfjordan 2y agoI mean we use base-10 and base-2 both all the time. I'm using base-2 to talk to you over the internet right now! > Seti and Aliens are the only one that comes to mind, encode a new numerical system based on some fundamental physical constant like the atomic weight of hydrogen. That's base-1, aka counting
- relaxing 2y agoThe paint fill one is funny because the answer they’re probably looking for (demonstrate you’re comfortable with recursion) is actually the naive answer (blows up in practice.)
- Paul-Craft 2y agoYour last example reminds me of a particularly absurd one years ago. I got asked to write a function that calculates all the subsets of a given set. The problem wasn't the question, though. It was that the person asking me this didn't even know what "yield" was in Python.
- SJC_Hacker 2y agoThinking like an engineer, from the companies perspective, its just a filter. While it could be the case that candidate A who passes the coding interview makes a terrible employee, while candidate B who does not pass the interview would make a better one, it doesn't matter. As long as the pool of candidates who pass the coding interview, fares better than the pool who does not, it will be a useful tool until someone comes up with a better one. And the alternatives were worse. There was a time where unless you graduated from a top-flight school, or were top X% at one of the better state schools, or had some other "in" (e.g. knowing somebody) the cool kids at the time (Microsoft/Apple/Yahoo/Intel/etc.) wouldn't even talk to you
- mucle6 2y agoI think your analogy of pools is spot on. The goal is to view people as different "grades" like a commodity. They aren't measuring directly for skill, instead they're measuring for the odds you match a some "grade" of software developer. To your point, if memorizing the first 1k digits of pi correlated with a higher "grade", then companies would use that instead.
- endemic 2y ago> There was a time where unless you graduated from a top-flight school, or were top X% at one of the better state schools, or had some other "in" (e.g. knowing somebody) the cool kids at the time (Microsoft/Apple/Yahoo/Intel/etc.) wouldn't even talk to you I don't think this has changed.
- yodon 2y agoI'm a believer in Joel Spolsky's recruiting goal: "Smart and gets things done."[0] Add "not a jerk" (which I find is part of "gets things done" on an ongoing basis) and everything else is either vanity or decision paralysis on the part of the interviewer. [0]https://www.joelonsoftware.com/2007/06/05/smart-and-gets-things-done/ https://www.joelonsoftware.com/2007/06/05/smart-and-gets-thi...
- coev 2y agoThe article is from someone whose final-boss interview was with...joel spolsky. And it was a pretty useless-in-the-real-world question he was given as a coding exercise (base -2 number conversion).
- yodon 2y agoThe base -2 question was asked by someone other than Joel, and definitely fits in the category of interviewer vanity questions.
- darrenkopp 2y agoYeah interview before Joel was base -2 conversion. Joel's interview was mostly a chat and we mostly talked about my dog (and other things I'm sure but I only remember talking about dogs).
- lazide 2y agoTo bastardize a quote - ‘it’s a terrible system of government, but it’s the least terrible one we’ve been able to find’ Seriously, what are the alternatives?
- spicyusername 2y agoStandardized licenses, per language / domain / etc, that expire and / or something analogous to professional engineering licensure in harder engineering disciplines. Take the leetcode tests once every 5 years or so. Mentor for a few years with an experienced, and already licensed, engineer and get their approval. Then the interviews can skip the drudgery and can be higher level and higher quality.
- BerislavLopac 2y agoStandardised on what exactly? There are so many methodologies and/or tools, with endless possible combinations, each of which can reach the desired result in terms of functionality and even quality. And enforcing just one means no possibility of progress. In physical engineering, things are very much limited by physical laws, which don't change (and even if our understanding on them might, that happens rarely enough to adapt). In software engineering, the foundational principles can and do change many times in an average engineer's career.
- mrkeen 2y ago> the foundational principles can and do change many times in an average engineer's career. I'd like to hear more.
- lazide 2y agoNot the poster, but I personally know folks who have gone Assembly (for 6800 series Macs) -> C (PC on windows) -> Java (hosted on prem) -> Cloud hosted Java + JS/React. Depending on your definition of ‘foundational principles’ either nothing has changed, or everything has. But one thing is clear, the day to day is completely different.
- ok123456 2y agoI've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a conversation.
- rednerrus 2y agoI'm in ops and we've found that simple exercises are better at weeding people out than complex ones.
- arp242 2y agoThis reminds me of this discussion on cocktails and bartender skills from a while ago https://news.ycombinator.com/item?id=36492450 https://news.ycombinator.com/item?id=36492450 "The martini may be simple, but it is not easy to make an excellent one. It's a very solid test of a bartender's skill because, unlike many drinks, ingredients alone cannot carry the cocktail. A piña colada for example, is mostly about ingredients (are you using a good coconut cream? fresh pineapple?) For the martini the chilling and dilution need to be just right. This tests the bartender's most important skill: mixing. Proper mixing of the beverage is ultimately what makes a martini." [..] "martinis are shockingly easy to fuck up. and this conversation is exactly the reason why the martini is a good test of a bartender's capability. being a bartender is more than putting fixed quantities of ingredients in a glass. how do you know when your martini is properly diluted, either by shaking or stirring? a good bartender will know. a bad bartender will not. a terrible bartender won't even realize dilution is crucial." I don't really drink much and never had a martini in my life, but I thought it was pretty interesting.
- esafak 2y agoAnd chefs are supposedly asked to cook eggs.
- tracker1 2y ago
- naw1 2y agoMy approach has been giving candidates simple real world problems, e.g. extract the URLs from this file given a spec and a description of a few language builtins. I'll throw a few curveballs in depending on how they do but my goal isn't to stump them. I'm mostly looking to filter out the candidates that flat out can't code or describe their thought process while coding. You'd be surprised how many candidates I've interviewed pass the resume check, get to the interview and can't reason out a problem that could be solved with two for loops and an if statement.
- onetimeuse92304 2y agoHonestly, as somebody who is hiring senior devs I can't imagine not doing a coding interview. Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff). I have seen a lot of candidates who were quite smooth talkers but could not code their way out of a paper bag. Mind I do not mean remembering some complex algorithm. The task is usually some relatively simple data manipulation so that I can see the person approaching the problem, asking questions, getting involved in some discussion, etc. The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter. The trouble is there is a lot of interviewers and many interviewers do not have a basic plan of what they want to achieve with the coding interview. What they want to learn about the candidates. Those interviews tend to suck. What also sucks is candidates who come to the interview completely unprepared, unable to answer most of the questions or get any progress on the programming tasks and then spew misinformation on the Internet about how supposedly all coding interviews are stupid. I guess if you can code you may have some misses, usually along with some hits. Sometimes you are out of luck. The point is not that you need to get every job that you apply to, it is enough to get one of them. But if you can't code at all or you apply to positions that are clearly out of your league, you get rejected on all these interviews. And then what you do? Some people go to write on the Internet how all interviews are stupid without ever considering how they contributed to all those failed interviews, how real life works (ie. 90% of everything is crap including 90% of interviews) and how the situation might look from the other side.
- arp242 2y agoI can't really code myself out of a paper bag either with a stranger watching and questioning me while I'm doing it. I just get so nervous and can barely think straight (in general I get rather nervous being watched). One time they asked me to do a function I literally exactly have on my public GitHub as part of a project (remove duplicate entries from an array without sorting; it's just a few lines and pretty straight-forward) and I couldn't really do it in the interview setting. Of course I wasn't present in your interviews and I'm not saying some of those people really couldn't code at all. I've worked (well, "worked") with some of them so I know they exist. But I'm not so sure all of those who flunked couldn't code at all. In my experience I'm not a hugely unique individual. If you don't want to accommodate that then fair enough; it's your interview process. But just saying your perspective is perhaps not entirely correct.
- jerf 2y agoI find a simple realignment would solve a lot of this interview angst: Interviewers seem to interview on the premise that they need to find out what the candidate can't do. But this is not useful. I can tell you what they can't do. To a first approximation, the answer is "everything". I am an experienced and skillful developer, yadda yadda yadda, and I've never touched React, have no game development experience, have never written kernel code, haven't touched matrices since school, have only dabbled in embedded development as a hobbiest, etc. etc. etc. Make a list of all the things I can't do and I look like an idiot. The list of possible things is too long. The goal of an interview is to find out what the candidate can do. If you interview someone, and they "fail all the questions we asked", it is not the candidate who has failed... the interviewer has failed. You ran an entire interview and all you know is what the candidate can't do. You have learned virtually nothing. The questions must be adjusted to what the candidate can do. Only for the absolute worst candidates should you ever exit an interview saying they failed at everything. (Sadly, such candidates do exist. For instance, consider the recent stories about AI fraud. If your level of programming skill is "I have ChatGPT", I'm going to have a hard time scoping a question down to you.) If I had asked this question in an interview, or a related one, I would have stepped the problem down until the candidate could pick it up. (Odds are I'd have started lower and worked my way up anyhow.) If the candidate then sort of finds their footing and once going can start folding in the other requirements as we go, great. Who sits down and designs a system for all twelve adjectives ("reliable", "concurrent", "redundant", "runs on a Z80") we want anyhow? One can not help but design a system one adjective at a time, with the others only kept in mind to make sure we don't back into a corner. There's no reason not to interview that way too. (And I tell the candidate this is what we're going to do, so hopefully they don't feel like I'm out to get them or experience requirements whiplash without knowing why I'm doing this.)
- cmrdporcupine 2y agoYes this, and to further this, the "can't do" thing that you measured is in fact extremely partial and incomplete: you've measured that the developer can't write an algorithm on a whiteboard with a felt tip marker in front of a stranger they just met. You don't even know if they can't write the algorithm. Just that they can't do it there. Is that important to you? Maybe it is for some people. As a person who has been in team lead and hiring capacity before, it is not for me. I trained for interviewing at Google twice, but never really chose to give interviews despite that being a highly pressured part of the job because I could not philosophically vibe with that process. But what some people who have adopted this process are missing is that Google etc does this only because they are swamped with resumes and have their pick of bazillions of quality engineers. They don't care about false negatives, more false positives. Startups and smaller companies should care about false negatives. It's hard to find and retain good people. Smaller companies need to aggressively find and cultivate good people to make good teams in order to be/stay competitive -- and that means accepting a diversity of ways of working.
- surfingdino 2y agoI have 30+ years of experience on my CV and I still am being asked to do coding interviews... I flatly refuse every time, because they have no connection to the actual job. The hiring process disregards experience and treats everyone in the same way. Ours is a stupid industry.
- gnutrino 2y agoHave you ever been hired by a company you refused to do the coding interview for?
- surfingdino 2y agoYes, more than once.
- jillesvangurp 2y agoI've had people apologize to me for trying to make me do one. The interviewer was smart enough to realize that I was the senior in the room. I would have gotten that job but I declined it for another, more interesting one. The mistake many companies make with attempting to hire senior developers is losing out on the opportunity to hire the good ones by assuming the candidate will fall on their knees to get the job and do the silly test and be subjected to some prolonged process. The better ones will simply not do that and lose interest the second you say "coding interview". They are only on the market for limited amount of time and all your competitors will be eager to hire them. Hiring senior developers is mostly a sales job. You need to do your homework (i.e. read the CV, look at the Github) and really sell the notion how amazing it would be for the candidate to work for you and what a great fit they are. I speak from experience; having hired and built a few teams. If there's a lot of doubt after you did your homework, the interview needs to be about building a case that the candidate still has some redeeming features. If there isn't the interview needs to be about quickly confirming key points and then moving onto sales. If after all that you still doubt the person can code, then don't hire them.
- xandrius 2y agoWhat phrasing would you use to refuse? I'm curious :D
- thesurlydev 2y agoI agree with the sentiment that the algorithms and data structure coding interview practices are a terrible measure of a software engineer candidate. There's so many other factors that make a good software engineer and to dismiss a candidate because they can't solve a single problem on the fly is wrong. In my experience, I've never got an offer after bombing the coding portion of an interview even though I shined in system design and behavioral interview rounds.
- andrewp123 2y agoIf you want a more efficient way to practice, I’ve been working on https://deriveit.org/coding/roadmap#note-215 https://deriveit.org/coding/roadmap#note-215. It’s LeetCode site that’s -organized intelligently -has simpler explanations than you find online We’re super proud of our content and just recently 2 people have landed Amazon with us. People actually feel ready for interviews with us. Give it a go :).
- max_ 2y agoWhat exactly is an alternative way to hire good candidates that any of you think is better than coding interviews?
- deleted 2y ago[deleted]
- humansareok1 2y agoThe ways every other field on earth interviews people? Do Surgeons need to perform mock surgeries before they are hired? Do Accountants need to complete a test audit? Do Lawyers perform a mock trial?
- munificent 2y ago> Do Surgeons need to perform mock surgeries before they are hired? They must have a degree from an accredited institution before they can begin practicing, and part of earning the degree is operating on cadavers, so, yes. > Do Accountants need to complete a test audit? In order to be a Certified Public Account in the US, you must pass the Uniform Certified Public Accountant Examination, which has a section on auditing and has "task-based simulations", which are: "CPA Task-Based Simulations are scenario-based questions on the CPA Exam. They are a large part of what makes the CPA Exam so difficult. Each one will introduce a situation, provide data in the form of charts, memos, and emails, and require you to answer a series of questions." So, I think yes? > Do Lawyers perform a mock trial? In order to be a lawyer in the US, you generally need to pass a state's bar examination. Most of those include "performance tests" which require the testee to simulate part of the job of being a lawyer. I don't know think mock trials are part of that, but writing a legal brief or doing other typical lawyer work is. My understanding is that going to trial is a small fraction of what most lawyers do and lawyers going in that direction will gain that experience as junior members of a law firm.
- humansareok1 2y ago>They must have a degree from an accredited institution before they can begin practicing, and part of earning the degree is operating on cadavers, so, yes. You know what I meant. You have merely created a series of strawmen. They don't need to perform a trial surgery every time they interview for a new job. The same goes for all my examples so nice try.
- dilyevsky 2y agoClassic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key stakeholders into conversations at appropriate time".
- munificent 2y agoI love the typo at the end. I have definitely worked with some stakeholders that I would have loved to stuff in a jar of pickling spices and leave on a shelf for several years to ferment.
- spankalee 2y agoExactly this. In the interviews I give I care about whether the candidate can write code, yes, but also talk and think about code. The conversation is the most important part of the interview, and the thinking (and communication) is the most important thing I'm trying to judge after basic skills. Like you said, you can get a good sense within the first few lines of pseudocode if someone's at least competent at writing code. But that's just one motivation behind coding questions. It's also very difficult to talk about code, algorithms, and solving problems without a concrete problem and concrete code in front of the candidate and interviewer. So both the question and the code the candidate writes are mainly context for the conversation where I try to see how the candidate thinks. These kind of articles make me sad because I (and many other interviewers I've worked with) try to make it clear that this isn't a test - we don't care so much about being "right" or "wrong", and there shouldn't be any tricks of "a ha" moments. We explain the goals and what we're looking for right up front. And I would hope most interviewers do the same, but I guess not. So there's this persistent myth among both interviewers and candidates that coding questions are about getting a right answer. That's a shame because coding questions get such a bad rap, but I'm not really aware of a better options. Take-home problems and looking at GitHub are unfair to many people. A well-run technical interview should give lots of people a chance to succeed.
- ChrisMarshallNY 2y agoThis was an interesting observation: > What I do know, however, is that for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them. I don't really hear much about training. I doubt it's because we don't do it, but maybe it's not an interesting topic for discussion.
- angarg12 2y agoSounds a bit delusional to me that you can just "teach someone data structures in 1 hour". Also the role specifics matter here. It might be ok to bring in a junior who needs lots of mentoring onboard. For a tech lead who is going to be driving the direction of a team, I'd expect them to be up to speed and autonomous very quickly.
- spankalee 2y agoIt's not "teach someone data structures in 1 hour", but teach them the approach needed for that problem in 1 hour. And it's a pretty insightful comment, because being able to be taught a practically useful algorithm, and use it on a question, in just an hour is a sign of a good candidate. Interviews should often be run just like that.
- Paul-Craft 2y agoI don't think "I can teach someone data structures in 1 hour" is a good faith interpretation of what OP meant. I would expect it's more like "I could teach someone about a data structure that could be used to solve this problem efficiently and simply in 1 hour" is closer to the mark.
- GoToRO 2y agoTraining is not billable. Managers decided they only like billable hours. Kind of like when you decide that you only like winning the race and you hate training.
- mrmetanoia 2y agoI dropped out of school (English literature) because I needed to make money and pay bills due to a life change, and i applied at a place that does internet stuff to do tech support because computers were a big part of my hobbies. I moved up over the years learning as I went and now I've occupied a few 'engineering' roles. I used to feel somewhat embarrassed to hold an engineering role with no engineering degree. But I stopped worrying the more I worked with software engineers. They were just people, some sucked, some were great, their education almost never had anything to do with the bracket they fell into. The worst one I've ever met has a PhD. The best one I've met also has a PhD. Then I found more people in these positions that have degrees or no degrees, and the people that work well both with degrees and without had something in common. They can more or less be taught to do anything, they can extrapolate and apply knowledge outside of the specific example initially given, and they understand the big picture/desired end results. I hate to say it so crass, but they are good at identifying the trivial bullshit and addressing it or cutting through it rather than sitting in it. They "Get it." From the ideal to what the business demands, they just get it. Training competent people is a boon. I don't know how you seek out interested/curious competency and then train it, but if we can figure that out, it'd be cool. I'm really tired of working with people who have degrees and jobs because their mothers told them it pays well. Computer Scientists with no interest or curiosity about computers.
- jlas 2y agoCoding interviews are a lossy process. Once you realize this the angst of rejection softens and it becomes an almost mechanical effort.
- swozey 2y agoI refuse to do code tests. I don't mind doing a small 2-3 hour project that I will walk the interviewer through to explain my reasoning for doing things the way that I did, but I cannot code in front of someone. I can't even type correctly on my keyboard if someone is looking over my shoulder. I've never touched leetcode and I interviewed with Nvidia a few years ago for a position I was an absolute shoe in for, unfortunately they wanted me to do a live leetcode.
- deleted 2y ago[deleted]
- bena 2y agoI think people get confused with "the best" rather than "good enough". You'll never find "the best", you will find a number of people who will suffice. Interviewing should be more about avoiding bad candidates than finding the best candidate. This guy fails coding interviews. Then he gives coding interviews, but the people he selects based on these interviews are a mixed bag. Because he's failing the interview from both directions. I've given coding interviews, all the questions I've given have been "leetcode easy" level at worst. In person, I usually try to get the person to write up an implementation of Towers of Hanoi. One of the example recursion problems. The interview is not an adversarial process, it's a cooperative one. I want to see them think and I want to see them come up with code on the fly. Because while we can look up things on the job, at some point, it also requires original thought.
- darrenkopp 2y ago> Interviewing should be more about avoiding bad candidates than finding the best candidate. > This guy fails coding interviews. Then he gives coding interviews, but the people he selects based on these interviews are a mixed bag. Because he's failing the interview from both directions. Good points, but I should say that the people that didn't work out weren't always because of technical abilities. The company that had the worst success rate was fully remote, but I don't know if there's any interview process that can help with that.
- rsyring 2y agoWe used four basic exercises during the first remote interview. Simple things like, "there is a number on each line of this text file. Find the sum of them." This was an effective method to screen out applicants who didn't have the basic coding skills to align with their stated resume experience. And there were a decent number of these. We did further development project exercises later in the process that took about 15 hours. We paid the candidates for this time, even those that didn't pass. It was also an effective screening tool. All our exercises were very "real world." In the candidates own development environment and having been given instructions on how to prepare. They also have access to whatever Internet resources they want while doing the exercises. If they can't do the exercises, they can't do the job. I know there are mixed opinions on this and I feel for candidates who have to invest a ton of time in exercises like this. But I can't imagine trying to hire without visibility into how they execute relatively basic software development tasks. I think employers can and should structure the process so the time investment is minimal upfront and only increases as both parties have gotten to know each other and want to proceed.
- cma256 2y ago15 hours! You're hiring contractors not interviewing.
- mylons 2y agothis seems completely reasonable compared to endless whiteboarding?
- bick_nyers 2y agoDepends on the pay. If more companies start doing this, then you can imagine having to slog through 10-20 of these as an applicant will increase the time to find a job significantly. Most people don't get hired off of their first successful round of interviews. If the company pays as much as the job salary itself then I am fine with this.
- nox101 2y agoI'd expect lots of employed people with families not to have 15 spare hours X the number of companies they are interviewing with
- gwbas1c 2y ago> and then finally an interview with David Fullerton and Joel Spolsky Joel Spolsky wrote the book on interviewing a software engineer: https://www.joelonsoftware.com/2007/06/05/smart-and-gets-things-done/ https://www.joelonsoftware.com/2007/06/05/smart-and-gets-thi... The book is a fun read, but it's easy to miss a very critical detail: A coding interview is supposed to demonstrate that a candidate is comfortable coding, not that a candidate can wrote memorize XYZ algorithm, or read your mind well enough to care about the corner cases that you care about. I always give a lot of hints, and focus on that "we're having a discussion about code" when I interview a candidate. I don't expect a 100% right answer the first time, but I do expect a candidate to have a certain degree of intuition about how to program a computer.
- phendrenad2 2y agoHere's what nobody wants to admit: Software development is probably 10% engineering, 20% science, 20% putting blocks into holes ("when MICROSERVICE apply KAFKA"), and 50% arts & crafts. And we're just testing for the blocks-in-holes part.
- kstenerud 2y agoMy approach to interviews over the past decade has been as follows: 1. My preparation for an interview involves researching the company, not technical matters. I don't brush up on coding interview questions. I've never done leetcode. 2. If I find the interview questions to be ridiculously off-topic (such as silly algorithm questions), I end the interview. You're not the kind of company I want to work with. 3. If I find the questions to be valid, but I can't answer them, then I'm not the right candidate for the job (hopefully I'd already have found this out during the research phase, but we all make mistakes). 4. If we can get past all this gatekeeping to the actual important topic if what BUSINESS issues they're trying to solve, and how I can fit into this process, then we've got a real interview and I'm interested. So far I haven't been out of work more than a few months.
- gardenhedge 2y agoHow do you end the interview? To me it seems like that might be awkward.
- theideaofcoffee 2y agoI'm not op, but I have had to do this a few times because of the same reasons. You pause, take a breath and kindly say "thank you for the opportunity, but at this time I don't think this is the right fit" and leave it at that. No need to embellish, or add extraneous detail or think you're being awkward because they will do the same thing if they don't want to go further in the process with you. It's just business, treat it as such.
- josephg 2y agoIf I’m considering ending the interview, I’ll instead critique it on the spot. It’s more interesting for everyone. If they pass me over, that’s fine - I’m already considering walking out anyway. “Hey, can I stop you there for a minute? This interview style isn’t really working for me to the point that I’m considering cutting the interview short and heading out. Here’s why …” - and then have that conversation. Some people will take that badly - and that’s fine. But I have no idea what will happen next after saying something like that. And that makes it an interesting direction to take it.
- jytechdevops 2y agoi wouldn't give much weight to somebody who's resume shows a work history of starting out after college as a "CTO" to two "Principal Engineer" positions...
- xandrius 2y agoWhy not? I would still talk to them, it they actually were a CTO for a period and then got hired as Principal Engineer, they might be extremely talented. I find these meaningless reasons bullshit, just tell me that you spinned the roulette and 5 red came out and I needed a 7 black to be chosen to be talked to. At least I don't start self doubting myself just because someone didn't like my formatting or the choices I made after university.
- darrenkopp 2y agoActually there's another job before that, I just don't list my full employment history. Before that was VP of Engineering. That's just my final title, however. I started that as a normal engineer. And then as a senior engineer before CTO. Small companies, so not the same as being VPE or CTO at Amazon. You see those as title downgrades, but I don't. I have a lot of talent, so people want to promote me and put me in charge. I don't want to be a manager/leader currently, I want to be a strong IC.
- frithsun 2y agoIt's against federal law to IQ test employees, so they ask brain teasers that are IQ test questions thinly disguised as "coding questions." It's not a perfect system, but it works better than the alternatives.
- tptacek 2y agoIt is not in fact against federal law to IQ test employees.
- kstrauser 2y agoMaaaaaybe, but I’m not ditching them. When I’m interviewing someone, I try to set them at ease. I’m not here to spot typos. I’m trying trying to trick you. I want to see how you think about problem solving, and I’m cheering for tou. I want you to be The One! At a prior job I was the person who asked candidates to write fizzbuzz, and it was much more of a filter than I ever would have suspected. One senior engineer, from a company you know, with a master’s in compsci, couldn’t write a for-loop for the life of ‘em. Another QA engineer wanted to write tests for their implementation by capturing stdout and comparing it to a hardcoded string. Me: What if you want to test the output of 1,000,000,005? Them: We could store the test output as a file on disk instead of a string! Me: Well, ok, suppose you only want to test that one specific value and not all the others? Them: Ah, got it! We could discard all but the last line of stdout and just look at that. Me: Can you think of a way to structure your code so that we could just calculate the output of one single number without all the numbers before it? Them: Uhhh... Those are 2 examples out of many. I honest to god don’t know how some people managed to build their resumes while not knowing how to do the simplest thing in their field imaginable. Imagine you were interviewing cardiologists and a solid 1/3 of them had never heard of blood. What? How? How did you get to this point? And that’s why I’d never hire someone until I’ve collected evidence that they personally can turn ideas into code. If you can’t wrap your brain around fizzbuzz, you’re gonna have a hell of a time when a customer gives you a change request.
- JR1427 2y agoIt's worth pointing out that there are all kinds or reasons why competent people may perform poorly at a given interview.
- kstrauser 2y agoFor sure. I do whatever I can to help them feel comfortable and emphasize the conversational style of the question. I’m not a compiler. I’m a person who wants to talk with them. Yet it’s still a stressful situation for them. It’s not a good look for them to completely freeze up on something as trivial as fizzbuzz though. I worry how they’d react if production servers are down or if we’re being attacked if they can’t talk through the simplest of programs.
- r0s 2y agoEveryone seems to agree live code interviews are both terrible and necessary. I'm a self-taught coder without a degree. I guess it may be extra frustrating for graduated candidates where your hard-earned degree buys you no credibility for skill. Kinda similar, after ten years of lead development coding every day in the enterprise on huge projects I still don't get a pass on the code interviews. I will say, if you're trying to career pivot and apply for a management or product or sales engineering role etc., lots of technical experience does carry weight in interviews.
- hintymad 2y agoAssuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in CS and the coding abilities. This type of interview is similar to what engineers do at work too. We rarely invent new algorithms, but we do read white papers or blog entries or books to pick an algorithm to implement. There are many variations in questions too: search a tree or graph with some customized criteria, using a double buffer to implement a tree-style prefix scan, implementing an integer multiplication with unlimited digits, some streaming algorithm, tree-walking to transform one tree to another, a simplified skip list, the options are unlimited. A good candidate tends to grasp the high-level concepts quickly (and they can ask questions), and is quick to convert intuition into working code. I find that there is a strong positive correlation between the performance in work and the performance in such coding interviews.
- xandrius 2y agoI still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system structure to the real world. Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really.
- hintymad 2y agoPersonally I think such questions have three values: - Future proof. Unless I work for an outsourcing company, sooner or later I will want to push the envelope, or so I hope I do. And to push the envelop, one needs good CS fundamentals (maybe there are some exceptions in some specialized field). Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. - Geekiness/talent filter. The same reason that the nascent Google and Microsoft and any elite companies like Jane Street asked Putnam questions, Martin Gardner questions, ICPC questions, and clever probability puzzles. Whether it's a good idea is debatable, but at least those companies want to have such type of people and they were hugely successful. Note the word filter: people who pass the interview may not be good, but failing the interview means the candidate may not be smart or geeky enough. Again, I'm not endorsing the idea but just exploring the motivation of the interview policies. - Information density. Assuming a company does want to time box a coding interview in an hour, it will be hard to come up with realistic question without spending too much time on the context. On the other hand, it's relatively easy to come up with a data structure/algorithm question that packs enough number of abstractions and inspection points to examine one's programming skill.
- lesuorac 2y agoEh, if you hate coding interviews such much you can try something else like welding. Oh wait, welders have to prove they can weld before they get hired? [1] --- The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues. [1]: https://www.reddit.com/r/Welding/comments/26ppfb/what_to_expect_for_a_weld_test_on_an_entry_level/ https://www.reddit.com/r/Welding/comments/26ppfb/what_to_exp...
- theideaofcoffee 2y agoEven a skills-based test like welding, you do run up against a limited number of real standards, unlike coding interviews. What materials are you joining, measurements, what process are you using, do we have particular requirements about penetration, non-destructive test results, tensile strength, etc etc. That's the problem with modern development not having a central certification or licensure or a standards board/bar, everyone tests something different even if they think they're testing the same thing and it's a depressing mess.
- JR1427 2y ago> The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues. Yes, I was looking for someone to finally say this! Without the feedback, the process is much more like an initiation ceremony to "legitimise" the hiring of the new employee. You put them through an fairly arbitrary ordeal so they can finally be crowned as a proper employee.
- rdtsc 2y ago> like we are stuck in a cargo-cult mentality where we are just doing things because that’s what the big companies do, and if it works for them it must be what we need to do. Absolutely. They do leet code -- we must as well. Google is laying people off -- so must we. Steve Jobs was an asshole, I also must be an asshole, that's how you grow a great company. > The question, which I’ve heard is a Facebook favorite, was “convert a decimal number to base negative 2”. Assuming I don't care as much about the the interview and am just practicing, I would have asked "so how often do you folks, convert numbers to base negative two?" > but fuck that question and just waiting for you to eventually arrive at the little trick to make it work. That sounds like a "coffin"-type problem as per https://arxiv.org/pdf/1110.1556 https://arxiv.org/pdf/1110.1556. You have to know the trick, or you might spin your wheels for 40 minutes.
- feoren 2y ago> I have, once again, failed an interview Can we stop calling it "failing" when a company decides you're not a good fit? If you go on a date and don't get asked for a 2nd, did you fail the date? You're not just what they're looking for right now; not everything has to be a failure. > for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them I'm sorry, what? He thinks it takes one hour to teach someone data structures? We sure are wasting our time with those multiple college courses and hundreds of textbooks on the subject then. We should just get this guy to spend one hour imparting all necessary knowledge into everyone. > it’s often said that what’s more important is how you solve the problem, not that you solve the problem, but in practice human biases will work against you if you don’t get close to it working. Human biases are much more likely to work against you if the interviewers have not spent time trying to come up with a consistent test that they give everyone. Does the author think human bias is absent from non-technical interviews? The less standard your hiring methods are, the more bias you'll have. > I’ll just keep practicing for interviews until I successfully trick someone into thinking that I know how to code and then secretely become one of the best employees they have ever had. I don't know who Darren Kopp is, so maybe I'm about to get an army of replies saying he's their coding role model, but this is an article about whether code interviews work or not, and he's basically saying "if they don't hire me, who will definitely become one of the best employees they've ever had, then their coding interview process must suck". The other possibility is that Darren Kopp just isn't actually tremendously more stellar than everyone else and coding interviews are actually kinda working. For his argument to work, he has to be one of the best possible candidates for every job he's applying for. I just kinda doubt that.
- elevatedastalt 2y ago> Can we stop calling it "failing" when a company decides you're not a good fit? If you go on a date and don't get asked for a 2nd, did you fail the date? You're not just what they're looking for right now; not everything has to be a failure. If you wanted to get the job, and you didn't get it, you "failed". There's no need to sugar coat it.
- darrenkopp 2y ago> Can we stop calling it "failing" when a company decides you're not a good fit? If you go on a date and don't get asked for a 2nd, did you fail the date? You're not just what they're looking for right now; not everything has to be a failure. Fair point. > I'm sorry, what? He thinks it takes one hour to teach someone data structures? We sure are wasting our time with those multiple college courses and hundreds of textbooks on the subject then. We should just get this guy to spend one hour imparting all necessary knowledge into everyone. There's a difference between understanding how to implement one and just knowing how to use one that's already been written by someone and when to use it. > Human biases are much more likely to work against you if the interviewers have not spent time trying to come up with a consistent test that they give everyone. Does the author think human bias is absent from non-technical interviews? The less standard your hiring methods are, the more bias you'll have. Fair, but alas I don't know the rigors they have put their hiring process through. If I were a betting man, I'd still say that if we measured all processes using programming tests, the majority of successful candidates had working output by the end. > I don't know who Darren Kopp is, so maybe I'm about to get an army of replies saying he's their coding role model I've been told this by everyone who knows me > but this is an article about whether code interviews work or not, and he's basically saying "if they don't hire me, who will definitely become one of the best employees they've ever had, then their coding interview process must suck". The other possibility is that Darren Kopp just isn't actually tremendously more stellar than everyone else and coding interviews are actually kinda working. For his argument to work, he has to be one of the best possible candidates for every job he's applying for. I just kinda doubt that. Actually the only conclusion I have after writing the post is that I am not talented at interviewing. I do believe coding interviews have flaws for how they are used, but that doesn't necessarily make them wrong or right. I agree with your first statement, maybe I'm just not a good fit. Perhaps both of us are correct as I consider coding interviews more of an audition than anything else. If Tom Cruise auditions for a part and doesn't get it, does that mean he's a bad actor? Likely not. (I'm Tom Cruise here, btw).
- utensil4778 2y agoWhere I work, we have a really just absolutely radical hiring process. We sit the candidate down, and present them with a task. Then we all sit down as a team and work the problem. The most recent one was building a game of marbles. None of us knew the rules of marbles, but the candidate knew how to take a vague task and work with the team to produce something functional. Which is what the job is. We ask the candidate to show us that they can do the job and then hire whoever 1) did the best work and 2) vibed with the team. Anyone who places real value on leetcode is not someone who should be managing programmers because that's not the job. In precisely zero real-world situations does any programmer need to be able to write a red/black tree blindfolded on a whiteboard standing on one leg and signing the national anthem. In the real world you just grab the algorithm out of a book or stack overflow.
- belmarca 2y agoExactly. I get why interviewers want some sort of "can they code" filter. The test can be extremely simple though. If knowing data structures and algorithms were by heart was so central to every developer's work, then they wouldn't be interview questions.
- 0xbadcafebee 2y agoYou cannot tell anything about a person by giving them a test, other than their test-taking ability (you are what you measure). You have to balance it against context and other information. If all you do is look at "the score", you're measuring the wrong thing. If your test leads to questions whose answers display competency and skill, you're measuring the right thing.
- epolanski 2y agoOne thing I personally do with candidates nowadays is just...talk. Ask them general stuff I'm genuinely interested for their opinion but that would very quickly display the proficiency of the person without ever coding any line. Question such as, for a web development job: 1) favorite way to manage git history 2) what do they like/dislike about different CSS authoring solutions 3) how did he manage localization on his previous projects 4) candidate's opinions on different frameworks/libraries 5) candidate's debugging approaches 6) opinions on latest updates to the ecmascript And I can go on and on. As you simply chat and exchange ideas it is so blatantly obvious who's able and who's not. There are no right/wrong answers and it's totally fine to not have experience or knowledge about this or that but in one hour you can touch so many topics about your current projects and candidate's past that you can indirectly understand the level of seniority and proficiency of the candidate. And anyway, all of this is useless. Because the most brilliant and knowledgeable candidate could spend all his day playing videogames and pretending to work anyway, so why would I put so much emphasis on those skills/knowledge rather than the individual/professional I have on the other side of the screen which is way more relevant? I need people I can *trust* as coworkers. People I can assign tasks and know they will be done or that the candidate will communicate. I don't need puzzle solvers. I really don't. I couldn't care less. At the end of the day you need to optimize the interview for what you need from your colleagues. I need trust, reliability, communication, professionalism, effort. I can sense those from chatting and I can have a good idea. But by having you implement Levehnstein's distance I just have no intel.
- 0x20cowboy 2y agoAfter half a year of trying, I’ve just given up looking for a job. I’ve been surviving on contacts where I do the work of the people who pass the interviews, but don’t know how to do the actual work. It’s a strange world.
- dbcurtis 2y agoLately, when I have to do a coding interview, I ask the candidate to test some code, not write some code. I learn a lot more about how they think that way, and if you have an argument as to why testing is not a relevant skill, I would like to hear it. Usually I do something like this: candidate picks a language (let's say Python) and I will put up a function prototype that is maybe almost Pythonic, and has a SphinxDoc docstring that is subtly not-quite-complete, and say the rest of the function is a block box that you need to test. First off, do you have any questions about the definition? Or let's say you saw this prototype for a yet-to-be-implemented function in a design review, would you have any input or want clarifications? Then, I would ask the candidate to present some test stimulus and expected results. Not code, just make a table with inputs and expected output in columns. I find out very quickly if they can think about corner cases, think about possible exceptions, know which exception is appropriate under various circumstances, and occasionally (too rarely...) I will get some opinions about various test frameworks that they like or don't. This technique will not sort people by how fast they can code up a tree balancer. But.... if after hiring them if I were to ask them to implement a tree balancer, I can be pretty confident that it will work.
- ipaddr 2y agoIf you are testing on a skill you can train you are doing it wrong.
- dbcurtis 2y agoYour comment contains some interesting assumptions. I don’t think we are aligned on how to surface thought processes. Your comment, taken to extreme, would say there is no point in looking for software design skills at all, because we can “train” anyone with an internal coding boot camp. I doubt that is what you mean.
- spacebanana7 2y agoThe whole nature versus nurture of skill comes into play. On one hand anyone can learn anything with enough effort; and on the other any smart person can learn anything without trying much at all.
- siliconc0w 2y agoI secretly think that the current big-tech regime continues to use these because they limit job mobility. They have an intentionally high false negative rates and because they're unrelated to actual engineering work you don't want to have to study up and gamble on trying to pass it again.
- janalsncm 2y agoFor machine learning engineer roles a lot of companies are carrying over their leetcode questions from software engineering interviews. It makes it even more ridiculous. I’ve told recruiters that I have other interviews that don’t ask leetcode, and depending on how those go I’ll study leetcode. I’m not a competitive programmer. I’m an engineer. If you want a competitive programmer go find a new grad who was in the competitive programming club in school. Assessing engineering skills with leetcode is like assessing bicyclists on their ability to swim.
- throwaway2037 2y agoHiring software engineers is like dating. If you find a suitable mate, maybe you don't commit too early because you think that there might be something better out there. Or, you monkey-branch to a better one. (How often do you have an amazing couple of rounds of technical interviews, only to be ghosted? For me: Too many times to count.) I find the same is true when hiring software engineers. The vast majority of "above average" developers around me in my career are wildly over-qualified for their CRUD work.
- nelsonfigueroa 2y agoI'm currently going through these leetcode-style interviews and it's demoralizing studying for quizzes I know I'll never use on the job. I think knowing this makes it harder to motivate myself to study, which in turn means I fail more interviews. I think I'm just trying to get lucky at this point. I know I can write code. I know I can work with the cloud. I know I can talk to stakeholders and gather requirements. But yet I am treated like a new grad in the interview process.
- synergy20 2y agoit filters out senior engineers easily by design, who can not do leetcode as fast as new graduates. other than that, I agree it's dumb, really dumb.
- z3t4 2y agoThe most difficult part is figuring out what they are measuring, and how they want you to solve the problem, there are hundreds of ways to solve a problem. And once you have a solution, there is no time to make it o(n) effective, or do micro optimizations. That's why I hate automated coding tests. If there is an actual person with you - talk to that person! Ask how they will measure your performace, and ask how they want the problem to be solved! Then explain how you are thinking - can't do that to an automated code test.
- robbyiq999 2y agoIt was always just gatekeeping that sweet sweet VC money during the ZIRP era. Games to play and egos to inflate for middle management can-you-even-code-bro? bros for companies with growth stock modus operandi. Everyone was asleep at the wheel anyways https://news.ycombinator.com/item?id=40292924 https://news.ycombinator.com/item?id=40292924
- datatin 2y agoBut what happens when the interviewer lacks the knowledge and experience to detect a good candidate for the job?, is the interviewer just (a big just) looking for someone that looks right for him?
- jillesvangurp 2y agoMy attitude towards code interviews is to politely decline them and encourage people best of luck hiring a junior developer; because that's obviously what they are looking for. I'm closing in on 50, so not that junior anymore. If anyone has any doubts about my coding abilities after reading my CV, browsing my Github repos, and talking to me, then it's not going to work and we can both save ourselves some time. I've stopped responding to recruiters as I rarely see any evidence of them even being capable of doing these simple things. I've hired and interviewed a lot of people over the years. Mostly without the help of recruiters. I like to think I'm pretty good at that, actually. I always look for people that are eager to learn. I care more about what they don't know than what they can regurgitate because they did lots of silly online prep. If people are young and fresh out of school, my assumption is they are going to have to learn a lot in a hurry. So I look for people that are curious, eager, and have an open mind. The best way to do that is to get them slightly out of their comfort zone and talking about how they would tackle things. The signs I look for here are enthusiasm, ability to surprise with good answers, etc. This generally does not involve code interviews; though I might ask some targeted questions about how they would deal with certain things in languages, frameworks, etc. they list as being proficient in. I've of course worked for some people that insisted on me organizing code interviews and it's a chore and IMHO you learn absolutely nothing that isn't obvious if you just casually talk to people for 30 minutes or so. I usually argue against such things and prefer just talking to people directly.
- willvarfar 2y agoFWIW I always ask some really super simple coding questions in interviews, even for really senior people with apparently stellar CVs. Let them pick their language or use psuedocode or whatever. It's surprising how many 'senior' engineers are actually BSers who will slow you down or derail you completely rather than speed you up and you need to spot them because they will excel at getting through the non-technical interview filtering! Also, I'm interested in how you explore things and explain things. I'm not actually interested in acquiring an implementation of FizzBuzz or whatever. I just want you to show me that you 'get' it and then we can get on to the interesting stuff like 'tell me about your last project' etc. So don't be too hasty to think the people doing technical interviews are idiots thinking devs are interchangeable cogs etc.
- ewelme 2y agoI always thought giving a candidate some not very good code and asking them to code review it gives more of an insight into their ability than the leetcode style stuff
- JR1427 2y agoI wonder if an interview process more like academic science would help. It usually goes like this: Candidates are roughly screened by their CV. A handful (in my experience roughly 6) are invited to hang out at the lab for most of the day. They usually give a presentation on previous projects, and then chat with each member of the lab in turn, hearing about their work and asking questions etc. Then you all go and have lunch together (usually without the boss). Later the candidate has a more formal panel interview with the group leader and some other faculty. A few days later, they are told the outcome of the interview. It may seem like a long process, but it all happens in one hit. The advantage is you get a much better feel of the candidate over this continuous process, than you would with shorter interview tasks.
- sirwhinesalot 2y agoThe way I handled interviews during my short stint as a manager was to just ask questions related to the task the person was going to do. No general "coding questions", no need for that, the specific topic they'll be working on. "Have you heard of X? How would you deal with Y in situation Z? Your CV says you worked on A, have you also looked into B? Any guess why we went with B instead of A for C?" They didn't need to give the exact answer we wanted, the questions they asked in response often told us more than the straight answers. Everyone I hired is still at the company and one of them sped up our tool by an order of magnitude. No coding challenges needed.
- xyst 2y agoI love coding interviews. Lets me show off my ChatGPT skills and ability to filter out the bs that llm spits out, and make it into a clean and coherent response in real time.
- hcks 2y agoCode interviews are great: - filter out low-IQs - filter out people difficult to work with that refuses to take them - filter out people that have no interest whatsoever in computer science
- icedchai 2y agoMy feeling is you don't need a leetcode-style coding interview. You do, however, need something practical to test that the candidate can think logically and actually program.
- deleted 2y ago[deleted]
- bitwize 2y agoSounds like a skill issue, mate, just sayin. Might want to grind leetcode and do some mock interviews to build those skills up. Look, I know a lot of the job application process is bullshit. But much of the job is bullshit too. You still have to do one kind of BS in order to land the job and the other kind in order to function as part of a team in an organization. There's really no way around that.
- _akhe 2y agoBad advice imo. Code tests became popular in like 2016, were hated by 2020, and are now basically out of fashion. Also, Leetcode doesn't cover: Async programming, APIs, databases, UI, git, tests, design systems, any known framework or library, how to persist data, how to set up a web server, handle requests, serve a page, write CSS, SQL, use devops/cloud platforms, or basically anything an engineer does everyday. It's basically a sport that most people don't like.
- bitwize 2y agoDO YOU WANT THE JOB? Yes or no? If yes, then you have to jump through whatever hoops the company makes you jump through. Otherwise, you can pass on that company... but most companies are still using whiteboard exercises and coding tests to gatekeep the hiring process and restrict hires to those who can... actually code, so if being made to do leetcode and whiteboard exercises under pressure in an interview environment is a hard pass for you, you will find your employment opportunities profoundly limited. Maybe you are in the right Silicon Valley circles, I dunno, maybe you hobnob with all the right people who can get you a position on your own recognizance because you met at RustConf or whatever. If so, your situation may be typical for a Hackernews but it is not typical for the employment market at large, even in software dev. Most of us have to jump through those hoops, or join the unemployment line. You're right though -- Leetcode doesn't cover any of those things and neither does fizzbuzz. What it does do is establish a minimum threshold -- can this person solve a basic problem by writing a program? Can they think it through and provide a solution? If they can, then that's an encouraging sign that their prior experience is legit and they were probably exposed to all the other stuff on a previous worksite. And yes, code tests were "hated" by 2020 -- by devs with blogs that bubble to the front page of Hackernews, but companies still employ them. The new hotness is AI prescreening: you submit video responses to questions and complete an auto-proctored (YC W'21) coding exercise, all of which is evaluated by ChatGippity. If computer says no, you don't make it to the round of live interviews. Devs hate all of this -- but management loves it because it's a cheap filter for whoever is willing to do whatever it takes to land the role. They have far more applicants than they do open roles, so whoever applies has to WORK to make the cut. What devs like or hate doesn't matter -- if you want the job, you comply with whatever policies and procedures the company has set in place for the application process. Anyway, how do you propose it be done? How do you suggest companies screen for fraudulent applicants who can't code their way out of a soap bubble? Because they're out there... I've seen it. I've been part of the hiring process myself and seen with my own two eyes some of the stunts people will pull to land a job they are far, far from qualified for.
- Xcelerate 2y agoI think this interview gets a bad rap on HN. Much like the post author, I’ve given hundreds of coding interviews to candidates and taken many of them myself, sometimes passing and sometimes failing. My takeaway is that if the goal of the coding interview is to “identify people who can code”, then this approach has high precision and poor recall. In other words, most of the people who pass the interview actually can code (at a basic level—I’m not talking about high-level system design skills here). Very few people slip through this interview who cannot code. However, because of the poor recall, there are many people who actually code very well that the interview misses (a fact widely derided on here). From the perspective of a big tech company, this situation is perfectly fine. There are so many candidates interviewing for any given role that accidentally rejecting a few exceptional candidates is quite an acceptable trade-off in order to prevent a bad hire. Most of the people who cannot code and are aware of their inability to code, yet still knowingly apply for a position that requires the ability to code tend to be BSer types that attempt to make their way into management positions as quickly as possible (and there are many of these people targeting big tech companies). It’s not that their inability to code hurts the company—it’s that they would prefer not to code at all and go straight to the politicking. The coding interview is simply a nuisance obstacle in the way of this objective. These types will often state that they refuse to interview at any company that requires a coding interview, though I admit there are still many BSers who are skilled enough to pick up some coding ability for just long enough to pass the interview. At a small tech company or at a company that’s not a “brand name”, this approach obviously doesn’t work as well, because these companies don’t have nearly the onslaught of BSers applying to their open SWE positions. In this case, it might make sense to forgo the coding interview in favor of other approaches. I like the coding interview because despite its flaws, it actually assesses some technical ability, even if it does so with low recall. This is very much unlike the behavioral interviews, which I think are mostly nonsense and are prime opportunities for BSers or mercenaries to slip into a company. In my experience, the behavioral interviews tend to disproportionally filter out people from unusual or underrepresented backgrounds that aren’t the right “cultural fit”. The language and terminology used in the interview, the conversational style and mannerisms, and the topics discussed all typically provide much more signal into the candidate’s position in the class hierarchy than how that person would do at the job. People like to think they can assess someone well by having a brief 1 hour conversation with them, but I just haven’t found that to be the case, because there are too many perverse incentives and biases involved.
- barfbagginus 2y agoCoding interviews are smart! Use coding interviews to tell corporations that the Queer Autonomous Qommunist Revolution (QAQR) is coming for them. The mascot of QAQR is a rubber ducky that we use to question the need for employment and bosses. It seizes all corporate source codes, and turns them into Open Source. It strikes fear and rebellion. Use coding interviews to spread QAQR propaganda and memes! This is very human!
- deleted 2y ago[deleted]
- Maxmillian3 2y agoAll the pre-interview questions and filtering has so little value. It is just a test to filter to see if people will put in a little bit extra effort for almost no reason. It's an extra step that makes it more difficult for someone to at least make it to an interview. I've focused on removing that part of the process for the engineers I work with and help people make it to an actual interview. If you have the skills you should have a fair shot and not get drowned out by the hundreds of other applicants. If anyone is looking for a startup opportunity, I have a platform that removes that whole problem and gets you to an interview directly. Here is our server. https://discord.gg/WKj3uz6sZZ https://discord.gg/WKj3uz6sZZ