The Flaws of Algorithmic Interviews in Software Development

Algorithm interviews often misrepresent a candidate's true development skills, focusing instead on pattern recognition and not practical application.

### Reevaluating Algorithmic Interviews in Software Development
* 🤔 Many in the software development community question the relevance of algorithmic challenges in interviews, suggesting they do not accurately reflect a candidate's **real-world application development skills**.
* 💻 Modern software development spans a spectrum from algorithmic tasks to system design, with most developers focusing on **application development**, which is closer to **system design**.
* 🔍 The assumption that proficiency in algorithms equates to application development skills is flawed, as a **diverse range of abilities** is necessary for creating functional applications.
* 📉 In fact, a typical interview process dedicates around **66% of its time to algorithmic challenges**, which most developers rarely encounter in their careers, often coding **less than 1% of the time**.
* 🧠 While studying algorithms can enhance problem-solving skills, it primarily signals a candidate's **ability to recognize patterns and prepare for interviews** rather than their overall development capabilities.
* 🔄 To better assess candidates, interviews should focus on evaluating skills relevant to application development, such as **interpreting business needs** and **effective code debugging**.
* 📚 The conclusion emphasizes that while algorithmic knowledge can be beneficial, it should not be the **sole criterion for hiring**, particularly for roles centered on **application development**.
* 🚀 Ultimately, a balanced interview approach that includes both **algorithmic challenges** and **practical application tasks** can provide a **more accurate representation** of a candidate's capabilities.

So before we start this article, I do have one question I want to see everybody vote yes or no on. This I'll go interview questions yes or no. I'll give somebody a maybe. So in general, it looks like most people don't think we should

be doing algorithms in interviews now. I probably have a slightly different take on this one than y'all. So let's let's see what they have to say. Okay, let's let Mike Cook. Modern software development is a spectrum ranging from deep algorithmic work to system design. The majority of

software development happens between that range. Most developers work on application development, which is closer to system design than it's low-level algorithm. Okay, fair. Most software development interviews are for jobs somewhere between application development and system design, yet many interviewers do technical interview rounds for algorithmic challenges and

system design, nothing in between. The assumption here is that if you can solve algorithms and do system design, you have the skills to develop applications. That assumption is flawed. A broad range of skills is needed to develop applications. You will not get them by just practicing

a hundred hours to recognize specific algorithm problem patterns. You won't get you won't get them by staring at overly simplified systems design of Netflix, Uber, or Twitter. Who takes the time to say Threads? Who even wants to be on Threads? Ew, Threads is just a bunch of pictures of dudes and

boats. That's pretty much that's like my experience on Threads. I don't think I want to be on Threads. I really don't need that Netflix mentioned. Let's go by the way. I work at Netflix by the way, if you're wondering. Uh, your application

development skills by well-developed applications, but many technical interviewers do not assess those skills. I don't know, something about system design really kind of helps you know how much experience a person has. Like, if I ask you to build like out in boxes and arrows and describe how you'd build a

good CLI application, I think that you can really tell how much CLI application development experience somebody has by how much they know about how you put together those pieces. I don't know, to me that seems like a pretty pretty obvious signal. Um, you really gonna hit me with that

paywall right now? You're gonna hit me with the paywall in front of everybody? Oh, but it's one of those scrolling paywalls. Classic scrolling paywalls. Okay. A typical set of interviews includes two algorithmic, algorithm rounds, a system design round, 66% of technical interviews

is dedicated to something you will likely code less than one percent during your entire career. I know, defeated that blocker. I've been doing software development for more than two decades. The only time I studied algorithms is uh, for fun. Difficult challenges can be fun in your free time with no pressure when

no pressure exists for, for an interview. Oh my goodness, okay. Can I just continue reading? Oh, there was a button there the whole time. There was a button the whole time. Didn't even see it. They appear in the corner of my actual work. I use libraries that are battle-tested without

specializing in that kind of work. There is no way I could improve upon them. Uh, very few people learn algorithmic development on the job. It requires hours of personal time to practice enough of them to be useful in an interview. They are not relevant for most developers.

