Don't bother with books about how to get a job. You're wasting your time.
Instead, spend more time with books about hiring. How to run an interview, what to look for, ect.
The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.)
At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you.
BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."
You are still asking the leetcode question, and no matter how fairly you explain it the candidate who practised those questions will probably do better.
I doubt it. Leetcode questions tend to be deliberately technically challenging, and focused on algorithms.
I don't ask technically challenging questions. I'm more focused on comprehension in a technical discussion, and a basic comprehension of concepts that are critical for the product that I work on.
Don't bother with books about how to get a job. You're wasting your time.
Instead, spend more time with books about hiring. How to run an interview, what to look for, ect.
The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.)
At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you.
BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."