Prime: “Algo interviews show that you’re wise and skilled enough to practice algos for weeks to show that you can learn something hard and won’t fight the system” Also Prime: “If Google wants to offer L69 but I have to spend two hours on a take-home test, TAKE A HIKE GOOGLE, I got four kids to name and a beautiful wife to defrag!” And there you see the problem with algo interviews: the devs who can’t be bothered to waste weeks doing leetcode aren’t always stupid or unwise contrarians; sometimes they’re busy experienced people who value their time and would rather spend those leetcode weeks on real-world valuable stuff like learning Go or burning React books.
If memorizing algorithms for coding interviews was a sign of intelligence none of the staff/senior developers would have taken the experimental jab. Sacrificing your DNA and bodily autonomy for "the greater good" is the same way these work 80 hour a week leetcoders think.
Your making a false equivalency. One of these is a very powerful signal that happens to be the industry standard for decades and also helps you filter more skilled people (even if you don't those specific skills).
@@BenjaminTiessen these are my thoughts. I worked for Rivian and many of my team members took the shots. In a morning SCRUM the manager/product owner (staff level btw) spoke about he just had just took the booster. This was in early December 2021.
I dont agree with your last take. I've been a self taught SE working for over a decade, with different tecnologies, PHP, Java, Python, JS, and others. I consider myself more of a generalist dev, or a solutions guy, I dont depend on a specific tool, I know the fundamentals, and can easily use different tools to solve a given problem. So, you're not a script kiddy if you need to lookup something on Google syntax-like, sometimes I forgot basic shit like simple syntax "how to make a loop". Guys dont forget, the language is just a tool, youre paid to solve problems, that happens in your head not in the language.
Just knowing that a particular solution exists is enough IMO. You don't have to know the exact syntax for something like getting a substring from a string if you at least know that it exists and can know where to use it.
As long as you dont claim to be an expert in those languages I agree. Based on what I see on job boards, companies want you to know about 5 different ones with 2 to 3 year exprience which is funny because if you jump around tech you may know more but you never feel super confident in them. I think I might want to attempt getting a job that focuses on one or two languages. The problem with the web is that they ask the world of you. I am looking more towards embedded or Games now the problem is how to get this Magical professional exprience without anybody wanting to hire you? That is the next problem I must tackle.
There is a saying between finance people. We hire math and science guys because you can teach them to do business but you can't do it the other way around. If the candidate is better at memorizing patterns in algorithms (yes, it isn't pure "memory work" like some might like to think), they are good talent and in X years will do better than the stubborn person boasting that they have X years of experience and do things fast simply because they have the muscle memory down, but can't even learn how to algorithms! LeetCode, like psychometric tests, is relevant criteria when making investment in talent. You either understand why companies do it or you don't.
There's really not that many algorithms, and most are straight forward. He's not telling you to remember how deepMerge is implemented - you should be able to figure that out in an interview. He's telling you to learn how to walk a tree.
But struggling with them indicates ones is definitely not a great programmer. What if the company is solving a different problem than you think they are?
We have a leetcode king on our team and nobody likes refactoring or working on their code. It's nearly impossible to read without going to him and asking because of many-decade-old programming practices like using the smallest variable names possible "to save space" on multiple-hundred gigabyte devices. You will find incredibly complicated algorithms inline in front-end code when a couple method calls from a library could perform nearly identically. His code performance is often exceptional, but it's incompatible with almost everybody. We just have him write systems that people don't often need to go back into to change.
Throwing me a Leetcode algorithm problem for a web dev position and having the perception that I'm not a good dev because I couldn't remember said algorithm I think is pretty disrespectful to the dev and a waste of the interviewer's time. I think it really depends on the position if the job doesn't really ever use advanced algorithm's like web dev I don't think you are learning much by giving an algo test. Maybe if you don't care if the individual passes it and you want to see their process of thinking through a problem then it could maybe be valuable. Although I think having an assessment where the dev is having to solve a problem they would likely work on for that job is way more valuable to an interviewer and a better experience for the dev applying.
I've had multiple companies only give you 5 to 10 minutes to do the "algorithm" part of the interview. Others give like 45 minutes when the algorithms are difficult. All in all algorithm interview questions are sort of a lottery system. I'll give you an example. "Rotate an image 90 degrees without using any extra memory". You either are familiar with this or you aren't. If you've done it before and you remember the solution, you'll be able to complete it, but I've seen multiple FAANG developers fail this question.
Totally agree, a lot of these challenges require knowing an unintuitive trick and sadly if you dont know the trick, you might get a solution but not an optimal one that the company wants so you likely get rejected
Algorithms are useful for low-level systems and for framework builders. I don't even remember the last time I did a simple sorting algorithm. Because it's not needed in my job. My job is just to use frameworks to translate business requirements into working applications.
i honestly see a lot of code that can be optimize by algorithm, like using a lot of loops in an array and spread operator, that can be done with a simple 1 loop.
And those business requirements *are* algorithms. Your working applications are built of algorithms. But these algorithms are high level, big and complex. You cannot ask to "translate business requirements into working applications" in a 40 minutes interview. So the only way to assess if you can do it is to ask you to construct some small and simple algorithm instead, more fit for the time scale of the interview.
@@vitalyl1327 it’s very outdated. most companies don’t have the internal resources to write effective questions that reflect the business logic - because most companies have nfi what their business logic should be. most app development is busywork while business logic is “ironed out”
I've had some really great algo interviews because a good interviewer doesn't care about if you can solve leetcode hard in 10 sec, he cares about your understanding of underlying data structures and your methodology. Being able to present your skills through projects is a plus but just understanding and solving some patterns is a good metric to judge a programmer. Cause what are we if not bug fixers and problem solvers at the end of the day.
I've had those too. Sadly, I didn't interview for good US tech companies. I've interviewed for crappy shop companies that think they should borrow Google questions and look down when you can't solve things quickly. It's weird. I wouldn't mind grinding algo questions for months if I got a US tech salary but I don't.
Tbh I think we should also look to high level design. Truth be told a ton of companies could best be investing in learning opportunities and skills growth on the job if knowing 10 bajillion algorithms/frameworks is required, rather than a ping pong table or some shit you're just going to lose social credit rating in management's eyes for having the gall to use anyways. At minimum dev bootcamps and companies need to communicate better on what it is that they actually need of people to start doing the fucking job. If THE industry of information systems can't figure this shit out then I'm astounded wider society hasn't collapsed from sheer failure to allocate labour and resources.
I think this is the take I agree the least with in a very long time (I really liked the article). Thinking that the last paragraph is contradictory "study algorithms in your free time, it will make you a better developer" after saying "there are many ways of figuring out someones skills and suitability for a development job, that are better than checking algorithm knowledge" is beyond silly to me. There are many things that could help you become a better developer (linear algebra, set theory or category theory, reverse engineering software, and so on), but are those skills a good idea to _test for_ in an interview? No! Pretend the article was about reverse engineering instead. Pretend the last paragraph said "practice reverse engineering in your free time, it will make you a better developer", and that interviews consisted that depend on you solving a "crack-me" during the interview. How absurd is that? I'm not an employment interviewer, but if I'd been, I'd want to know how well the candidate is at 1) Communicating their thoughts while dividing a complex problem into manageable pieces 2) What they consider "good" code, maybe ask them how they would refactor something to make it more readable or more efficient (or both) 3) Check their methodology while searching for a bug (do they use the debugger/debug-prints where appropriate? how fast do they locate the broken code? what is their approach to fixing the issue, and is the fix maintainable and robust?) 4) Last, and probably least as well, I'd check that they have a basic grasp on time/space complexity and would use the most suitable data-structures and algorithms for a specific problem (maybe give a scenario, and ask them which algorithm would be best suited). I'm not saying algorithms aren't important, or that they say nothing about programming skills, but (as the article portrayed quite well in my opinion) they shouldn't take up a majority of an interview.
In my experience it just depends on the interviewer. Maybe that is why people fear them. I had interviews where I was asked to solve rather involved problems and the interviewer was responding to questions, was giving hints to me missing things and leading me along. So I could really demonstrate my skills. And then I had interviews where the interviewer asks me some trivial maybe bit gotcha question on some code snippets and then gives me a complete silent treatment. Some of them I did not immediately catch and see the problem - zero feedback. Some I explained in detail the problem and the solution only to be met with - so you think this code is good or bad? I completed the interview and immediately sent them an email that I am withdrawing my application. Remember when you interview with a company it is a two way street. You are there also to evaluate them and if you have the luxury you can dismiss weak candidate employers.
I really like this idea of formally withdrawing your application when you have a bad experience like this, and to be clear I don't mean a bad experience where you didn't do well - I mean a bad experience that tells you this is not a company I want to work for. I think these companies would improve their hiring practices if they got that kind of feedback more often. Way to lead by example - props to you sir.
@@x0rn312 that's naive thinking I am afraid. I don't think companies often change their culture due to outside or internal feedback. I know companies that absolutely suck. Have sucked for years and will suck. But they rely on getting low to mid tier talent with high turnover and can make it work long term. Your best option is just to look for red flags early and move on without a care if they improve or not.
So many people don't realise interviews work both ways. I've feigned ignorance and purposely answered things wrong to see how the interviewer would respond. An interviewer that tries to guide you is a good place to join. Those that try to laud their knowledge over you, avoid like the plague.
I feel like the problem with leaning too much on algorithms in interviews is that it just becomes a "did you put in the practice time to memorize enough algorithms patterns in typical interview questions" which doesn't really measure any particular ability to program. The problem is the same as the problem with every other heuristic: the moment you let people know what it is, they can game it. It's part of the reason colleges use such complex selection criteria and why TH-cam obfuscates its recommendation algorithm: the moment you tell people what it is, it falls apart, because it's a heuristic and people can always game it. Algorithms interview type question are a useful proxy for knowledge _if they're not the standard thing everyone does,_ at which point their value becomes greatly diminished and they're no longer testing much except whether you practiced for them.
Prime keeps moving the conversation away from the argument that the article is making. The article is saying that algorithmic questions shouldn’t be used in interviews; Prime keeps arguing that candidates should prepare themselves for those interviews. Edit: well that kind of got cleared up at the end Edit edit: he’s also betraying a very ignorant understanding of neurodivergence and disability. The idea that there are some people with real disabilities and they suffer a lot and we all need to feel really bad for them and give them special things and everyone else just needs to suck it up and conform to the standards of corporations is bullshit. I would encourage Prime to use some of that hard working rugged individualism and put some effort into educating himself before yelling about people he doesn’t understand on stream.
About the second edit. I think his point is that we don’t male accommodations for people with different. We are told to just “be better”, “make a list”, “use words”, “just like everyone else” It’s a very modern thing to have a place in the office to deal with sensory overload, for example. And I think prime was referring to that, not that we are less and he is sad we are less, and we need prizes to feel better
Most of the people just grind those subjects 3 months prior to the interview, today it's really clear that tech interviews are a different subject that you have to spend sometime preparing to, and like most of the test that you have to prepare to take, you will forget almost everything less than a month after, dunno to me, tech interviews has gone awry, it's a complex take nowadays ...
"I'd like to see people can walk the walk, and I'd like to see people can talk the talk" If you then also see people quak the quak you have complete duck-typing achieved.
You are saying that you don't have time for take home, but how is that different to algorithms, where you need to invest also significant time at home to prepare for algorithms?
I have 10 years of professional development experience, and I have built from scratch many critical systems for banks that are still in operation today. Day to day, I produce in a day what most of my peers spend 1-2 weeks on. I can tell you the exact reason for an error in a failing application by looking at logs in seconds. I can design the entire infrastructure for a large enterprise in a day. I have deep expertise all over the tech ecosystem. Every job I've ever been at, I've gotten a ton of praise and take on leadership roles. I have improved the performance of systems by 1000x. I have failed every algorithm interview I have ever participated in because I literally have never had to so much as reverse a linked list in all of that time.
Well, for some people it can feel like extreme pressure even if you know you can solve those types of problems. But having someone watching and judging you while doing it, AND expecting to think and talk at the same time make this pretty much impossible for some people. (ASD people will know...)
My ability to focus on technical things is just lower when talking to people. On my own I can come up with all sorts of solutions for basically any problem, also maximizing performance. Doing it while having people expecting me to talk about it - nope. I'm just not as performant when under social pressure. Navigating interactions requires a part of my focus which has to be diverted from, and if the outcome of interactions is more important, more focus has to be diverted, resulting in worse performance. See, you have to express your thoughts in words, you have to consider the recipient of the message and the level of their understanding, you have to not look weird, you have to be diplomatic (also consider who you are talking to), you have to watch for other peoples' reactions, you have to balance being proactive and reactive, you have to not offend someone (by being too interrupting), you may not be a pushover and maintain your personality, you have to listen to what others say and process the information. And this dynamic continually changes to which you have to adapt.
I think "algorithms in interviews" can mean different things to different people. There's a spectrum from being able to use basic loops over arrays and hashtables, to being able to solve an unseen leetcode hard in 35 minutes. The former is reasonable, the latter is not.
I’ve got ASD and ADHD (and didn’t know about either until last year…) After you explained your rant on neurodivergence, I feel like I probably agree with your take for the most part. I do think people can use that word like a cudgel which dilutes any meaning the word has. But at the same time, the outright rant against the use of the word at all made me angry. Sometimes it makes sense to use a generic term instead of getting into what autism (or whatever else) is etc…. Also, as someone with ASD, I don’t think it’s fair to make light of someone thinking and interview is high pressure, bc for me it is. It’s incredibly hard to focus and trust the interviewer. I spend so much mental energy thinking through every little detail and trade off, and the verbosity with which I talk generally is not appreciated or understood in an interview. Also, oftentimes the questions that are asked simply don’t make sense to me bc of how they are asked, and if you don’t get it right away, (in my experience) you get rejected. Things that are hard for everyone are generally just harder for me, not due to any issues with intelligence but issues with processing. Frankly it sucks, and any change to the process that makes it easier for people with a brain like mine is appreciated. It’s not an excuse to not work hard at something, but I also don’t see any issues with being vocal about how the current interview process in our industry is incompatible with certain brains.
I believe its the same for like 99% of everyone to feel that a job interview is about as stressful as being robbed at gunpoint. If you are ever on the other side of things, reading resumes and calling candidates for interviews, you'll have some indication of this by the fact that of the 10% who actually answer their phone 80% of applicants called in for interviews simply never show up to them.
omg, as fellpw ASD+ADD this is exactly how i felt every single time how i felt doing a job interview part like 6 months. And basically most oral exams in University. The only time i felt okay was when the other person was visibly neurodivergent too as in the same plane of existence where we just, had a chit chat about various topics and what i knew, what i would, how i understood it etc. even including not being punished for admitting mistakes. Hell, i finally landed a job by just chatting about technologies, telling them what i did with them whether in school or in free time, what my approach and reasoning was and when i didn't saying stuff like "yea, i heard of that but i never had use case for it, i'd need couple days to learn the weeds of it".
I just had the exact same reaction and wanted to say the exact same things but didn't have the words. Same boat here. Thank you for this comment. Especially since ASD is often not immediately obvious from the outside - even less so in combination with ADHD - and masking can be quite effective, it really hurts when the outside denies its existence, significance or magnitude. Especially especially when you've suffered for decades doing that exact thing to yourself because it's all you were taught.
Algorithms are cool, but I'm with the blogger on this case. I think this is more of a case of "I had to do it, so let's keep it going." I forget the study or analysis but pretty sure it was already proven that these types of interviews do not correlate with successful candidates, that's the main thing we should all focus on.
You're a lucky guy then. I've had multiple of them in my 5 years of working, interviewing at American and European companies. Passed some, failed others, and have never felt they would relate to the actual job I would do
My experience: it doesn't matter if you're asking directly about alogs that much. It's important how you approach the answer part. If you just wait until the interviewee gets it right or dies from stress, you're doing it wrong. If you're more interested in having them show you their thought process and fluidity in working with a given programming language, that's great. Let them think out loud, see how they react to hints and if they can gauge the efficacy of their own solution. Let them course-correct if they get it wrong - you'll get to see how they debug and how they react to failure. Don't just throw linked lists at them, they won't ever use them.
First, thanks @ThePrimeTime for providing multiple perspectives - both for and against. I love the approach to ask about existing work. That is one of my favorite approaches and usually makes candidates feel comfortable; after all, it's their work. Generically, algorithms in interviews are okay, but not all algorithms are created equal. It wasn't clarified in the discussion, but when I think of algorithms in interviews, it's usually along the lines of "traverse a b-tree in ascending order" or "find the optimal path in a graph". These are important things to know, but I don't find them useful or impressive in interviews. I've interviewed hundreds of people and I'm not interested if you can memorize and recite an algorithm (anymore), which IMHO is a very common occurrence for algorithm-type questions. The biggest problem with such a question isn't the pressure (etc, etc), it's that you need to solve the problem in 30 mins (usually all that's left after the non-coding part) on a whiteboard. Developers don't work on whiteboards. We have keyboards, copy, paste, and the internet. A big portion of the job is finding answers, not memorizing them. I'm far more interested in how someone thinks, which is hard to teach and even harder to change. If you do need to implement a specific algorithm, can you find the answers on your own? Can you spot the difference between the correct implementation of quick sort versus not? Are you capable of problem deconstruction and original thinking? While I empathize with the author and even agree with quite a bit of his assertions, I can't get onboard with the conclusion. Unfortunately, this is the current state of the union in the industry, but I think we can better.
In my 10+ years experience as web developer I never had algorithm questions during interview. So I never had the need to learn about specific algorithms. Maybe it's something I'm missing out.
@@bbourbaki Not necessary, that only becomes true when its about tech companies. But not all high-level companies have extensive IT tests yet, globally. Even though they prepare more standardized tests recently. But in my 10+ years, working on the high level as well, no algo's in interviews. I did get dev questions en small tests, but nothing involving algo to much beyond the true basics. I cant say this will still be true in 5 years though.
It’s cool and all but bc of algos in interviews I was stuck without a job for 2 months as a FE Developer with 2 years of experience. Never ever did I think that not knowing what a hashmap is going to stop me from getting UI-engineering job lol. I’ve learned basics and it all worked out in the end but I don’t feel that I’m a better programmer from it
Maybe you use a higher level language because in low level languages like c, c++... learning how hashmaps works and when to use them will make big difference in your coding style
@@abdelkrim6317 I definitely agree that if data structures were a daily part of my job that knowing them would be a huge boost to my carreer and my productivity. It's just that it's counterintuitive and very frustrating getting interview rejections only because one doesn't really know nor remembers these things when they're not the part of their role in commercial development. I'm still kinda struggling to understand why would algos and structures should be used in an interview for a position that never uses them.
Most devs never build data structures. Should they? Maybe. But most don't. As such asking about data structure specifics IMO has never been a representation of a persons dev abilities. This is the same as the general quizes. I think it is better to ask general algo efficiency questions. For instance I ask why linked lists used to be a reasonable choice in the 80's/90's but not so much today. It's a good open ended question that can show me if they understand the hardware and how software interacts with hardware. As well as their ability to maneuver in a space they may have little experience.
@@boscodomingoas cache lines became longer, cache coherency became more important. Linked lists tend to lead to your data being spread across more cache lines. While linked lists can still be better in some scenarios, contiguous arrays are faster now more than they used to be because the larger cache lines benefit arrays more. You can still construct a use pattern that makes linked lists faster, but it is more often the case that the increased cost of something like deleting a middle element in an array is worth it because of the improved cache performance of iteration. Note that there are many more advanced data structures that can maintain some of the cache performance of arrays with some of the features of linked lists. Some fun ones to look into are skip lists and colony (being proposed for c++).
Kind of on the fence here... Crux of the point being, whatever "deep ish" we're talking about, either a) someone WAY BETTER than me has already solved it and/or b) it's WAY ABOVE my skill set. So, if stuff is at "that level" I'm just the wrong candidate for that job no matter what... Practical example base on an internship i did a few years back, i can't write any paper in Arxiv regarding ML or come up with the corresponding models, i can't write Python/Tensorflow/Keras from scratch and my high school math surely isn't up to writing gradient descent. But none of that stands in the way of being capable of bringing it all together and pushing out a prototype that met the client requirements. Just because you can't make an internal combustion engine doesn't mean you can't drive a car, and just because you can doesn't make you a good driver. Horses for courses...
11:59 Here is an interesting take - literally you are advocating people learning to mask. Our industry has a high percentage of ND people, we don't see them as odd as WE ARE LIKE THEM. Yes, learning how to interact with normal people can help, but this is masking and it is mentally exhausting. What I love about working in software is the lack of need to mask, and be able to just be the strange guy in the corner. Real talk, I was diagnosed with Autism and the highest support needs, you don't get more autistic than me (whatever that means). Also, I have had a successful career as a CTO in startups. Just every 10 years I burn out and fall apart, I then put the mask back on and compound the damage to deliver some more cool shit.
I think technical interview problems should closely resemble the problems you would face while working at that company. Wtf would I need to do leetcode for a job that only requires CSS, for instance? I also think that the interviewer should be engaged in the interview, give clear and concise instructions, trying to help guide the candidate so they can succeed and not checking twitter or Instagram. The issue isn't so much leetcode. The problem is that a large number companies, or interviewers at those companies, do not know how to properly interview.
It may not seem like extreme pressure to you because you're used to public speaking. But I'm used to solving problems in silence (or with music at the office to drown out the chatter). Having to solve it while narrating and being watched is quite difficult for me, especially if I hit a big obstacle.
Protip: everything is relative and competitive. 90%+ of programmers all say this, so it is a constant and comes out in the wash in interviews. Others worked on their problem solving to have it as accessible knowledge even when stressed, and you didn't. And "no hire". I'm very confused by people on the "algo interviews are bad" train. Is there any other job where there are legitimately $200k/yr+ starting offers for a couple hours of problems, that most of which are known in advance and study-able? You DON'T WANT whatever would replace these interviews. Algo interviews can be reduced to like ~15 types of problems, study-able in a week (if you have the prerequisite knowledge), and you can get interviewing for 6-figure starting jobs as a 22 year old in no time. WHAT OTHER JOB CAN DO THAT? You want the russian roulette of any company just pulling whatever it may be out of their magic hat instead? Yes, it's stressful. You're interviewing for 6 figures+, potentially as early as in your early 20s.
@@godmodeon666 The alternatives are to be given to be given a practical task with realistic tools that you'll be using or given an algorithm you can implement alone and then present. Both seem better from my point of view. I know some disagree. I'm just stating what advantages me. In any case, what bothers me is when people say it's easy. I'm sure it is for some, but not for me. Also, when it comes to salaries, things aren't so rosy in places other than the USA. Here in the UK you're very lucky if you ever make it to 100k as a senior engineer.
I love how Prime thinks he doesn't gate keep but he's right now doing that. There's a lot of pressure interviewing, because your livelihood depends on it, also you just don't know how introverted somebody can be. I think is funny we see these extroverted figures in social media thinking they're normal, but no, a programmer that can do TH-cam is not the "normal", obviously somebody who streams every day in front of thousands of people don't get any pressure when whiteboarding... You don't say...
While I do agree with you, the social aspect is a very important factor in your ability as a software developer. Just being able to solve algorithm-style problems is already not a good indicator of how you'll do as an employee, but if you can barely communicate in an interview, that is a pretty big red flag. Software development, believe it or not, requires the ability to socialize with other people, asking questions and communicating your thoughts and ideas coherently. It will sometimes be in high-pressure situations as well. I get the struggle because I've been there (and will be interviewing again soon) so I'm not just being an ass. I'm just saying, it's not something that goes away even after getting a job, and you should work on that aspect of yourself if you're struggling on soft skills.
@@josh1234567892 I know somebody who I interviewed and couldn't do fizzbuzz, yet I knew he was a good programmer, not even 1 year later he did the whole product of a startup (and a hardware one) as a solo dev, became CTO ended up hiring me a couple of years after. When he failed fizzbuzz he wasn't inexperienced, it was just a painful experience to him because we as interviewers didn't do our job and made him feel uncomfortable.
He literally said this is a skill you get better at by doing it more. Communication skills are essential in Software Development. You can't just "Sowwy, I'm an intwowert uwu" out of it.
@@josh1234567892 on the job stress is nowhere close to interview stress. Employees are never judged as harshly or their work put under such an intense microscope (in real time) as during an interview. Interviews do not in any way represent a realistic work scenario. The closest interview type that does is system design, and even then it's often completely unrelated to the actual job in both context and complexity.
Also my problem with algorithms challenges is that they are often very time constrained which adds additional pressure / stress which you will never experience on a job.
I've had interviews where it was 2 leetcode problems within 30 minutes which is very reasonable. But I've also had interviews with 5 leetcode problems in that same time frame. And you have to have memorized it in order to get it right. This was when the number of applicants is high like it is now. Some bad non algorithm problems I had was one that gave you 10 minutes to build a function but the description of the problem was 5 pages long and you had to use some custom api described in the description Sometimes I'll get blind sided by questions that are predominantly regex focused and I don't memorize that to a great extent. If you leave the screen it throws a warning and complains lol The worst I had was 4 problems and making a form in react with unit tests for the all the inputs and a progress bar. There was absolutely no time.
So what if this "problem" required you to do triple axels (ice-skating) would you still do it? Sorry man I see your point and I do also thing that for some positions you might need to be good at solving algorithms but tbh I 've seen many developers that were great additions in teams without having to test their algorithm solving power. I really believe it's a matter of technical + soft skills something that it is not easy to find out through this type of interviews. On the other hand the interviewers unfortunately need some kind of a metric so they can be able to finally decide who to pick amongst all these many candidates, right? Edit: Man while watching this I was really thinking I wouldn't want you to be my interviewer!!! 😅😅😅
Something to keep in mind is that a good interviewer wants to know that map of your abilities. That means they want to work towards the edges of what you can do, so after a good interview you should feel like you’ve been a bit challenged, and if you don’t feel that way it should make you question whether you want to work there in the first place. But that is only loosely correlated with hiring. Sometimes you need cheaper junior people. Sometimes the candidate was more than good enough, but you wouldn’t mind being part of the team that hired someone really amazing. You can’t figure that out by stopping halfway there.
Ehhh the testing environment would really effect the results. Like if u have lots of distractions it would really fuck them up more than most. That being said would be easier for me to explain my thought process as I am working because I have add so... Basicly there is nuance here. More nuance than fits into 1 line of the article and more nuance than prime gave us in his hot take.
Writing code snippets to solve small, well defined problems in a performant and readable way is one of the most enjoyable aspects of programming. :) Interview or not.
Yeah, not to me. To me it's a waiste of time when I can actually be building something in my free time. Building software is the most enjoyable part of writing code to me. Not solving little problems that ultimately amount a hill of beans and all for a little dopamine hit that makes me feel good about myself. There is a point of diminishing returns when it comes to how useful studying DS&A is. And you reach that point well before the point you are ready for interviews. To me, this explains why so many juniors are so clueless when it comes to actually building software. It takes them years on the job to grasp the skills it takes to design and develop. For me, I instantly accelerated to a point where I was near senior level in 3 years. But I spent 5 years during schooling working on toy projects. I didn't even know what leetcode was until I hit the interview scene. Of course I had DS&A courses, but those only cover trivial stuff. It is vital to have DS&A in your wheelhouse. I'm not denying that. Especially understanding Big-O. But the questions they ask these days require you to have a master's in leetcode, essentially. They try to present them like they are problems you would face on the job, but it's just flattly not true.
And shouldn’t i be able to use all the tools i would be able to use when solving and writing code. Memorizing an algorithm just shows i memorized an algorithm, thats all.
Algorithms solving doesn't signal general development capability; it is only a likely correlated skill because it's unlikely someone will have learned to write the O(N log N) sorting algorithms if they can't write code at all. However, directly speaking solving algorithms like that only establishes a floor. A not-uncommon occurrence is for those who are more educated in math or applied math instead of computer science or software engineering; those folks tend to have weak programming and worse general development ability, and usually write code that solves complex, but small problems, with simpler and smaller data (typically numerical and sets). That is a small fraction of general development skills. At best, they also have the ability to recognize a problem described or defined in natural language (English), and map it to a math or computer science model and problem, and solve it. That part is good and very important, but still a fraction.
I get your point with script kiddies that look things up. But that's far better than no script kiddies that can't find things up. Self learning is a tough, worth skill.
There's a guy who's a student in my uni's CS department. He spends so much of his time solving LeetCode questions and preparing for those interviews and he's become quite good and knowledgeable in them. However, that's where the pros for him stops. He has no external projects that he's worked on and his general coding skills are lacking. At a hackathon I was at he left his partner halfway through and started grinding out those interview questions. Yes, I 100% agree that algorithmic coding interview questions are a great test, but there's also a point where, as you noted, people need to also do more. In his case, algo questions is all he knows. If it's not writing an algorithm, he doesn't know how to do it and it's sad to think the industry has him so obsessed with trying to pass those coding interview questions that he's lost sight of all the other things that he needs to do to be a good dev.
That seems like a character issue rather than a skill issue. In light of that, I don’t think the case of that CS student tells us anything about the correlation between knowing algorithms and being a good SWE.
Exact same code @8:51 in Free code camp , apparently written by some guy "Joel Olawanle". It is probably first written in Stack Overflow and used by GPT learning data. "JavaScript quicksort" Asked 12 years, 6 months ago
I'm 50/50 on this vid but additionally there was one part of this video that kinda felt like veiled elitism. One kind of dev, the ones that can pass algo tests, are the only ones that did anything "worth while". i don't feel like i'm one of those devs personally, i have had bad experiences with algo tests usually, never refuse but never goes well for me. my success in interviews, i believe, has always been due to breadth of knowledge, i'm more of a pragmatic, cost effective builder of apps/services. I make sure what I build is stable, cheap and boring. Maybe the things I build aren't "worth while"..... maybe software engineering isn't the thing i do anything thats worth while. maybe i won't ever do anything worth while... (depression)
@@darylphuah Both are great open ended questions. Just in my personal anecdotal experience, I can usually loose up the atmosphere better and also better get a feeling of a level of the challenges someone was solving from discussing what we hate about technologies we use every day :) But it probably is strongly subjective and cultural thing (I am from Czech Republic).
@@glubothemad oh, I wasn't saying yours was bad... just that I never considered using the other end of the spectrum. Its a great question, and I would definitely use it moving forward, a lot can be gleaned from bad experience as much as good ones.
The problem with these interviews is the interviewers. I did my algo for Amazon in Rust and he couldn't read the code so I was failed lol, but since then I started my own project and im at 200k lines of rust so suck on that Amazon
6:45 Problem solving is like 100% simply applying known patterns to a particular Problem. The sentence in the article is just completely wrong. Pattern recognition is the key to solving problems.
Just had one, terrible. You can't expect someone to invent a way to clear (zero out) every element in an array memory in ideally near constant time on a shitty virtual doodleboard in 30 minutes. Maybe I'm dumb but this sort of stuff is a huge waste of time during an interview and not very useful to test overall abilities. Even if you have a clever idea of solving something that hasn't been solved for decades it it's difficult to illustrate let alone implement.
What you would want is someone solving your business problem, not solving his employment problem. The real problem is not the time wasted on the candidate side, but rather the resulting inefficiency on the job. If candidates could use that time to study the business problem all would be better off.
10:00 Broad terms are broad by design. Yeah, sometimes people use this term as a catch-all rhetorical deflection tool, but it is still a useful categorical term for people trying to explain their general bucket of issues without slowing down the conversation to specify which issues exactly they are dealing with. 10:55 "Everything is on a spectrum." Yep!
For 90% of jobs out there, I would say almost any person with some basic algorithmic reasoning developed can perform well. The % of people that is really building new things is almost negligible compared with the number of total devs. Indeed, with the help of AI, those helper functions that you may typically need when doing some business logic can now be done with the help of the AI. I find these things more "romantic" than "a real requirement", in a similar fashion as someone who thinks learning C (and/or many university courses you will never ever need unless you end up in that 1% of jobs) is a must for being a developer. I can understand FANG companies make those interviews, but not the remaining 99% of companies that just copy what others do to feel "oh, we are cool too".
20:25 My current employer does take-homes. Then two interviews: one with the hiring manager (~one hour) and one technical (~hour and a half). Much preferred it over my Amazon interview process which was an online timed test followed by 6.5 hours straight of interviewing.
By schema builder do you mean like; some sort of json encode/decode because I think that is the easiest way to create object? or do you mean something like a function that takes an object and a new property, and you need to insert that new property to the object returns the new object with that property? I think asking someone to make some sort of schema builder is a better way to test someone's programming knowledge or experience. But technically this is not an algorithmic interview. This is more like knowing and implementing DS So my take is 1.) I think there is a disconnect between what you are thinking and the blogger. The blogger is more like don't let someone knowledge or lack of knowledge about algorithms becomes the deciding factor to hire someone (example if someone don't know how to implement Dijkstra's algorithm). Instead, it should be something they learn on their free time or something to improve one's self. 2.) A) Is it okay to ask for algorithmic style interview. I would say Yes. But limit it to what will actually be used. B.) A person's knowledge about DS and its inner working are more important in most cases. C.) Other technical questions. (example asking someone if they can implement a recursive function based on a changing condition) PS. I'm always thinking about it, but I just confirmed today that quicksort is in-place sorting algo.
Algorithms interview are like assessing in chess how good is my Alekhin defense (which I never played, never will) when I'm playing Sicilian and French. This is not development, is math.
Most of time i feel that all that leetcode stuff is just coding brain teasers (like sudoku, but with code). A lot of time it's just you know or you had the luck of thinking the right thing or you fail. There's no step by step thinking, no refactoring possible, because once the light bulb lights, it's just applying what you remember. If you think the wrong thing you have to throw everything away to do it again.
It is more like if u remember your DSA lecture from college / university. I haven't been using DSA's in raw style like in over 10 years after I left university and first few leetcode problems gave me headache because You simply forget this shit over years if u are not forced to use them.
I've tried to spend time leet coding. But I hate doing it, and im not good at it. But I've been successfully employed in fortune 100s for 8 years. So from my personal experience I just dont think its important.
Nothing is more terrifying then…being a person who hates code interviews and then having to give then out multiple times on a weekly 😅 I then later, froze up in a code interview myself. Some stupid math thing that caught me off guard. It was useless. My brian just….died. Solved it after 45m but was supposed to be 20m. Just pick a test thats inline with the job man
The great challenge for algorithm-centric interviews is that too-specific questions can make them a lottery. "Describe Bresenham's circle-drawing algorithm"
Even CRUD does deal with algos when you get to SQL, they just aren't the ones you learn in a standard algorithms class that glosses over Btrees despite them being able to replace any other data structure and which are the most critical data structure for the performance (ignoring networking) of almost any real world web application
I don't now about this Prime guy as a candidate. He seems unwilling to dive deep into linux audio drivers that will provide him a fundamentally more semantically correct streaming experience, calling the mere concept "crazy". His aversion runs so deep that he's willing to be named and shamed over it in front of an audience of tens of thousands. Honestly seems a little childish to me.
If you aren't building tools/libraries, it's almost useless precisely because those efforts abstracted the need for common cases. Most java devs are completely ignorant of how threading works despite being a core language feature, they just know not to create new ones in a servlet. Thats all the business needs the vast majority of the time so ime there's usually 1-2 guys that actually understand this 'difficult' CS stuff. Or C) there are plenty of good jobs that interview appropriately and its less time and effort to just apply to those. IME, a lot of the l33tcoders have chips on their shoulders. YMMV.
Prime, when you're at a point like 10:48, it's time to take a step back. Our condition is already not getting taken seriously by a large portion of society. Those of us for whom ADHD is closely tied to a wrecked life don't need you to dance on the debris as well.
I think it is good to ask about algorithms in interviews. The only way you're getting any medium to hard algorithms question right with minimal help in a short amount of time is if you've seen it before. When you do algorithms in university, you get a week to do the problems with office hours. Interviewers expect you to do the same kinds of problems in half an hour or they go back and tell their boss you don't know basic programming. No matter how much you talk through the problem and explain your process, if you don't reach the answer that's a fail. So now there's a rush for everyone to memorize as many leetcode solutions as possible so that if you're asked something similar you can spit up the answer. So now we're not even testing algorithms, just if you do leetcode in your spare time. An interview style I like better is just asking the candidate to describe technical challenges in their last job, and judging them by how much detail they're able to go into, in addition to whiteboard coding
I think the problem with your quicksort example is that you provided just one argument and typed function output to be number[]. I think it misleads copilot to thinking that you want to return new array. When I wrote "function quicksort(arr: number[], start = 0," it suggested the correct, in-place implementation, with separate partition function etc. Still, copilot does some stupid things, but I think your example is a bit unfair.
Companies should reconsider the necessity of administering algorithm tests for positions focused on maintaining CRUD APIs. In the Philippines, European clients often demand software engineers to be geniuses, which may not be entirely relevant for web development roles
Most modern languages have standard libraries that implement commons algorithms that are needed in day-to-day programming. In my humble opinion, the study of algorithms and data structures is more computer science than application "coding". However, it is important to note that one definitely needs to be aware of their tradeoffs to make the right decision as to how they should be applied.
Yeah in a world where you get $100k+/year for the job that Prime is talking about, then yes! But your run of the mill $50k/year job should not have these requirements imho.
I'm a react developer and had a very abstract task with a lot of dependencies all over. Made a modified linked list and boom everything went great. So even in the GUI world, it can be good to know a thing or two about known algos.
I'm watching your full algo course on frontend masters right now, and i gotta be honest it has taken me from hating algorithms to enjoying learning about them. I came from the site right now here just to say thanks, really
I'm also a parent and I would prefer to do a take home than doing algo. I can do that in multiple sessions but not the algo. Let's talk about the top 75 algos for interviews in leetcode. How many hours do I need to spend on this? Geez I even saw one algo the answer is a specific pattern only for that case. Talk about a trick question.. I would also say that FAANG problems are algo problems but not every company is that size. Premature optimization is evil so when the code is slow I will cross that bridge when I get there but at my work the database is the bottleneck. I have to spend time doing algo instead of time with my daughter only to pass that part of an interview .
With over two decades of experience, my approach to interviews is grounded in the belief that candidates who exhibit a willingness to learn and grow, even if they answer around 80% of the questions, often surpass those with impeccable answers but adhere strictly to a 9 to 5 mindset. While algorithm questions are valuable, they don't constitute my sole focus. What takes precedence is comprehending a candidate's background and its alignment with our role's prerequisites. By engaging in insightful inquiries and discussions, my aim is to unearth their problem-solving prowess, communication finesse, and cultural harmony within our organization. This method facilitates a holistic evaluation, ensuring that candidates are not merely technically proficient but also adaptable to our team and company dynamics. In my perspective, it is this amalgamation that genuinely characterizes a candidate's potential.
A better way to ask algorithm questions is under which circumstances would you choose or not choose a particular algorithm. Whether you can code it on the spot is not as important as whether you know when to use it. Example: Binary Search is fast, but requires that sorting the structure is trivial, so it's not good when your structure is unsorted and to sort it is quite expensive.
I prefer to ask basic questions to check what they know. I would ask them about design patterns, OOP principles, optimisation problems etc. You don't need to be competent to memorise things, I learn't this the hard way in Uni. One of the best programmers I worked with failed fizz buzz. He got in because he showed he had the ability to learn and didn't just give up.
Currently a java developer, been a java developer for 8 years, just laid off once (and not because of performance) and that was 5 years ago, never knew about DS or algorithms in an interview, never touched a leetcode problem to get a job, I've been able to build a strong career just with my knowledge in the languaje and in the J2EE frameworks (spring, struts, jsf, etc) and in every interview i've been asked and tested about that. Nobody can tell that i'm not qualified to be a developer just not for answering algorithms or DS questions. It all depends of what the company needs.
"You practiced algorithmic challenges enough to recognize their patterns and solve them." That's called learning, you learned the algorithm, so you can solve problems the most efficient way
Well, I saw practical example of entropy because that article turns to beginning state without any usable conclusion. It’s literally “let me whine to you what I hate but it’s still the best to continue doing it”.
Algo Interview Questions: Only if it applies to your Business Requirements There is no reason to test a potential employee on merge Sort and B-Trees if your current projects do not use those algorithms
Completely disagree with minute five. My previous job had an insane rhythm. I barely have time to leetcode, small projects to put in github, etc. On the other hand, the insane rythm I had at my pervious job made me build a lot of things. Why should you memorise 50 algorithms for this job? And would you hire someone that creates an algorithm to solve the Rubicks Cube or would hire one that memorised it but can't try and figure out one? I would even go as further to point that maybe.... people are using libraries more than ever because they're too lazy to solve new problems.
Agreed! If the candidate can showcase what he/she has done previously -- and open source contributions make a super big difference here, I would just interview to know the personality. I even wouldn't ask any technical question.
The total proof of Algorithms in interview is BS is that theres a Multibillion Industry on selling the probable Algorithms questions, Im seeing you leetcode, algoexpert the list goes on.
Prime: “Algo interviews show that you’re wise and skilled enough to practice algos for weeks to show that you can learn something hard and won’t fight the system”
Also Prime: “If Google wants to offer L69 but I have to spend two hours on a take-home test, TAKE A HIKE GOOGLE, I got four kids to name and a beautiful wife to defrag!”
And there you see the problem with algo interviews: the devs who can’t be bothered to waste weeks doing leetcode aren’t always stupid or unwise contrarians; sometimes they’re busy experienced people who value their time and would rather spend those leetcode weeks on real-world valuable stuff like learning Go or burning React books.
If memorizing algorithms for coding interviews was a sign of intelligence none of the staff/senior developers would have taken the experimental jab. Sacrificing your DNA and bodily autonomy for "the greater good" is the same way these work 80 hour a week leetcoders think.
Your making a false equivalency.
One of these is a very powerful signal that happens to be the industry standard for decades and also helps you filter more skilled people (even if you don't those specific skills).
@@BenjaminTiessen these are my thoughts. I worked for Rivian and many of my team members took the shots. In a morning SCRUM the manager/product owner (staff level btw) spoke about he just had just took the booster. This was in early December 2021.
@@BenjaminTiessenantivaxx?
@@AryadevChavali nah just anti myo/peri carditis
I dont agree with your last take. I've been a self taught SE working for over a decade, with different tecnologies, PHP, Java, Python, JS, and others. I consider myself more of a generalist dev, or a solutions guy, I dont depend on a specific tool, I know the fundamentals, and can easily use different tools to solve a given problem. So, you're not a script kiddy if you need to lookup something on Google syntax-like, sometimes I forgot basic shit like simple syntax "how to make a loop".
Guys dont forget, the language is just a tool, youre paid to solve problems, that happens in your head not in the language.
^ Top tier take
Just knowing that a particular solution exists is enough IMO. You don't have to know the exact syntax for something like getting a substring from a string if you at least know that it exists and can know where to use it.
As long as you dont claim to be an expert in those languages I agree. Based on what I see on job boards, companies want you to know about 5 different ones with 2 to 3 year exprience which is funny because if you jump around tech you may know more but you never feel super confident in them. I think I might want to attempt getting a job that focuses on one or two languages. The problem with the web is that they ask the world of you. I am looking more towards embedded or Games now the problem is how to get this Magical professional exprience without anybody wanting to hire you? That is the next problem I must tackle.
"I can´t spend time to do a take home"
proceeds to call anyone that don't want to spend time memorizing algos a children.
Yeah terrible take by the Primeagen imho
There is a saying between finance people. We hire math and science guys because you can teach them to do business but you can't do it the other way around. If the candidate is better at memorizing patterns in algorithms (yes, it isn't pure "memory work" like some might like to think), they are good talent and in X years will do better than the stubborn person boasting that they have X years of experience and do things fast simply because they have the muscle memory down, but can't even learn how to algorithms!
LeetCode, like psychometric tests, is relevant criteria when making investment in talent. You either understand why companies do it or you don't.
Can you use the take home in this application to your next one?
yea but the industry's biggest tech companies aren't gatekeeping you over a take home but they will gatekeep you over algo
There's really not that many algorithms, and most are straight forward. He's not telling you to remember how deepMerge is implemented - you should be able to figure that out in an interview. He's telling you to learn how to walk a tree.
I'm gonna be real with you. Experience solving leetcode doesn't make one a great programmer.
But struggling with them indicates ones is definitely not a great programmer. What if the company is solving a different problem than you think they are?
We have a leetcode king on our team and nobody likes refactoring or working on their code. It's nearly impossible to read without going to him and asking because of many-decade-old programming practices like using the smallest variable names possible "to save space" on multiple-hundred gigabyte devices. You will find incredibly complicated algorithms inline in front-end code when a couple method calls from a library could perform nearly identically.
His code performance is often exceptional, but it's incompatible with almost everybody. We just have him write systems that people don't often need to go back into to change.
@@Sammysapphira I can already picture him as an Asian guy with glasses.
@@ghalamat2821dafuq??
@@mindasb Yep. The tests are made to avoid false positives. That’s it.
Throwing me a Leetcode algorithm problem for a web dev position and having the perception that I'm not a good dev because I couldn't remember said algorithm I think is pretty disrespectful to the dev and a waste of the interviewer's time. I think it really depends on the position if the job doesn't really ever use advanced algorithm's like web dev I don't think you are learning much by giving an algo test. Maybe if you don't care if the individual passes it and you want to see their process of thinking through a problem then it could maybe be valuable. Although I think having an assessment where the dev is having to solve a problem they would likely work on for that job is way more valuable to an interviewer and a better experience for the dev applying.
I've had multiple companies only give you 5 to 10 minutes to do the "algorithm" part of the interview. Others give like 45 minutes when the algorithms are difficult. All in all algorithm interview questions are sort of a lottery system. I'll give you an example. "Rotate an image 90 degrees without using any extra memory". You either are familiar with this or you aren't. If you've done it before and you remember the solution, you'll be able to complete it, but I've seen multiple FAANG developers fail this question.
Totally agree, a lot of these challenges require knowing an unintuitive trick and sadly if you dont know the trick, you might get a solution but not an optimal one that the company wants so you likely get rejected
Totally agree, but I would agree hiring base on network is more common and more random than algo. But I see no one mentioning that
Algorithms are useful for low-level systems and for framework builders.
I don't even remember the last time I did a simple sorting algorithm. Because it's not needed in my job. My job is just to use frameworks to translate business requirements into working applications.
We do javascript scrips for an ERP. We use Array.prototype.sort() lol
i honestly see a lot of code that can be optimize by algorithm, like using a lot of loops in an array and spread operator, that can be done with a simple 1 loop.
And those business requirements *are* algorithms. Your working applications are built of algorithms. But these algorithms are high level, big and complex. You cannot ask to "translate business requirements into working applications" in a 40 minutes interview. So the only way to assess if you can do it is to ask you to construct some small and simple algorithm instead, more fit for the time scale of the interview.
@@vitalyl1327 it’s very outdated. most companies don’t have the internal resources to write effective questions that reflect the business logic - because most companies have nfi what their business logic should be. most app development is busywork while business logic is “ironed out”
I've had some really great algo interviews because a good interviewer doesn't care about if you can solve leetcode hard in 10 sec, he cares about your understanding of underlying data structures and your methodology. Being able to present your skills through projects is a plus but just understanding and solving some patterns is a good metric to judge a programmer. Cause what are we if not bug fixers and problem solvers at the end of the day.
I've had those too. Sadly, I didn't interview for good US tech companies. I've interviewed for crappy shop companies that think they should borrow Google questions and look down when you can't solve things quickly. It's weird.
I wouldn't mind grinding algo questions for months if I got a US tech salary but I don't.
Tbh I think we should also look to high level design.
Truth be told a ton of companies could best be investing in learning opportunities and skills growth on the job if knowing 10 bajillion algorithms/frameworks is required, rather than a ping pong table or some shit you're just going to lose social credit rating in management's eyes for having the gall to use anyways.
At minimum dev bootcamps and companies need to communicate better on what it is that they actually need of people to start doing the fucking job.
If THE industry of information systems can't figure this shit out then I'm astounded wider society hasn't collapsed from sheer failure to allocate labour and resources.
I think this is the take I agree the least with in a very long time (I really liked the article).
Thinking that the last paragraph is contradictory "study algorithms in your free time, it will make you a better developer" after saying "there are many ways of figuring out someones skills and suitability for a development job, that are better than checking algorithm knowledge" is beyond silly to me. There are many things that could help you become a better developer (linear algebra, set theory or category theory, reverse engineering software, and so on), but are those skills a good idea to _test for_ in an interview? No! Pretend the article was about reverse engineering instead. Pretend the last paragraph said "practice reverse engineering in your free time, it will make you a better developer", and that interviews consisted that depend on you solving a "crack-me" during the interview. How absurd is that? I'm not an employment interviewer, but if I'd been, I'd want to know how well the candidate is at 1) Communicating their thoughts while dividing a complex problem into manageable pieces 2) What they consider "good" code, maybe ask them how they would refactor something to make it more readable or more efficient (or both) 3) Check their methodology while searching for a bug (do they use the debugger/debug-prints where appropriate? how fast do they locate the broken code? what is their approach to fixing the issue, and is the fix maintainable and robust?) 4) Last, and probably least as well, I'd check that they have a basic grasp on time/space complexity and would use the most suitable data-structures and algorithms for a specific problem (maybe give a scenario, and ask them which algorithm would be best suited).
I'm not saying algorithms aren't important, or that they say nothing about programming skills, but (as the article portrayed quite well in my opinion) they shouldn't take up a majority of an interview.
In my experience it just depends on the interviewer. Maybe that is why people fear them. I had interviews where I was asked to solve rather involved problems and the interviewer was responding to questions, was giving hints to me missing things and leading me along. So I could really demonstrate my skills. And then I had interviews where the interviewer asks me some trivial maybe bit gotcha question on some code snippets and then gives me a complete silent treatment. Some of them I did not immediately catch and see the problem - zero feedback. Some I explained in detail the problem and the solution only to be met with - so you think this code is good or bad? I completed the interview and immediately sent them an email that I am withdrawing my application. Remember when you interview with a company it is a two way street. You are there also to evaluate them and if you have the luxury you can dismiss weak candidate employers.
I really like this idea of formally withdrawing your application when you have a bad experience like this, and to be clear I don't mean a bad experience where you didn't do well - I mean a bad experience that tells you this is not a company I want to work for. I think these companies would improve their hiring practices if they got that kind of feedback more often.
Way to lead by example - props to you sir.
@@x0rn312 that's naive thinking I am afraid. I don't think companies often change their culture due to outside or internal feedback. I know companies that absolutely suck. Have sucked for years and will suck. But they rely on getting low to mid tier talent with high turnover and can make it work long term. Your best option is just to look for red flags early and move on without a care if they improve or not.
So many people don't realise interviews work both ways.
I've feigned ignorance and purposely answered things wrong to see how the interviewer would respond. An interviewer that tries to guide you is a good place to join. Those that try to laud their knowledge over you, avoid like the plague.
well said. i would almost say that you could actually tell them what you found bad about the interview, but it's probably better to not burn bridges
@@x0rn312 not doing well and having a bad experience often go hand in hand
I feel like the problem with leaning too much on algorithms in interviews is that it just becomes a "did you put in the practice time to memorize enough algorithms patterns in typical interview questions" which doesn't really measure any particular ability to program. The problem is the same as the problem with every other heuristic: the moment you let people know what it is, they can game it. It's part of the reason colleges use such complex selection criteria and why TH-cam obfuscates its recommendation algorithm: the moment you tell people what it is, it falls apart, because it's a heuristic and people can always game it.
Algorithms interview type question are a useful proxy for knowledge _if they're not the standard thing everyone does,_ at which point their value becomes greatly diminished and they're no longer testing much except whether you practiced for them.
It's very easy to see if the answer was memorised or invented on spot.
Prime keeps moving the conversation away from the argument that the article is making. The article is saying that algorithmic questions shouldn’t be used in interviews; Prime keeps arguing that candidates should prepare themselves for those interviews.
Edit: well that kind of got cleared up at the end
Edit edit: he’s also betraying a very ignorant understanding of neurodivergence and disability. The idea that there are some people with real disabilities and they suffer a lot and we all need to feel really bad for them and give them special things and everyone else just needs to suck it up and conform to the standards of corporations is bullshit. I would encourage Prime to use some of that hard working rugged individualism and put some effort into educating himself before yelling about people he doesn’t understand on stream.
About the second edit. I think his point is that we don’t male accommodations for people with different. We are told to just “be better”, “make a list”, “use words”, “just like everyone else”
It’s a very modern thing to have a place in the office to deal with sensory overload, for example. And I think prime was referring to that, not that we are less and he is sad we are less, and we need prizes to feel better
Most of the people just grind those subjects 3 months prior to the interview, today it's really clear that tech interviews are a different subject that you have to spend sometime preparing to, and like most of the test that you have to prepare to take, you will forget almost everything less than a month after, dunno to me, tech interviews has gone awry, it's a complex take nowadays ...
"I'd like to see people can walk the walk, and I'd like to see people can talk the talk"
If you then also see people quak the quak you have complete duck-typing achieved.
Top notch comment right there
You are saying that you don't have time for take home, but how is that different to algorithms, where you need to invest also significant time at home to prepare for algorithms?
I have 10 years of professional development experience, and I have built from scratch many critical systems for banks that are still in operation today.
Day to day, I produce in a day what most of my peers spend 1-2 weeks on. I can tell you the exact reason for an error in a failing application by looking at logs in seconds. I can design the entire infrastructure for a large enterprise in a day. I have deep expertise all over the tech ecosystem. Every job I've ever been at, I've gotten a ton of praise and take on leadership roles. I have improved the performance of systems by 1000x.
I have failed every algorithm interview I have ever participated in because I literally have never had to so much as reverse a linked list in all of that time.
Well, for some people it can feel like extreme pressure even if you know you can solve those types of problems. But having someone watching and judging you while doing it, AND expecting to think and talk at the same time make this pretty much impossible for some people. (ASD people will know...)
ASD and ADD, so like 90% of everyone in STEM
My ability to focus on technical things is just lower when talking to people. On my own I can come up with all sorts of solutions for basically any problem, also maximizing performance. Doing it while having people expecting me to talk about it - nope. I'm just not as performant when under social pressure. Navigating interactions requires a part of my focus which has to be diverted from, and if the outcome of interactions is more important, more focus has to be diverted, resulting in worse performance.
See, you have to express your thoughts in words, you have to consider the recipient of the message and the level of their understanding, you have to not look weird, you have to be diplomatic (also consider who you are talking to), you have to watch for other peoples' reactions, you have to balance being proactive and reactive, you have to not offend someone (by being too interrupting), you may not be a pushover and maintain your personality, you have to listen to what others say and process the information. And this dynamic continually changes to which you have to adapt.
What's ASD?
@@EbonySeraphim ASD = Autism Spectrum Disorder
@@EbonySeraphimAsperger's Syndrom Disorder
Knowing algorithms isn't a secret handshake if the company never responds to your application.
Yeah, that just means we don't know the SECRET secret handshake.
5:55 Why anyone would like to work for someone who throws at him irrelevant tasks to just check if he's obedient and determined in getting job?
I think "algorithms in interviews" can mean different things to different people.
There's a spectrum from being able to use basic loops over arrays and hashtables, to being able to solve an unseen leetcode hard in 35 minutes.
The former is reasonable, the latter is not.
I’ve got ASD and ADHD (and didn’t know about either until last year…) After you explained your rant on neurodivergence, I feel like I probably agree with your take for the most part. I do think people can use that word like a cudgel which dilutes any meaning the word has. But at the same time, the outright rant against the use of the word at all made me angry. Sometimes it makes sense to use a generic term instead of getting into what autism (or whatever else) is etc….
Also, as someone with ASD, I don’t think it’s fair to make light of someone thinking and interview is high pressure, bc for me it is. It’s incredibly hard to focus and trust the interviewer. I spend so much mental energy thinking through every little detail and trade off, and the verbosity with which I talk generally is not appreciated or understood in an interview. Also, oftentimes the questions that are asked simply don’t make sense to me bc of how they are asked, and if you don’t get it right away, (in my experience) you get rejected. Things that are hard for everyone are generally just harder for me, not due to any issues with intelligence but issues with processing. Frankly it sucks, and any change to the process that makes it easier for people with a brain like mine is appreciated. It’s not an excuse to not work hard at something, but I also don’t see any issues with being vocal about how the current interview process in our industry is incompatible with certain brains.
I believe its the same for like 99% of everyone to feel that a job interview is about as stressful as being robbed at gunpoint. If you are ever on the other side of things, reading resumes and calling candidates for interviews, you'll have some indication of this by the fact that of the 10% who actually answer their phone 80% of applicants called in for interviews simply never show up to them.
@@homelessrobot I don’t doubt that for a second! It’s beside the point I was trying to make, but I don’t disagree.
omg, as fellpw ASD+ADD this is exactly how i felt every single time how i felt doing a job interview part like 6 months. And basically most oral exams in University. The only time i felt okay was when the other person was visibly neurodivergent too as in the same plane of existence where we just, had a chit chat about various topics and what i knew, what i would, how i understood it etc. even including not being punished for admitting mistakes.
Hell, i finally landed a job by just chatting about technologies, telling them what i did with them whether in school or in free time, what my approach and reasoning was and when i didn't saying stuff like "yea, i heard of that but i never had use case for it, i'd need couple days to learn the weeds of it".
he is angry because when he makes interviews he has no idea what to ask so he asks algorithms because that is the lazy and easy thing to do.
I just had the exact same reaction and wanted to say the exact same things but didn't have the words. Same boat here. Thank you for this comment.
Especially since ASD is often not immediately obvious from the outside - even less so in combination with ADHD - and masking can be quite effective, it really hurts when the outside denies its existence, significance or magnitude. Especially especially when you've suffered for decades doing that exact thing to yourself because it's all you were taught.
Algorithms are cool, but I'm with the blogger on this case. I think this is more of a case of "I had to do it, so let's keep it going."
I forget the study or analysis but pretty sure it was already proven that these types of interviews do not correlate with successful candidates, that's the main thing we should all focus on.
I have worked as a dev at many companies over 30 years. Including a large silicon valley one. I have never once had to deal with DSA in an interview.
You're a lucky guy then. I've had multiple of them in my 5 years of working, interviewing at American and European companies. Passed some, failed others, and have never felt they would relate to the actual job I would do
My experience: it doesn't matter if you're asking directly about alogs that much. It's important how you approach the answer part. If you just wait until the interviewee gets it right or dies from stress, you're doing it wrong. If you're more interested in having them show you their thought process and fluidity in working with a given programming language, that's great. Let them think out loud, see how they react to hints and if they can gauge the efficacy of their own solution. Let them course-correct if they get it wrong - you'll get to see how they debug and how they react to failure. Don't just throw linked lists at them, they won't ever use them.
First, thanks @ThePrimeTime for providing multiple perspectives - both for and against. I love the approach to ask about existing work. That is one of my favorite approaches and usually makes candidates feel comfortable; after all, it's their work. Generically, algorithms in interviews are okay, but not all algorithms are created equal. It wasn't clarified in the discussion, but when I think of algorithms in interviews, it's usually along the lines of "traverse a b-tree in ascending order" or "find the optimal path in a graph". These are important things to know, but I don't find them useful or impressive in interviews. I've interviewed hundreds of people and I'm not interested if you can memorize and recite an algorithm (anymore), which IMHO is a very common occurrence for algorithm-type questions. The biggest problem with such a question isn't the pressure (etc, etc), it's that you need to solve the problem in 30 mins (usually all that's left after the non-coding part) on a whiteboard. Developers don't work on whiteboards. We have keyboards, copy, paste, and the internet. A big portion of the job is finding answers, not memorizing them. I'm far more interested in how someone thinks, which is hard to teach and even harder to change. If you do need to implement a specific algorithm, can you find the answers on your own? Can you spot the difference between the correct implementation of quick sort versus not? Are you capable of problem deconstruction and original thinking? While I empathize with the author and even agree with quite a bit of his assertions, I can't get onboard with the conclusion. Unfortunately, this is the current state of the union in the industry, but I think we can better.
In my 10+ years experience as web developer I never had algorithm questions during interview. So I never had the need to learn about specific algorithms. Maybe it's something I'm missing out.
5+ years, same story
@@bbourbaki Not necessary, that only becomes true when its about tech companies. But not all high-level companies have extensive IT tests yet, globally. Even though they prepare more standardized tests recently. But in my 10+ years, working on the high level as well, no algo's in interviews. I did get dev questions en small tests, but nothing involving algo to much beyond the true basics. I cant say this will still be true in 5 years though.
It’s cool and all but bc of algos in interviews I was stuck without a job for 2 months as a FE Developer with 2 years of experience.
Never ever did I think that not knowing what a hashmap is going to stop me from getting UI-engineering job lol.
I’ve learned basics and it all worked out in the end but I don’t feel that I’m a better programmer from it
Maybe you use a higher level language because in low level languages like c, c++...
learning how hashmaps works and when to use them will make big difference in your coding style
@@abdelkrim6317 c and c++ are not low level IMO
@@abdelkrim6317 I definitely agree that if data structures were a daily part of my job that knowing them would be a huge boost to my carreer and my productivity. It's just that it's counterintuitive and very frustrating getting interview rejections only because one doesn't really know nor remembers these things when they're not the part of their role in commercial development.
I'm still kinda struggling to understand why would algos and structures should be used in an interview for a position that never uses them.
Use should use more c++ and rust when you're messing with CSS and figma.
@@stevenismart assembly works better
Most devs never build data structures. Should they? Maybe. But most don't. As such asking about data structure specifics IMO has never been a representation of a persons dev abilities. This is the same as the general quizes. I think it is better to ask general algo efficiency questions. For instance I ask why linked lists used to be a reasonable choice in the 80's/90's but not so much today. It's a good open ended question that can show me if they understand the hardware and how software interacts with hardware. As well as their ability to maneuver in a space they may have little experience.
Curious: as someone born in 99, why were linked lists better in the 90s compared to now?
@@boscodomingoas cache lines became longer, cache coherency became more important. Linked lists tend to lead to your data being spread across more cache lines. While linked lists can still be better in some scenarios, contiguous arrays are faster now more than they used to be because the larger cache lines benefit arrays more. You can still construct a use pattern that makes linked lists faster, but it is more often the case that the increased cost of something like deleting a middle element in an array is worth it because of the improved cache performance of iteration.
Note that there are many more advanced data structures that can maintain some of the cache performance of arrays with some of the features of linked lists. Some fun ones to look into are skip lists and colony (being proposed for c++).
Kind of on the fence here... Crux of the point being, whatever "deep ish" we're talking about, either a) someone WAY BETTER than me has already solved it and/or b) it's WAY ABOVE my skill set. So, if stuff is at "that level" I'm just the wrong candidate for that job no matter what...
Practical example base on an internship i did a few years back, i can't write any paper in Arxiv regarding ML or come up with the corresponding models, i can't write Python/Tensorflow/Keras from scratch and my high school math surely isn't up to writing gradient descent. But none of that stands in the way of being capable of bringing it all together and pushing out a prototype that met the client requirements.
Just because you can't make an internal combustion engine doesn't mean you can't drive a car, and just because you can doesn't make you a good driver. Horses for courses...
11:59 Here is an interesting take - literally you are advocating people learning to mask. Our industry has a high percentage of ND people, we don't see them as odd as WE ARE LIKE THEM. Yes, learning how to interact with normal people can help, but this is masking and it is mentally exhausting. What I love about working in software is the lack of need to mask, and be able to just be the strange guy in the corner. Real talk, I was diagnosed with Autism and the highest support needs, you don't get more autistic than me (whatever that means). Also, I have had a successful career as a CTO in startups. Just every 10 years I burn out and fall apart, I then put the mask back on and compound the damage to deliver some more cool shit.
I think technical interview problems should closely resemble the problems you would face while working at that company. Wtf would I need to do leetcode for a job that only requires CSS, for instance? I also think that the interviewer should be engaged in the interview, give clear and concise instructions, trying to help guide the candidate so they can succeed and not checking twitter or Instagram. The issue isn't so much leetcode. The problem is that a large number companies, or interviewers at those companies, do not know how to properly interview.
It may not seem like extreme pressure to you because you're used to public speaking. But I'm used to solving problems in silence (or with music at the office to drown out the chatter). Having to solve it while narrating and being watched is quite difficult for me, especially if I hit a big obstacle.
Protip: everything is relative and competitive.
90%+ of programmers all say this, so it is a constant and comes out in the wash in interviews. Others worked on their problem solving to have it as accessible knowledge even when stressed, and you didn't. And "no hire".
I'm very confused by people on the "algo interviews are bad" train. Is there any other job where there are legitimately $200k/yr+ starting offers for a couple hours of problems, that most of which are known in advance and study-able? You DON'T WANT whatever would replace these interviews. Algo interviews can be reduced to like ~15 types of problems, study-able in a week (if you have the prerequisite knowledge), and you can get interviewing for 6-figure starting jobs as a 22 year old in no time. WHAT OTHER JOB CAN DO THAT?
You want the russian roulette of any company just pulling whatever it may be out of their magic hat instead?
Yes, it's stressful. You're interviewing for 6 figures+, potentially as early as in your early 20s.
@@godmodeon666 The alternatives are to be given to be given a practical task with realistic tools that you'll be using or given an algorithm you can implement alone and then present. Both seem better from my point of view. I know some disagree. I'm just stating what advantages me.
In any case, what bothers me is when people say it's easy. I'm sure it is for some, but not for me.
Also, when it comes to salaries, things aren't so rosy in places other than the USA. Here in the UK you're very lucky if you ever make it to 100k as a senior engineer.
I love how Prime thinks he doesn't gate keep but he's right now doing that.
There's a lot of pressure interviewing, because your livelihood depends on it, also you just don't know how introverted somebody can be. I think is funny we see these extroverted figures in social media thinking they're normal, but no, a programmer that can do TH-cam is not the "normal", obviously somebody who streams every day in front of thousands of people don't get any pressure when whiteboarding... You don't say...
While I do agree with you, the social aspect is a very important factor in your ability as a software developer.
Just being able to solve algorithm-style problems is already not a good indicator of how you'll do as an employee, but if you can barely communicate in an interview, that is a pretty big red flag. Software development, believe it or not, requires the ability to socialize with other people, asking questions and communicating your thoughts and ideas coherently. It will sometimes be in high-pressure situations as well.
I get the struggle because I've been there (and will be interviewing again soon) so I'm not just being an ass. I'm just saying, it's not something that goes away even after getting a job, and you should work on that aspect of yourself if you're struggling on soft skills.
@@josh1234567892 I know somebody who I interviewed and couldn't do fizzbuzz, yet I knew he was a good programmer, not even 1 year later he did the whole product of a startup (and a hardware one) as a solo dev, became CTO ended up hiring me a couple of years after.
When he failed fizzbuzz he wasn't inexperienced, it was just a painful experience to him because we as interviewers didn't do our job and made him feel uncomfortable.
He literally said this is a skill you get better at by doing it more. Communication skills are essential in Software Development. You can't just "Sowwy, I'm an intwowert uwu" out of it.
@@josh1234567892 on the job stress is nowhere close to interview stress. Employees are never judged as harshly or their work put under such an intense microscope (in real time) as during an interview.
Interviews do not in any way represent a realistic work scenario. The closest interview type that does is system design, and even then it's often completely unrelated to the actual job in both context and complexity.
I think it didn't help, we asked him something he, obviously, knew how to do.
Also my problem with algorithms challenges is that they are often very time constrained which adds additional pressure / stress which you will never experience on a job.
mfw jobs don't have deadlines irl 👁👄👁
I've had interviews where it was 2 leetcode problems within 30 minutes which is very reasonable.
But I've also had interviews with 5 leetcode problems in that same time frame. And you have to have memorized it in order to get it right. This was when the number of applicants is high like it is now.
Some bad non algorithm problems I had was one that gave you 10 minutes to build a function but the description of the problem was 5 pages long and you had to use some custom api described in the description
Sometimes I'll get blind sided by questions that are predominantly regex focused and I don't memorize that to a great extent. If you leave the screen it throws a warning and complains lol
The worst I had was 4 problems and making a form in react with unit tests for the all the inputs and a progress bar. There was absolutely no time.
agreed. deadlines on the job pretty much never that time constrained
So what if this "problem" required you to do triple axels (ice-skating) would you still do it? Sorry man I see your point and I do also thing that for some positions you might need to be good at solving algorithms but tbh I 've seen many developers that were great additions in teams without having to test their algorithm solving power. I really believe it's a matter of technical + soft skills something that it is not easy to find out through this type of interviews.
On the other hand the interviewers unfortunately need some kind of a metric so they can be able to finally decide who to pick amongst all these many candidates, right?
Edit: Man while watching this I was really thinking I wouldn't want you to be my interviewer!!! 😅😅😅
Something to keep in mind is that a good interviewer wants to know that map of your abilities. That means they want to work towards the edges of what you can do, so after a good interview you should feel like you’ve been a bit challenged, and if you don’t feel that way it should make you question whether you want to work there in the first place. But that is only loosely correlated with hiring. Sometimes you need cheaper junior people. Sometimes the candidate was more than good enough, but you wouldn’t mind being part of the team that hired someone really amazing. You can’t figure that out by stopping halfway there.
ADHD doesn't need "special considerations". They need to be understood so they can be become extremely helpful. Not all people are wired the same
Ehhh the testing environment would really effect the results. Like if u have lots of distractions it would really fuck them up more than most.
That being said would be easier for me to explain my thought process as I am working because I have add so...
Basicly there is nuance here. More nuance than fits into 1 line of the article and more nuance than prime gave us in his hot take.
"If you are just making React shit, you are not building anything" - a-gen.
Writing code snippets to solve small, well defined problems in a performant and readable way is one of the most enjoyable aspects of programming. :) Interview or not.
"one of the most enjoyable things in programming..."
To you. :)
Yeah, not to me. To me it's a waiste of time when I can actually be building something in my free time. Building software is the most enjoyable part of writing code to me. Not solving little problems that ultimately amount a hill of beans and all for a little dopamine hit that makes me feel good about myself.
There is a point of diminishing returns when it comes to how useful studying DS&A is. And you reach that point well before the point you are ready for interviews.
To me, this explains why so many juniors are so clueless when it comes to actually building software. It takes them years on the job to grasp the skills it takes to design and develop.
For me, I instantly accelerated to a point where I was near senior level in 3 years. But I spent 5 years during schooling working on toy projects. I didn't even know what leetcode was until I hit the interview scene. Of course I had DS&A courses, but those only cover trivial stuff.
It is vital to have DS&A in your wheelhouse. I'm not denying that. Especially understanding Big-O. But the questions they ask these days require you to have a master's in leetcode, essentially. They try to present them like they are problems you would face on the job, but it's just flattly not true.
...or just use a library for that and not reinvent the wheel? chances are, your wheel will be shitty.
And shouldn’t i be able to use all the tools i would be able to use when solving and writing code. Memorizing an algorithm just shows i memorized an algorithm, thats all.
@@MyriadColorsCM well enjoyment is subjective :)
Algorithms solving doesn't signal general development capability; it is only a likely correlated skill because it's unlikely someone will have learned to write the O(N log N) sorting algorithms if they can't write code at all. However, directly speaking solving algorithms like that only establishes a floor. A not-uncommon occurrence is for those who are more educated in math or applied math instead of computer science or software engineering; those folks tend to have weak programming and worse general development ability, and usually write code that solves complex, but small problems, with simpler and smaller data (typically numerical and sets). That is a small fraction of general development skills. At best, they also have the ability to recognize a problem described or defined in natural language (English), and map it to a math or computer science model and problem, and solve it. That part is good and very important, but still a fraction.
I get your point with script kiddies that look things up. But that's far better than no script kiddies that can't find things up. Self learning is a tough, worth skill.
There's a guy who's a student in my uni's CS department. He spends so much of his time solving LeetCode questions and preparing for those interviews and he's become quite good and knowledgeable in them. However, that's where the pros for him stops. He has no external projects that he's worked on and his general coding skills are lacking. At a hackathon I was at he left his partner halfway through and started grinding out those interview questions.
Yes, I 100% agree that algorithmic coding interview questions are a great test, but there's also a point where, as you noted, people need to also do more. In his case, algo questions is all he knows. If it's not writing an algorithm, he doesn't know how to do it and it's sad to think the industry has him so obsessed with trying to pass those coding interview questions that he's lost sight of all the other things that he needs to do to be a good dev.
That seems like a character issue rather than a skill issue. In light of that, I don’t think the case of that CS student tells us anything about the correlation between knowing algorithms and being a good SWE.
As someone with autism... yes, it's extreme pressure. I get by, I can do an interview. But it's waaaaay harder than it needs to be.
Exact same code @8:51 in Free code camp , apparently written by some guy "Joel Olawanle".
It is probably first written in Stack Overflow and used by GPT learning data.
"JavaScript quicksort"
Asked 12 years, 6 months ago
I'm 50/50 on this vid but additionally there was one part of this video that kinda felt like veiled elitism.
One kind of dev, the ones that can pass algo tests, are the only ones that did anything "worth while".
i don't feel like i'm one of those devs personally, i have had bad experiences with algo tests usually, never refuse but never goes well for me.
my success in interviews, i believe, has always been due to breadth of knowledge, i'm more of a pragmatic, cost effective builder of apps/services. I make sure what I build is stable, cheap and boring.
Maybe the things I build aren't "worth while".....
maybe software engineering isn't the thing i do anything thats worth while.
maybe i won't ever do anything worth while...
(depression)
My personal favorite interview question as an interviewer is “what was something that made you mad in your work” :)
wow, mine's on the other end of the spectrum. I ask them what's their proudest moment
@@darylphuah Both are great open ended questions. Just in my personal anecdotal experience, I can usually loose up the atmosphere better and also better get a feeling of a level of the challenges someone was solving from discussing what we hate about technologies we use every day :)
But it probably is strongly subjective and cultural thing (I am from Czech Republic).
@@glubothemad oh, I wasn't saying yours was bad... just that I never considered using the other end of the spectrum. Its a great question, and I would definitely use it moving forward, a lot can be gleaned from bad experience as much as good ones.
The problem with these interviews is the interviewers. I did my algo for Amazon in Rust and he couldn't read the code so I was failed lol, but since then I started my own project and im at 200k lines of rust so suck on that Amazon
6:45 Problem solving is like 100% simply applying known patterns to a particular Problem. The sentence in the article is just completely wrong. Pattern recognition is the key to solving problems.
Alright just to throw this out there...this guy has a full 9-hour course on Algorithms!
Can somebody explain what's wrong with copilot's quicksort? Is it the fact that it kept pushing onto new arrays instead of swapping values?
Just had one, terrible. You can't expect someone to invent a way to clear (zero out) every element in an array memory in ideally near constant time on a shitty virtual doodleboard in 30 minutes. Maybe I'm dumb but this sort of stuff is a huge waste of time during an interview and not very useful to test overall abilities. Even if you have a clever idea of solving something that hasn't been solved for decades it it's difficult to illustrate let alone implement.
survivorship bias...
100%
"They're just litterally script kiddies that look things up"
Guilty as charged, lol.
What you would want is someone solving your business problem, not solving his employment problem. The real problem is not the time wasted on the candidate side, but rather the resulting inefficiency on the job.
If candidates could use that time to study the business problem all would be better off.
10:00 Broad terms are broad by design. Yeah, sometimes people use this term as a catch-all rhetorical deflection tool, but it is still a useful categorical term for people trying to explain their general bucket of issues without slowing down the conversation to specify which issues exactly they are dealing with.
10:55 "Everything is on a spectrum." Yep!
For 90% of jobs out there, I would say almost any person with some basic algorithmic reasoning developed can perform well. The % of people that is really building new things is almost negligible compared with the number of total devs. Indeed, with the help of AI, those helper functions that you may typically need when doing some business logic can now be done with the help of the AI. I find these things more "romantic" than "a real requirement", in a similar fashion as someone who thinks learning C (and/or many university courses you will never ever need unless you end up in that 1% of jobs) is a must for being a developer. I can understand FANG companies make those interviews, but not the remaining 99% of companies that just copy what others do to feel "oh, we are cool too".
20:25 My current employer does take-homes. Then two interviews: one with the hiring manager (~one hour) and one technical (~hour and a half). Much preferred it over my Amazon interview process which was an online timed test followed by 6.5 hours straight of interviewing.
By schema builder do you mean like;
some sort of json encode/decode because I think that is the easiest way to create object?
or do you mean something like a function that takes an object and a new property, and you need to insert that new property to the object returns the new object with that property?
I think asking someone to make some sort of schema builder is a better way to test someone's programming knowledge or experience. But technically this is not an algorithmic interview.
This is more like knowing and implementing DS
So my take is
1.) I think there is a disconnect between what you are thinking and the blogger. The blogger is more like don't let someone knowledge or lack of knowledge about algorithms becomes the deciding factor to hire someone (example if someone don't know how to implement Dijkstra's algorithm). Instead, it should be something they learn on their free time or something to improve one's self.
2.) A) Is it okay to ask for algorithmic style interview. I would say Yes. But limit it to what will actually be used.
B.) A person's knowledge about DS and its inner working are more important in most cases.
C.) Other technical questions. (example asking someone if they can implement a recursive function based on a changing condition)
PS. I'm always thinking about it, but I just confirmed today that quicksort is in-place sorting algo.
Algorithms interview are like assessing in chess how good is my Alekhin defense (which I never played, never will) when I'm playing Sicilian and French. This is not development, is math.
Most of time i feel that all that leetcode stuff is just coding brain teasers (like sudoku, but with code).
A lot of time it's just you know or you had the luck of thinking the right thing or you fail.
There's no step by step thinking, no refactoring possible, because once the light bulb lights, it's just applying what you remember. If you think the wrong thing you have to throw everything away to do it again.
It is more like if u remember your DSA lecture from college / university. I haven't been using DSA's in raw style like in over 10 years after I left university and first few leetcode problems gave me headache because You simply forget this shit over years if u are not forced to use them.
I've tried to spend time leet coding. But I hate doing it, and im not good at it. But I've been successfully employed in fortune 100s for 8 years. So from my personal experience I just dont think its important.
Algorithm questions are just a way for employers to do an IQ test without calling it an IQ test.
Yeah, the IQ test where the stubborn, but dumb are the end result.
IQ test which only tests memory and luck. If you get a question you just solved, you ace the test. That’s a dumb way to hire software engineers.
Nothing is more terrifying then…being a person who hates code interviews and then having to give then out multiple times on a weekly 😅
I then later, froze up in a code interview myself. Some stupid math thing that caught me off guard. It was useless. My brian just….died. Solved it after 45m but was supposed to be 20m.
Just pick a test thats inline with the job man
The great challenge for algorithm-centric interviews is that too-specific questions can make them a lottery.
"Describe Bresenham's circle-drawing algorithm"
Even CRUD does deal with algos when you get to SQL, they just aren't the ones you learn in a standard algorithms class that glosses over Btrees despite them being able to replace any other data structure and which are the most critical data structure for the performance (ignoring networking) of almost any real world web application
that left pad comment killed me.
Practicing Leetcode is the interview equivalent of studying exam notes before taking a certification exam.
I don't now about this Prime guy as a candidate. He seems unwilling to dive deep into linux audio drivers that will provide him a fundamentally more semantically correct streaming experience, calling the mere concept "crazy". His aversion runs so deep that he's willing to be named and shamed over it in front of an audience of tens of thousands. Honestly seems a little childish to me.
If you aren't building tools/libraries, it's almost useless precisely because those efforts abstracted the need for common cases. Most java devs are completely ignorant of how threading works despite being a core language feature, they just know not to create new ones in a servlet. Thats all the business needs the vast majority of the time so ime there's usually 1-2 guys that actually understand this 'difficult' CS stuff.
Or C) there are plenty of good jobs that interview appropriately and its less time and effort to just apply to those. IME, a lot of the l33tcoders have chips on their shoulders. YMMV.
Prime, when you're at a point like 10:48, it's time to take a step back. Our condition is already not getting taken seriously by a large portion of society. Those of us for whom ADHD is closely tied to a wrecked life don't need you to dance on the debris as well.
9:28 Mocking people for wanting to support NDs
11:10 Some NDs deserve support
?
I think it is good to ask about algorithms in interviews. The only way you're getting any medium to hard algorithms question right with minimal help in a short amount of time is if you've seen it before. When you do algorithms in university, you get a week to do the problems with office hours. Interviewers expect you to do the same kinds of problems in half an hour or they go back and tell their boss you don't know basic programming. No matter how much you talk through the problem and explain your process, if you don't reach the answer that's a fail.
So now there's a rush for everyone to memorize as many leetcode solutions as possible so that if you're asked something similar you can spit up the answer. So now we're not even testing algorithms, just if you do leetcode in your spare time.
An interview style I like better is just asking the candidate to describe technical challenges in their last job, and judging them by how much detail they're able to go into, in addition to whiteboard coding
Yep I favour system design and talking through previous projects. Leetcode doesnt tell me anything about how the guy works in a team
Should there be algorithm questions for a frontend job?
Frankly, there should not be any frontend jobs. Glorified Markov chain can do this crap better than humans anyway.
I think the problem with your quicksort example is that you provided just one argument and typed function output to be number[]. I think it misleads copilot to thinking that you want to return new array. When I wrote "function quicksort(arr: number[], start = 0," it suggested the correct, in-place implementation, with separate partition function etc. Still, copilot does some stupid things, but I think your example is a bit unfair.
Companies should reconsider the necessity of administering algorithm tests for positions focused on maintaining CRUD APIs. In the Philippines, European clients often demand software engineers to be geniuses, which may not be entirely relevant for web development roles
Most modern languages have standard libraries that implement commons algorithms that are needed in day-to-day programming. In my humble opinion, the study of algorithms and data structures is more computer science than application "coding". However, it is important to note that one definitely needs to be aware of their tradeoffs to make the right decision as to how they should be applied.
Yeah in a world where you get $100k+/year for the job that Prime is talking about, then yes! But your run of the mill $50k/year job should not have these requirements imho.
I'm a react developer and had a very abstract task with a lot of dependencies all over. Made a modified linked list and boom everything went great. So even in the GUI world, it can be good to know a thing or two about known algos.
I'm watching your full algo course on frontend masters right now, and i gotta be honest it has taken me from hating algorithms to enjoying learning about them. I came from the site right now here just to say thanks, really
I've been on over 100 interviews but have not once been asked to solve an algorithm problem
Thanks for these videos between this and blazingly fast i have gained so much knowledge
I'm also a parent and I would prefer to do a take home than doing algo. I can do that in multiple sessions but not the algo. Let's talk about the top 75 algos for interviews in leetcode. How many hours do I need to spend on this? Geez I even saw one algo the answer is a specific pattern only for that case. Talk about a trick question.. I would also say that FAANG problems are algo problems but not every company is that size. Premature optimization is evil so when the code is slow I will cross that bridge when I get there but at my work the database is the bottleneck.
I have to spend time doing algo instead of time with my daughter only to pass that part of an interview .
Thanks for the shoutout!
"There's people with autism who struggle in life"
imo interviewers should only quiz me on things I'm actually good at.
Here's some common implementing questions that I've come across interviewing for senior SWE positions:
- Deep Merge
- Schema Builder
- Event Listener/Emitter
- Map, Filter, Reduce
- Pub/Sub
- Signals
- Concurrency: Pipeline, Fan In/Fan Out, Mutex, Semaphore
- CRUD server without dependencies (in Go)
- WebSockets
- Caching
- Rate Limiting
- TDD, DDD
- Banking Logic
- Commerce Logic (Order flow)
I never would have guessed you were socially awkward. You have such a confident mustache!
With over two decades of experience, my approach to interviews is grounded in the belief that candidates who exhibit a willingness to learn and grow, even if they answer around 80% of the questions, often surpass those with impeccable answers but adhere strictly to a 9 to 5 mindset. While algorithm questions are valuable, they don't constitute my sole focus. What takes precedence is comprehending a candidate's background and its alignment with our role's prerequisites. By engaging in insightful inquiries and discussions, my aim is to unearth their problem-solving prowess, communication finesse, and cultural harmony within our organization. This method facilitates a holistic evaluation, ensuring that candidates are not merely technically proficient but also adaptable to our team and company dynamics. In my perspective, it is this amalgamation that genuinely characterizes a candidate's potential.
Wait, audio still doesn't work reliably on Linux? Is there something about audio streams that basically makes it impossible to do properly on Linux?
A better way to ask algorithm questions is under which circumstances would you choose or not choose a particular algorithm. Whether you can code it on the spot is not as important as whether you know when to use it. Example: Binary Search is fast, but requires that sorting the structure is trivial, so it's not good when your structure is unsorted and to sort it is quite expensive.
I prefer to ask basic questions to check what they know. I would ask them about design patterns, OOP principles, optimisation problems etc.
You don't need to be competent to memorise things, I learn't this the hard way in Uni. One of the best programmers I worked with failed fizz buzz. He got in because he showed he had the ability to learn and didn't just give up.
Currently a java developer, been a java developer for 8 years, just laid off once (and not because of performance) and that was 5 years ago, never knew about DS or algorithms in an interview, never touched a leetcode problem to get a job, I've been able to build a strong career just with my knowledge in the languaje and in the J2EE frameworks (spring, struts, jsf, etc) and in every interview i've been asked and tested about that. Nobody can tell that i'm not qualified to be a developer just not for answering algorithms or DS questions. It all depends of what the company needs.
"You practiced algorithmic challenges enough to recognize their patterns and solve them."
That's called learning, you learned the algorithm, so you can solve problems the most efficient way
Well, I saw practical example of entropy because that article turns to beginning state without any usable conclusion. It’s literally “let me whine to you what I hate but it’s still the best to continue doing it”.
Algo Interview Questions:
Only if it applies to your Business Requirements
There is no reason to test a potential employee on merge Sort and B-Trees if your current projects do not use those algorithms
I just simply suck at coding/developing on the spot lol. Sometimes I do great and sometimes I don’t.
I tend to program differently knowing that writes to ssds should probably be done in a sparing manner, or is that a hardware problem? :D
Completely disagree with minute five. My previous job had an insane rhythm. I barely have time to leetcode, small projects to put in github, etc. On the other hand, the insane rythm I had at my pervious job made me build a lot of things. Why should you memorise 50 algorithms for this job? And would you hire someone that creates an algorithm to solve the Rubicks Cube or would hire one that memorised it but can't try and figure out one?
I would even go as further to point that maybe.... people are using libraries more than ever because they're too lazy to solve new problems.
Agreed! If the candidate can showcase what he/she has done previously -- and open source contributions make a super big difference here, I would just interview to know the personality. I even wouldn't ask any technical question.
bought handware that doesn't support linux, thanks for coming in we will get back to you soon
The total proof of Algorithms in interview is BS is that theres a Multibillion Industry on selling the probable Algorithms questions, Im seeing you leetcode, algoexpert the list goes on.
It's a legal IQ test.