okay so I agree with this take right now I agree with his take I too use libraries that are battle tested such as left pad ah you're a connoisseur of fine libraries I see do you use isEven or isOdd this is a real question this is a

friendship test question if I don't see the right one you're out say it say it if they appear in the course of my let's say actual work I use oh yeah blah blah blah blah blah algorithm interviews get false signals okay so I I do want to let

this guy cook we're going to let him cook before I give my opinion on these things at least that's what I said so I'm gonna give my opinion on things right now so absolutely I do agree with this sort of I think it completely depends on what you're building I think

if you build more CI CD stuff you really just deal with zero algorithms I think if you build uh like if you're just making React you're not building anything if you're building just like CRUD endpoints you're probably not doing any algorithms at that point but if

you're building say CLI tools if you're building any anything in the tools world which is a lot of stuff you're dealing with that a significantly higher amount of time and it is completely like it is a good signal to know people know some of the requirements because

there is a lot of useful stuff in there and so just something to think about that you know when when people make these really broad strokes what I see is that they they don't necessarily know like they haven't done all the things and so they don't know

Algorithm interviews that get false signals. Algorithmic challenges and interviews signal only one thing: you practice algorithmic challenges enough to recognize the pattern and solve them. It says actually one more thing than this, so this guy's already incorrect right here, which is it says one more

thing: you are wise enough and capable enough of learning things that are difficult such that you can pass some arbitrary bar that has been set in our industry. I think that that is a very important signal to understand because if you don't, if you can't do those things, it

means you are just intentionally saying no to the system. You're either too dumb or you are, uh, you skill issue, right? You either have a skill issue or you are just completely lacking in wisdom and think that it won't happen to you, right? Like, I don't want to be on that side of the

fence when somebody, when somebody gives me one of these problems, I want to show that I've put in the time, I've learned the secret handshake, I've high-fived it, right? That I, I've just done the right thing. Either you don't know that it

exists, which one interview will teach you very quickly that they ask you hard questions, or B, you're intentionally saying you don't need to do them. Okay, if you don't need to do them, why would I want to hire someone that wants to kick against the system? Real talk, why would I

want to hire someone like that? You say, hey, I'm not gonna, I refuse to do it, and I think that if you ask me those questions, I won't hire you. Okay, so you, you know, we're going to ask you something. I've given you the literal key

to the door and you don't want to open the door okay that's fine find somewhere else that has a different door go for it it's I'm not upset about it just go somewhere else uh but they do uh but they do not signal

General development skills Fair very fair they say well sort of there I also have a hard time believing this as well I think that in the rare case of someone being Ultra amazing that means they've spent only their time doing that but in the general case if

people can do this I think that they have enough programming sauce to be able to do most things they signal pattern recognition and preparation more than they signal problem solving that's literally problem solving what that is the definition of problem solving what's your problem I want to get hired how do

you get hired learning how to do this well that doesn't signal problem solving I solved the problem of getting hired I have a sub level of wisdom by focusing on one's ability to solve algorithms under extreme pressure I don't think it's extreme pressure I mean it's just

like you're on a whiteboard having to draw some stuff and nowadays it's mostly in code signal with an editor that kind of looks like something you're used to I mean is it really extreme I mean is it extreme pressure I mean is it extreme

it seems seems a little hyperbolic here you ignore other factors necessary for application development the biggest being the candidate can turn business requirements into a solution that solves a business need yes that's called a different interview so you set aside one hour to really test how somebody would

kind of develop something, you know, you ask them the questions you, you, you have a problem you want them to solve. It. You don't make some shitty way of making them kind of forcefully asking you out questions. You just start talking about what you want to build. You hear them jam

with you, you help guide them and you can kind of test that they understand how to build software from a requirement standpoint. Like that's not that hard of an interview. In fact, that's a very fun interview to perform and it's a very fun

interview, uh, being a part of. And so yeah, I think it's kind of nutty to say that you can either have either or. How about both? Besides, AI can already do that better than humans. Yes. I mean, sort of. I, I always give this example way too much

because, because people just say, just say these things and it's just so wrong sometimes. Uh, I'm here. TS tests. There you go. Uh, give me the quick. So let's see. Hold on. Uh, let's go like this. Function quick sort, uh, numbers, uh, number this

