BickNowstrom

Learn Python stack: scipy, numpy, pandas, scikit-learn, jupyter, matplotlib/seaborn.

Learn machine learning tools: XGBoost, Scikit-learn, Keras, Vowpal Wabbit.

Do data science competitions: Kaggle, DrivenData, TopCoder, Numerai.

Take these courses: https://www.coursera.org/learn/machine-learning http://work.caltech.edu/telecourse.html

Work on soft skills: Business, management, visualization, reporting.

Do at least one real-life data science project: Open Data, Journalism, Pet project.

Contribute to community: Create wrappers, open issues/pull reqs, write tutorials, write about projects.

Read: FastML, /r/MachineLearning, Kaggle Forums, Arxiv Sanity Preserver.

Implement: Recent papers, older algorithms, winning solutions.

As a software engineer you have a major advantage for applied ML: You know how to code. AI is just Advanced Informatics. If you want to become a machine learning researcher... skip all this and start from scratch: a PhD. Else: Learn by doing. Only those who got burned by overfit, will know how to avoid it next time.

> ... so badly fooled while obscuring such a small amount of the face ... may go completely off the rails when presented with data not close enough to their training sets.

Older research has looked at this, in the context of neural networks in self-driving cars. The nets take the easy way out: use just the most significant features (like road markers) to solve the problem. However, training sets may not contain roads where snow or fog is obscuring these significant features, which makes the nets fail, because they haven't learned to rely on other features too. In contrast, human vision is remarkably robust.

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1176&c... [pdf] "FeatureBoost: A Meta Learning Algorithm that Improves Model Robustness"

Since the added noise is not just noise, but especially engineered perturbations to maximally activate the output neurons for a certain class -- if you want to draw a comparison to humans, one could look at the hyperstimulus/supernormal stimulus.

https://en.wikipedia.org/wiki/Supernormal_stimulus

Vilayanur S. Ramachandran proposes that the hyperstimulus is responsible for exaggerated forms in (primitive) art, so to maximally stimulate our brain: https://www.youtube.com/watch?v=7ZTvHqM-_jE

Further to fringe, this sci-fi short story about deviously crafted basilisk images that crash the human brain: http://www.infinityplus.co.uk/stories/blit.htm

> This first example of the Berryman Logical Image Technique (hence the usual acronym BLIT) evolved from AI work at the Cambridge IV supercomputer facility, now discontinued. V.Berryman and C.M.Turner hypothesized that pattern-recognition programs of sufficient complexity might be vulnerable to "Gödelian shock input" in the form of data incompatible with internal representation. Berryman went further and suggested that the existence of such a potential input was a logical necessity.

Ensembles are also vulnerable to adversarial images.

From one of the canonical papers on adversarial images:

> In addition, the specific nature of these perturbations is not a random artifact of learning: the same perturbation can cause a different network, that was trained on a different subset of the dataset, to misclassify the same input.

> ... suggest that adversarial examples are somewhat universal and not just the results of overfitting to a particular model or to the specific selection of the training set

https://arxiv.org/abs/1312.6199

More recent research shows that one can make adversarial images which fool ensembles. Once you have these images there is a very high chance it will also fool any individual architecture you pass it on to next.

https://twitter.com/goodfellow_ian/status/790330213963923456

These attacks show the inherent flaws of ML models (not just convnets, as per http://karpathy.github.io/2015/03/30/breaking-convnets/ ), and as far as I know, they are not trivial to work around. Research on adversarial images is still very active, in part because the military would like to rely on deep learning, and does not like to mistake a tank for a puppy (and vice versa).

You are right, but only in a very strict, not-fun, manner :). Even if we had more data on different boats sinking, the model would not be very useful: We don't go with the Titanic anymore and plotted all icebergs. Still, if a cruise ship were to go down, I'd place a bet on ranking younger women of nobility traveling first class higher for survivability than old men with family traveling third class, wise predictor or no.

This dataset is more in line with what you are looking for: https://www.kaggle.com/saurograndi/airplane-crashes-since-19...

The people who win Kaggle competitions are consistently machine learning experts, not domain experts.

Notably: https://www.kaggle.com/c/MerckActivity

> Since our goal was to demonstrate the power of our models, we did no feature engineering and only minimal preprocessing. The only preprocessing we did was occasionally, for some models, to log-transform each individual input feature/covariate. Whenever possible, we prefer to learn features rather than engineer them. This preference probably gives us a disadvantage relative to other Kaggle competitors who have more practice doing effective feature engineering. In this case, however, it worked out well.

http://blog.kaggle.com/2012/11/01/deep-learning-how-i-did-it...

> Q: Do you have any prior experience or domain knowledge that helped you succeed in this competition? A: In fact, no. It was a very good opportunity to learn about image processing.

http://blog.kaggle.com/2016/09/15/draper-satellite-image-chr...

> Do you have any prior experience or domain knowledge that helped you succeed in this competition? I didn't have any knowledge about this domain. The topic is quite new and I couldn't find any papers related to this problem, most probably because there are not public datasets.

http://blog.kaggle.com/2015/09/16/icdm-winners-interview-3rd...

> Do you have any prior experience or domain knowledge that helped you succeed in this competition? M: I have worked in companies that sold items that looked like tubes, but nothing really relevant for the competition. J: Well, I have a basic understanding of what a tube is. L: Not a clue. G: No.

http://blog.kaggle.com/2015/09/22/caterpillar-winners-interv...

> We had no domain knowledge, so we could only go on the information provided by the organizers (well honestly that and Wikipedia). It turned out to be enough though. Robert says it cannot happen again, so we’re currently in the process of hiring a marine biologist ;).

