Some additional points since i'm currently interviewing a lot
-Practice leetcode since it will make up 50-60% of the interview process
-Study your resume inside and out, know the whys of what you did not just the whats
-Don't talk too much, sometimes nervousness and anxiety can make itself with a candidate talking too much or too little, both are bad, be concise with your answers but don't ramble on, the more you ramble the more surface area you give the interviewer to poke holes at what you said. Being concise can lead the interviewer towards areas where you are most comfortable answering questions.
-Realize you might be an amazing developer but you only have a couple of hours to show prospective employer what you got, don't be too harsh on yourself if you get rejected, it is impossible to know a person in 3 hours, they are merely going based on their best judgement of you (which is mixed in with actual performance considerations and bias many times) and not the "reality" of you.
“Don’t talk too much”, this so much. Address the question. If you have done that, talking more can only make it worse. If you want to take the discussion further, finish your answer and ask a question to signal that there is something more that might be of interest to the interviewer.
And, if you can do that where you are, put yourself forward to be interviewing. After about 20-30 interviews you’ll find a few nuanced insights, some of them specific to your area.
At least in big tech cities it is in no way a ridiculous thing to say. I interviewed with about 20+ companies based in SF, NYC, Seattle and only one loop didn’t have leetcode equivalent steps
> Practice leetcode since it will make up 50-60% of the interview process
I think this depends on the role. I was interviewing for staff level front end roles a few months ago and didn’t have a single leetcode-style interview. All the coding questions were realistic problems.
i've known senior front engineer who were asked a little of leetcode type problems at big tech. Were you interviewing at big tech companies? Startups are just kinda random in my experience, they all have their own unique processes.
deeply understanding 1 problem per day is better than reading the solutions of a dozen. Solving leetcode via induction could prove valuable, solve a simple case of n = 1, then try to solve n = 2 do you see a pattern? try to solve n = 3 etc... Don't assume anything, don't categorize problems before thinking of patterns, sometimes dp problems are simple greedy problems, don't go into problem solving with bias. Look to build raw problem solving ability more than remembering problems of a certain flavor. understand advantages of linked list vs arrays, understand dictionaries, understand dfs vs bfs (both traverse graphs but what property does bfs have over dfs?), understand heaps, understand general recursion flow for binary trees,
theres no book, and theres no easy way to get good at that stuff, just have to practice problems and learn about better ways of solving problems via new algorithms and data structures you did not know about.
-Practice leetcode since it will make up 50-60% of the interview process
-Study your resume inside and out, know the whys of what you did not just the whats
-Don't talk too much, sometimes nervousness and anxiety can make itself with a candidate talking too much or too little, both are bad, be concise with your answers but don't ramble on, the more you ramble the more surface area you give the interviewer to poke holes at what you said. Being concise can lead the interviewer towards areas where you are most comfortable answering questions.
-Realize you might be an amazing developer but you only have a couple of hours to show prospective employer what you got, don't be too harsh on yourself if you get rejected, it is impossible to know a person in 3 hours, they are merely going based on their best judgement of you (which is mixed in with actual performance considerations and bias many times) and not the "reality" of you.