thing and number that thing. All right. Co-pilot, go. Okay. Yay. I give this example a lot because what they just did here. Quick sort is an in-place sorting algorithm. What they just provided me is a massive copying algorithm. This ain't it. This is

not even quick sort by definition. Yeah, it looks like quicksort. It does all the things quicksort does, but it did it completely incorrect. Okay. This is slow sort. This is stupid sort. This is like merge sort. You've pretty much written me merge sort, but almost dumber in some

sense okay so do they do it better than humans I don't know okay I think that that's kind of an arbitrary point the best case uh you find a candidate that uh productively develops applications in the normal case you find candidates that studied algorithms well enough to pass

the interview in the worst case you alienate many candidates that do not perform well with gotcha type algorithm questions I do not think it's a gotcha as long as you don't do something stupid right there are people that do gotcha questions but most algorithm questions

aren't gotchas they're just not they're just think through the problem and show me you can think through a problem and solve it uh such a candidate let's see so let's see questions such as candidates with neurodivergence that's everybody's

favorite word and it's a complete bucket it's a bucket word to make an excuse oh you don't think I got some level of neurodivergence okay you don't think that I I am not socially awkward you don't think that by thriving on the

internet slash programming that I am not diverging somewhere in the brain well guess what I probably got some weird brain worms going on upstairs and guess what I can still do it okay it's just ridiculous people that say this they always throw this out there like this is

just like anyone can say this word because you can't argue with someone I'm neurodivergent Oh no you're not prepare to meet my lawyers like what are you gonna do you can't challenge someone on saying such a phrase like this is a catch-all bucket

to avoid questions is ridiculous it is ridiculous it is ridiculous how many people in here call them type one in the chat if you think you're neurodivergent there's a lot of people that think they're neurodivergent our field is

probably primarily comprised of people that are just a little wonky okay I mean let's just face it every single field is filled with people that are a little wonky is there so I mean most of us probably have ADHD maybe 80% if that is

even a real thing or is it just an observation of different types of human behaviors I don't even know right oh I've definitely got me that word dyslexia soup going on you know I I just don't like the hard part about all these

phrases is that you you everything is on a spectrum that's the problem everything is a little spread now I've met people that are truly suffering from real like like deep Asperger's all the way to like full-blown autism that's like very like

you can see that they're they're gonna struggle in life and those people I genuinely feel bad for and they really they really deserve some extra special things and those are things we should take care of and really treat well okay and we should really provide them a

place to flourish and we should try to make that possible and it's not going to always be possible for everybody right it's very very difficult but most people I meet that say they're that way they're not that way they're just socially awkward they just spent too much time

playing World of Warcraft and not enough time talking to a human and you've just lost the skill that's all there is to it you just haven't practiced social skills in your whole life and now it's difficult of course it is of course it's

difficult social skills are just like any other skill you never practice typing you're not gonna be good at typing you're gonna feel awkward trying to type is this a personal attack no it's not a personal attack well maybe it's a personal attack I feel called out

I know there are real people here with real problems and hey if you're here with a real problem I'm most certainly not talking about you you you deserve real real considerations and I would have no problem giving real considerations you know what I mean I am fully supportive of that it makes me

feel like I want to cry think about those people because they you know like I can't imagine all of us come into life with some level of something that's fighting against us right I I got no dad right I didn't I didn't get those things

I had I had a different set of things I had to fight against plus the whole dyslexia part really made things kind of hard growing up always been terrible at English English is the only class I failed at uh it was very tricky but that's a different set of

problems right I feel bad anyways all alternatives considered so what should you do instead of algorithms and interviews create tests more like what you'd expect a developer to do regularly which are skills are essential uh for work yeah but then you could argue that

Do people like, again, these are just also not good either. For example, focused on getting signals for interpreting business needs, functional requirements, and non-functional requirements. This is good to measure for breaking down complex projects into manageable tasks. Instead, this is good to test for application design patterns, maybe

be good to test for depending, right? Uh, but you also have to know if you have to play around with some arrays. Is this person going to totally code base, or are they going to be good, right? Like, you're kind of dropping this whole programming is a skill thing from there. Evaluate is

