I work with a lot of people from both bootcamp backgrounds and CS backgrounds that find applying fundamentals to technical interviews quite challenging. It's definitely hard, was hard for me to.
The big mindset shift for me happened after I started interview others. I ran hundreds of interviews at Facebook and it really changed how I see the process. I realize this isn't helpful advice, "get a job at Facebook and do hundreds of interviews" but yes there is hope.
u/DoggySnack wrote (the comment Michael replied to):
So if doing hundreds of problems isn't the best advice, what do you recommend doing on top of consistent practice?
u/michaelnovatireplied·
The interview process is not about solving Leetcode problems, it's the biggest misconception people have grinding Leetcode online. As I said, 8 years E7 principal engineer, trained interviewers, now I help mentor people and have helped people struggling on Leetcode get jobs at dozens of top companies, so I can speak confidently to my experience, but it's just my view.
1. You need personal feedback and advice on what to improve on. Getting feedback from hiring managers, peers, senior engineers (who have done a lot of interviews). I find people, myself included, get way too caught up in solving problems alone in their rooms. At the end of the day, these problems exist because they represent interesting computer science concepts/patterns and you have to be able to explain them out loud to people in a way they understand, not just write solutions alone.
2. Efficient studying. People pride themselves on the number of problems they've solved but I assure you the higher the number the more time was probably wasted studying inefficiently. If you already thoroughly understand binary trees, you don't need to do more binary tree problems. Going back to number 1 though, people often don't know that if they understand something "enough".
3. Focus on the method and not memorizing specific solutions/strategies. I've read some bizarre conversations like "why can't I pass this question?", "you need to change like 20 to a hash table", "oh that worked it passed when I made that change!". The discussion should be around the CONCEPTS, not how to just pass the questions.
Finally, my common analogy here is the toolbelt analogy. A really good handy-person will be able to get a lot of repairs done by creatively using minimal tools. They might use really old worn out tools and a hammer in the most interesting ways. But by knowing how to use these simple tools so well, with a little creatively, they can get a lot done. Grinding Leetcode is like trying to hang a photo by going out and buying a brand new complete set of every tool possible, and then using the "right" tool kind of improperly. You might get the job done, but you weren't really using the tools entirely properly.