Coding interviews are stupid (ish)
My 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.
Classic 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".
I 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.)
My 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.
The 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.
I'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.
We 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.
> 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. You have to know the trick, or you might spin your wheels for 40 minutes.
I have never heard of the negative base question (I would have never passed that without help): 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.
The 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.
> 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.
This 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.
Thinking 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
If you want a more efficient way to practice, I’ve been working on 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 :).
I 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.
Simple 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.
At 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.
Here'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.
> 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-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.
I 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.
We 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.
Hiring 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.
I'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-thi...
I 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.
Code 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
The 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.
For 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.
What exactly is an alternative way to hire good candidates that any of you think is better than coding interviews?
Lately, 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.
All 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
It 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
Where 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.
I 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.
The 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.
After 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.
Everyone 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.
My 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.
I'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.
You 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.
I 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.
My 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.
I 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.
But 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?
i 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...
I 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
Honestly, 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.
To 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?
One 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.
Coding interviews are a lossy process. Once you realize this the angst of rejection softens and it becomes an almost mechanical effort.
Eh, 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_exp...
Maaaaaybe, 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.
It'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.
> 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.
I 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.
I 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.
it 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.
[flagged]
Sounds 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.
Coding 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!
Assuming 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.