worth automating again. This all should be done in a simple interview. Uh, reviewing code effectively and understanding the benefits of this process. Okay, that's a cool code, and I think that that's always a cool one. I've had those as part of my technical interview

process, which is tell us what this code is doing. Comparing trade-offs between threading and async for server construction. I mean, that's kind of funny that you say threading versus async because I mean really you you technically did and didn't say the same thing, right? I think you're having a

language issue here. Uh, this sounds like too much JavaScript brain. Uh, identifying opportunities for performance optimization and code debugging, resolving issues uh in a given piece of code, uh refactoring code for improved readability and maintainability, integrating APIs effectively in software

applications. Like a lot of these would be extremely hard to do in an interview. Now they're definitely possible, but there's definitely some difficulty here. There's some good stuff. Like I'm not saying you shouldn't do these things. I think these are great. This is why I

I think a lot of people try to do take-homes, they try to do take-homes so they can give the person an opportunity to show what they do, show their application development chops, you know what I mean? I do agree with that. Reading code is a different skill than writing code and

and I agree a lot of people think take-homes they're they're a waste of time. I hate take-homes, like some people hate take-homes, some people love take-homes. I think it's largely where you're at in life right now. If Google said, "Come be a

L6 with us right now, the primogen, but before you do that, do this take-home." I'd say, "I'm not gonna do a take-home, yo dog. My life is too full. I got like four kids and a beautiful wife. I'm writing courses for Front End Masters. I'm streaming and

I'm doing a full-time job. Yeah, that ain't happening. I'm not doing a take-home. Sorry, it's just not something I'm doing. If you want this, I'll give you one interview, that's what you got. You know, just because I'm in a different stage of

life now. If you would have asked me 10 years ago, which Netflix did, they said, "Here's a take-home." You want to guess what I did? Oh, take-home, okay, yeah, okay, okay, we're gone, okay, we're going, we're going as fast as I can. Like I tried to build the

greatest take-home ever. I was in a completely different stage of life. It's just different, right? Unsure of where to start with such test coding challenges is an excellent resource for challenges to fit these requirements. Should I learn algorithms? Studying algorithms will make you a better developer. I remember kind

Oh, seems like maybe then if studying algorithms makes you a better developer, maybe just maybe this entire article has been debunked. What the what? What? Why would you do that, dude? I feel like I'm being trolled. I'm just saying that if you think studying

algorithms will make you a better developer, if only there's like a simple way you could test if they'd know algorithms and have put in the time, right? Just maybe if there was like some sort of test, maybe a whiteboard or a computer could be included, ambiguous.

Gang, rise up. Definitely a masturbator here, dude. This is ridiculous. All right, let's keep on going. By the way, I hate this take. I hate this take at the bottom of this take. Okay, the reality is that yes, studying algorithms will make you a better developer. Testing for algorithms

gives us one of many signals to know that you are a good developer. I still want to see some sort of algorithmic type kind of challenge problem for you to do so that you can prove to me that you got the chops to do it. Now, I don't

need, I'm not going to ask you to do like find uh find a uh a cycle in a singly linked list like right, like to me that's uninteresting. I'd much much rather try to find something that's a bit more complicated, like here's a good one.

Here's a great one that I think is a great one, right? Uh say you have a schema that has a property named, uh name, and this thing has like say a type that's a string, and maybe we give them a types as array or um or object or or string, number, blah blah.

blah blah and then you have the value and this thing has uh depending on the type it will give you like or it could have a type right it could have uh you know a Fields Fields could exist if it's an object if it's an object it has a

fields which is like a recursive property right I'm just kind of spitballing here so this isn't a fully fleshed out one but you get the idea and then I also have a value right that is an object that is a bunch of objects

that have property names and it is either going to be the the value itself which like if it's a number will be 69 or it's going to be something that's like an array where it has all the values in it and I need you to convert that into the object

for me if it's of type object right like try to build something like schema schema building great exercise right sounds like an O camel yeah I mean I've had to do this at my job schema Builders I had an entire team not figure out how to do that right this is like basic

