Outstanding post, especially the supplement info from others. Most of the opportunities I've seen in DS also have emphasized engineering over science. (Maybe that's due to my job history.)<p>I've also wondered what fraction of DS employers use Hadoop but not enough data to warrant it. Certainly the DJIA giant pharma where I work doesn't.
For anyone who isn't a data scientist, much of this applies to any interview experience, especially the latter part of the article.<p>Recruiters and companies tend to flip out when I push back, but you know what? That is an excellent signal that this is the wrong job for you. I only have a very brief time to form an impression of your company and your team; why come to me with irrational or unsupported by the data behavior? I really don't understand it. Everyone claims hiring is really hard, and then they do everything they can to alienate the interviewee, then wonder when the offer is turned down, or why the person failed to perform some stupid coding trick on demand they last saw 20 years ago, maybe, in a classroom.<p>Make the interviewee like you and want to work for you. That shouldn't be hard to understand. Then figure out what work you need to have done, and talk to them about it. It'll be readily clear in most cases. If you are lucky and land a live one, there mind will be straying far from the constraints of your little problem and pretty much have grasped your business, your problems, and are full of ideas of how to improve them all. If not, you probably still have a good worker (if they are able to do the work, i.e. didn't lie on their resume).<p>I would add to this article - do what you can to see the source code[1]. If you can't, often questions can expose what it is like. Most won't give good answers, but if you are put through the normal wringer one of the 6-12 people you talk to will be fairly open and honest. Every place has warts and limitations - the question is whether these are due to inavoidable tradeoffs (jump on board), or a horrible culture/infrastructure (run away unless you are being very, very well compensated to fix the problem).<p>[1] trawl the github/bitbucket page of every engineer if you have to, or of course the company's pages if they do open source. It's surprising how much undocumented spaghetti is released by companies in 'support' of their products. I'm mulling pulling it up on a laptop and doing a little code review if the questions for me get silly. But realistically, I'll probably not accept the offer to interview if it is really bad.