10 karma · joined July 23, 2011
2. Their unit test coverage was not good enough which incidentally is how I found that there were bugs. The problem in trying to contribute back to the community by trying to rectify these bugs? When I read the source code, I get the feeling that each algorithm is owned to a great extent by one developer who brings in their own idiosyncrasies which means that you need to really study the code to make sure you don't accidentally add more bugs. The other disadvantage of this approach is that questions regarding potential bugs and puzzling issues can go unanswered or answered in an unsatisfactory manner (mainly because of the one developer writing most of the code issue).
Having said all this, I want to be charitable and chart these to growing pains. But if I were building something critical and big dataish, I would either use Python (dumbo) or Scala which are much more concise languages where it is easier to express math without introducing bugs.
4) So the fact of the matter is that you should be versatile enough to absorb their tech stack as soon as possible. That is possible only if you have worked in depth in at least one tech stack. This is especially true for Map Reduce based technologies.
Its hard to be specific: All those things are doing in analytics departments. There are not many machine learning people in my place of work so I mostly find problems that require algorithmic solutions and try to see if I can solve them. Things probably are more structured in larger companies..
1. Its not necessary to have the necessary degrees: I did but a lot of people in my team come from the social sciences and other fields. You might find it hard to cross HR but that is something that can be rectified by cleaning up the "weird parts" of your resume and highlighting the "right parts". You seem to have a good handle on what is what on that front.
2. Your statistics, linear algebra and probability skillset need to be upto par. People from a more statistical background will grill you on those things. Its extremely easy to see whether a person can think statistically by giving them a toy data problem and asking them to hack at it. The way to train for it is to play around with small datasets and I see you have been doing that a bit.
3. People who come from a more C.S. side of things will try to explore your knowledge about "machine learning algorithms" which typically are easy to learn if you know your math background. The field has a lot of jargon which might appear to make it fancy. Again, the math behind these algorithms is not hard but there are things that you learn about how these algorithms work in practice that really make a difference. So again doing small projects and putting them up on github will help you learn more and make your resume look good.
4. Technology: There are loads of languages that are used in practice. Make sure you know one scripting language (R, SciPy/NumPy or even Matlab) and are comfortable using that as your scratch pad. The people who are statistically oriented in my team use R. Other skills that are extremely valuable but won't kill you to know are to learn the Map Reduce Stack (Java (uggh), Pig).
I am currently doing machine learning on a dataset. This involves typically playing around with the data in NumPy and sometimes Matlab. Once I am comfortable with a particular choice of algorithms, I try to write it up in Pig. I use Java (Hadoop) for the worst case scenario.
Hope this helps...