IMHO, you can't really drill for technical interviews. The landscape is way too large for one to be fresh on whatever they ask you to do.
1) you don't have to know everything, only the topics they happen to ask. You are rolling the dice, but part of the time you'll be lucky. Besides, after reviewing for a few months (also did 4 yr degree in CS) I felt really strong in the algo topics. That said, I started half of my recent Google interviews thinking "how the fuck do I solve this? is this where I fail?"
2) Aside from the topics, you can absolutely drill the process. Drill a basic flow like understand/clarify the question, do examples, mention a brute-force, etc. when you do LC problems.
Good interviewers want you to pass, and aren't just giving you a test of arbitrary programming trivia.
Lip service is certainly paid to 'everyone has to look things up', and doing a quick search won't necessarily count against you, but, IME, the hesitation and doubt that caused you to look things up will. With so little material with which to evaluate a candidate, absolutely everything that doesn't impress them is going to count against you.
This is certainly Google’s philosophy, but our industry doesn’t think with one mind on this.
And as for having so little material - to me this is a sign of a badly designed interview. Almost everyone is weak in one area or another. If your interview only assesses candidates in one way (eg via a coding challenge, or based on a single whiteboard problem) then you are making a decision with insufficient signal. Multifaceted interviews are good interviews.
Plenty of otherwise strong candidates are weak in at least one section of any assessment. And plenty of bad hires will still, for example, know trivia about data structures even though they don’t actually know how to program. Making a hiring decision based on a single metric leaves way too much to chance.
(Source: I’ve done over 400 technical interviews)
> "I'd Google the exact algorithm for X"
This is a fail in the interviewer's book. Read: "Could not produce an algorithm with less than O(n)" or "lacks familiarity with fundamental data structures"
1. HackerRank (or similar) challenges are pretty close to what you'd find in a lot of technical interviews.
2. Searching online for "<technology> interview questions" for a few of the technologies that you're likely going to be asked about. Make sure you have good answers for the questions that pop up a lot. This helps a lot with remembering Stuff You Should Know that kind of slipped your mind (ie., angular digest cycle) because you maybe haven't seen it in a bit.
3. Write up a summary of your previous accomplishments and be sure you can call them out on the spot.
A lot of what the interviewer is looking for is confidence. And preparation begets confidence.
If you drill enough of the Coding questions, they all start to run into similar buckets, and the way you approach them improves too. Buy a whiteboard off amazon, solve them legit out loud explaining what you're doing to yourself. You will get better.
The other stuff is great advice too, always try to have a summary (in your mind or on paper) of recent projects etc.
And of course.. Doing interviews helps to :D
Interviewers should be looking for competence, not confidence.
It's not easy either. If I mess up once while giving advice on a place where the candidate is stuck, I can really confuse the candidate. Plus the time cost of reviewing a person's resume to determine what questions are appropriate for them. Lastly, I can't be expected to know all the tech on someone's resume at a level that I can gauge their capabilities, I use other means to determine if what a COBOL person is telling me is accurate.
So you have to kind of plan that interviewers take shortcuts (like judging confidence) and take advantage of that fact. If someone asks what are some benefits or drawbacks to a tech stack you use, have at the ready a good story about a shitty/hilarious/intersting experience you had while developing it. The experience doesn't need to be a 1-to-1 mapping either, it's a-okay to kind of nudge a question towards an answer you prepared.
This is better advice than you're really appreciating. If you feel like you are doing this, but still am having trouble, it's likely that you need work in some other non-obvious aspect of interviewing. I highly suggest finding a coach or someone who can take you through mock interviews and help you find out exactly what you can do to improve your chances!
LC problems are not always well written and a lot of times you just have to hope someone took the time to write out a good solution. A lot of times they just paste their code and expect you to get it.
For me personally, my brain goes completely blank at the problem statement, pretty much in the dark without a flashlight, and I have to work everything out by hand and hope that my code actually ends up being correct and reasonable. It's scary but I've ended up doing well.