encoding decoding right doing some sort of encode decode like this just shows you can work with things right you understand data structures another good one is just implement merge deep or deep merge depending on whether you put the Deep before or after the merge right like I think this is a great problem to

watch somebody work through I want to see you do that I want to see you do that do it do it show me you understand programming right that shows me you know how to do pretty much everything right uh did you upgrade your camera I am looking fine yeah yeah yeah deep merge

deeper merge well you had a team that couldn't figure that out no I had a team that gave me that as a piece of data I literally had a schema somewhere and then I had a compacted data format in the database and nobody nobody knew

where the decoding was I asked several teams and people are like uh we don't know how it works I'm like dude this is your team this is your database this is your UI how do you display this in objects and they're like I nobody I had

like 15 people in a Slack thread all saying I don't know so I built the gosh darn thing myself and I just said f you guys I got the schema and I got the object functionality I'm building it myself so I

built it myself it took like a day I got it all right built a couple unit tests called it a day walk away you know just F y'all I can do this I just didn't want to do it I just wanted the npm install some stupid schema I've

never heard of version latest duplication sometimes you duplicate right sometimes you Bill O'Reilly and say we're doing it live right all right anyways let's go on if you're applying to jobs that have algorithm interviews you have two options refuse

to do the algorithm interviews I think that honestly I think this makes you look childish when you do this real talk I think this makes you look childish in the sense that if someone sends me a take-home I will just say I don't have the time for this I'm sorry

like I cannot spend a full day doing a take-home plus a full day doing an interview. I can provide you guys one day, right? That's like a time constraint that's not a real thing. I'm not refusing to do something, I'm just saying I can't

spend 16 hours interviewing for a job. It's just not, it's just not feasible. Whereas just saying I won't do it at all, like I'll give them an option, how about this one? I'll do the, I'll do the, I will

do the take-home, but I'm only gonna do four hours of interviews, like I need to fit it into one day. That's that, right? But just refusing to do it out of the interview site seems a little, a little wild, right? Right, it just seems a little wild.

uh, learn algorithms and practice them in an interview-like environment. This is great advice, you should always do that, you should always do that because it, like, regardless of you, even if you refuse, let's just say you refuse. Number one, you should still do this. The reason

why you should do this is that communicating out loud your ideas, especially to somebody else, is a skill. It is a skill you should practice because at some point, whether at a job interview or in front of your co-workers, you're gonna have to go do something

right, and you're gonna have to do it in front of them. And so, guess what? This is a great way to practice, right? Oh, let's see. Only one of those will give you a chance to that particular job. If you want that job, too, yes. Conclusion: If

You're giving an interview, consider how to evaluate technical ability. If, uh, the job you are interviewing for actually involves working on deep algorithms, absolutely go ahead and test that. If your job is application development or, uh, or more abstract, cut it out completely. I disagree with the statement.

And conclusion and his odd concession that studying algorithms will make a better developer, I don't see how that's not a thing. I mean, my personal favorite is if the person has some sort of public, you know, example of the work they've done. I ask them about that and I want to

know about that, and then I want to hear them go deep on what they built and why they built it and make them go as deep as possible. I think that that's really good. And even if it's something as stupid as configuring Vim, right, I want to know

what you've done. How have you read it? How did you get a part of it? How many files is it broken up? Is it well organized? Is it not organized? Is it one big ass file? Like, just tell me your process. Tell me how you went deep. I want

to see you've gone deep at least once. If you've gone deep once, it means you can go deep again. People that have never gone deep on something literally have never done anything, you know, like worthwhile. You know what I mean? Antagonize, uh, the interviewer too many

people. I'm not... I think you might have this incorrect. Too many people antagonize the interviewee or the interviewer, right? Don't be a script kitty. Don't be a script kitty. I'm on the hiring team. I do interviews regularly for Netflix. I'm

good at interviews I like doing interviews I like the shop talk interviews but I also like the technical interviews I like them both because I see them as equally valid signals I've had people talk the talk and not able to walk the walk I like to see people can

walk the walk and I like to see people be able to talk the talk okay because here's the deal when it comes down to coding I want to see that you know the language that you're used to I give people several options for the languages they want oh you want to do