http://blog.kaggle.com/2016/01/29/noaa-right-whale-recogniti...

> Through Kaggle and my current job as a research scientist I’ve learnt lots of interesting things about various application domains, but simultaneously I’ve regularly been surprised by how domain expertise often takes a backseat. If enough data is available, it seems that you actually need to know very little about a problem domain to build effective models, nowadays. Of course it still helps to exploit any prior knowledge about the data that you may have (I’ve done some work on taking advantage of rotational symmetry in convnets myself), but it’s not as crucial to getting decent results as it once was.

http://blog.kaggle.com/2016/08/29/from-kaggle-to-google-deep...

> Oh yes. Every time a new competition comes out, the experts say: "We've built a whole industry around this. We know the answers." And after a couple of weeks, they get blown out of the water.

http://www.slate.com/articles/health_and_science/new_scienti...

Competitions have been won without even looking at the data. Data scientists/machine learners are in the business of automating things -- so why should domain knowledge be any different?

Ok, sure it can help, but it is not necessary, and can even hamper your progress: You are searching for where you think the answer is -- thousands are searching everywhere and finding more than you, the expert, can.

Because we are not doing hypothesis testing, we are doing classification on a toy dataset. Sure, one could treat this as a forecasting challenge, but then one would need another Titanic sinking in roughly the same context, with the same features... That demand is as unreasonable as calling this modeling knowledge competition meaningless.

And if you see classification as a form of hypothesis testing, then cross-validation is a valid way of testing if hypothesis holds on unseen data.

It is swarm intelligence: How does the system keep finding successful paths in a changing environment? Can we take inspiration from this behavior to create better optimization algorithms?

Simulation can be a very beneficial experiment. See for instance: https://papers.nips.cc/paper/5351-searching-for-higgs-boson-...

This challenge is not about causal inference. I do agree it is more of a toy dataset, to get started with the basics, and that there are a lot of other variables that go into survivability. But to say these variables, except for age, are irrelevant is mathematically unsound: You can show with cross-validation and test set performance that your model using these variables generalizes (around 0.80 ROC AUC). You can do statistical/information theoretical tests that show the majority of these variables is a significant signal for predicting the target.

In real life it is also very rare to have free pickings of the variables you want. Some variables have to substituted with available ones.

The Titanic story is to make things interesting for beginners. One could leave out all the semantics of this challenge, anonymize the variables and the target, and still use this dataset to learn about going from a table with variables to a target. In fact, doing so teaches you to leave your human bias at the door. Domain experts get beaten on Kaggle, because they think they need other variables, or that some variables (and their interactions) can't possibly work.

Let the data and evaluation metric do the talking.

Everybody learns differently, but I would suggest starting with the how, not the what. Compare: How do I sort a list? With: What is exactly happening when I sort a list? Application before theory.

Start with a tutorial/pre-made script for one of the Kaggle Knowledge competitions. Move on to a real Kaggle competition and team up with someone who is in the same position on the learning curve as you. Use something like Skype or a Github repo to learn new tricks from one another.

So knowledge like: Did the passenger have kids on board? Was the passenger nobility? Was the passenger travelling first class? Where was the passenger located on the ship after boarding? And how do these factors influence survivability?

And reality like: The actual sinking of the Titanic?

If your model concludes that nobility, traveling first class, close to the exits, without family, has a higher chance of surviving, then this is fancy nonsense or a false belief?

You make a really strange case for your view.

You seem to be saying a whole lot without backing up your argument. If anything, your view is meaningless.

https://en.wikipedia.org/wiki/Ant_colony_optimization_algori...

https://en.wikipedia.org/wiki/Artificial_ants

This entire blog post does not cast the author in a favourable light.

First off: It is rude to post the questions and expected answers, perhaps moreso when you just failed to pass the test yourself. That reeks of sabotage out of spite.

Then pulls the argument from authority, aggrandizing his accomplishments in an effort to salvage some of his obviously bruised ego.

> Is Google raising the bar too high or is their recruiting staff seriously lacking the skills they are supposed to rate?

Seems like Google raised the bar just high enough to weed out the unpleasant personalities. A job interview, even a phone screening, is not all about technical skill, it is also about soft skills: Is this person a pleasant and communicative person?

> Recruiter: wrong, it's file metadata.

> Me: the inode is an index uniquely identifying ...

Here is where the interview (or at least, this is probably how the author remembered it) went off the rails. Arguing with the recruiter and trying to right a perceived wrong was just plain bad strategy.

From there on out it starts being argumentative, and you can see the recruiter having none of it.

> Recruiter: Quicksort has the best big-O.

Here you can clearly tell the recruiter is just fishing for "correct" answers at this point. Just tell the recruiter with the big-O is here, don't be obtuse or difficult.

> Why not let me compare my code to yours in a benchmark?

Here it turns into a code-measuring contest. Not a very bright idea. By this point in the interview I find this author's personality very grating and needlessly argumentative. He can't do anything right by now.

> We will stop here because it's obvious that you don't have the necessary skills to write or review network applications.

The recruiter seems to agree with me, but I doubt this is what was said exactly. The conclusion may be similar though.

> Maybe Google should have stated that practice is not necessary for the job.

Maybe Google does know best what is necessary for the job. Or maybe the author knows, but he is too curt in getting his views across. Not a favourable trait.

It is hard to not get salty over a failed job interview. It takes strength of character to not burn bridges and try again in the future with a more pleasant humble approach. Take it as a lesson and move on.