My sweatshirt is a Limited Edition code; Crewneck in Mint! Get yours now before March 14th before they're gone forever: store.dftba.com/collections/hello-mayuko/products/code-crewneck-sweatshirt
I prefer the approach I once had at Netflix in lieu of technical interviews. They give you a small project that you have a few days to finish. Then you get to explain your code during the interview. It’s less pressure and is a better way to express your abilities.
The downside of small projects is that they're super time consuming. It can be really disheartening to spend 20+ hours of your free time perfecting the project only to get rejected later on for some reason. And the time spent doing this project is only applicable for that one company. Speaking from personal experience, this is why I really hesitate to do interviews that require a coding project.
@@cumibakar10 I'd only do that for certain companies I really care about. Also, its preferable to spending a hundred hours on leetcode which I hate doing.
A take home 1 day project (after passing a simple technical screen, a leetcode easy question) is the only assessment that seems reasonable. You’ll also get to talk through your solution. If after 10 years at your job, you will fail the very same technical challenge that got you the job (cos 10 years ago, you were aggressively practicing leetcode questions), then it is broken.
if the take home takes longer than two hrs, it's not reasonable, you're just doing unpaid labor. unless they have a VERY good reason. the second point you mentioned, this is the main issue, when the actual job has nothing to do with the technical interview then what was the point of the interview? make the interview actually relevant to actual challenges that you end up facing at work.
Nah.... imagine doing a take home project and then receiving no reply and no feedback from the company because the company went with someone else instead. No thanks. The idea of take home projects comes with good intentions but is really not practical if you are apply to many many companies which is not uncommon in a job search.
@@scythazz eh I mean when Amazon and other Big N companies have experimented with at home assessments and take homes. They're usually reasonable though. Are you really gonna give up the chance at an interview at a big N company because of one hour?
@@m1rac1e Name brand companies of course...... And OP was saying 1 day take home projects. The take home tasks is probably trivial if it only takes an hour. Heck, some harder leetcode question could possibly take one hour to solve. I was thinking it was referring to more large scale projects. I'm only saying if companies gave take home assignments as the norm, it would quickly become infeasible if you apply to multiple companies at once. Also, if take home assignments are to be implemented, then feedback on the assignment must be given even for rejected candidates. You can't expect people to do a take home assessment and then hear nothing back from the company.
This may be only me but...I started treating algorithm style questions more as "understanding my problem" instead of "coming up with a solution". I personally stopped providing solutions (if it is straightforward sure I will write out some code) and try to have a conversation around the problem being asked. I feel when doing this I am able to truly showcase how I tackle problems I have never encountered before.
that's what my friends at Coding Dojo told me. I was so stressed out they told me to understand what the algorithm is about first. plus, I think interviewers will give you credit, not see you as a joke.
this is all nice and true... until you realize you got rejected because you did not figure out how to do the interview question without many prompts from the interviewer. Highly dependent on what kind of company you apply to.
@@scythazz yup i agree it is definitely company specific but I'd take it a step further and say interviewer specific...sometimes you get a good one that is truly looking to see how you think and sometimes you get one that is only following a specific rubric
How has this worked out for you? Is this actually a viable approach? I ask because I feel like I just tried to do that during a screening interview and am not sure how to feel about it. According to the interviewer, my logic seemed to be on the right track, but I legit wrote almost entirely comments saying what I want to do instead of actual code, because time was at a premium. I'm left feeling glad that there was a separate online assessment that proves that I can write actual real code too lol. I'm an electrical engineering student and I've pretty much just been trying to teach myself data structures and algorithms between school and work (school won't let me take a course on the topic, of course). So, that's realistically "nascent" DS+A knowledge that likely can't hang with a typical fresh CS grad. I also have a tendency to get stuck on how to implement what I'm thinking of with pretty much any language's syntax, because I've had to jump between languages so frequently at school and during my internship and it feels like 10 different languages just went through a blender, and I'll find myself using C syntax in Python loops or whatever. So, I figure just writing comments structuring out what I think should be happening as I think through it, and adding some more comments to the code saying what I want the code to do, even if the syntax is off, is probably going to look better than me sitting there humming and hawing over it for the entire interview.
The fundamental issue with a large number of technical interview questions is that they do NOT actually evaluate your skills. They work about as well as asking a Comedian to 'tell a joke' to determine if they are good at stand up comedy. I've taken and given probably more than 100 technical interviews, and they really only serve as a way to weed out people at the low end, not find people at the high end.
Preach! It's so true. Technical interviews are broken. Ridiculous! They're more about memorizing trivia than actual problem-solving. And they definitely don't find the best candidates. Just the ones who are good at jumping through hoops. Like, I recently bombed an interview after a take-home assignment - for a regular e-commerce site. just because of useless trivia questions. This left me a bad taste in my mouth and in my next interview I used an AI assistant and I got my current job because of it. Now I'm a top contributor, according to my manager. Proof that these interviews are useless! edit: the one I used was called interviewhammer, but there are other platforms like it if you search.
Seems like a little survivorship bias as well as missing the point of small companies copying major companies like Google who need a tough system to easily filter out candidates
I can't agree. Technical interviews in their most common current standard form (solving a puzzle in front of a stranger) are massively disadvantaging neurodiverse people and people with anxiety. It's also been shown that women are much more likely to underperform while being watched, even if they could do the same problem when not being watched (see "Does Stress Impact Technical Interview Performance?" by Behroozi et al.). I have a lot more sympathy for small take-home coding projects. I've also had interviews where you look at someone else's code, talk through it and have to find bugs and/or make small changes (which is a more realistic scenario for day-to-day work). On the spot coding should be limited to sanity check stuff that any candidate should be able to do without much difficulty.
So you’d rather waste whole days on a take home assignment instead of a few hours on coding interviews, and do that for every job you apply for? Besides the fact that take home assignments are so easily cheatable.
@@cumibakar10 I already waste days brushing up on things like linked lists and sorting algorithms that I've never needed in my day-to-day life for regular interviews. Most code you'll need in the job will be "cheatable" in that someone else has already done it. The key with the take home assignments is that the candidate should be able to talk through the code and answer questions. If they've "cheated" they won't be able to do this. If they've used other resources to help them reach that solution that is exactly what they will do as a software engineer
@@TheJennifer122 completely agree, I struggle a lot to focus on interview prep stuff (I can force myself to sit down and work for a few hours, but the progress is usually very minimal and i have to re-read the info multiple times) but don't struggle at all when it comes to writing software, solving business problems, and making architecture decisions. And, I get extremely anxious and stressed when I have to do a coding interview with live share which causes me to mix up aspects of different languages (ex: using python style `if:` when writing golang `if {}`) which causes lots of dumb bugs. Take home tests let me focus on the problem without the major stress increase from a coding interview and hours wasted brushing up on my dsa skills/practice problems, then after I've thought about the problem with a clear head, I have no problem explaining my thought process to the interviewer.
Interviewer training is also very important. A good interviewer will adapt to support the most diverse set of candidates they can. No matter what the format, a good interviewer will try to get the most positive signal they can and try to support you in highlighting your strengths.
The problem with leetcode interviews is the fact that you have to prepare for them. Imagine if you had a full time job, had kids to take care of, bills to pay, a mortgage maybe you’re automatically going to be at a disadvantage to the single dude who lives at home with his parents and dedicates 10+ hours to leetcoding.
exactly. it doesnt measure how good you are as a software engineer, which is a lot more than just coding. look at how many companies have sprung up in the past few years that "prepare you for the FAANG" interview. its created a whole freaking sub-industry
Well if in that scenario obviously the company would want the dude who lives at home with his parents and can dedicate more time to his work than someone who can't... There is no job that you are going to be hired to and don't have to learn something new. So having an interview that shows how well an applicant can learn new concepts and dedicate time to improving their skills will identify who is a more valuable candidate. Id you think of the saying "You can't teach a dog new tricks", I'd rather have a puppy that doesn't know any tricks at all but is capable of learning new tricks rather than an old dog that only knows sit and lay down.
@@LouiWoodman That's good and all if you're a new graduate, but if you're a senior SWE with 10 years experience, they're hiring you for your experience and expertise, not your ability to reverse a linked list.
@@donaldcodes i agree for seniors, but are you sure they're really focusing on LC for seniors? I thought senior interviews were more geared towards system design
Yeah I'm the first one. I have a family spread across 5000mi to take care of, a full time job, personal volunteering responsibilities, a neurodivergent brain and low energy in general. Not practical. Not doing it.
I think it's hard to gauge a engineer/developers ability with just a gauntlet of algo questions. As someone who has been through those I agree with the first points where it's mainly luck. If you receive a leetcode question you've practiced before then its alot easier to explain and go through then one you haven't. I found the best interviews were the ones where it's a take home project and through several rounds you build on that project which replicates what you would do on the job.
So basically, "interview processes are hard to get right so let's just go with leetcode questions"? No one's aiming for perfect. But if a certain type of interview fails a lot of capable people, then I'd argue it's fair to call it "broken" instead of just "not perfect". I understand the value of small, scoped problems that are more focused on SWE/CS basics rather than specific technology X. If someone has a solid foundation, they're pretty likely to do well with whatever technology they need to learn on the job. However, I think DS&A questions are sometimes still too far removed from the reality of software engineering. For example, even if a DOM is a tree... You rarely need to know how to do low-level manipulations on it. Languages used in web programming have DOM APIs that do the work. As an engineer you need to know how to deal with abstractions. You should know that a DOM is a tree and a tree has nodes, and that basic understanding informs how you use the API, but it's usually none of your concern how and what that API does down to the smallest detail. I think a better type of question would be at a more "realistic" level of abstraction considering the day-to-day work, and then maybe ask the candidate some in-depth questions about _why_ the solution works if the company believes that kind of low-level knowledge is important to the job.
A false positive (incompetent hire) is far worse for a company than a false negative (competent person falsely rejected), so it’s normal for hiring processes to be more difficult than the day-to-day job. This is true in any industry.
@@cumibakar10 This is not about difficulty, it's about relevance. DS/A type stuff is not difficult per se. The equivalent would be to ask someone you want to hire as a chef to churn their own butter. It's not hard, and it's something they may have even done as part of their culinary training, but it's not a skill that chefs typically specialize in and it's not that predictive of their cooking ability.
I agree, CS/IT fields are falling prey to reductionism, and its because that's what makes hiring manager jobs easier. Instead of having multiple job titles, each with different interview questions pertaining to day-to-day responsibilities, its much easier to find standardized leetcode questions online that you can repeatedly ask and sit back as candidates jump through hoops. If CS/IT is so standardized and academic, then why don't college degrees hold more weight in the field when colleges get paid billions of dollars to conduct tests? Are software engineering certifications the next step after leetcode questions?
there are those types of interviews. There are system design interviews and frontend interviews. But for interns i think leetcode like interviews are still the best
@@nervengewitter Large companies are going to prioritize scalability and predictive value over relevance to the job. They have many years of data to justify that the current system achieves their goals for hire rates and false positive rates. It's legal, scalable, predictive, and produces metrics for comparing candidates. Companies know it's not realistic (per this interview) but that simply doesn't matter because they still get more than enough competent candidates willing to participate.
Getting insight into how a person solves a problem and what their process is for writing code is a million times more valuable than how well they can recall what effectively are obscure and rarely used CS concepts. That an engineer can identify that they need to sort a dataset and do it efficiently for a specific use case because they identified a restraint for what could be a scalability issue in the future is millions of times more important than if they can implement merge sort on the spot on a clock. How big your tool bag of algorithms is, is useless if you don't know when to apply them.
Like Daniel says, a technical interview shouldn't be a riddle. It also shouldn't be a memorisation test like a theory exam in university. Data structures and algorithms questions are memorisation questions. They don't test your problem solving skills or your engineering expertise, they test if you remember that one thing from that dreadful semester at uni - which you might not even be able to in the first place, if your DSA professor taught to understand, not to memorise. When I interviewed for my current job, I was asked how I might implement a particular, small thing. It wasn't about integrating my logic into an existing codebase, and I didn't have to write code that compiled - just code that made sense. The task started simple, with a few basic requirements, and a few assumptions that we clarified. Once I'd sketched out a prototype solution, I was asked how I might adjust it to account for a couple additional considerations. No 'one correct solution', no struggle to remember an algorithm, no lateral thinking. Just using my skills to solve a self-contained problem. It wasn't perfect, but it was much better than the previous interviews I'd had. I was able to show that I had practical understanding of the kind of problems I might need to solve on the job, and how various related systems might interact in the process. Take-home assignments are a mixed bag for me. Some are nice and fun, because I can write an elegant solution in an evening. Some are ridiculous, because I might have to spend many hours on it every day for 2 weeks, without getting paid, and some may involve - yet again - lateral thinking riddles. Software engineering is more about reading code than writing it. We should put emphasis on that in hiring processes. Ask candidates to review some sample code, or a code change. Describe a bug and ask them how they'd search for the cause. We can come up with better ways to determine who's a good fit for the role, and as an engineer I know I would want to spend time doing that, because a great new colleague will greatly improve my own productivity too.
Surely Dsa that is asked in interviews maybe be rarely required in a real job but it surely isn't memorization.The questions are endless and unique that's why people find dsa to be tough. So I would say that dsa is a good way to approximate the programming aptitude of a person but I also feel that development related things should also be included as they form the actual job that sdes do!!!
@@srinivasanshankaranarayana3093 If you can fairly easily write ABCD answers to an interview question, it's probably not a good interview question. If your question is "how would you sort an array of numbers in C++ without stdlib sorting functions", answer A would contain the code for bubble sort, answer B mergesort, answer C quicksort, answer D bogosort (or something), and all that you'd get from the interviewee is whether they remember how to implement those. You don't need that, they don't need to have sorting algos memorised, if they ever need to implement one they can look it up.
I concede that they are not broken. However, whether or not it's a particularly good metric is another thing altogether. When I interview potential developers I throw them some easy lobs that build on each other. I want them to feel comfortable and confident. If they don't get it I show them a possible solution. I'm looking for them to take note of it in some way or another so as to have a reference for the next thing. I don't care what they can memorize. I'm looking for the person that knows how to use resources and can communicate. The workplace is not some exam where you can't use a calculator or something. It's the real world where you access to so many resources to help solve your problem. Trust me, you're not cheating if Google helped you lol. At the end of the day if you want to get a job at one of the "top-tier" places you better study up. However, there's no shortage of people who can do those problems. The market is becoming more and more saturated. There is a shortage of good well rounded employees though. Maybe look to a smaller company that will help you become more than just a software engineer.
Great comment, especially the “not cheating if you Google it” part :-) Someone needs to write the How To Code With StackOverflow book - it’d look good with an O’Reilly cover on it (I’m really showing my age here) :-)
it's a bit hard to see this as being something objective when a large part of this video is an ad for a company whose entire purpose relies on this process existing
You're basically explaining the need of interviews which isn't something any of us are questioning. The issue is that every company asks the same questions, not at all related to the work, they do exactly the opposite of what you described in the video. And even this wouldn't be an issue if their expectations were matched by your paycheck, but they're not. The only reason they're able to get away with it is increasing market saturation and the fact that enough people are willing to agree to their terms regardless, this is the real reason. The same reason why interns often work months for free or that musicians are often asked to do gigs just for "exposure".
@@TheCStrike2 But as time goes on, it is getting more and more saturated and these big tech companies want the cream of the crop and that's why we will get more broken interviews to filter out the best of the best. This is crap but this is a numbers problem.
The whole tech interview can be gamed, thus gaming the tech career. If you have strong leetcode ability, and mediocre on-the-job experience, you can command high TC. The real problem we're seeing here is the inflation of difficulty of LC-esque question since people are now grinding LC, which prompts candidates to further practice LC. DS&A interview has ceased to become a good measurement of candidate's experience. I'd rather see the difficulty inflation of system-design problems, even for new graduates since it'll prime them for backend engineering/architecture.
I think you've successfully convinced me the opposite of your thesis. You get a strong 'no' on the persuasive scale. The biggest problem, and this is somebody whose made it into the tech space - albeit at a low level - is that these style interviews have INFESTED every other field. Before i got this job I was applying to work in an office as basically a paper pusher - verifying documents, updating spreadsheets etc - they made me, no joke, do a take home project and explain each step. That was after 1) a phone interview 2) a zoom interview with the hiring manager and 3) another phone interview. I wasn't going to be architecting backend or standing up their new environment. I was going to be doing the boring crap nobody wanted to do. And I need to jump through hoops that started in like the top 6 tech companies in the world. EDIT: And there was going to be MORE INTERVIEWS afterwards. Not to mention to work at a casino(my job prepandemic) I was required to perform a 'talent' section during the interview process. These jerks made me sing for minimum wage.
iirc most faang companies dont use take home projects, but i think they should do it at least for senior roles. If those smaller companies have all those steps it just means they too have alot of candidates dude. Stop complaining and start grinding
@@hil449 asking software engineers with around 8-10 years of experience to grind Leetcode you mean ? Fresh out of the college I agree, we can grind those and get those FANG interviews in and land something maybe. Even then its a maybe.
I say that this is very helpful. Currently (at the time I'm writing this), I'm a Senior in Computer Science that is going to graduate later this year. I haven't had any interview experiences and I'm currently working on getting internships this summer. This has enlightened me on the knowledge of some of the process that goes into the interview process. I'm still nervous tho....
Good luck. Mr. Hardwick. I've been a CS student since 2018. Haven't had internship or job. I'm suspended this year, so have 2 more years to go. And I intend to finish.
Defending something broken just because you are sponsored by a company that is profiting from that broken process. Content creators these days would endorse anything! Disappointed!
There is a way to streamline the process of interviewing many candidates without LeetCode. I don't work for this company nor am I affiliated with them but that company's name is Checkr in San Francisco. I did their on-site and the questions that were asked had nothing to do with LeetCode and was 100% applicable to my day-to-day job. Checkr did a Medium post on their interview process. They do not hide anything. All the information on what will be asked is on their medium article. They ask: Debugging & Refactoring / Object Oriented Design / System Design / Build a simple backend API.
I still disagree. If companies are looking for people who can solve new problems why are they testing using problems that are are already solved with other peoples solutions. The idea of a rubric is nice, however I think the questions being asked are fundamentally flawed. We wouldn't ask a plumber to plumb a complex piece of machinery to demonstrate that they have the ability to plumb a toilet. If the goal is simply to see if a person has the ability to deconstruct a problem it would make more sense to make a hard to solve - impossible to solve problem where the solution has little to no weight and the thought process is more important, or to remove the process of programming the problem all together. However at the moment the stress to find the solution is far too high and leads to people just memorizing patterns for the solution rather than becoming problem solvers. Nevertheless very well made video and an interesting perspective
The reason is simple - it's easy for them to sort people out this way as there's enough saturation for them to be picky like this, all of the other reasons in the video are essentially false, except maybe for the best of the silicon valley companies.
If the entire process is all about leetcode challenges, then I agree it's flawed. But if you're applying for an SDE position at Amazon as an example, you shouldn't be focusing entirely on the coding interview. The process is split between coding, systems design and leadership principles (behavioral questions). They get a lot of insights about your technical experience with questions that are seemingly unrelated to coding. The proportion of each topic varies according to the level you're applying for. I.e.: Senior engineers are evaluated much more on the behavioral aspect than the technical aspect. Many engineers fail for ignoring all the other aspects and focusing entirely on the coding. Many don't even understand why they get rejected. So my advice is to understand the specific process of the company you're applying for, and properly split your prep across all important domains.
I wrote an article on Medium called, "If software engineering is so in demand, why is it so hard to get a job?" It got a lot of attention, which was surprising to me since it was more or less just a tongue-in-cheek vent about the interviewing process. Here are some of the most interesting responses I got: -Pragmatic Engineer was critical of it, since he mostly stands behind the way we do interviews -They did a really entertaining share session on a podcast called Tech Team Weekly. They talked about a time they tried a take-home challenge, then shortly afterward a candidate put their exact question up on a bidding site to hire someone else to solve his take-home challenge for him. They didn't know who it was, so they bid on it and solved the question themselves Since I wrote it, I've also had some better interview experiences: -Companies that look for whether you communicate and code fluently, rather than just if you get the right answer -A frontend role where they just gave me a css, html, and javascript file and asked me to add a ui feature in 45 minutes while they watched -A take-home frontend challenge, followed by detailed feedback on why they wanted something different (ie not using the endpoints properly)
The best interviews I've experienced actually provide a real-world experience. I was provided a scenario, the opportunity to understand it, and asked to propose different approaches and explain my reasoning. Afterwards I was asked to implement features, given an existing codebase. This is way more relatable to real world development. Often times you start on an existing project and not on Greenfield development. Random DSA questions are not it and don't provide any meaningful signals to their potential work performance.
I usually consider FAANG interviews as exceptions. They received millions of applications a year so they get to pick the best of the best. The coding challenge piece of the interview is not entirely fair but at least it does the job of weeding out a majority of candidates. It sucks but I think there's some merit to the statement that they'd rather reject a false positive than hire a risky candidate. A bad hire costs way more than simply rejecting a potentially good hire. With that being said, I think that there are other (potentially better) ways to measure candidates skillset, other than coding challenges: - Present a real-life scenario (with codes) along with tasks (i.e. bug fixes, enhancement, etc) and ask the candidate to discuss their approach to address them. Depending on the time, they get to pick and implement some of it. - Put more emphasis on system design questions for mid level or senior positions. These are my favorite as it really showcases the candidate creativity and the ability to apply their previous work experience and design skill. - Discuss previous work experience and how much of those can be transferred or applied to the new role. I find a conversation format is great for this exercise as the candidate gets to explain their thought process while working on previous projects and directly engage with the interviewer via questions/answers. Coding challenge should be required still. But the difficulty should be scaled properly with the level of the position and not harder than LC medium.
the sheer volume of interviewing hence the time, money, energy, context switching this costs businesses means the tradeoff between false positive and negative isn't so clear-cut. these days it's actually quite straightforward to let go of a new hire, especially with probation periods being the norm.
Having to study for an Interview only evaluates your studying capabilities. By that logic everyone who passes an exam of any kind is skilled at it. Which we all know it is not true.
No, they are broken. In Europe they give you a project to do which you should send back in a few days and then you together go thru the code. No silly computer science highschool algorithms questions like in the US.
Technical interviews don’t always hire the best candidate. Being good at a job vs a technical interview is totally exclusive. Sometimes technical interview isn’t even about projects you’ll be working but sometime thing totally different job related to the project and the team you will be working with
They don't hire based on what they want sometimes 💀💀💀. They are broken because its legit everything luck and nothing based on your knowledge and qualities. This industry is straight up going to sh1t due to it.
I once did an interview at a big tech company some time back. I cut through, 3 out of the 5 interview stages like butter. The 3 interviewers were so impressed with my coding and communications skills that they told me I would get the job. Needless to say, I didn't get it. I flopped the remaining 2 because I couldn't answer follow-up questions. Luck definitely has something to do with it!!!!
25:49 She makes a good point. The last API I build that handles adding user comments to a database involved using mergesort to recursively sort the list of users and then performed a binary search on it (in O(n logn) time) before querying the database (which returned records in a linked list that had to be reversed) only then to be able to add the comment to the db. /s
I really enjoyed watching this video from the perspective of a regular tech interviewer. I’m a senior engineer in my day job as well as being part of the interview team and, over the years (too many to mention :-) ), I’ve interviewed hundreds of candidates. I see my role as guiding the candidate through the problem space. Most candidates are really nervous so it’s important that we try to put them at ease and make it clear that we’re there to help them to show their best side. It’s all to easy to trash a candidate but all that achieves is a waste of an hour or two for me and a candidate whose confidence is shattered, and who will (rightly) bad mouth the company to everyone they know i.e. we all lose. Like Daniel, I’ve also been using the same set of questions for a long time. They’re relatively simple but with lots of possible add-ons that can be explored depending on the candidate’s seniority or ability. It doesn’t even matter if I interviewed their friend recently who then told them all about the questions because there are so many ways we can go with them. I found myself nodding in agreement throughout the video. Thanks for the effort that you very clearly put into this content and for making it equally useful to those on both sides of the (these days often virtual) table.
I still believe that these FAANG interviews are just a justification to weed out non-CS graduates at Ivy League Universities, they just will never admit it. The tech industry is one of the few (if not the only one) that to jump to a higher level, you basically have to become a semi full-time student and get interviewed with problems that don't correlate with their real issues and challenges; and on top of that, they are reluctant to take feedback and still believe this is the better system. Let''s be real, this kind of interviews are specifically targeted to recent CS grads, with no real experience but fresh from the factory and with all this knowledge loaded in cache in their prefontal cortex, ready to be used. I just can't fit in my mind that these companies, that literary are solving the biggues problems in modern technology, can't come up with a more comprehensive interview process. They are just using the inclusion card: "yeah our process includes everyone, no matter background, education or previous experience, but 93% of our employees have a Bachelors or higher (real numbers btw), but don't worry you can still interview, you just need to pass this nice fine filter that we pretend to have just so we can be inclusive and don't discriminate". Let's face the facts, is broken and they know it, and sadly it will always be like this.
I don't entirely disagree with you but I don't think the reason 90+% of those who get in are CS grads is because of just bias. It'd be safe to say it's because you're up against people who have spent 3-4 years and thousands of dollars to get a reputable standard of education.
having a bachelors is still valued and there's a reason for it. Most people that learn by themselves just know how to use modern frameworks and know nothing about the fundamentals of CS, and that's something you dont want to be slacking on because in 5 years languages/frameworks change but the fundamentals of algorithms and system design wont change that much
It's clear to me that Coding interviews ARE broken. I am a software engineer with over 19 years experience, I have worked on a vast variety of successful projects. I was rejected by a financial institutions after failing a faang-type interview but was hired by a consulting house after passing their true to actual work interview. As fate would have it, the consulting house I joined was hired by said financial institution because the institution could not find suitable talent to meet their needs. Long story short, I ended up leading a joint team of devs and delivered a solution they were happy with and on time. No doubt their Interview process was broken as they rejected many capable candidates based on these types of coding interviews. Their interview was more difficult to do than their mission critical software, I am sure that is not the first time you have heard that. In the end you gotta ask what's the point if your hiring process eliminates suitable talent that will help your business grow?
I am working in the industry for more than 15 years as a frontend engineer and in my personal projects I do it all from front- to backend engineering as well as devops. I never studied CS. Most of what I do I learned all by myself because I was interested in it. Speaking of coding interview (at least the ones you talked about) I would be completely lost. I don‘t really know what a binary search tree is nor what it‘s good for. When you displayed the question to create a function which is able to tell if 2 strings are anagrams of each other, I quickly sat down and wrote it in ~5 mins. Still, in an interview situation I would be too stressed, I guess. I would say, I am incredibly good at my job (as feedback from others says so), I have very huge problems with the theoretical part of CS which makes me feel like I‘m an imposter.
This is super helpful not just for engineers trying to understand the interview process better, but for engineers who are performing interviews themselves at their companies.
Validating someone's technical prowess is all fine and dandy but the interview process is broken. Time comes at a cost and if I am spending 10+ hours, not counting preparation, interviewing for a single position then something is wrong. Especially if I am not getting paid for it. I am fully convinced several years ago I wrote an entire feature for a company I was interviewing for and still didn't get the job. Interviewing with three kids, a spouse and the day-to-day responsibilities of a tech lead leaves no time for career progression. We are one of the only fields that does this -- why? How come merit and past performance is more heavily valued in fields like finance, management and sales?
Fun fact: I have 5 years of experience and am on my 3rd job now, and I’ve never been asked DS&A interview questions. I did study DS&A purely out of interest though.
Pretty much exactly the same. 5 years experience, 3rd job, always gotten take home problems or online assessments. I've refused a couple interviews as I inquired if they'll be centered around DS&A. I think they're cool concepts worth learning but I don't have the time or desire to learn a skill that's only used for interviews. Find companies that value your personality and ability to solve realistic problems and talk about it. Or go all in for big tech, the big tech interviews where they don't belong is really the problem.
Nah, it's totally still broken. what really frustrates me even more is you have these big companies still employing these same techniques and they're controlling whether or not this process will continue. If I was in one of those big companies, I would certainly make an effort to change that. I'm especially baffled why senior software engineer interviews are still conducted in the same manner as a regular, entry-level one. There's so much to tap into through someone's experience. Or just go look at a codebase together. If they can't converse, THEN go to the coding option.
In other professions, are there parts of the hiring process similar to technical interviews in software? Do plumbers need to hook up a bathtub or unclog a kitchen sink? Do architects have to take a quiz on building codes? Do artists have to do a portrait or landscape or animate a cartoon character on the spot during an interview? Interviewing a surgeon: "hey my little toe is really hurting, could you amputate it right now"? Ha, okay that is silly example. But in many professions there's a license or official certificate or something showing the person went through some sort of thorough exam or evaluation, just once, and mostly need not be Some professions do make sense to have a "performance" during hiring for evaluation. Musicians and actors to audition. Massage therapists have personal styles that can't be caught on paper. In other professions it's only a portfolio, some stuff to show off, that matters such as works in a gallery, a demo reel, a website, whatever. So why can't software engineering have a standard official testing & certification/licensing process, so candidates can go through testing only once? There'd have to be several flavors of that, since, for example, back end engineering is so different from embedded audio signal processing. No more online coding tests because a one time certificate in Python or React or low-level networking or whatever indicates the competence. Interviewing can focus on relevant narrow specialties, the particulars of the specific project or business. How many different types of such tests would be needed? Might be a bad idea since some areas of software change so much and rapidly.
I don't think leetcode questions are the issue here, but rather the process which has gotten worse overtime. The end result is that you have leetcode coders, but not software engineers
Exactly. I've never written any sort of complex algorithms professionally.. Sure they basics help but in a decade I've never made a double linked list, inverted a binary tree etc.
Seriously, I have to disargee with a lot of things said in this video. As someone who has quite a number of software engineering experience and decided to pursue a Master's degree in Computer Science. This process is not getting any easier than I was a new grad. I even applied to a new grad role despite with my expertise I could easily do a job for a mid level, and still got rejected because I just got unlucky enough to get a leetcode question that I just don't know or never approach that kind of question before. Is this really not broken? For real?
i agree it's not fair. BUT at least it's exploitable. If you ARE able to breeze through these technical interviews, that will make you more likely to land the job. So you just gotta grind it out. You have a masters in CS so you prolly know this already, I'm just saying, yes its unfair and despite that say fuck you and succeed anyways. Personally, every single question I did, i treated it like an actual interview by recording myself and talking through my thought process. Then I rewatched and revised until I could go through them with ease while talking through everything + no stuttering or anything. Don't just mindlessly do problems. There should be something new or useful to learn or some mistake that you're trying to correct with every question that you do. Learn with purpose. The goal is to make yourself look smart and competent. You want to be able to easily come up with a solution while explaining your thought process to the interviewer. Am I actually an insane prodigy programmer? Do I have a photographic memory and every single leetcode question done with multiple solutions? Not at all. I just spent a majority of my time understanding data stuctures/algorithms and coding questions. A small portion on side projects. Yes, it's a shitty system but at least you can use it to your benefit. It could be way worse and obtuse without any transparency. Also, the most efficient method isn't just to solve every problem under the sun. That's basically impossible. you gotta understand the patterns these questions follow. hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed This article helped me a lot. Good luck.
Yes, it’s unfair. It’s really unrelated. It’s not a great way to pick a good employee. It’s totally bs. The reason why because most of the people that runs the interviews are nerds and been bullied when they were in school.
@@MrMokong03 makes zero sense, the best interviews i have had are with nerds and the worst ones have been the "popular" brogrammer types that care more about what you look like or what you're wearing.
@@m1rac1e I’ve been engineer for 12 years most of the good and great engineer that I met are well rounded and not nerd at all. These are the people who have low gpa in school but willing to learn and work. You can ace that data structure and algorithms interviews but it’s not going to make you a better engineer trust me on this. We have people from harvard that can’t design or code for shit.
This video is so weird, I actually agree with almost everything you and your guests said, but everything you're saying has made me come to the complete OPPOSITE conclusion as you. You could retitle this video "Coding Interview are broken (a Deep Dive)" and refilm the intro and last like 2 minutes and it would make more sense than you currently have it. Perhaps it is because you are sponsored by a company that profits from the brokenness of the current interview system (and seemingly are selling a video yourself with advice for how to get past the broken interview system) that your logic is so flawed as to be opposite of what anyone else would conclude from watching your video?
If you have been coding for years, have a portfolio of websites, have a github you could share personal projects of, can verbally communicate technical answers about concepts and examples only a developer would know, and the actual job let alone day to day tasks will never be nearly as hard as the technical interview... why on Earth should this process be kept?
YES YES YES EXACTLY. But they will expect you to be overqualified and very competent and in the job itself you will write unit tests and center a div 😂😂😂😂. It's an absolute joke
Agree!!! Tech interview is a nightmare! My colleague who has 5 years experience in c# couldn’t pass this tech challenge, however after 1.5 year the same company got him without it and he is beast there .
As it stands, for entry level jobs, people at bigger schools with large networks have the advantage. Meaning that those in smaller, more affordable schools are left at a disadvantage. There are universities out there that offer courses in interviewing and curriculums that focus on these short form problems rather than actual development. Smaller, lower funded schools can't afford to offer these classes.
well ... I have > 25 years of experience in web/IT from design to full stack... I have developed 2 CMS that I was selling to my clients (I have founded 2 companies)... but I am just bad at the algorithm stuff; and thus have a hard time going to the next step of any interview ... Even if I can show so many things I have built ! .... so, yeah, for me the interview process is broken... I am really trying my best at getting better a leetcode... even if it is a total waste of time for the actual value I would bring to a company :/ ...
This was a tremendous overview of some of the reasons that tech interviews have to be as tough as they are. The idea of a rubric is a great one and one I'll try and take back to my company
I would never give a tree-traversal problem to a web frontend developer. That hasn’t mattered since the advent of jquery. I think by going to algorithm and data structure, it adds bias towards those with upper class education or upper class background who went to well known schools with formal CS education, more than someone who can style and create smooth interactive experience on the web. I don’t think algos and data structure is normalizing as you think it is more than creating a slant towards people with formal education. I do agree though of creating a repeatable set of questions and grading rubric that fits the needs of the company, I just don’t think algo and data structure is normalizing or unbiasing, rather, it has the opposite effect
The frustrating part is that you need to spend a couple of months grinding Leetcode, to solve 1-3 tech questions and then not to use those knowledge ever.
I read somewhere that our brains refuse to learn things that we know as a fact we will never use. This makes it all the more difficult for those of us with 10+ years in the field to learn dynamic programming and Dijkstra's algorithm when you are say, an embedded software engineer.
I've been an engineer for eight years and was a journalist for five years before that. I certainly had my own opinions and preconceptions about this topic and I have to say, as a piece of journalism, this was excellent. It was well researched and took an open-minded view of the pros and cons of tech interviewing from all of the different stakeholders involved. It definitely changed my perspective and provided a lot of insight for me. I mostly work for startups and am back on the interviewee side of things at the moment (layoff). I've found the "take home" project is the preferred technical evaluation in that part of the industry these days. I've seen that from both sides, it certainly has its own pros and cons but I think a lot of the same themes you touch on here apply. Regardless, great video and was happy to see you have videos on imposter syndrome and other topics that don't get enough coverage on developer TH-cam, went ahead and subscribed 👍
The secret to easily solving almost any coding interview problem is to forget about the problems for a little while and instead first become very familiar with your fundamental data structures, some fundamental operations and algorithms on them, and their time and space complexities. And the secret to being able to learn all that is to know up front that there is only so much to learn -- it is NOT an endless grind. For example, a linked list. Fundamental operations include traversing, removing a node, reversing in place, detecting cycles in place, and maybe interweaving in place. Just knowing that alone will get you pretty far with solving linked list problems. Another example, a graph. Fundamental operations include DFS, BFS, topological sorting, Dijkstra, Bellman-Ford, Prim or Kruskal, and maybe Hierholzer and Edmonds-Karp. Just knowing that alone will get you very far with solving graph problems. Obviously there is much more to learn about linked lists and graphs if you want to really go into cutting edge research and development in some university or corporation. But for just learning enough to get good at coding interview questions, what I mentioned above is quite enough. I realize even what I mentioned can seem intimidating, especially when starting out. Personally I found heaps really difficult to understand at first. What matters is that you keep pushing forward until you make a breakthrough and that you understand it is NOT an endless grind. It DOES get easier. The sense of confusion and frustration DOES go away. It IS worth it. So get familiar with your fundamental data structures and algorithms. You will be very happy you did. And then most of those "problems" will be no problem. :)
It is very telling so many software developers, mostly web developers, are in industry for a very short time before switching to become content creators on TH-cam. The hiring process along with job requirement listings are a dumpster fire. Software developers some how managed to create software systems long before webdev was a thing.
Guys the only way this shit stops is when people stop giving them what they want. This is a toxic atmosphere that designed to make you unhappy with your career. Decline technical interviews and move on to a company that wont waste your time and theirs. Tech interviews are a complete waste of everyone's time involved. And its all done because no one wants to train people. And they wonder why no one has company loyalty anymore.
In my most recent interview, my recruiter actually told me what topic I should expect the interview to be on. I thought it was great because it really narrowed down what I had to study, and I was able to get an offer.
Mine gave me instructions of what I had to prepare on. That was good because I could've focused on the important stuff... The day of the interview the senior dev said he will improvise and straight up messed everything up 😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
I respectfully and yet highly disagree. These questions are not engineering questions. Real engineering has infinitely many solutions which vary in effectiveness. Most of the time interviewers are looking for only one of the infinitely many answers to these leetcode questions, which means interviewers aren't looking for engineers, they're looking for scientists or even something else, you're simply testing whether or not the interviewee has seen the problem before instead of testing their knowledge set and not allowing them to apply their skillset to something new. I won't pretend I have an answer to a better interviewing practice, but simply saying "this is better than any alternative" isn't a valid answer either.
It’s almost like HR shouldn’t be made up of people without a technical background. Psychology degrees and business degrees just aren’t as useful there. We should stress either finding SWE with recruiting skills, or hire recruiters with engineering experience. We *don’t* need recruiters who are 21-22yo recent grads from a psychology background.
Great video! I learned a bunch. Every profession has it's artificial hurdles that in reality have almost nothing to do with the actual job---i.e., medicine has the insane residency process, the law has the bar exam, etc. Sounds like software engineering is no different. Thanks for all you do.
The bar exam is standardized in a way that tech interviews aren't, so it's not really the same. Different companies and even individual interviewers can change the experience of a leetcode-like interview, but pre-selected questions in a text that the interviewee understands has a much better chance of being delivered in the same way to each test taker.
Technical Interviews Are BROKEN. Why ? Because there are companies that are selling the solution "get a job at big company A" with our course. There are software developers that can pass any interview process, can write any DS&A question in less then 10 minutes, but when they have to solve problem with SQL join they will solve it with two sql queries and join the results with some exotic DS in memory just to show off. A technical manager with couple of questions can evaluate the candidate and he/she can have a picture what kind of code the candidate can produce. For example, the candidate shows basic knowledge of Design patterns and excitement to use them (meaning everything is Singleton even it's not) then the candidate discover over--engineering and he/she isn't aware of it. This isn't hard process, interviewer have to notice patterns of behavior and can predict what kind of code the candidate can produce even if he/she never worked for the company. I know that this is strange, but I have seen software developers with 10+ years that still use same solutions when they started and the frameworks they used have better approaches of solving the same problem. Software developers are people and they have habits and believes. Some of those believes stick with them years after the fact they aren't longer true. And what companies should look is software developers that can change their habits and believes over the time and they know why they need to make change from believe A to believe B
When I do Leetcode problems to prepare for technical interviews, I look at the answers right away uploaded by users. I copy and paste the best answers and format it to my style. I definitely make sure that I understand what I'm copying first. I then memorize the general solution. I have about 7 years of experience as a SE with a B.S. and M.S. in Computer Science. For me, remembering the "trick" for a given problem is the hard part. Coding it out once I know the "trick" is very easy. I apply this approach to the top 100 Easy, top 50 Medium, and top 5 Hard questions. After I finish a problem, I usually never code it out again. I just recite it out load or in my head. If I forget the solution, I take a peak at the solution and then try to recite it again. Out of the 20+ first-round technical interviews that I have done, I have never failed one. Regarding the multi-round on-site interviews, I'm always able to come up with a solution. Maybe not the most optimal solution every time but something that works. My strategy is quantity over quality. If you try to solve each problem from scratch, how many problems can you actually get through?
If you "make sure that you understand", then why is your interview performance contingent on you remembering what you've memorized? The whole point of understanding is that you won't have to remember what's on your flashcards. It's not the right approach
So you're telling me there's no way to solve these problems without memorizing? There's a video titled " 6 steps to solve any problem" on TH-cam. Is this video misleading?
@@OfoeNelson Simply solving the whiteboard problems is easy. To solve it in the most optimal way with respect time to time and space complexity is where it can get hard. e.g. For certain problems, to get from O(n^2) down to O(n), you need to know the "special trick". These "special tricks" are not necessarily generalizable to other problems. You either know it or you don't.
Love this video, quality of both the filming and content was amazing. Over this past month I have been interviewing for a senior full stack role and each company has done things differently. You can really tell which companies have put effort into setting up their recruitment processes. One startup that I interviewed for was really well structured and had a live coding problem that had all the right stuff. Easy to solve problem, small details missing to prompt the candidate to ask questions then a few small gotcha's in test data that can be picked up by good tests or an eye for detail. Other companies its been all over the place, engineers being late for an interview. engineers or managers not willing to answer any questions to down right being rude and condescending of the candidates. I even had a engineers on the interview panel that weren't even in my field who ran out of questions to ask. I think another thing that gets missed is you are interviewing the companies as much as they are interviewing you. Companies need to allow time for candidates to ask questions about their work, tech stack, team environment etc. Don't shy away from asking the engineers on the panel some tough questions back.
First, i'd suggest a title change since it got my blood pressure up while starting the video. This is a touchy topic and interviews as they are currently are have kept me out of employment for years, being seemingly designed to keep people with ADHD from working. Second, it's a good look at why interviews are so bad and what goes into them. You did a great job of explaining what the interviews are like and how people feel about them. Currently, the best technical interview i've taken was at a company without its own office that gave me a take-home project that I could do in any language and then walk through it during the face-to-face interview. We went deep into two problems that had actual relevance to the focus of the company (one was parsing email tags, as the company was doing email parsing as a core function of its product, the other was manipulating a list of songs in a playlist because one of the devs worked at spotify and they were also dealing with sorting and managing inboxes). I have ideas of my own that i'd like to see done in an interview, but have yet to get hired to suggest it anywhere. I think it's true that no interview will fit every company, and that should be obvious to all of us here, but I do think there is a way to interview people that doesn't involve ableist coding tests done on a timer. Time pressured coding doesn't gather anything useful about a candidate and just selects people who spent a lot of time on Leetcode. People have told themselves that it allows for people of all backgrounds to come into the field if they just pass the test, but the opposite is true, as Daniel explains. Remember, Stanford has a class on passing FAANG interviews. The interviews select Stanford degrees.
I disagree - technical interviews are broken for the most part today. Tech interviews are meant to be proxies to determine whether a candidate is a good fit for the role. With that rule of thumb in mind, 1. Coding interviews are meant to proxy how the candidate thinks of and writes code in a work environment. How does medium-hard leetcode problems accomplish that? Even if the interviewer presents the solution conceptually and expects the interviewee to just write the code, it still requires the interviewee to know how the required datastructures are represented. A counter-point to this could be why hire somebody who cannot represent a tree in code. The point is not that, they probably can given enough time. But can they, in a 45mins interview! Now extrapolate that to complicated datastructures like Tries, or topo sorts, there is no way a candidate can represent these datastructures on the spot. 2. System design interviews are meant to proxy the candidate's ability to parse through an ambiguous problem and come up with a reasonable solution. I have seen so many companies that expect the solution to match something on their solution sheet. That's the same as reading the interviewer's mind. Jedi tricks, anyone? There are some more reasonable and knowledgable interviewers who could go in any direction or course-correct the interviewee. But even there, some companies prefer a checklist based evaluation: did they add a load balancer, did they do foo? Whereas a better signal probably would be did the interviewee reason the trade-offs and added something reasonable. But that's not an easy signal to catch. The worst kind is interviewers who remain silent throughout a system design interview and expect the interviewee to come up with a reasonable solution. A system design doc is a way to bring consensus on a solution to a business problem. If the rest of the team remains silent, guess how easy that would be. 3. Understanding the quality of experience - none of today's interview processes are good proxies of understanding a candidate's quality of experience post 8-10 yrs of experience, IMO. Writing prod level code takes about 2-3 yrs to master, doing a random "design youtube" question doesn't tell much about the quality of system design experience the candidate had (that's probably why there are a gazillion companies and courses preparing people for system design interviews, they even provide solution templates), and behavioural questions seem to focus mostly on "is the candidate a jerk" v/s going deep on projects and trying to understand how the candidate contributed. So, with all due respect, I think as an industry, we have a long way to go to make tech interviews not broken. I agree with you on investing more time on the process and being intentional about it.
It all started with big companies just trying to filter thousands of applicant to stand out but now even a wordpress blog site maintiner requires to reverse a binary tree.
Hard disagree. The best way is to have simple interviews to get a feel, then hire the person on a temporary basis to try them out. if they fit, keep em. Been doing this with candidates for a few years now and it works great.
That's awesome that you found a process that works for you! I'd be curious if that format works for other companies too. For me it was like pulling teeth to even try to get our companies to hire for more mobile developers, so I wonder how you were able to get everyone at your company onboard with this.
I can add a bit of large company perspective. Mayuko discussed how expensive engineering resources are a little in the video by explaining how interviewing time takes away from actual coding/engineering and companies sometimes struggle to justify it. Larger companies try to not only optimize the process to extract the signal they want, but to also extract that signal efficiently (i.e. with the least amount of cost to the company). Facebook for example, feels like they can fairly accurately extract that signal in about 5 hours of interviews, so spending a few weeks evaluating someone would be really costly to get a marginally better signal for them.
Larger companies can afford to have a tiny false positive rate though, and have performance review processes to "correct" them. Each new hire at smaller companies can change the culture and direction of the company, and it might be worth getting that marginally better signal!
@@michael.novati I only work at large companies and have had no issues with the hiring strategy I use. I think the false positive rate is actually really low. In my experience of having a simple casual discussion about tech and maybe one simple technical exercise is enough to make a decision. 90% of the time they are good candidates, and the other 10% of the time we let them go within a few weeks. No biggie.
My preffered technical assesment aproach is a small-ish take home asignment…and it’s luckily the only one I’ve went through so far, but I think it is a lot more common here in europe
very cool video format! can't wait for future tech topics, I have to give a technical interview one day and I have never have! This video started the journey :) thank you!
Thank you for the valuable insightful video. I didn't realize that I watched an half and hour video. That means, your delivery is really good, also simple. Keep up your good work. And wish me good luck for my SWE interviews in 5 years in the future. Haha
This has given me so many insights into what is expected of me as an interviewee. It even had me thinking back to previous interviews and realizing "oh that's what helped me in this one interview" or "that's what played against me on this other one". Will definitely have to rewatch any time I have an interview coming up to get a refresher on that interviewer perspective.
Save 30 minutes. Interview questions were broken yesterday, they are broken today, and will be broken tomorrow. But the day after that, is when things will have a chance to start improving.
Disagree , As a ComSci student I hate how I need to take out time and learn some glorified maths problems . Then Science part of computer science has no respect at all. understanding concept like OS , networking are so important if u wish to develop anything . EVERYONE coming into tech industry needs to understand that u should become better engineer not a better programmer . U can excel at any level if u become a good engineer . But u need to write efficient code ?. At some point , even if u don’t understand how the program actually interacts with Computer architecture and is actually optimised . U still get the glorious SWE position. But they end up debugging code and taking order form someone who is actually a Software ENGINEER. not a Software PROGRAMMER.
Although the title is about the technical interview, this video is more than that! I happen to be one of the interviewers for our team, we exactly design the questions and interview process for our interviewee based on the points you mentioned. We would like to find a good match with reasonable time consumption and resources, however, as the team grows, it becomes more difficult, just try our best to keep it up. Thank you for making this video! This definitely helps me to revisit our interview process and make it better and more suitable for every stage of our team!
I actually personally prefer DS&A over practical assessments/take-home tests, but if this were a persuasive essay I would give you a 2/5. This thinly veiled ad was definitely not well-structured or developed enough to make me believe your take on this issue. If anything, I'm walking away feeling like the opposite view has more weight.
I've worked in Technical fields most my life. Naval Nuclear Reactor operator, Electrical & Equipment engineering and Computer science. I've always found the companies that did the best job at hiring someone qualified left the interview of candidates up to the people in that department who know the actual job the person needed to do. Every time HR got involved it went to hell. HR always tends to use some list they look up in a book or on the internet copy other companies job requirements ... Which of course that companies HR did the same garbage. Then the interview with them well they were going by information they wrote down and didn't actually understand themselves. So trying to explain an answer to them was impossible because if it didn't match their written answer exactly well they just assumed it was wrong if you are lucky they would go ask an engineer when you pointed out none of the answer were incorrect the issue was their lack of understanding of the topic but of course you just lost points there because they feel you are making them look bad. Over the years I ended up in the position of deciding who does and doesn't get hired. Walk them through the area explain what is going on what the job position is. Give the candidates a task related to what is going on and see what answers they can come up with on their own. No sharing. Putting people into a real world situation has worked best sink or swim. I don't give a crap what gender a person is what color skin they have or any other outside aspect I only care if they can do the job. If they can't they are 100% useless to me. Anything beyond that skill wise is a bonus if they bring it to the table. Also I won't hire anyone who likes Agile or Clean Code. I could write an entire book or two on why. It wouldn't be worth my time to break the bad habits.
25:25 Counter point: Abstracting to the DS & algorithms defies the point. Almost any novice engineer can solve that kind of problem given the answer. But on the job you have to abstract the business logic yourself which is something DA & algorithms based interviews still don't measure.
Hey Mayuko! Awesome video. I really like how you structured your video and all the information. Didn't know about the rubriks, makes me want to try this at my current company 🚀
Very well researched and a well put together video, however, it did not show that coding interviews are NOT broken, it explains why they are broken and that they need fixing.
Loved working with you on this video, Mayuko!! I'm honestly astounded by the outcome - this is hands down the most well researched, thoughtful and balanced video on this topic, and I hope helpful to all the engineers out there who might be feeling lost in the process ❤
Thank you again Sophie for sharing your insights on this!! It was honestly so refreshing to talk to you about your thoughts. Really happy that you liked the final video!!
@Sophie Novati thank you for your input! I wish companies would forgo algos since it's not necessarily needed for CSS or other programming languages. altho, at Coding Dojo I told my cohorts, "No algos, no jobs." 😄
My sweatshirt is a Limited Edition code; Crewneck in Mint! Get yours now before March 14th before they're gone forever: store.dftba.com/collections/hello-mayuko/products/code-crewneck-sweatshirt
OMG I bought this 😍😍😍!!
TAKE MY MONEYYYYYYY
will any other colorways be dropping?
I prefer the approach I once had at Netflix in lieu of technical interviews. They give you a small project that you have a few days to finish. Then you get to explain your code during the interview. It’s less pressure and is a better way to express your abilities.
The downside of small projects is that they're super time consuming. It can be really disheartening to spend 20+ hours of your free time perfecting the project only to get rejected later on for some reason. And the time spent doing this project is only applicable for that one company. Speaking from personal experience, this is why I really hesitate to do interviews that require a coding project.
So you’d rather waste whole days on an assignment project than a few hours on coding interviews? And do that for every company you apply for?
@dkgong
good to know! I know that they are filmmaker-friendly. sounds like they are more laid back with coders.
@@anniephan665 I see what you mean. People are different. I prefer project as algos always give me math anxiety. 😅
@@cumibakar10 I'd only do that for certain companies I really care about. Also, its preferable to spending a hundred hours on leetcode which I hate doing.
A take home 1 day project (after passing a simple technical screen, a leetcode easy question) is the only assessment that seems reasonable. You’ll also get to talk through your solution.
If after 10 years at your job, you will fail the very same technical challenge that got you the job (cos 10 years ago, you were aggressively practicing leetcode questions), then it is broken.
if the take home takes longer than two hrs, it's not reasonable, you're just doing unpaid labor. unless they have a VERY good reason.
the second point you mentioned, this is the main issue, when the actual job has nothing to do with the technical interview then what was the point of the interview?
make the interview actually relevant to actual challenges that you end up facing at work.
Nah.... imagine doing a take home project and then receiving no reply and no feedback from the company because the company went with someone else instead. No thanks. The idea of take home projects comes with good intentions but is really not practical if you are apply to many many companies which is not uncommon in a job search.
@@scythazz eh I mean when Amazon and other Big N companies have experimented with at home assessments and take homes. They're usually reasonable though.
Are you really gonna give up the chance at an interview at a big N company because of one hour?
@@m1rac1e Name brand companies of course...... And OP was saying 1 day take home projects. The take home tasks is probably trivial if it only takes an hour. Heck, some harder leetcode question could possibly take one hour to solve. I was thinking it was referring to more large scale projects.
I'm only saying if companies gave take home assignments as the norm, it would quickly become infeasible if you apply to multiple companies at once.
Also, if take home assignments are to be implemented, then feedback on the assignment must be given even for rejected candidates. You can't expect people to do a take home assessment and then hear nothing back from the company.
@@scythazz i agree
This may be only me but...I started treating algorithm style questions more as "understanding my problem" instead of "coming up with a solution". I personally stopped providing solutions (if it is straightforward sure I will write out some code) and try to have a conversation around the problem being asked. I feel when doing this I am able to truly showcase how I tackle problems I have never encountered before.
that's what my friends at Coding Dojo told me. I was so stressed out they told me to understand what the algorithm is about first. plus, I think interviewers will give you credit, not see you as a joke.
This is what many interviewers seem to prefer too it seems
this is all nice and true... until you realize you got rejected because you did not figure out how to do the interview question without many prompts from the interviewer. Highly dependent on what kind of company you apply to.
@@scythazz yup i agree it is definitely company specific but I'd take it a step further and say interviewer specific...sometimes you get a good one that is truly looking to see how you think and sometimes you get one that is only following a specific rubric
How has this worked out for you? Is this actually a viable approach? I ask because I feel like I just tried to do that during a screening interview and am not sure how to feel about it. According to the interviewer, my logic seemed to be on the right track, but I legit wrote almost entirely comments saying what I want to do instead of actual code, because time was at a premium. I'm left feeling glad that there was a separate online assessment that proves that I can write actual real code too lol.
I'm an electrical engineering student and I've pretty much just been trying to teach myself data structures and algorithms between school and work (school won't let me take a course on the topic, of course). So, that's realistically "nascent" DS+A knowledge that likely can't hang with a typical fresh CS grad. I also have a tendency to get stuck on how to implement what I'm thinking of with pretty much any language's syntax, because I've had to jump between languages so frequently at school and during my internship and it feels like 10 different languages just went through a blender, and I'll find myself using C syntax in Python loops or whatever. So, I figure just writing comments structuring out what I think should be happening as I think through it, and adding some more comments to the code saying what I want the code to do, even if the syntax is off, is probably going to look better than me sitting there humming and hawing over it for the entire interview.
The fundamental issue with a large number of technical interview questions is that they do NOT actually evaluate your skills. They work about as well as asking a Comedian to 'tell a joke' to determine if they are good at stand up comedy. I've taken and given probably more than 100 technical interviews, and they really only serve as a way to weed out people at the low end, not find people at the high end.
I agree and it sends like most people who are leadership roles are honestly very unintelligent
Preach! It's so true. Technical interviews are broken. Ridiculous!
They're more about memorizing trivia than actual problem-solving.
And they definitely don't find the best candidates. Just the ones who are good at jumping through hoops.
Like, I recently bombed an interview after a take-home assignment - for a regular e-commerce site. just because of useless trivia questions.
This left me a bad taste in my mouth and in my next interview I used an AI assistant and I got my current job because of it.
Now I'm a top contributor, according to my manager. Proof that these interviews are useless!
edit: the one I used was called interviewhammer, but there are other platforms like it if you search.
Seems like a little survivorship bias as well as missing the point of small companies copying major companies like Google who need a tough system to easily filter out candidates
I can't agree. Technical interviews in their most common current standard form (solving a puzzle in front of a stranger) are massively disadvantaging neurodiverse people and people with anxiety. It's also been shown that women are much more likely to underperform while being watched, even if they could do the same problem when not being watched (see "Does Stress Impact Technical Interview Performance?" by Behroozi et al.). I have a lot more sympathy for small take-home coding projects. I've also had interviews where you look at someone else's code, talk through it and have to find bugs and/or make small changes (which is a more realistic scenario for day-to-day work). On the spot coding should be limited to sanity check stuff that any candidate should be able to do without much difficulty.
So you’d rather waste whole days on a take home assignment instead of a few hours on coding interviews, and do that for every job you apply for? Besides the fact that take home assignments are so easily cheatable.
@@cumibakar10 I already waste days brushing up on things like linked lists and sorting algorithms that I've never needed in my day-to-day life for regular interviews. Most code you'll need in the job will be "cheatable" in that someone else has already done it. The key with the take home assignments is that the candidate should be able to talk through the code and answer questions. If they've "cheated" they won't be able to do this. If they've used other resources to help them reach that solution that is exactly what they will do as a software engineer
@@TheJennifer122 completely agree, I struggle a lot to focus on interview prep stuff (I can force myself to sit down and work for a few hours, but the progress is usually very minimal and i have to re-read the info multiple times) but don't struggle at all when it comes to writing software, solving business problems, and making architecture decisions. And, I get extremely anxious and stressed when I have to do a coding interview with live share which causes me to mix up aspects of different languages (ex: using python style `if:` when writing golang `if {}`) which causes lots of dumb bugs. Take home tests let me focus on the problem without the major stress increase from a coding interview and hours wasted brushing up on my dsa skills/practice problems, then after I've thought about the problem with a clear head, I have no problem explaining my thought process to the interviewer.
Interviewer training is also very important. A good interviewer will adapt to support the most diverse set of candidates they can. No matter what the format, a good interviewer will try to get the most positive signal they can and try to support you in highlighting your strengths.
@@cumibakar10 Preparation will be more than whole days on an impromptu question
The problem with leetcode interviews is the fact that you have to prepare for them. Imagine if you had a full time job, had kids to take care of, bills to pay, a mortgage maybe you’re automatically going to be at a disadvantage to the single dude who lives at home with his parents and dedicates 10+ hours to leetcoding.
exactly. it doesnt measure how good you are as a software engineer, which is a lot more than just coding.
look at how many companies have sprung up in the past few years that "prepare you for the FAANG" interview. its created a whole freaking sub-industry
Well if in that scenario obviously the company would want the dude who lives at home with his parents and can dedicate more time to his work than someone who can't... There is no job that you are going to be hired to and don't have to learn something new. So having an interview that shows how well an applicant can learn new concepts and dedicate time to improving their skills will identify who is a more valuable candidate. Id you think of the saying "You can't teach a dog new tricks", I'd rather have a puppy that doesn't know any tricks at all but is capable of learning new tricks rather than an old dog that only knows sit and lay down.
@@LouiWoodman That's good and all if you're a new graduate, but if you're a senior SWE with 10 years experience, they're hiring you for your experience and expertise, not your ability to reverse a linked list.
@@donaldcodes i agree for seniors, but are you sure they're really focusing on LC for seniors? I thought senior interviews were more geared towards system design
Yeah I'm the first one. I have a family spread across 5000mi to take care of, a full time job, personal volunteering responsibilities, a neurodivergent brain and low energy in general.
Not practical. Not doing it.
I think it's hard to gauge a engineer/developers ability with just a gauntlet of algo questions. As someone who has been through those I agree with the first points where it's mainly luck. If you receive a leetcode question you've practiced before then its alot easier to explain and go through then one you haven't. I found the best interviews were the ones where it's a take home project and through several rounds you build on that project which replicates what you would do on the job.
Coding interviews are broken 100%, even software engineer with 20 years of experience admitted that
So basically, "interview processes are hard to get right so let's just go with leetcode questions"? No one's aiming for perfect. But if a certain type of interview fails a lot of capable people, then I'd argue it's fair to call it "broken" instead of just "not perfect". I understand the value of small, scoped problems that are more focused on SWE/CS basics rather than specific technology X. If someone has a solid foundation, they're pretty likely to do well with whatever technology they need to learn on the job. However, I think DS&A questions are sometimes still too far removed from the reality of software engineering. For example, even if a DOM is a tree... You rarely need to know how to do low-level manipulations on it. Languages used in web programming have DOM APIs that do the work. As an engineer you need to know how to deal with abstractions. You should know that a DOM is a tree and a tree has nodes, and that basic understanding informs how you use the API, but it's usually none of your concern how and what that API does down to the smallest detail. I think a better type of question would be at a more "realistic" level of abstraction considering the day-to-day work, and then maybe ask the candidate some in-depth questions about _why_ the solution works if the company believes that kind of low-level knowledge is important to the job.
A false positive (incompetent hire) is far worse for a company than a false negative (competent person falsely rejected), so it’s normal for hiring processes to be more difficult than the day-to-day job. This is true in any industry.
@@cumibakar10 This is not about difficulty, it's about relevance. DS/A type stuff is not difficult per se. The equivalent would be to ask someone you want to hire as a chef to churn their own butter. It's not hard, and it's something they may have even done as part of their culinary training, but it's not a skill that chefs typically specialize in and it's not that predictive of their cooking ability.
I agree, CS/IT fields are falling prey to reductionism, and its because that's what makes hiring manager jobs easier. Instead of having multiple job titles, each with different interview questions pertaining to day-to-day responsibilities, its much easier to find standardized leetcode questions online that you can repeatedly ask and sit back as candidates jump through hoops.
If CS/IT is so standardized and academic, then why don't college degrees hold more weight in the field when colleges get paid billions of dollars to conduct tests? Are software engineering certifications the next step after leetcode questions?
there are those types of interviews. There are system design interviews and frontend interviews. But for interns i think leetcode like interviews are still the best
@@nervengewitter Large companies are going to prioritize scalability and predictive value over relevance to the job. They have many years of data to justify that the current system achieves their goals for hire rates and false positive rates.
It's legal, scalable, predictive, and produces metrics for comparing candidates. Companies know it's not realistic (per this interview) but that simply doesn't matter because they still get more than enough competent candidates willing to participate.
Getting insight into how a person solves a problem and what their process is for writing code is a million times more valuable than how well they can recall what effectively are obscure and rarely used CS concepts. That an engineer can identify that they need to sort a dataset and do it efficiently for a specific use case because they identified a restraint for what could be a scalability issue in the future is millions of times more important than if they can implement merge sort on the spot on a clock. How big your tool bag of algorithms is, is useless if you don't know when to apply them.
Like Daniel says, a technical interview shouldn't be a riddle. It also shouldn't be a memorisation test like a theory exam in university.
Data structures and algorithms questions are memorisation questions. They don't test your problem solving skills or your engineering expertise, they test if you remember that one thing from that dreadful semester at uni - which you might not even be able to in the first place, if your DSA professor taught to understand, not to memorise.
When I interviewed for my current job, I was asked how I might implement a particular, small thing. It wasn't about integrating my logic into an existing codebase, and I didn't have to write code that compiled - just code that made sense. The task started simple, with a few basic requirements, and a few assumptions that we clarified. Once I'd sketched out a prototype solution, I was asked how I might adjust it to account for a couple additional considerations. No 'one correct solution', no struggle to remember an algorithm, no lateral thinking. Just using my skills to solve a self-contained problem.
It wasn't perfect, but it was much better than the previous interviews I'd had. I was able to show that I had practical understanding of the kind of problems I might need to solve on the job, and how various related systems might interact in the process.
Take-home assignments are a mixed bag for me. Some are nice and fun, because I can write an elegant solution in an evening. Some are ridiculous, because I might have to spend many hours on it every day for 2 weeks, without getting paid, and some may involve - yet again - lateral thinking riddles.
Software engineering is more about reading code than writing it. We should put emphasis on that in hiring processes. Ask candidates to review some sample code, or a code change. Describe a bug and ask them how they'd search for the cause. We can come up with better ways to determine who's a good fit for the role, and as an engineer I know I would want to spend time doing that, because a great new colleague will greatly improve my own productivity too.
Surely Dsa that is asked in interviews maybe be rarely required in a real job but it surely isn't memorization.The questions are endless and unique that's why people find dsa to be tough. So I would say that dsa is a good way to approximate the programming aptitude of a person but I also feel that development related things should also be included as they form the actual job that sdes do!!!
@@srinivasanshankaranarayana3093 If you can fairly easily write ABCD answers to an interview question, it's probably not a good interview question. If your question is "how would you sort an array of numbers in C++ without stdlib sorting functions", answer A would contain the code for bubble sort, answer B mergesort, answer C quicksort, answer D bogosort (or something), and all that you'd get from the interviewee is whether they remember how to implement those. You don't need that, they don't need to have sorting algos memorised, if they ever need to implement one they can look it up.
I concede that they are not broken. However, whether or not it's a particularly good metric is another thing altogether.
When I interview potential developers I throw them some easy lobs that build on each other. I want them to feel comfortable and confident. If they don't get it I show them a possible solution. I'm looking for them to take note of it in some way or another so as to have a reference for the next thing. I don't care what they can memorize. I'm looking for the person that knows how to use resources and can communicate. The workplace is not some exam where you can't use a calculator or something. It's the real world where you access to so many resources to help solve your problem. Trust me, you're not cheating if Google helped you lol.
At the end of the day if you want to get a job at one of the "top-tier" places you better study up. However, there's no shortage of people who can do those problems. The market is becoming more and more saturated. There is a shortage of good well rounded employees though. Maybe look to a smaller company that will help you become more than just a software engineer.
I'll keep this in mind. Sounds encouraging and useful. Thank you!
Great comment, especially the “not cheating if you Google it” part :-) Someone needs to write the How To Code With StackOverflow book - it’d look good with an O’Reilly cover on it (I’m really showing my age here) :-)
it's a bit hard to see this as being something objective when a large part of this video is an ad for a company whose entire purpose relies on this process existing
Failed interview --> yep, technical interviews are broken
Passed interview --> hmm, I guess they're alright
You're basically explaining the need of interviews which isn't something any of us are questioning. The issue is that every company asks the same questions, not at all related to the work, they do exactly the opposite of what you described in the video. And even this wouldn't be an issue if their expectations were matched by your paycheck, but they're not. The only reason they're able to get away with it is increasing market saturation and the fact that enough people are willing to agree to their terms regardless, this is the real reason. The same reason why interns often work months for free or that musicians are often asked to do gigs just for "exposure".
The software engineer market is not saturated. That’s why a lot of us are making $200k-$300k.
@@TheCStrike2 But as time goes on, it is getting more and more saturated and these big tech companies want the cream of the crop and that's why we will get more broken interviews to filter out the best of the best. This is crap but this is a numbers problem.
The whole tech interview can be gamed, thus gaming the tech career. If you have strong leetcode ability, and mediocre on-the-job experience, you can command high TC.
The real problem we're seeing here is the inflation of difficulty of LC-esque question since people are now grinding LC, which prompts candidates to further practice LC. DS&A interview has ceased to become a good measurement of candidate's experience.
I'd rather see the difficulty inflation of system-design problems, even for new graduates since it'll prime them for backend engineering/architecture.
I think you've successfully convinced me the opposite of your thesis. You get a strong 'no' on the persuasive scale.
The biggest problem, and this is somebody whose made it into the tech space - albeit at a low level - is that these style interviews have INFESTED every other field. Before i got this job I was applying to work in an office as basically a paper pusher - verifying documents, updating spreadsheets etc - they made me, no joke, do a take home project and explain each step. That was after 1) a phone interview 2) a zoom interview with the hiring manager and 3) another phone interview. I wasn't going to be architecting backend or standing up their new environment. I was going to be doing the boring crap nobody wanted to do. And I need to jump through hoops that started in like the top 6 tech companies in the world. EDIT: And there was going to be MORE INTERVIEWS afterwards.
Not to mention to work at a casino(my job prepandemic) I was required to perform a 'talent' section during the interview process. These jerks made me sing for minimum wage.
iirc most faang companies dont use take home projects, but i think they should do it at least for senior roles. If those smaller companies have all those steps it just means they too have alot of candidates dude. Stop complaining and start grinding
@@hil449 asking software engineers with around 8-10 years of experience to grind Leetcode you mean ? Fresh out of the college I agree, we can grind those and get those FANG interviews in and land something maybe. Even then its a maybe.
I say that this is very helpful. Currently (at the time I'm writing this), I'm a Senior in Computer Science that is going to graduate later this year. I haven't had any interview experiences and I'm currently working on getting internships this summer. This has enlightened me on the knowledge of some of the process that goes into the interview process. I'm still nervous tho....
Good luck. Mr. Hardwick. I've been a CS student since 2018. Haven't had internship or job. I'm suspended this year, so have 2 more years to go. And I intend to finish.
@@stevensong8784 I do hope that you will finish. Good Luck to you too!
Defending something broken just because you are sponsored by a company that is profiting from that broken process. Content creators these days would endorse anything! Disappointed!
There is a way to streamline the process of interviewing many candidates without LeetCode. I don't work for this company nor am I affiliated with them but that company's name is Checkr in San Francisco. I did their on-site and the questions that were asked had nothing to do with LeetCode and was 100% applicable to my day-to-day job. Checkr did a Medium post on their interview process. They do not hide anything. All the information on what will be asked is on their medium article. They ask: Debugging & Refactoring / Object Oriented Design / System Design / Build a simple backend API.
I still disagree. If companies are looking for people who can solve new problems why are they testing using problems that are are already solved with other peoples solutions. The idea of a rubric is nice, however I think the questions being asked are fundamentally flawed. We wouldn't ask a plumber to plumb a complex piece of machinery to demonstrate that they have the ability to plumb a toilet. If the goal is simply to see if a person has the ability to deconstruct a problem it would make more sense to make a hard to solve - impossible to solve problem where the solution has little to no weight and the thought process is more important, or to remove the process of programming the problem all together. However at the moment the stress to find the solution is far too high and leads to people just memorizing patterns for the solution rather than becoming problem solvers. Nevertheless very well made video and an interesting perspective
Plump a toilet with a stranger’s toolbox, and no user manuals
The reason is simple - it's easy for them to sort people out this way as there's enough saturation for them to be picky like this, all of the other reasons in the video are essentially false, except maybe for the best of the silicon valley companies.
If the entire process is all about leetcode challenges, then I agree it's flawed. But if you're applying for an SDE position at Amazon as an example, you shouldn't be focusing entirely on the coding interview. The process is split between coding, systems design and leadership principles (behavioral questions). They get a lot of insights about your technical experience with questions that are seemingly unrelated to coding. The proportion of each topic varies according to the level you're applying for. I.e.: Senior engineers are evaluated much more on the behavioral aspect than the technical aspect. Many engineers fail for ignoring all the other aspects and focusing entirely on the coding. Many don't even understand why they get rejected. So my advice is to understand the specific process of the company you're applying for, and properly split your prep across all important domains.
I wrote an article on Medium called, "If software engineering is so in demand, why is it so hard to get a job?" It got a lot of attention, which was surprising to me since it was more or less just a tongue-in-cheek vent about the interviewing process. Here are some of the most interesting responses I got:
-Pragmatic Engineer was critical of it, since he mostly stands behind the way we do interviews
-They did a really entertaining share session on a podcast called Tech Team Weekly. They talked about a time they tried a take-home challenge, then shortly afterward a candidate put their exact question up on a bidding site to hire someone else to solve his take-home challenge for him. They didn't know who it was, so they bid on it and solved the question themselves
Since I wrote it, I've also had some better interview experiences:
-Companies that look for whether you communicate and code fluently, rather than just if you get the right answer
-A frontend role where they just gave me a css, html, and javascript file and asked me to add a ui feature in 45 minutes while they watched
-A take-home frontend challenge, followed by detailed feedback on why they wanted something different (ie not using the endpoints properly)
The best interviews I've experienced actually provide a real-world experience. I was provided a scenario, the opportunity to understand it, and asked to propose different approaches and explain my reasoning. Afterwards I was asked to implement features, given an existing codebase. This is way more relatable to real world development. Often times you start on an existing project and not on Greenfield development. Random DSA questions are not it and don't provide any meaningful signals to their potential work performance.
I usually consider FAANG interviews as exceptions. They received millions of applications a year so they get to pick the best of the best. The coding challenge piece of the interview is not entirely fair but at least it does the job of weeding out a majority of candidates. It sucks but I think there's some merit to the statement that they'd rather reject a false positive than hire a risky candidate. A bad hire costs way more than simply rejecting a potentially good hire.
With that being said, I think that there are other (potentially better) ways to measure candidates skillset, other than coding challenges:
- Present a real-life scenario (with codes) along with tasks (i.e. bug fixes, enhancement, etc) and ask the candidate to discuss their approach to address them. Depending on the time, they get to pick and implement some of it.
- Put more emphasis on system design questions for mid level or senior positions. These are my favorite as it really showcases the candidate creativity and the ability to apply their previous work experience and design skill.
- Discuss previous work experience and how much of those can be transferred or applied to the new role. I find a conversation format is great for this exercise as the candidate gets to explain their thought process while working on previous projects and directly engage with the interviewer via questions/answers.
Coding challenge should be required still. But the difficulty should be scaled properly with the level of the position and not harder than LC medium.
the sheer volume of interviewing hence the time, money, energy, context switching this costs businesses means the tradeoff between false positive and negative isn't so clear-cut. these days it's actually quite straightforward to let go of a new hire, especially with probation periods being the norm.
Having to study for an Interview only evaluates your studying capabilities. By that logic everyone who passes an exam of any kind is skilled at it. Which we all know it is not true.
No, they are broken. In Europe they give you a project to do which you should send back in a few days and then you together go thru the code. No silly computer science highschool algorithms questions like in the US.
Technical interviews don’t always hire the best candidate. Being good at a job vs a technical interview is totally exclusive. Sometimes technical interview isn’t even about projects you’ll be working but sometime thing totally different job related to the project and the team you will be working with
They don't hire based on what they want sometimes 💀💀💀.
They are broken because its legit everything luck and nothing based on your knowledge and qualities. This industry is straight up going to sh1t due to it.
I once did an interview at a big tech company some time back. I cut through, 3 out of the 5 interview stages like butter. The 3 interviewers were so impressed with my coding and communications skills that they told me I would get the job. Needless to say, I didn't get it. I flopped the remaining 2 because I couldn't answer follow-up questions. Luck definitely has something to do with it!!!!
25:49 She makes a good point. The last API I build that handles adding user comments to a database involved using mergesort to recursively sort the list of users and then performed a binary search on it (in O(n logn) time) before querying the database (which returned records in a linked list that had to be reversed) only then to be able to add the comment to the db.
/s
I really enjoyed watching this video from the perspective of a regular tech interviewer. I’m a senior engineer in my day job as well as being part of the interview team and, over the years (too many to mention :-) ), I’ve interviewed hundreds of candidates.
I see my role as guiding the candidate through the problem space. Most candidates are really nervous so it’s important that we try to put them at ease and make it clear that we’re there to help them to show their best side.
It’s all to easy to trash a candidate but all that achieves is a waste of an hour or two for me and a candidate whose confidence is shattered, and who will (rightly) bad mouth the company to everyone they know i.e. we all lose.
Like Daniel, I’ve also been using the same set of questions for a long time. They’re relatively simple but with lots of possible add-ons that can be explored depending on the candidate’s seniority or ability. It doesn’t even matter if I interviewed their friend recently who then told them all about the questions because there are so many ways we can go with them.
I found myself nodding in agreement throughout the video. Thanks for the effort that you very clearly put into this content and for making it equally useful to those on both sides of the (these days often virtual) table.
a leetcode a day keeps the unemployment away 😉
Your vids are great btw. I owe you for getting my FAANG job I really appreciate it.
The hours added up over months, you could've spent doing something else. Like learning about functional programming.
I still believe that these FAANG interviews are just a justification to weed out non-CS graduates at Ivy League Universities, they just will never admit it. The tech industry is one of the few (if not the only one) that to jump to a higher level, you basically have to become a semi full-time student and get interviewed with problems that don't correlate with their real issues and challenges; and on top of that, they are reluctant to take feedback and still believe this is the better system. Let''s be real, this kind of interviews are specifically targeted to recent CS grads, with no real experience but fresh from the factory and with all this knowledge loaded in cache in their prefontal cortex, ready to be used. I just can't fit in my mind that these companies, that literary are solving the biggues problems in modern technology, can't come up with a more comprehensive interview process. They are just using the inclusion card: "yeah our process includes everyone, no matter background, education or previous experience, but 93% of our employees have a Bachelors or higher (real numbers btw), but don't worry you can still interview, you just need to pass this nice fine filter that we pretend to have just so we can be inclusive and don't discriminate". Let's face the facts, is broken and they know it, and sadly it will always be like this.
I don't entirely disagree with you but I don't think the reason 90+% of those who get in are CS grads is because of just bias. It'd be safe to say it's because you're up against people who have spent 3-4 years and thousands of dollars to get a reputable standard of education.
having a bachelors is still valued and there's a reason for it. Most people that learn by themselves just know how to use modern frameworks and know nothing about the fundamentals of CS, and that's something you dont want to be slacking on because in 5 years languages/frameworks change but the fundamentals of algorithms and system design wont change that much
It's literally meant to prevent that lmao. It's a standardized test.
It's clear to me that Coding interviews ARE broken. I am a software engineer with over 19 years experience, I have worked on a vast variety of successful projects. I was rejected by a financial institutions after failing a faang-type interview but was hired by a consulting house after passing their true to actual work interview. As fate would have it, the consulting house I joined was hired by said financial institution because the institution could not find suitable talent to meet their needs. Long story short, I ended up leading a joint team of devs and delivered a solution they were happy with and on time. No doubt their Interview process was broken as they rejected many capable candidates based on these types of coding interviews. Their interview was more difficult to do than their mission critical software, I am sure that is not the first time you have heard that. In the end you gotta ask what's the point if your hiring process eliminates suitable talent that will help your business grow?
I am working in the industry for more than 15 years as a frontend engineer and in my personal projects I do it all from front- to backend engineering as well as devops. I never studied CS. Most of what I do I learned all by myself because I was interested in it. Speaking of coding interview (at least the ones you talked about) I would be completely lost. I don‘t really know what a binary search tree is nor what it‘s good for. When you displayed the question to create a function which is able to tell if 2 strings are anagrams of each other, I quickly sat down and wrote it in ~5 mins. Still, in an interview situation I would be too stressed, I guess. I would say, I am incredibly good at my job (as feedback from others says so), I have very huge problems with the theoretical part of CS which makes me feel like I‘m an imposter.
Sounds like something a recruiter would say.....
This is super helpful not just for engineers trying to understand the interview process better, but for engineers who are performing interviews themselves at their companies.
You should share this with tech interviewers. Mr. Novati. If you know any.
Validating someone's technical prowess is all fine and dandy but the interview process is broken. Time comes at a cost and if I am spending 10+ hours, not counting preparation, interviewing for a single position then something is wrong. Especially if I am not getting paid for it. I am fully convinced several years ago I wrote an entire feature for a company I was interviewing for and still didn't get the job. Interviewing with three kids, a spouse and the day-to-day responsibilities of a tech lead leaves no time for career progression. We are one of the only fields that does this -- why? How come merit and past performance is more heavily valued in fields like finance, management and sales?
CS values merit more than any other field.
Fun fact: I have 5 years of experience and am on my 3rd job now, and I’ve never been asked DS&A interview questions. I did study DS&A purely out of interest though.
Pretty much exactly the same. 5 years experience, 3rd job, always gotten take home problems or online assessments. I've refused a couple interviews as I inquired if they'll be centered around DS&A. I think they're cool concepts worth learning but I don't have the time or desire to learn a skill that's only used for interviews. Find companies that value your personality and ability to solve realistic problems and talk about it. Or go all in for big tech, the big tech interviews where they don't belong is really the problem.
Nah, it's totally still broken. what really frustrates me even more is you have these big companies still employing these same techniques and they're controlling whether or not this process will continue. If I was in one of those big companies, I would certainly make an effort to change that.
I'm especially baffled why senior software engineer interviews are still conducted in the same manner as a regular, entry-level one. There's so much to tap into through someone's experience. Or just go look at a codebase together. If they can't converse, THEN go to the coding option.
In other professions, are there parts of the hiring process similar to technical interviews in software? Do plumbers need to hook up a bathtub or unclog a kitchen sink? Do architects have to take a quiz on building codes? Do artists have to do a portrait or landscape or animate a cartoon character on the spot during an interview? Interviewing a surgeon: "hey my little toe is really hurting, could you amputate it right now"? Ha, okay that is silly example. But in many professions there's a license or official certificate or something showing the person went through some sort of thorough exam or evaluation, just once, and mostly need not be
Some professions do make sense to have a "performance" during hiring for evaluation. Musicians and actors to audition. Massage therapists have personal styles that can't be caught on paper. In other professions it's only a portfolio, some stuff to show off, that matters such as works in a gallery, a demo reel, a website, whatever.
So why can't software engineering have a standard official testing & certification/licensing process, so candidates can go through testing only once? There'd have to be several flavors of that, since, for example, back end engineering is so different from embedded audio signal processing. No more online coding tests because a one time certificate in Python or React or low-level networking or whatever indicates the competence. Interviewing can focus on relevant narrow specialties, the particulars of the specific project or business.
How many different types of such tests would be needed? Might be a bad idea since some areas of software change so much and rapidly.
I don't think leetcode questions are the issue here, but rather the process which has gotten worse overtime. The end result is that you have leetcode coders, but not software engineers
Exactly. I've never written any sort of complex algorithms professionally.. Sure they basics help but in a decade I've never made a double linked list, inverted a binary tree etc.
Seriously, I have to disargee with a lot of things said in this video. As someone who has quite a number of software engineering experience and decided to pursue a Master's degree in Computer Science. This process is not getting any easier than I was a new grad. I even applied to a new grad role despite with my expertise I could easily do a job for a mid level, and still got rejected because I just got unlucky enough to get a leetcode question that I just don't know or never approach that kind of question before.
Is this really not broken? For real?
I agree
i agree it's not fair. BUT at least it's exploitable. If you ARE able to breeze through these technical interviews, that will make you more likely to land the job.
So you just gotta grind it out.
You have a masters in CS so you prolly know this already, I'm just saying, yes its unfair and despite that say fuck you and succeed anyways.
Personally, every single question I did, i treated it like an actual interview by recording myself and talking through my thought process. Then I rewatched and revised until I could go through them with ease while talking through everything + no stuttering or anything.
Don't just mindlessly do problems.
There should be something new or useful to learn or some mistake that you're trying to correct with every question that you do. Learn with purpose.
The goal is to make yourself look smart and competent. You want to be able to easily come up with a solution while explaining your thought process to the interviewer.
Am I actually an insane prodigy programmer? Do I have a photographic memory and every single leetcode question done with multiple solutions? Not at all.
I just spent a majority of my time understanding data stuctures/algorithms and coding questions. A small portion on side projects.
Yes, it's a shitty system but at least you can use it to your benefit. It could be way worse and obtuse without any transparency.
Also, the most efficient method isn't just to solve every problem under the sun. That's basically impossible. you gotta understand the patterns these questions follow.
hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed
This article helped me a lot.
Good luck.
Yes, it’s unfair. It’s really unrelated. It’s not a great way to pick a good employee. It’s totally bs. The reason why because most of the people that runs the interviews are nerds and been bullied when they were in school.
@@MrMokong03 makes zero sense, the best interviews i have had are with nerds and the worst ones have been the "popular" brogrammer types that care more about what you look like or what you're wearing.
@@m1rac1e I’ve been engineer for 12 years most of the good and great engineer that I met are well rounded and not nerd at all. These are the people who have low gpa in school but willing to learn and work. You can ace that data structure and algorithms interviews but it’s not going to make you a better engineer trust me on this. We have people from harvard that can’t design or code for shit.
Great video and advice Mayuko. Thank you.
This video is so weird, I actually agree with almost everything you and your guests said, but everything you're saying has made me come to the complete OPPOSITE conclusion as you. You could retitle this video "Coding Interview are broken (a Deep Dive)" and refilm the intro and last like 2 minutes and it would make more sense than you currently have it. Perhaps it is because you are sponsored by a company that profits from the brokenness of the current interview system (and seemingly are selling a video yourself with advice for how to get past the broken interview system) that your logic is so flawed as to be opposite of what anyone else would conclude from watching your video?
If you have been coding for years, have a portfolio of websites, have a github you could share personal projects of, can verbally communicate technical answers about concepts and examples only a developer would know, and the actual job let alone day to day tasks will never be nearly as hard as the technical interview... why on Earth should this process be kept?
YES YES YES EXACTLY.
But they will expect you to be overqualified and very competent and in the job itself you will write unit tests and center a div 😂😂😂😂.
It's an absolute joke
Agree!!! Tech interview is a nightmare! My colleague who has 5 years experience in c# couldn’t pass this tech challenge, however after 1.5 year the same company got him without it and he is beast there .
As it stands, for entry level jobs, people at bigger schools with large networks have the advantage. Meaning that those in smaller, more affordable schools are left at a disadvantage. There are universities out there that offer courses in interviewing and curriculums that focus on these short form problems rather than actual development. Smaller, lower funded schools can't afford to offer these classes.
why are people quitting tech jobs and becoming youtubers???
lol
well ... I have > 25 years of experience in web/IT from design to full stack... I have developed 2 CMS that I was selling to my clients (I have founded 2 companies)... but I am just bad at the algorithm stuff; and thus have a hard time going to the next step of any interview ... Even if I can show so many things I have built ! .... so, yeah, for me the interview process is broken... I am really trying my best at getting better a leetcode... even if it is a total waste of time for the actual value I would bring to a company :/ ...
This was a tremendous overview of some of the reasons that tech interviews have to be as tough as they are. The idea of a rubric is a great one and one I'll try and take back to my company
sounds good! it's not just about how good you are at algos. you need to have good attributes.
I would never give a tree-traversal problem to a web frontend developer. That hasn’t mattered since the advent of jquery. I think by going to algorithm and data structure, it adds bias towards those with upper class education or upper class background who went to well known schools with formal CS education, more than someone who can style and create smooth interactive experience on the web. I don’t think algos and data structure is normalizing as you think it is more than creating a slant towards people with formal education.
I do agree though of creating a repeatable set of questions and grading rubric that fits the needs of the company, I just don’t think algo and data structure is normalizing or unbiasing, rather, it has the opposite effect
The frustrating part is that you need to spend a couple of months grinding Leetcode, to solve 1-3 tech questions and then not to use those knowledge ever.
I read somewhere that our brains refuse to learn things that we know as a fact we will never use. This makes it all the more difficult for those of us with 10+ years in the field to learn dynamic programming and Dijkstra's algorithm when you are say, an embedded software engineer.
I've been an engineer for eight years and was a journalist for five years before that. I certainly had my own opinions and preconceptions about this topic and I have to say, as a piece of journalism, this was excellent. It was well researched and took an open-minded view of the pros and cons of tech interviewing from all of the different stakeholders involved. It definitely changed my perspective and provided a lot of insight for me.
I mostly work for startups and am back on the interviewee side of things at the moment (layoff). I've found the "take home" project is the preferred technical evaluation in that part of the industry these days. I've seen that from both sides, it certainly has its own pros and cons but I think a lot of the same themes you touch on here apply.
Regardless, great video and was happy to see you have videos on imposter syndrome and other topics that don't get enough coverage on developer TH-cam, went ahead and subscribed 👍
there mayuko goes again. creating another invaluable video to help all of the internet get through their tech careers. she just doesn't stop!!
The secret to easily solving almost any coding interview problem is to forget about the problems for a little while and instead first become very familiar with your fundamental data structures, some fundamental operations and algorithms on them, and their time and space complexities. And the secret to being able to learn all that is to know up front that there is only so much to learn -- it is NOT an endless grind. For example, a linked list. Fundamental operations include traversing, removing a node, reversing in place, detecting cycles in place, and maybe interweaving in place. Just knowing that alone will get you pretty far with solving linked list problems. Another example, a graph. Fundamental operations include DFS, BFS, topological sorting, Dijkstra, Bellman-Ford, Prim or Kruskal, and maybe Hierholzer and Edmonds-Karp. Just knowing that alone will get you very far with solving graph problems. Obviously there is much more to learn about linked lists and graphs if you want to really go into cutting edge research and development in some university or corporation. But for just learning enough to get good at coding interview questions, what I mentioned above is quite enough. I realize even what I mentioned can seem intimidating, especially when starting out. Personally I found heaps really difficult to understand at first. What matters is that you keep pushing forward until you make a breakthrough and that you understand it is NOT an endless grind. It DOES get easier. The sense of confusion and frustration DOES go away. It IS worth it. So get familiar with your fundamental data structures and algorithms. You will be very happy you did. And then most of those "problems" will be no problem. :)
It is very telling so many software developers, mostly web developers, are in industry for a very short time before switching to become content creators on TH-cam. The hiring process along with job requirement listings are a dumpster fire. Software developers some how managed to create software systems long before webdev was a thing.
Guys the only way this shit stops is when people stop giving them what they want. This is a toxic atmosphere that designed to make you unhappy with your career. Decline technical interviews and move on to a company that wont waste your time and theirs. Tech interviews are a complete waste of everyone's time involved. And its all done because no one wants to train people. And they wonder why no one has company loyalty anymore.
In my most recent interview, my recruiter actually told me what topic I should expect the interview to be on. I thought it was great because it really narrowed down what I had to study, and I was able to get an offer.
Mine gave me instructions of what I had to prepare on. That was good because I could've focused on the important stuff...
The day of the interview the senior dev said he will improvise and straight up messed everything up 😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
Most nerds will get the job. Those people are not well rounded. They just robots and follow orders. They will hire people like them like nerds.
I respectfully and yet highly disagree. These questions are not engineering questions. Real engineering has infinitely many solutions which vary in effectiveness. Most of the time interviewers are looking for only one of the infinitely many answers to these leetcode questions, which means interviewers aren't looking for engineers, they're looking for scientists or even something else, you're simply testing whether or not the interviewee has seen the problem before instead of testing their knowledge set and not allowing them to apply their skillset to something new. I won't pretend I have an answer to a better interviewing practice, but simply saying "this is better than any alternative" isn't a valid answer either.
It’s almost like HR shouldn’t be made up of people without a technical background. Psychology degrees and business degrees just aren’t as useful there. We should stress either finding SWE with recruiting skills, or hire recruiters with engineering experience.
We *don’t* need recruiters who are 21-22yo recent grads from a psychology background.
Great video! I learned a bunch. Every profession has it's artificial hurdles that in reality have almost nothing to do with the actual job---i.e., medicine has the insane residency process, the law has the bar exam, etc. Sounds like software engineering is no different. Thanks for all you do.
The bar exam is standardized in a way that tech interviews aren't, so it's not really the same. Different companies and even individual interviewers can change the experience of a leetcode-like interview, but pre-selected questions in a text that the interviewee understands has a much better chance of being delivered in the same way to each test taker.
Technical Interviews Are BROKEN.
Why ? Because there are companies that are selling the solution "get a job at big company A" with our course.
There are software developers that can pass any interview process, can write any DS&A question in less then 10 minutes, but when they have to solve problem with SQL join they will solve it
with two sql queries and join the results with some exotic DS in memory just to show off.
A technical manager with couple of questions can evaluate the candidate and he/she can have a picture what kind of code the candidate can produce.
For example, the candidate shows basic knowledge of Design patterns and excitement to use them (meaning everything is Singleton even it's not) then the candidate discover over--engineering and he/she isn't aware of it.
This isn't hard process, interviewer have to notice patterns of behavior and can predict what kind of code the candidate can produce even if he/she never worked for the company.
I know that this is strange, but I have seen software developers with 10+ years that still use same solutions when they started and the frameworks they used have better approaches of solving the same problem.
Software developers are people and they have habits and believes. Some of those believes stick with them years after the fact they aren't longer true.
And what companies should look is software developers that can change their habits and believes over the time and they know why they need to make change from believe A to believe B
This is one of the best presentations I’ve seen on utube .. keep it up
Props to your editor though! Transitions be getting cleaner, Mayuko!!
When I do Leetcode problems to prepare for technical interviews, I look at the answers right away uploaded by users. I copy and paste the best answers and format it to my style. I definitely make sure that I understand what I'm copying first. I then memorize the general solution. I have about 7 years of experience as a SE with a B.S. and M.S. in Computer Science. For me, remembering the "trick" for a given problem is the hard part. Coding it out once I know the "trick" is very easy. I apply this approach to the top 100 Easy, top 50 Medium, and top 5 Hard questions. After I finish a problem, I usually never code it out again. I just recite it out load or in my head. If I forget the solution, I take a peak at the solution and then try to recite it again. Out of the 20+ first-round technical interviews that I have done, I have never failed one. Regarding the multi-round on-site interviews, I'm always able to come up with a solution. Maybe not the most optimal solution every time but something that works. My strategy is quantity over quality. If you try to solve each problem from scratch, how many problems can you actually get through?
This was actually a very interesting approach, i might have to try it out
If you "make sure that you understand", then why is your interview performance contingent on you remembering what you've memorized? The whole point of understanding is that you won't have to remember what's on your flashcards. It's not the right approach
So you're telling me there's no way to solve these problems without memorizing? There's a video titled " 6 steps to solve any problem" on TH-cam. Is this video misleading?
@@OfoeNelson Simply solving the whiteboard problems is easy. To solve it in the most optimal way with respect time to time and space complexity is where it can get hard. e.g. For certain problems, to get from O(n^2) down to O(n), you need to know the "special trick". These "special tricks" are not necessarily generalizable to other problems. You either know it or you don't.
@@axis2010 So many confusing answers on this. Some say you need to memorize solutions some say you don't...
what a great video Mayuko, thanks a lot for this!!!
Love this video, quality of both the filming and content was amazing.
Over this past month I have been interviewing for a senior full stack role and each company has done things differently. You can really tell which companies have put effort into setting up their recruitment processes. One startup that I interviewed for was really well structured and had a live coding problem that had all the right stuff. Easy to solve problem, small details missing to prompt the candidate to ask questions then a few small gotcha's in test data that can be picked up by good tests or an eye for detail.
Other companies its been all over the place, engineers being late for an interview. engineers or managers not willing to answer any questions to down right being rude and condescending of the candidates. I even had a engineers on the interview panel that weren't even in my field who ran out of questions to ask.
I think another thing that gets missed is you are interviewing the companies as much as they are interviewing you. Companies need to allow time for candidates to ask questions about their work, tech stack, team environment etc. Don't shy away from asking the engineers on the panel some tough questions back.
First, i'd suggest a title change since it got my blood pressure up while starting the video. This is a touchy topic and interviews as they are currently are have kept me out of employment for years, being seemingly designed to keep people with ADHD from working. Second, it's a good look at why interviews are so bad and what goes into them. You did a great job of explaining what the interviews are like and how people feel about them. Currently, the best technical interview i've taken was at a company without its own office that gave me a take-home project that I could do in any language and then walk through it during the face-to-face interview. We went deep into two problems that had actual relevance to the focus of the company (one was parsing email tags, as the company was doing email parsing as a core function of its product, the other was manipulating a list of songs in a playlist because one of the devs worked at spotify and they were also dealing with sorting and managing inboxes).
I have ideas of my own that i'd like to see done in an interview, but have yet to get hired to suggest it anywhere. I think it's true that no interview will fit every company, and that should be obvious to all of us here, but I do think there is a way to interview people that doesn't involve ableist coding tests done on a timer. Time pressured coding doesn't gather anything useful about a candidate and just selects people who spent a lot of time on Leetcode. People have told themselves that it allows for people of all backgrounds to come into the field if they just pass the test, but the opposite is true, as Daniel explains. Remember, Stanford has a class on passing FAANG interviews. The interviews select Stanford degrees.
I disagree - technical interviews are broken for the most part today. Tech interviews are meant to be proxies to determine whether a candidate is a good fit for the role. With that rule of thumb in mind,
1. Coding interviews are meant to proxy how the candidate thinks of and writes code in a work environment. How does medium-hard leetcode problems accomplish that? Even if the interviewer presents the solution conceptually and expects the interviewee to just write the code, it still requires the interviewee to know how the required datastructures are represented. A counter-point to this could be why hire somebody who cannot represent a tree in code. The point is not that, they probably can given enough time. But can they, in a 45mins interview! Now extrapolate that to complicated datastructures like Tries, or topo sorts, there is no way a candidate can represent these datastructures on the spot.
2. System design interviews are meant to proxy the candidate's ability to parse through an ambiguous problem and come up with a reasonable solution. I have seen so many companies that expect the solution to match something on their solution sheet. That's the same as reading the interviewer's mind. Jedi tricks, anyone?
There are some more reasonable and knowledgable interviewers who could go in any direction or course-correct the interviewee. But even there, some companies prefer a checklist based evaluation: did they add a load balancer, did they do foo? Whereas a better signal probably would be did the interviewee reason the trade-offs and added something reasonable. But that's not an easy signal to catch.
The worst kind is interviewers who remain silent throughout a system design interview and expect the interviewee to come up with a reasonable solution. A system design doc is a way to bring consensus on a solution to a business problem. If the rest of the team remains silent, guess how easy that would be.
3. Understanding the quality of experience - none of today's interview processes are good proxies of understanding a candidate's quality of experience post 8-10 yrs of experience, IMO. Writing prod level code takes about 2-3 yrs to master, doing a random "design youtube" question doesn't tell much about the quality of system design experience the candidate had (that's probably why there are a gazillion companies and courses preparing people for system design interviews, they even provide solution templates), and behavioural questions seem to focus mostly on "is the candidate a jerk" v/s going deep on projects and trying to understand how the candidate contributed.
So, with all due respect, I think as an industry, we have a long way to go to make tech interviews not broken. I agree with you on investing more time on the process and being intentional about it.
It all started with big companies just trying to filter thousands of applicant to stand out but now even a wordpress blog site maintiner requires to reverse a binary tree.
Hard disagree. The best way is to have simple interviews to get a feel, then hire the person on a temporary basis to try them out. if they fit, keep em. Been doing this with candidates for a few years now and it works great.
That's awesome that you found a process that works for you! I'd be curious if that format works for other companies too. For me it was like pulling teeth to even try to get our companies to hire for more mobile developers, so I wonder how you were able to get everyone at your company onboard with this.
@@hellomayuko well it’s not necessarily more hires than we would otherwise. Just a different method to doing it.
I can add a bit of large company perspective. Mayuko discussed how expensive engineering resources are a little in the video by explaining how interviewing time takes away from actual coding/engineering and companies sometimes struggle to justify it. Larger companies try to not only optimize the process to extract the signal they want, but to also extract that signal efficiently (i.e. with the least amount of cost to the company). Facebook for example, feels like they can fairly accurately extract that signal in about 5 hours of interviews, so spending a few weeks evaluating someone would be really costly to get a marginally better signal for them.
Larger companies can afford to have a tiny false positive rate though, and have performance review processes to "correct" them. Each new hire at smaller companies can change the culture and direction of the company, and it might be worth getting that marginally better signal!
@@michael.novati I only work at large companies and have had no issues with the hiring strategy I use. I think the false positive rate is actually really low. In my experience of having a simple casual discussion about tech and maybe one simple technical exercise is enough to make a decision. 90% of the time they are good candidates, and the other 10% of the time we let them go within a few weeks. No biggie.
Mayuko! So glad you made this video! Spot on.
Now in your every videos I look at the sticky notes and think when will your book get published. Cause I can't wait for reading it!
My preffered technical assesment aproach is a small-ish take home asignment…and it’s luckily the only one I’ve went through so far, but I think it is a lot more common here in europe
very cool video format! can't wait for future tech topics, I have to give a technical interview one day and I have never have! This video started the journey :) thank you!
This is the first mayuko video I’ve given a dislike 😭💀
Thank you for the valuable insightful video. I didn't realize that I watched an half and hour video. That means, your delivery is really good, also simple. Keep up your good work. And wish me good luck for my SWE interviews in 5 years in the future. Haha
This is such a great & helpful video. Thank you!
very thorough and informative video, thank you for sharing
This has given me so many insights into what is expected of me as an interviewee. It even had me thinking back to previous interviews and realizing "oh that's what helped me in this one interview" or "that's what played against me on this other one". Will definitely have to rewatch any time I have an interview coming up to get a refresher on that interviewer perspective.
Sorry, its just not similar enough to day to day work and the luck element of the questions.
Save 30 minutes. Interview questions were broken yesterday, they are broken today, and will be broken tomorrow. But the day after that, is when things will have a chance to start improving.
Disagree , As a ComSci student I hate how I need to take out time and learn some glorified maths problems . Then Science part of computer science has no respect at all. understanding concept like OS , networking are so important if u wish to develop anything . EVERYONE coming into tech industry needs to understand that u should become better engineer not a better programmer . U can excel at any level if u become a good engineer .
But u need to write efficient code ?.
At some point , even if u don’t understand how the program actually interacts with Computer architecture and is actually optimised . U still get the glorious SWE position.
But they end up debugging code and taking order form someone who is actually a Software ENGINEER. not a Software PROGRAMMER.
Although the title is about the technical interview, this video is more than that! I happen to be one of the interviewers for our team, we exactly design the questions and interview process for our interviewee based on the points you mentioned. We would like to find a good match with reasonable time consumption and resources, however, as the team grows, it becomes more difficult, just try our best to keep it up.
Thank you for making this video! This definitely helps me to revisit our interview process and make it better and more suitable for every stage of our team!
Clickbait and let me be a devil advocate
9:50 CORRECT!
It's not that tech interviews are broken, they're just the most difficult part of the job.
Coding interviews are broken, you so are you,
I actually personally prefer DS&A over practical assessments/take-home tests, but if this were a persuasive essay I would give you a 2/5. This thinly veiled ad was definitely not well-structured or developed enough to make me believe your take on this issue. If anything, I'm walking away feeling like the opposite view has more weight.
I've worked in Technical fields most my life. Naval Nuclear Reactor operator, Electrical & Equipment engineering and Computer science. I've always found the companies that did the best job at hiring someone qualified left the interview of candidates up to the people in that department who know the actual job the person needed to do. Every time HR got involved it went to hell. HR always tends to use some list they look up in a book or on the internet copy other companies job requirements ... Which of course that companies HR did the same garbage. Then the interview with them well they were going by information they wrote down and didn't actually understand themselves. So trying to explain an answer to them was impossible because if it didn't match their written answer exactly well they just assumed it was wrong if you are lucky they would go ask an engineer when you pointed out none of the answer were incorrect the issue was their lack of understanding of the topic but of course you just lost points there because they feel you are making them look bad.
Over the years I ended up in the position of deciding who does and doesn't get hired. Walk them through the area explain what is going on what the job position is. Give the candidates a task related to what is going on and see what answers they can come up with on their own. No sharing. Putting people into a real world situation has worked best sink or swim. I don't give a crap what gender a person is what color skin they have or any other outside aspect I only care if they can do the job. If they can't they are 100% useless to me. Anything beyond that skill wise is a bonus if they bring it to the table.
Also I won't hire anyone who likes Agile or Clean Code. I could write an entire book or two on why. It wouldn't be worth my time to break the bad habits.
Thanks your clockbell gave me flashbacks to college campus. Appreciate the mini heart attack for being late to class
Why does google chrome suck at memory management if they have DSA gurus that should be able to optimize it?
25:25 Counter point: Abstracting to the DS & algorithms defies the point. Almost any novice engineer can solve that kind of problem given the answer. But on the job you have to abstract the business logic yourself which is something DA & algorithms based interviews still don't measure.
Hey Mayuko! Awesome video. I really like how you structured your video and all the information. Didn't know about the rubriks, makes me want to try this at my current company 🚀
Very well researched and a well put together video, however, it did not show that coding interviews are NOT broken, it explains why they are broken and that they need fixing.
Loved working with you on this video, Mayuko!!
I'm honestly astounded by the outcome - this is hands down the most well researched, thoughtful and balanced video on this topic, and I hope helpful to all the engineers out there who might be feeling lost in the process ❤
Thank you again Sophie for sharing your insights on this!! It was honestly so refreshing to talk to you about your thoughts. Really happy that you liked the final video!!
@Sophie Novati
thank you for your input! I wish companies would forgo algos since it's not necessarily needed for CSS or other programming languages. altho, at Coding Dojo I told my cohorts, "No algos, no jobs." 😄
I have a technical interview tomorrow and I am so ready to be trash at it LET'S GO!
Sheesh can’t wait for the fighting to begin