I think the degree of "classical"/"foundational" relates to your exact thesis topic so it is hard to judge. And even then you can always put spins on it. For example a PhD thesis topic on"Reformulations of James-Stein estimators in the context of letf-censored data" would be indeed quite classical but then again if you want to focus on bio-themed ML applications, having a strong theoretical background on working with censored data. More directly, standard guidelines apply:

1. Collaborate with people outside your domain. It doesn't matter much if those are from the Biosciences, the Medical School or the Languages school. Show that while you are specialised, you can apply your specialism. (see point 3 too) This can also help to get a foot through the door for conference papers. (see point 2 too)
2. Publish multiple (non-junk) papers. That one, final year, awesome paper of Annal of Statistics might be the clutch 3-pointer for that junior faculty position but a steady research output stream even if less impactful shows you can deliver continuously. Early on it is actually quite hard particularly for non-specialists to evaluate the significance of a publication.
3. Code reasonably well. I am not talking C++ template meta-programming here, but be able to show that you can create an R or a Python package with some reasonable structure and quality. Extra point if you can use "ML tools" like JAX or PyTorch Lighting. You are not going to be lone gunman, you will be part of team. (Relates to point 1 a bit)
4. Know your ML fundamentals well. That's not that hard; you are a Stats PhD, being able to adequately explain GBMs or NNs Backprop or GMMs or Langangians means that someone from ML can talk shop with you. Yeah, you won't know particulars of AutoDiff or PPO; who cares? They won't probably know them either unless they are actively working on the matter.
5. Network. There is some network connectivity involved in hiring as well as in information diffusion. In addition, references matter. I remember out head of recruitment at my first job telling me that if I knew a good candidate I should let them know because for each position they would weed out internal referrals first (it makes sense, someone has already done "some screening").

This is a very broad question but in general, yes.

On multiple occasions there such a big overlap between the fields that unless someone is doing some highly specialised (e.g. some very particular problems in Measure Theory or Computer Vision) the underlying skills will be transferable and almost interchangeable (e.g. in Gaussian Processes- or Causality- related topics).

I don't think it is great question generally but this also depends on the position, the level of technical aptitude and seniority expected.

It is not something I would expect most people to rock up with in 15' while someone is looking over their shoulder. Probably it is a question that will help me to distinguish a kick-ass junior than someone who has a standard Keras syntax understanding but for more seniors roles this is likely a bad indicator. Far less senior engineer tasks fail because the person couldn't code backprop from scratch than because the wrong architecture was chosen, or they didn't know what part of an existing pipeline to optimise, or where to look for potential bugs given a particular unexpected behaviour, etc.

In general, I think it was more a point of "showing your thought process" than actually getting the code right. I would "abstract" things quite a bit first and then "start coding". But as others said, if they absolutely need to "split hairs" that is a way to do it too.

Best of luck with your interview in any case!

Not a single mention to boosting? Harsh...

Additive logistic regression: a statistical view of boosting (With discussion and a rejoinder by the authors)

​

1. This is an extremely serious accusation.
2. Even in your blog-post you at best provide ~12 sentences/very short passages that are reworded and/or copied verbatim.
   1. You can raise a valid point about the C-P ones are not properly annotated. Yes, a serious issue indeed. It is unacceptable, they should be in quotes, italics, etc.
   2. The reworded ones you provided are mostly descriptions of some known systems. I haven't read the thesis itself but that's pretty minor, ultimately you describe system/algorithm/procedure X you are going to use similar words.
   3. Twelve instances at best constitute reason to make minor amendments. If we are talking about an an average PhD thesis that is 100+ pages long, all the passages you give probably amount to a page or a page and a half. Again, should they be fixed? Yes.
3. I somewhat doubt you appreciate what the spirit of plagiarism in a PhD thesis is. I have seen plagiarised theses and we are talking about c-p multiple pages, using the results of other people as your own, claiming substantial findings with data/work that ain't you own. The instances you give? That's some lazy referencing and lax refereeing. Not great but the world has much, much bigger fish to fry.
4. You have blown this completely out of proportion.
   (And to state the obvious here, I have no affiliation with Theodorou, Bath U. or Umea U.)