this in C++ Rust Go or JavaScript pick one and run with it right and I just want to see them do something I want to see that they know the language because when they're inside there and they can't tell you what packages to use they can't tell you

where to do it they're like oh you just look it up what I see is someone who's never even taken the chance to become an expert at what they do right they're just literally script kitties that look things up okay just a feeling just a

Algorithms In Interviews SUCK | Prime Reacts

This is a place for all the things that are awesome on stream. 

ThePrimeTime

Initial poll and introduction of the topic: Algorithm interviews in software development.

A poll shows most people believe algorithm interviews shouldn't be used.

Mike Cook's perspective: Software development spans a spectrum, with most work between deep algorithmic work and system design.

Many interviews focus on algorithms and system design, neglecting application development skills.

The assumption that algorithmic and system design skills translate to application development is flawed.

Practicing algorithms and system design doesn't provide the necessary skills for application development.

Critique of algorithm-focused interviews and alternative assessment methods.

Application development skills are not adequately assessed in many technical interviews.

System design questions can reveal experience level, particularly in CLI application development.

A significant portion of interviews focuses on aspects rarely used in actual work (66% on algorithms, less than 1% in career).

The speaker's experience: Algorithms studied for fun, not for professional use.

Algorithmic development is rarely learned on the job and requires extensive personal practice.

The speaker's agreement with Cook's points and personal experiences.

Agreement with Cook's view and use of battle-tested libraries.

The relevance of algorithms depends on the type of development; less relevant for CI/CD, React, or CRUD, more relevant for CLI tools.

Algorithm knowledge is a valuable signal, particularly for tool development.

Broad generalizations about algorithm interviews often come from lack of diverse experience.

Counterarguments to the critique of algorithm interviews.

Algorithm interviews signal pattern recognition, learning ability, and willingness to learn difficult concepts.

Refusal to do algorithm questions signals unwillingness to adapt or learn.

Hiring managers may avoid candidates who refuse to engage with standard interview processes.

Algorithm interviews primarily test pattern recognition and preparation, not necessarily problem-solving skills.

The pressure of algorithm interviews is often overstated.

Proposed alternatives to algorithm interviews and their challenges.

Focus on assessing a candidate's ability to translate business requirements into solutions.

Suggesting a more collaborative interview process focused on problem-solving in a realistic context.

AI's ability to solve algorithms doesn't negate the value of human problem-solving skills.

Example of AI providing incorrect code for a quicksort algorithm.

Algorithm interviews can lead to different outcomes depending on candidate abilities and interview design.

Discussion on neurodivergence and its relevance to algorithm interviews.

The use of neurodivergence as an excuse for poor performance in algorithm interviews is criticized.

Neurodivergence is a spectrum, and using it as a catch-all excuse is inappropriate.

Acknowledging the existence of genuine difficulties faced by individuals with neurodivergence.

Many who claim neurodivergence may simply lack social skills due to limited social interaction.

Emphasizing empathy and understanding for those with genuine difficulties.

Alternative interview approaches and concluding thoughts.

Suggestions for alternative interview methods that focus on practical development skills.

Assessing skills in interpreting business needs, breaking down projects, and using design patterns.

Code review, understanding threading/async, performance optimization, and API integration as potential interview elements.

Discussion on the pros and cons of take-home assignments.

The initial premise of the article is questioned due to the acknowledged benefits of studying algorithms.

The speaker's final stance: Algorithm challenges are valuable but should be more contextually relevant and less focused on obscure problems.

Example of a more practical and relevant algorithm-based interview question: Schema building and data transformation.

Another example of a practical interview question: Implementing deep merge.

Advice for candidates facing algorithm interviews: Either learn algorithms or negotiate interview time constraints.

Practicing algorithm problems aloud is beneficial for improving communication skills.

Conclusion: Tailor interview assessments to the specific job requirements, and consider practical demonstrations of skills.

Personal preference for evaluating candidates based on their public work and ability to explain their projects in detail.

The speaker's experience as a hiring manager at Netflix and preference for both technical and conversational interviews.

Importance of demonstrating language proficiency during interviews and avoiding the appearance of being a 'script kitty'.