You wouldn't want to work there.
" but the team has decided to keep looking for someone who might have more direct neural net experience."
Fair enough - but this has to be slim pickins. How many AI jobs are there out there? Realistically, very few.
We got confused, and then we stopped. The end.
apply for 100 jobs, get zero response, and zero reason why.
be told illogical things.
be told out right lies.
welcome to capitalism. welcome to the workplace that is run entirely by data. (or by people who only care about data). welcome to the future of humanity.
1. Break down "data science" into several different roles–in our case, Analyst (business-oriented), Scientist (stats-heavy), Engineer (software-heavy). Turns out that what we mostly want are Engineers-Analysts, so our process screens heavily for those.
2. Figure out which types of people can be trained to be good at those roles, given the team's current skillset. I opted to look primarily for people with strong analysis skills and some engineering.
3. Design interview tasks/questions that screen for those abilities. In my case, the main thing I did was make sure that the interviews depended very little on pre-existing knowledge, and a lot on resourcefulness/creativity/etc. E.g. the (2-hour) takehome is explicitly designed to be heavily googleable.
4. Develop phone screens that are very good at filtering people quickly, so that we don't waste candidates' time. By the time someone gets to an onsite interview on our team there's something like a 50% chance they'll get an offer.
On the candidate side, when I'm applying I try to figure out first and foremost what a company means by "data scientist", usually by networking & talking to someone who already works there. This filters out maybe 90% of jobs with that title, and then I put more serious effort into the rest.
For instance, a common description might say the candidate will be working with "big data" to help with "data-driven initiatives" and the requirements will be something like "knowledge of Excel, with a Masters in Statistics, or equivalent experience".
It's really hard to tailor a cover-letter or a resume to a job posting like that. For one thing, I can't even imagine what kind of work they are doing if they are using Excel for "big data". Second of all, I currently have a job, and writing cover letters and creating resumes takes a lot of time. By the time I get to the phone screen I've probably already spent at least a couple of hours applying. Plus, in the interest of keeping my cover letter and resume short, I have to leave off a fair amount of my experience and performance metrics.
Honestly, at this point I think I'm just going to start reaching out to people in the fields I'm interested in and asking them if they know of any roles that would fit my skill-set. The way I see it, I'd at least have a chance of getting feedback from someone who can view my skill-set holistically, rather than HR, who will let me know that I don't tick all their boxes (or vice versa).
I lead a Data Science team and part of the struggle with writing sensible job descriptions is that there are too many people providing input into the job description. HR can also put their hand in the pot when they try to use buzzwords (e.g. Hadooop) to internally justify why a role with 2 years of experience needs to be paid like other roles (e.g. traditional Excel based Analyst) with 5-10 years of experience.
>>They tend to have a short description of the role, which is generally filled with buzzwords, followed by a list of requirements. I wish organizations would talk about what they wanted to do with their data instead.
One major challenge for Data Scientists is how hyped the role is, leading to people in an organization believing whatever they want about Data Scientists. Are you a leader who wants a business analyst who can use software and interface with IT? Data Scientist. Are you an engineering manager who wants a person who can interface with the business and use machine learning? Data Scientist. Are you a VP who thinks big data and ML is the problem to your bad or non-existent data? Data Scientist. Do you want somebody who can exhale the maximum amount of hot air while still sounding like a tech and math genius? Data Scientist.
Also add in that business people with minimal experience in modern Analytics are trying to build up Data Science and Analytics capabilities in their own part of the organization because they realize Excel is not the answer to every question. I've spent a lot of time speaking with people to help them understand the type of people they need to hire. Sometimes people are sensible and sensible job descriptions and expectations come from that. Other times they are adamant about what they need (even if they are wrong) and the end result are convoluted job descriptions that are either never filled or filled with the wrong person.
It may seem like a daft question, but have you tried asking them? They may clam up and refuse to give you anything, but I would imagine most small companies would be willing to talk about what the role involves. It's a bit late at the end of the interview to be asking "So what would I be doing?".
You may find out that they're working on some data which is e.g. image-heavy and you happen to be an image processing expert.
Candidates know that, typical in person interview has a 1/10 chance (or worse) of getting an offer from an inperson interview, and so most candidates, including good ones, would care less to spend much time on interviewing with any one employer, or do much to increase their unknown chances.
As a rusult employers don't get right candidates and then wine about lack of talent and pay for crappy tools that just sort resumes half assed way... good grief.
An engineer who wants to learn data science is a great fit for us, an academic who wants to write R all day is not (though an academic who wants to learn engineering/functional programming is fine!)
Beyond that, I ask some questions about projects they've worked on, and in particular, how their approach would change if assumptions were different. Here I'm looking for the ability to reason backwards from a business goal, as opposed to somewhat blindly applying statistical techniques.
If they do well on these, we send the take-home exam. As previously noted, this is specifically designed to require relatively little knowledge but heavily test analysis skills, and lightly test programming skills. It's almost impossible to complete this exam without using Google effectively, so that's another thing I'm testing.
BTW, as to some of that "feedback":
Honestly, I think the way you communicated your thought process and results was confusing for some people in the room.
"Okay, pal - let's put your people up in a room full of strangers (some of whom show through their body language and/or constant phone-checking that they pretty much don't really want to be there in the first place), make them answer some made-up questions (which may or may not be coherently presented; or even particularly relevant to the job description) -- combined with the background stress of being unemployed, and/or stuck in job they absolutely HATE, and can barely stand another day of -- and see how they do."
Quite honestly given your questions [about vacation policy] and the fact that you are considering other options, [we] may not be the best choice for you.
Great -- so they're basically accusing you of being a slacker (not really into the work, only interested in what's in it for you, etc). Which is quite a presumptuous attitude to take in response to a perfectly reasonable question about the value proposition they're asking you to consider (a question for which it might be in better form to wait until the later stags of the negotiation process to bring up... but that's a very minor style point that you definitely shouldn't be dinged for).
"Quite honestly" that attitude sucks. And you don't need to feel bad about being "rejected" by people like that.
Internal recruiters have hinted that my Software QA Engineer background + no CS degree implies I have no technical skill.
Once I got that offer and 'data scientist' was listed as a position on my resume, I've had at least one or two recruiters reach out to me each week. Not just your 'bulk tech recruiter', but individual hiring managers/team leads from companies who had no interest in me prior to the title change.
Hell, I had a manager I had already interviewed with from another company (and got rejected) reach out to me TWICE to come back in. To be honest, I'm not entirely sure he remembered that I had interviewed there only a month earlier.
All after I had the title change on my resume. What I'm getting at, is for me, the title change really opened up doors. I figure 'data science' is such a huge buzzword now, recruiters look more for that buzz word than they do for the actual content of what you've done on your resume. I'm sure it will die down at some point.
This may be more prominent outside of silicon valley where I am, and (in my opinion without any facts to back it up), where I feel more weight is given for the title than the substance.
I've had the following:
- 106 Rejections
- 39 Offers
- 24 Refused
- 15 Contemplated
- 5 Taken
- Software Engineer (55rj, 8o, 6r)
- Product Manager (5rj, 6o, 5r)
- Senior Software Engineer (31rj, 23o, 22r)
- Product Lead (0rj, 1o, 1r)
- Senior Product Manager (9rj, 3o, 2r)
- VP of E (2rj, 1o, 1r)
- CTO (0rj, 1o, 0r)
Things to note:
- People conflate Agile & Scrum a lot.
- Make it easy for people in the room to know what you personally accomplished during your career.
- Make an impression, don't overdo it however.
- Make your descriptions easy to understand.
- Don't just list tech stacks on your resume, list achievements.
- Stay consistent.
- Ask questions.
Regardless how impressive your Github & Stackoverflow accounts might be, you will still be asked to do a stupid code challenge. It irks me. I understand the reasoning for it when you don't have a viable pool of information on the individual, but when you do... It's just disrespectful.
Few places I have been rejected by:
Salesforce, Atlassian, Trello, Twitch, Segment, AirBnB, Twitter, OKCupid, LinkedIn, Shippo, and many many more.
Amazon, VMWare, Oracle, Google (twice), Apple (twice), Venmo, Auth0, Discord, Youtube, Hitbox, Steam, Pusher, CloudflareI'm glad I had those interviews early on, so now when I see an interview start to drag on, I cut it short as it doesn't look like a priority on their end.
I had a very similar experience. Job offer was basically on the table and then they balked because I mentioned that I had another offer (at a larger company, which they seemed shocked/annoyed with) and I had a question about parking at their new offices. The current offices had free parking, so I had simply asked if the new ones would too. The response was very cold (must have a been the source of internal strife, I guess?). An hour later I got a call saying they were no longer interested.
To share my story, I also had a difficult time transitioning into a data scientist role after leaving academia (pure mathematics), and I always thought the root cause was my lack of experience and competency. So instead of keeping on applying, I spent over a year just to sharpen up my skills. It paid off in the end.
How can one develop his/her skills and cultivate expertise if one is job-shopping all the time (possibly aimlessly)?
Dodged a bullet on that one:
- PTO is a touchy subject?
- They are looking at more than one candidate, why would any candidate limit themselves to one potential employer?
I was shocked to hear that, apparently it is somewhat common in retail jobs not to get paid out. Happened to me at a company that claimed to be more of a technology company. Maybe they don't think word gets around. Or that smarter employees will just take a lot of time off before quitting, which does a lot more harm to the company than if they just paid out the time owed to the employee.
I have a hard time understanding. At least for what I've seen/done, it would take about a year of experience to be of any real value. I'd say you start seeing real dividends from an employee near the three year mark. I think the primary exception would be where you have a big gaping hole in an organization...like building a data science program or something from the ground up. But if you've got software and customers long long past the 1.0 stage to support, and someone is going to (someday) understand/contribute to the core? Think about Google's monolith or the Linux kernel...sure most software isn't that mature/grand, but there are many projects out there that are closer to that than greenfield. And it's not just the code, it's the developed relationships/rhythm with coworkers and customers.
Maybe I've explained it to myself, I don't know. The difference may be startup companies or projects versus mature ones. At least in the latter case, it seems to me that if a company retains an engineer for less than 2-3 years, they've almost certainly lost on that investment.
That's actually the only correct answer. Having been on both sides of the table for many years, I can pretty much guarantee that whatever reason the candidate is given is nowhere close to the actual reasons.
There may not be any specific reason why we didn't pick you, but we'll give you a tiny sample anyway. So you think that's the reason - it's not.
In other cases, we have a strong reason not to pick you, but it's embarrassing so we feed you a bogus reason instead.
And in more cases than I'd like, there is no problem on your side, we are having internal issues that we can't reveal anyway. Any reason you hear from us in that case is completely irrelevant.
By the way, when you evaluate people in interview, you really need to figure out a vector: where they are today in terms of knowledge and experience, but also in what direction they are going (fast learner or not, high potential, etc.). Which is why sometimes you can hire someone who has less relevant experience, but you think they'll learn fast and are very smart, and sometimes you are looking for the perfect match to the current position, but don't care too much whether they can pick up new stuff or not.
And your lawyers would strongly advocate against that.
In most cases they can't/won't tell you because it could open up legal liability. If they say a reason for you, but then hire someone else to whom that reason also applies and you find out, you could sue them. Or you could find a way to twist it into something against a protected class. Too many ways for the company to get screwed.
That's why they all say "we've decided to go another way" or something equally generic.
And he was right, too.
But I broke it down as follows. We received 300+ applications, we filtered down to 100 that were worth even reading in detail. From those we took 50 that we discussed/scored as a group, and came up with 15 people we wanted to interview. Of those we interviewed 10, and of those we interviewed 5 a second time, and 3 a (brief) third time.
"So yes, you did well, and we'd like to keep your name and reach out" (said sincerely). But for him knowing that he didn't screw something up, there was just an even better candidate and he was realistically still in the top 1-2% of applicants was confidence-boosting.
It's a difficult enough field to hire in when you understand what it is (and isn't) - and lots of companies are trying to do it with far more vague goals.
(1) They are inundated with applications folks of all sorts of backgrounds: engineering, finance, academia, marketing, BI/analytics, etc.
(2) They still haven't figured out hiring. To be fair, no one really has figured it out. Jeff Kolesky recently covered this as part of an excellent blog post. [0]
(3) In addition to the typical variance in engineering interview processes, we now introduce variance in the definition of data science across companies, which just complicates things further.
(4) Basically everything else Tim mentioned in his post: role or goals aren't clearly defined, remote data science is an unknown, etc.
Let's supposed, for a moment, that the hiring was completely random. 100 people apply, they pick a random name out of a hat, and hire that person.
Your name might never be chosen.
For startups, this transcends data science. It might be the one time that week they focus on that need.
Networking is still king.
Exactly and this also argues against wanting to get hired to work remotely.
True, though not unheard of. I worked at a startup that hired remote devs via networking of that nature. It seemed to work well for them. Eventually the entire team migrated to the same area but things operated smoothly remote for the time being.
- Signal is still quite low among noise, even with long multiple interviews, take-home homework, coding challenges, etc. Most relevant data is still hidden and takes months-years to come out.
- Companies seek to minimize false-positives much more than minimizing true-negatives.
- It's a numbers game from both ends because the probabilities are low, due to above 2 points.
And doesn't bother to respond after you submit. I'm certainly not the world's best coder, but my solution met all those requirements in a reasonably elegant manner, and took several hours (10-20?) to make comprehensive.
That gets you on my shit list, and people I know get to hear about it, too.
Does anyone have any suggestions? Here is my linkedin account: https://www.linkedin.com/in/karl-dailey-02557b65
My takeaway from it.
There is a ramp up time for new hire, which could be a couple of months. So durations of a year or less doesn't look good. I personally like to see minimum of 2 years for each job. Of course, too long can be a concern too unless they really grew in their role.
I agree with his conclusion, Network is king, but I also believe in listening to the universe. If everyone is "wrong", maybe you are the problem. If lots of people don't wish to hire you after you have solid experience in the industry, something is wrong with you and you are being stubborn by refusing to recognize it and fix it.
My future really rests upon this. I have a degree in mechanical engineering with irrelevant experience. My only regret is not doing bachelors in computer science.
I wouldn't lie if all the post got me little tensed and made me thinking, "what am I doing with my time". About to finish introduction to Computer Science using Python on Edx.
That said, what is this?
a) "I cannot do X" b) "But here is some advice on how to do X"
I mean... why would anyone listen to the advice that is proven to lead to failure? Serious question.
I know switching jobs is common here, but i would think that sticking at least 1 to 2 for a job would be normal (assuming it works out).
Bit of a silly article. You could say this about anything. And I don't see what the problem is with never being contacted, if someone doesn't want me for whatever reason, I don't really want to hear from them again.
I can't even get a call back for an interview lined up. I have done NLP, got a masters degree in computer science from Penn, plenty of experience with big data such as hdfs and hive, spend my free time doing what ever data science I can. but obviously doing something wrong.
any suggestions? Here is my linkedin account: https://www.linkedin.com/in/karl-dailey-02557b65
1) Change your profile picture to something serious. Get a collared shirt and a nice background outdoors. No tie. People will unconsciously judge you on your picture, so you want something that shows you're a professional, but you're confident and happy in life.
2) Think hard about your job titles. Your latest job is far more than just a "Data Analyst". It seems closer to a Scientist or Engineer role, even if your company doesn't call it that. "Analyst" makes people think of entry-level positions. Your DBA-Programmer position is more like a Software Engineer/DBA/System Admin position. If you can't pick one, generally those all-in-one positions can be known as Systems Engineers. Whatever you do, make sure that DBA isn't the primary thing people see. In general, sell your previous positions more. Like "IT". That's not a title, that's a department.
3) Expand on your projects section more.
4) Make sure your resume matches your LinkedIn. People absolutely look you up on there. I did it all the time. When the two didn't match, I was suspicious.
Good luck.
The first thing I did was look at your current position and I immediately became skeptical. You have been at your position for 10 months, yet you have done a lot of fancy sounding things that seem to have no connection to each other. To me this is a huge red flag that you're just grabbing some data, churning through some code you found on StackOverflow or in a book/documentation, and then making grand claims about the work you are doing at ComCast.
Your use of buzzwords only makes me think this more.
For example "Churn forecasting: probabilistic modeling of deletion rates on dVR with a beta binomial distribution to forecast the number of devices that carried a show over 300 days. Maximum Likelihood Estimation was used to derive distribution parameters."
This honestly looks like you saw a tutorial about an R-library and then you copy/pasted the documentation for one of the functions into your profile. By using so many buzzwords (including the term deletion rates), you've left me wondering if this is something you actually did or just something you made up. If you actually defined and derived the Likelihood function you should state that. Otherwise saying you used MLE means nothing since many functions in R use MLE under the hood.
Another one is "Built node.js/angularjs integrated tool to allow analysis team to test the sensitivity of KNIME workflows for forecasting." In my mind I'm thinking, what exactly does web programming have to do with KNIME? What exactly do you mean by sensitivity? How are KNIME workflows sensitive? Do you mean you are checking the accuracy of forecasting models built in KNIME? Lots of Data Scientists will have no idea what node.js and angular are and many will not care when they find out. Data Scientists may build charts using JS, but very few will be building Web based UIs themselves (I assume this is what you are trying to say?)
To be honest, I have no idea what you do in your job. Are you actually a Data Scientist as part of your job duties or did you develop an interest in Data Science and you have access to Comcast data so you've been playing around on your own?
At a hiring manager, I want to know the person I'm evaluating has spend time working on a business problem from start to finish. This means they thought about the problem, defined how to answer it (or figured out how the business owners want them to define it), figured out which data was relevant, thought through a model if it's a business problem that can be addressed by a statistical or ML method - this includes thinking through how the output of model will be used by the larger business - and making a lot of mistakes and changes in this journey.
If the person is just getting into Data Science, I want to know the person has the analytical and metacognition skills to think through a business problem. If they have that then I evaluate their thinking with models.
I'd recommend you trim down your LinkedIn profile and focus on the projects which took you some time (e.g. a month or longer) and where you had to iterate a solution. Use these projects to illustrate what you actually do at your job.
It's possible that you've done everything you state. You may be working with a team of people. At a large company you'll have other teams supporting you with data collection, cleaning, and putting the data into a shape that makes it amenable to machine learning and joining with other relevant sources. If that's the case, focus on projects where you were leading the project in some way and emphasize how you worked with and led the team.
But based on your LinkedIn profile I'm skeptical and a resume like this would not pass my filter. The HR person I work with would see your profile as impenetrable. If they can't figure out what you do and what you have done they are not going to send your resume to me.
Finally, can you move into a role at Comcast that gives you an official "Data Scientist" title? From what I've heard Comcast has a solid Data Science practice and it seems like they have some really interesting data. Finding that combination is really hard. Many good or potential Data Scientists end up at jobs where they are unhappy because the Data Science culture and/or data is awful.
I thought about if I should ask or not but I honestly don't understand how such a policy could be good for employees so I wanted an idea of the culture that allows it. If that question contributed to them not giving me an offer then good riddance so I don't regret asking.
Wow, get similar rejection lately: this is a fast paced company and the way you explained your thought process was confusing and might slow us down, so good luck with your job search.
Better not answer with "Thank you very much. I also had a feeling that some people in the room lacked the mental capacity to follow my explanation."
;)
My own experience was that my initial position as a software performance engineer resulted in a perception that I was a "tester" without technical skills despite having multiple CS credentials and published code in practitioner-oriented sources.
Overcoming recruiter biases was such a struggle that I now routinely counsel students and early career programmers to carefully consider whether job role perceptions would negatively affect their future prospects. I also tell them, when financially viable, to not take on roles where hiring orgs cannot give them a day-to-day job description that directly matches their desired career path.
This advice seems quite challenging or maybe misguided for data science careers though. It seems like just getting an entry-level data science job might require a dedicated MS in either CS or stats, with a healthy set of projects in whichever of those two subjects you didn't spend grad school working on to prove yourself . . .
Contrary to what the reddit folks would have you think. The ONLY thing that consistently get someone through the door is demonstrable real work experience, on real projects, in the industry (read: not academia). Side projects are not a substitute and the lack of degree is a barrier.
It turns out that QA was only the tip of the iceberg. You have a job title as "QA" and a job title as "support".
You will NEVER get any development or engineering job with that. Expect 90% reject in the resume screening because you are not a developer.
If they were development jobs, replace both by "software developer".
My most recent job is obfuscated a bit in the public eye/only visible to logged-in LinkedIn users, for good reason. (I politely request people looking into it not discuss it)
Are you applying online or via getting coffees with people in the data science team and just talking shop? The latter seems to have a high conversion rate if you can nail it.
In the OP's case I would change their title (if applicable) to "QA / engineer" as a) that probably paints a more accurate picture of what you were doing and b) gets around yokels that look down on QA/SDET.
Others have said the same, but I'd wager the biggest issue is (a) the limited past roles that directly dealt with data science/analysis or (b) SF's narrow-minded hiring practices. Maybe a masters or data science bootcamp would go further than more blog posts?
They're really trying to mitigate risk that they pass you along to engineers and the engineers say "why am I looking at this person with no formal qualifications" and then the recruiter feels like they've wasted the time of the engineering team. It's stupid but insidious.
If you can I would suggest trying to bypass the recruiters and contact the engineers/hiring manager directly; ask them out for coffee and ask for advice on starting a career in data science, or show them your portfolio via email there.
edit: spelling
I realize that most startups recruiting through HN are looking to hire for web, app or backend development, but there are a few data science jobs. Since people recognize you here on HN, you have a much better chance of landing a job.
It's unfortunate that most recruiters primarily screen based on resume.
I don't know if Triplebyte [1] helps people find data science jobs, but do check with them.
It's OK to leave stuff out on your resume if it's not relevant (and maybe even harmful) to the position you're applying for.
It still hurts, of course.
Mentioning that you have another offer is seen as a negotiating tactic. Then they have to compete/bid against the other offer, and you are removing some of their leverage/power. A strong reaction to such a move can be to cut off the interview, so to regain back their power.
In his case, the author doesn't seem to have had an offer on the table. Perhaps the interviewer felt as though the candidate was trying to negotiate too much, too early in the process. Perhaps the interview didn't go over all that well?
Even one or two sessions can help you a lot - they are trained in pinpointing "soft" issues.
Would not python with numpy be a better fit ? or fortran with some handwave interface code
Back (early 80;s) when I did map reduce we used PL1/G
From a business standpoint though, there are a few main reasons:
–Data pipelines are well modeled as functions: they take a few input datasets, return a few outputs at the end, and do a ton of processing in between
–FP idioms generally make parallelization easier, and this is very important for the datasets we're dealing with
–A strong type system like Scala's lets us prevent many runtime errors, which is quite important when your pipelines can take several hours
–It's fairly trivial to wrap a statistical/ML algorithm in a pure functional interface, even if the algorithm itself is imperative
For example i've found that as a pipeline gets optimized for production use it needs to preallocate all of its output space and then modify things in at each step (like a one hot encoder flipping a few bits in specific rows of a zeroed array instead of allocating new ones and copying them in).
I find it difficult to reconcile this sort of code with a "pure functions without side effects" philosophy and still have it perform an an acceptable level.
People who actually understand statistics are rare. I can probably weed out 1/3 to 1/2 of candidates simply by asking what a p-value is, or what precision/recall are (this includes people who said they worked in search).
Of the ones who know basic stats, most are neither good at nor interested in programming. They just want to use existing libraries to crunch numbers in a Jupyter notebook, then hand that off to the developers.
Finding a person who can come up with a predictive model, understand what they did, optimize it without breaking it's statistical validity and deploy it to production is very hard.
(If you can do this, I'm hiring in Pune and Delhi. Email in my profile.)
(not sure I can defend somebody that does not know what precision/recall are)
I'd happily take a Bayesian answer if they preferred that, but that hasn't happened very often.
"just compose a team" sounds easy, doesn't it? Unfortunately there are lots of failure modes involving different parts of the team not really understanding what each other are trying to do, let alone what they are doing, and subtle errors getting by people who don't know what to look for. So, you can find such teams and some of them work well but a lot of them don't.
So an alternate is to try and find or create domain experts who mix all the appropriate skills, but this is hard and in the extreme case involves chasing down unicorns.
Companies and industries flop back and forth between preferring different approaches - right now a lot of people are talking about "data scientists" as one of the latter, but it will likely change over time as it always does.
It's a hard problem, and it shows.
> There are so many more statisticians who can at least communicate and work effectively with developers and vice versa.
Not in my experience. You need to design your data infrastructure to promote easy analysis, and you need to design your models to scale well according to the amount of data you're working with. There are also many cases where a project will require mostly engineering work for a while, and then mostly analysis/statistics work–there are ways to handle this with specialists of course, but there's generally a significant switching cost.
Also people with a combination of statistics & programming aren't that rare–IMO it's more that employers tend to search for both degrees, when instead you should be trying to evaluate the skills directly.
That said, most companies should probably be hiring data engineers rather than data scientists–for most "data science" jobs I've seen, almost no statistics is actually necessary/useful.
One is that there is buzz & excitement around "data science" right now. Nothing specific to this area, but in my experiences this creates a large number of under- or un-qualified applicants. It also creates an environment for companies to desire to hire a role they are not well qualified to hire for. It is really difficult to hire well for roles you don't understand well.
The second thing is that extremely few people are actually ready for this sort of job straight out of an academic program. A related Ph.D. or post doc plus a few years solid training in industry can make you a great candidate, but the academic work alone usually isn't even remotely close. There is confusion about this among both candidates (don't know what they don't know) and hiring managers (don't know what they are actually looking for).
Add to that an oversupply of academic credentials relative to academic jobs and you have a problem. If you are a large company with a well defined data science program and a defined "entry level" data science role, if you take skill development and training seriously and have the senior staff for it, well then you are fine taking strong academic candidates and turning them into talented data scientists. If you are a less experienced company looking for scientists to solve a problem you don't fully understand, you may be in for a pretty rough ride.
I've helped a few organisations solve this bootstrap problem by helping out with candidate selection and interviews, but many other just don't ask for help.
And everyone at the company knows it -- including and most especially, upper management. Because that's after all where it originated.
This trend will probably continue until someone decides to up recruiter pay and hire engineering background candidates for recruiting roles (if possible).
Bayesian stats tend to use likelihood ratios or Bayes factors instead of p-values for hypothesis testing.
The trick in all cases is that you're comparing to expected results given some prior distribution. Most people use a dumb prior (e.g. Gaussian) and then they're confused when the numbers make no sense as data is multimodal or heavy tailed, thus mismodelled.
And then there's this, that even if your intro to probability course everywhere covers the classic statistics with p-values and hypothesis testing and frequentist confidence intervals and so on, you are not necessarily going to use them that much. I calculated some p-values and other tests with R for some example datasets a couple of years ago and never seen them since in coursework, everything we've done after that has been more or less fully Bayesian. The concepts are still fresh[1] in my mind mostly because I read some statistics blogs, such as Andrew Gelman's [2]. The irony is that Gelman does not exactly love frequentist framework, he just mentions its concepts often enough.
[1] or not totally forgotten
So why don't you just use the phrase "Why don't you just ...?"?
https://en.wikipedia.org/wiki/Confusion_matrix
You can see from that that sensitivity and recall are the same thing, but specificity and precision are not.
Edit: note that I'm not saying you need this to add roi as an analyst for a business!
My only quibble would be that precision + recall are one set of evaluation metrics applicable to classification tasks. Modelers can absolutely use other loss functions.
Additionally, precision/recall do not map nicely to regression problems, so people use other metrics (RMSE, MAE, etc.).
[1] This paper is the one that most often gets cited as background by people who don't like recall/precision as metrics: http://dspace2.flinders.edu.au/xmlui/bitstream/handle/2328/2...
You remove the experiences you have and wonder why your resume doesn't pass a screening test? Must seem quite empty.
In jobs that were heavy on ML, I would use high-performance tools for the models (imperative code, numeric computing packages etc.) and functional code for the ETL, which worked pretty well–no need to be dogmatic about it, a 70% pure codebase is still generally easier to reason about than a 20% pure codebase.
Therefore an array of boxed types will not be memory aligned; and any vector instructions (which are very important to scientific computing) cannot be used.
Perhaps something has changed in Scala land since I last looked(??).
I responded to the claim that ML courses start with the definition of precision and recall. In my admittedly limited experience those courses start with linear regression and mean squared errors. After that, there is so much generalization possible and that doesn't include precision/recall.
You make money by solving someone's problems, making money by stating definitions is only done on TV quizzes.