5 Coding Interview Misconceptions, Analyzed (this will change your approach) 

Glad that our problem-solving approach has helped! Yep that's a great observation, that problem-solving and domain expertise can be pulled apart and evaluated separately.

Thanks for the thoughtful note. Very much agree with the overall sentiment here. I have an essay that talks about similar ideas: watchandcode.com/essays/flight-to-quality-in-teaching-and-hiring/. I'm also seeing this concerning trend: 1) People got into the industry when things were easy (~2012-2022). 2) Got laid off in the recent market correction (~2022). 3) And now have been unable to re-enter the industry (even after many months). It's a hard thing to watch up close, but it makes sense given the macro trends. It seems like there are three plays. 1) Become a competitive candidate (most difficult). 2) Downgrade into less competitive roles like technical support (easiest). 3) Wait it out in hopes that the bar lowers again (most risky).

The old unknown unknowns problem. Most work is just gluing things together but if that's all you know it's hard to imagine anything else.

Thank you! Is there a specific part that stood out?

@@GordonZhu I think it's the perspective shift that, DSA questions are not just for testing your knowledge in DSA, but actually to test your general problem-solving abilities; something that takes longer to cultivate. Also, the way you explained how companies need to filter down candidates made sense; it feels less unfair now.

@@sleepybraincells Thank you -- that's helpful. It's good for me to understand what messages are getting through.

Thank you!

It's not that simple. That's just ONE important aspect. And it's difficult to get right. Most people overestimate their ability and work on problems that are too hard. This is especially true with LeetCode, where even the "easy" questions are too hard for most people at the beginning. There are a ton of things you have to get right to become a good problem-solver, but if I had to describe it in one sentence, I'd say that it requires large, recurring doses of [thoughtful practice] + [deep introspection]. For example, just ONE aspect of thoughtful practice is doing problems at the right level. Another is not looking at solutions. Within introspection, you have to reflect deeply and accurately on where your current weaknesses are, and how you can fix them. You then have to successfully implement the fix(es). All of these subtasks are difficult and nuanced, and may trigger more subtasks, all of which are also difficult and nuanced. That's what makes problem-solving so difficult, satisfying, and frustrating at times. If this is interesting to you, you may enjoy the book "How to Solve It" by Polya. It was written for mathematicians, but is equally applicable to programming.

For full context, see watchandcode.com/essays/a-brief-history-of-watch-and-code/. From 2014-2020, we functioned primarily as a video tutorial site, and our pricing reflected that. Because of the many limitations of passive video (just not effective for most people), we transformed into an intensive hands-on program. The heart of that is our assessments, which are HAND-GRADED assignments that simulate a rigorous code review process. This labor intensive aspect is required to help students learn about the nuanced parts of programming. And all of the hands-on work is done by senior staff. We do NOT use teaching assistants because it's just not possible to maintain the same quality of instruction. This is all very expensive, and we've done everything we can to keep things affordable given our current structure. One reason I'm posting on RU-vid again is to help interested students that can't afford our program. In the future, we're also strongly considering low cost self-serve options. Though the efficacy of passive video is limited, I honestly think we do them much a lot better than everyone else. And so if people watch *better* videos than they would otherwise, that's still a big win for everyone.

Hey Adrian! Just checked out your channel too. Looks neat. I don't know anything about web scraping.

Thank you!

The purpose of using data structures and algorithms is to minimize the prerequisite knowledge required. Otherwise, candidates would have to study X for one company, Y for another company, and Z for others. A lot of the things that you mentioned, like code design, can be assessed in algorithms interviews. The more difficult the problem, the more good design and readability matters. You said "Someone can be really good on problem solving/DS&A and not be competent in other, more common, things." Totally agree. Problem-solving ability will not immediately translate to tasks that require prerequisite knowledge. If you're a backend engineer, it'll take you a period to get up to speed on a different domain, like frontend, no matter how good you are at problem-solving. It is true that most people don't run into issues where skill with data structures and algorithms is the *limiting factor*. But at scale, it often IS a limiting factor because of the size of the data. Also, even when performance is not a limiting factor, it still informs program design. In our internal research, people routinely make important decisions based on performance misconceptions. CS researchers have had similar findings. See blog.brownplt.org/2022/10/10/performance-preconceptions.html. Completely agree that algorithms interviews DO NOT tell you whether someone can "create a new screen in your app". But that's not what these companies are trying to figure out.

​@@GordonZhu The way I see, when people say that interviews are broken, they don't mean that they are not happening exactly as designed by companies. They mean that the design itself is flawed. For example, when you say in the video that companies probes the problem solving skills of the candidates because that's how they differentiate good from great developers, it reduces developer skills to a 1-dimension metric. If you are good at this thing, you are good at everything "easier", which is an absurd oversimplification. The process, as designed, can find a consistent type of developer, but that type is not necessarily of great developers, as I have experienced. Yes, minimizing the prerequisite knowledge is a good thing in general. I don't think data structures and algorithms are, necessarily, bad for the interview process. You can use it to assess important skills, like problem solving or getting an insight on the person way of tackling a problem. 100% agree with you here. But I disagree that you can get a lot about other skills. If you are capable of going through a difficult problem, trying to find a solution, and then thinking if there is a better solution, implementing it, while thinking/developing a good design, with abstractions, implementing patterns, following principles, or whatever would make that a good design, in just 45 minutes, you are in another level. Easier problems could be used to asses these other things a bit better, but you lose data on problem solving. Also, if you agree that we can and should assess these kind of things in a candidate, you should agree that DS&A is not the only thing should know/study for an interview. Which is why I think that reducing the interview process to evaluate only DS&A, just because it is somewhat universal, is a super flawed logic. I had an interview in the past where the interviewer and I were chatting for maybe 30min about a lot of different topics in a higher level, like APIs, DBs, infrastructure, security, etc. Did that evaluate my problem solving skills? No, but it was valuable for him in other ways. I'm not saying that it's a better solution, but combining a few different strategies like that could result in a much more complete assessment of the candidate skills. I am aware of the misconceptions about optimization. Martin Fowler says that "If you make an optimization and don’t measure to confirm the performance increase, all you know for certain is that you’ve made your code harder to read.". That's because people with the misconceptions can think they are making things faster without it actually being the case. Knowing algorithm complexity analysis can help you optimize your code, but it's not always that simple, as asymptotic behavior can mislead you. Also, code run time optimization is just one link in the overall service optimization. If a service runs 10% faster after a code optimization, but becomes 20% harder to maintain (new functionalities get harder to implement or bugs harder to fix), than the original optimization may no be worth. Writing clear code, in this sense, can be a lot more valuable than optimizing it. Yes, there are situations where you can get a lot from optimizations, but if you want to evaluate something more universal (the argument for using DS&A), you should focus more on the things that makes a code more maintainable. Adding something new if you allow me, what I understand when people say there is a lot of memorization behind interviewing, that's because the preparation requires a lot of "training" to get (or regain) the hang of problem solving. There are even books that gives tips on how to solve the problems fast. Once you get the job and stop "exercising" your interview problem solving skills, they quickly degrade. If you ever need that kind of skill in the job, you will have to re-train yourself. Same for the tips that are not useful outside of the controlled interviewing process. I understand that there is some value in being able to train and get good in the first place, but if you do something almost exclusively for the interview and nothing more, something that you will not keep in the long term, it can feel a lot like memorization.