| This is very detailed. Pretty similar to what I have seen in industry. A few comments from a guy who has been involved in several ML teams for the past few years. 1. Hire depending on your team. There are candidates who are amazing data scientists but do retarded shit like select * from table order by rand() on a ten billion row table and bring down the cluster. Sometimes, it is OK because your team has incredibly strong engineers who can work in close combinations with these people. Sometimes you can't really afford that. At my current workplace, my manager did a really good job of hiring people who are fullstack (data + backend + viz + ml) while having strong preferences in one direction or the other. So you might have an incredibly strong ML engineer who can roll his own ML code out on Spark, while also being open to writing back-end infrastructure code once in a while. Or you might have this guy who thinks in data pipelines all day long, but will spend a bit of time thinking about mathematical model. The teams work well. 2. Hiring for ML teams is really really hard. When I was in San Francisco at my previous job, we used to screen quite a few candidates everyweek. We would see failures similar to what you posted. Either engineers who knew fuck all about ML or people who were good at the theory but didn't know how to code. Somehow, at my current job in NYC, we lucked out because we have a bunch of really awesome people who moved out of finance but want to continue to live in NYC. > They may (or may not) have a very deep understanding of one tiny piece, but lack a decent understanding of the breadth of the field. This is close to what I have seen from both sides of the table. But, one thing that annoys me is the number of teams where people have pet algorithms that they are obsessed about. They keep asking questions about those pet algorithms and ding a candidate for not knowing that specific algorithm in depth. One should be able to be flexible while doing this. > They don't know deeply at least one or two techniques and tools. I think we see people from so many different walks of life that for junior people the goal is to make sure that they know the shit that they have in their resume and drill them if they don't. As in, we don't hire for specific techniques or tools because the team has its own collection of tools/libraries (Spark/Hadoop/Python/Word2Vec/CF etc) which you will be able to pick up fast if you are good enough. |
> I think we see people from so many different walks of life that for junior people the goal is to make sure that they know the shit that they have in their resume and drill them if they don't. As in, we don't hire for specific techniques or tools because the team has its own collection of tools/libraries (Spark/Hadoop/Python/Word2Vec/CF etc) which you will be able to pick up fast if you are good enough.
I think you misread what eshvk was saying; he isn't saying that they don't know one or two specific techniques or tools, but rather they don't have any tools/techniques at all that they know deeply. If you read what followed the part you quoted, it should become clear.