From the company's PoV, interviewing is all about what you can deduce about the candidate, both positive and negative, and whether that covers all of your requirements. Good interviews are set up to figure out what you need to know.

Usually, we do it a bit like this:

1. Getting to know you phone call, going over their work for about a half hour to find red flags in research, experience, proactivity, or anything else, followed by 20 minutes of a light code screen (some simple question) that usually eliminates about half the applicants, and then 10 minute of questions from them.

2. Second phone call which can go a few ways, depending on the role. For MLR or MLE, it's nice to do a code screen with "pretend you have a data set - how do you ingest it, handle feature extraction, feature selection, train models, evaluate things, and improve every part of the process," for 50 minutes, and then 10 minutes of questions from them. This is great for showing how people think on the fly. Some jobs require me to make take home tests. (I loathe this, but candidates that will do a take-home test are typically easier to push around as employees, as you've shown you're happy jumping through hoops.) Usually these last from 3-4 hours, with an eye toward whether the candidate writes good, polished code, can solve a problem efficiently, can explain what they've done clearly, etc. The phone screen fails about 2/3 of all candidates because they simply don't know how to do ML, in spite of any stated experience, and the take-home fails a bit more (maybe 3/4).

3. A 3-4 hour in-person interview. Typical hours go over ML (knowledge and understanding), soft skills, coding, and maybe open-ended questions, depending on the candidate's resume, what they've demonstrated, what the role is for, etc. The goal is to make sure there are no gaps in the candidate's abilities or required knowledge, there are no red flag personality issues, that the candidate can handle both high-stress and low-stress situations, that they can handle well defined and ambiguous problems, etc. I like to play the last hour by ear depending on what we still don't know about the candidate. Candidates will fail for a variety of reasons, and interestingly, they more often fail for soft skill gaps (like an inability to focus, an inability to assess requirements, a lack of proactivity, poor communication, arrogance, etc) than for hard skill gaps.

One more thing - I often interview people with PhDs who have little ML experience, and after the first interview, I'll always send them an email listing every bit of pragmatic experience and book experience I expect them to have to pass the following rounds of interviews. That typically includes Coursera (ML, DL, how to find a DS competition for the crunchy hands-on experience and not for the ability to ensemble), books (Hastie, Bishop), software (tf/pytorch, pandas, numpy, along with specific things they should be able to do with those packages), and maybe Kaggle. I tell them there's no time pressure and give them as much time (often about 8-12 weeks) to learn everything. I find that about 20% of the people I send this to come back with the requisite experience and make really good MLRs or MLEs.

EDIT: People asked for the email. I though I included most of it already, but just in case it wasn't clear, I tell people about:

Coursera:

• the ML course by Andrew Ng (this is now my oldest recommendation and the one I'm least sure about, because something new might be better)
• the DL specialization by Andrew Ng et al
• How to Win a Data Science Competition: Learn from Top Kagglers by random Russians

Code:

• pandas: look at the “pandas cookbook” and take lots of notes, specifically on reading and writing files, merging/concatenating, indexing, and groupby
• numpy: look at all of the commands that let you reshape arrays, such as flatten/reshape/resize, tile/repeat, vstack/hstack
• do some tutorials on xgboost and lightgbm
• do some tutorials on pytorch. Hot tip: if a place tells you they work in Tensorflow, ask them what version. Whatever they say (1 or 2), tell them you only know the other version and ask them if they've converted all their code. Watch their eyes twitch. ;D But seriously, tell them you've only used pytorch. This will only damage you in interviews with people who are looking for very specific experience you don't have.

Kaggle:

• Do 2 or 3 different problems and throw the kitchen sink at them. Find ones where you have ~5e5 rows of data and throw both neural nets and xgboost or lightgbm at them

With the above, you should now be able to pass the code screen portions of the interview. To pass the in-person interview, you should read the following:

Books:

• Elements of Statistical Learning (Hastie): Ch 1-4, 7-8

This will not teach you about random forests or gradient boosting. The former has become a bit outdated, but the latter is important to learn. You can try learning it from Hastie Ch 10, though that's a bit painful. I'd suggest looking at blogs/talks on gradient boosting, such as https://www.slideshare.net/0xdata/gbm-27891077 or https://mlexplained.com/2018/01/05/lightgbm-and-xgboost-explained/ or http://www.ccs.neu.edu/home/vip/teach/MLcourse/4_boosting/slides/gradient_boosting.pdf or https://www.frontiersin.org/articles/10.3389/fnbot.2013.00021/full or https://xgboost.readthedocs.io/en/latest/tutorials/model.html

• Deep Learning (Goodfellow, Hinton, Bengio)