Data science interview questions with answers

>> I prefer to ask candidates how they would approach solving a problem

Word. Totally off topic, but: I work in the field of information technology since more than 20 years now, more or less. Not always the same focus, not always full time, but always IT related. I consider myself a good problem solver because of my self learning and analytical skills.

I recently applied for a job as a BI developer. The interview consisted of 10 questions about SQL. I more or less answered them, just 1 or 2 wrong. Not wrong as in "not correct" but rather "Not what we exactly expected" or "you did not see the little traps".

Comes out they didn't take me because of my lack of SQL skills. I do not understand how this kind of recruiting process will help anyone getting skilled people and how this is still common practice. It's frustrating for people like me, who do not have the complete SQL syntax in mind, but are flexible in choosing their problem solving approaches. A couple of years ago I started in a big data company, never heard of MongoDB before, little skills in Bash. If they would just asked me questions about that, hiring me would be a total no-go. They did hire me. I improved process, like measurable, and mastered MongoDB. Nothing, that one could expect from a questionaire.

A second interview, same outcome. They not even asked me detailled questions, just wanted to know what my SQL skills are. I answered: Immediate, but I'm good in learning. The did not take me, too.

Although, I understand that it's hard to evaluate this kind of skill, I'm really frustrated, when I face those "hiring techniques". Or maybe I'm just not good in SQL, and they anticipated it.. ;)

I completely agree! I run a data science department at a corporation and I give applicants real world data and ask them to answer real world questions. "Here's a dataset of the dates we sent an email and the open rate. Does one day of the week have a higher open rate than the others?" People have to know how to turn a string into a date, turn a date into the day of week, and then apply statistical reasoning and then give me a one sentence answer. That kind of thing is far more common at work than explaining the kernel trick.

Agree. In addition to curiosity another quality I think is very important is persistence. A surprising amount of being an effective data scientist comes down to being able to learn new things quickly and being able to make the computer do what you want it to, especially when the first few things you try don't work.

Success if often a trial and error process, involving slowly building a deep understanding of the problem you're trying to solve (business and technical), hitting lots of problems, and not giving up too easily (at least, not giving up due to surmountable technical hurdles).

This often means spending many hours banging your head into a brick wall; but in my experience these are often the times I'm learning quickest even if it doesn't feel like it at the time.

Diving deep into a domain and interfacing with a subject matter expert goes a long, long, way. We've been building custom data products for enterprise for about seven years, and a lot of the work is listening and grokking large amounts of content about whatever domain we were helping with in general, and the specifics of our clients. Retail, banking, telcos, energy, communication.

Having a background in acoustics, reservoir characterization, telecom networks, opens up clients because you 'get it' or at least you work hard to get it, which improves buy-in of the experts to sit down with you and answer your questions. You did your homework.

If you don't and just storm in talking about something something neural nets, they'll see it as a waste of time, won't bother explaining nuances, will delay sending data you desperately need. You won't have their cooperation even if you have executive support. There's no data in CSV form or an API to hit in most real world projects, so you need their help getting data, and their expertise to understand it.

Another major point is specifying the metrics. The real world metrics, not AUC or F1 scores. You need collaboration to get there, too.

There's so much to be done before there's data to work with, let alone good data. And there's so much after the model building step.

It can drive people to quit. One reason is that when you storm in and consider that people are morons, you get frustrated rapidly.

> The best data scientists are just people who try to understand the ins and outs of business processes and look at problems with healthy suspicion and curiosity

I guess the unsaid part of this is “... and curiosity AND are often able to leverage this in data-driven solutions to bussiness problems”. Because nobody cares whether you’re curious or not if you don’t bring any value to the company. With that said, the part you mentioned almost seems like an innate ability, while the part I filled in could probably be trained.

Suppose you were still in college and wanted to become a data scientist. Based on your current knowledge and values, how would you go about it, being a student? Which skills would you hone and how?

This is why I'm switching from DS to SWE. The communication hurdles with the business people are so hard for me. I've talked with other nerds my whole life and struggle to connect with and dissect the other side. That and the pay is better.

> You should strive to obtain a deep understanding of your data and its distribution, and you should be deeply skeptical if the sample you happen to have looks normal.

Although normality testing is useless in many situations, the parent comment somewhat overstates the degree of caution required. In many contexts the exact distribution doesn't matter; sort-of-normal is good enough. For example, the t-test is used ubiquitously. It assumes normality, so we would expect possible non-normality to be a major problem, right? Not so. The t-test is extremely robust to departures from normality given equal sample sizes [1,2,3]. Or you can use a so-called non-parametric test. Rather than investing great effort in specifying exactly what distribution you're dealing with, it's more productive to simply use a test that is robust against your unknowns and move on to pursuing your actual objectives.

It's true that if you are interested in predicting events in the tails of the distribution, you really do need to study the distribution in detail. Predicting rare events is very difficult. But if you're just interested in differences between group means, don't overthink it.

[1] http://www.jerrydallal.com/LHSP/student3.htm [2] Posten, H.O., Yeh, H.C., and Owen, D.B. (1977). Robustness of the two-sample t-test under violations of the homogeneity of variance assumption. Communications in Statistics - Theory and Methods 11, 109–126. [3] Posten, H.O. (1992). Robustness of the two-sample t-test under violations of the homogeneity of variance assumption, part ii. Communications in Statistics - Theory and Methods 21, 2169–2184.

There's a test for normality. Well, I knew one, Kolmogorov, but Wikipedia already lists 8. What data scientist doesn't know of such a test?

And how would you fit the data? There's not one, unique way to fit. And as you say, a small deviation can mean a lot: if you use L2 distance, the errors at the outer regions of a normal distribution are probably dwarfed by any deviation that occurs more towards the center.

These kinds of stories seem insane to me. I currently have to do some data science-y stuff in the more generalist consulting dev role I have. I used to do a lot of SQL stuff years ago, but have forgotten most of the syntax beyond the basics. That being said, all it took is some minor googling and reading of a few blog posts to solve some middling hard problems for my client.

What kind of companies make people jump through these nerd hoops? Do they actually have real work that needs doing or is this all just posturing by interviewers?

Interesting and perhaps shows the cultural differences between ML and stats people. I took a machine learning course in my bachelor's and two more ML courses in my master's (CS). These weren't some "deep learning lite", mess-around-in-Keras courses, because DL wasn't even big back then. We covered lots of stuff, Bayesian linear regression, Gaussian processes, Gibbs sampling, Metropolis-Hastings, hierarchical Dirichlet processes, SVMs, multi-class SVM, PCA, kernel PCA, perceptrons, CMAC neural nets, Hebbian learning, AdaBoost, Fisher vectors, EM algorithms for various distributions, fuzzy logic, optimization methods like conjugate gradients etc etc.

But not once were the "Gauss-Markov conditions" mentioned. Frequentist theory was only marginally addressed. I taught myself some of that stuff from the Internet, such as hypothesis testing theory, p-values, t statistic, ANOVA, etc.

Also, I'd say I'm good with data structures and algorithms, complexity theory, graph theory etc.

I thought these skills would be a good fit for data science jobs, but I guess it's really such a wide umbrella term, that probably you're more looking for people trained in the frequentist, statistical side of it. What application field are you in, if it's no secret?

Not really sure why your comment is marked dead when it is correct. Maybe it's a new account thing? As you say, the Gauss-Markov conditions are necessary (and sufficient) to make OLS BLUE, but OLS still works fine under a variety of pathological conditions, and many of those conditions can be tested for and adjusted for using common techniques.

One of my favorite data science factoids is how "regression" (to return to a former state) came to mean "prediction of a continuous variable".

In the late 1800s, Sir Francis Galton noticed that extremely tall or short parents usually had children that were not as tall or short as themselves, i.e. the children's heights were regressing (returning) to the mean. He collected hundreds of data points, graphed them, and estimated a coefficient describing this relationship, thereby inventing "linear regression."

We call them "regression" models simply because the first linear regression model was created to demonstrate the concept of regression to the mean.

https://en.wikipedia.org/wiki/Regression_toward_the_mean#His...

The error here is ML terminology; the article answers correctly, if shallowly, the statistical definition of regression.

Classical regression techniques can be (and are correctly) used on binary, ordinal, or categorical dependent variables. I know we teach people doing ML that the two forms of supervised ML are classification and regression, but that does a disservice mostly in order to make visual examples in teaching easier by making every topic a binary classification question and then saying "oh yeah, this works for regression too".

Granted in an interview you'd probably want to use context in case the hiring people were trained on a specific vocab, but that maybe speaks more to the folly of using these dial-an-answer systems in place of actually learning the material.

From the README:

> The answers are given by the community

> If you know how to answer a question — please create a PR with the answer

> If there's already an answer, but you can improve it — please create a PR with improvement suggestion

> If you see a mistake — please create a PR with a fix

I read two answers from technical.md, and one of them was inconsistent with what was asked for...

I would be very suspicious of using this repo for studying.

I think it's a bit far fetched to assume that recruiters tailor interview questions based on these Github repo's. For me as a junior data scientist it really useful to test my own knowledge and highlight areas which I need to study more.

Having somewhat standard "objective" questions helps even with senior candidates. You'd be surprised how many senior's would struggle with the basics, or who aren't as senior as their resume would lead you to believe.

My experience is that interviews like these are for supporting role data science jobs. E.g. company x has a product (tech or not), they have some data, and they want to hire someone to make that data useful in improving their product or selling more of it.

The general data science process is that when faced with a problem, you 1) select the appropriate algorithmic tool(s) for the problem and 2) apply the tool(s) to the data. One of the challenges in data science generally is that the tools can get pretty fucking complicated.

The point of theory interview questions in general is to assess the first point, whether or not a candidate has the capacity to pick the right tool for a given problem. They want to hear that you understand some of the standard tools and what sorts of problems they are good for. If you "get" the common tools, you'll likely be able to reason about the application of new/different tools for weird problems as you face them, or so the logic goes.

Everything I just said was more or less objective. This is my opinion: bad companies that do not know how to hire data scientists usually do what you're describing. They ask theory questions to assess whether or not the candidate already understands the specific tools they expect them to use. Good companies tend to pay more attention to whether the candidate is capable of understanding the universe of tools in general and are less worried about their specific application area.

I should note that this is less relevant when hiring consultants or "plug and play" senior people. Of course for those roles you want to know that the candidate has done something similar already and is primed for success.

ML research positions like those at OpenAI are a completely different level than data science interviews.

>I have to agree that these interview questions function more as a cheatsheet review than actually anything practical that would be seen in an interview. Data science interviews don't function as a biology test where you're just rattling off memorizations to how neural networks or linear models work.

Me and my co-workers have been asked exactly that by top companies although it was more for machine learning engineer/applied scientist positions. Many textbook questions asked one after the other. It's not the only interview type they did but it definitely mattered and was often the first filter. So if you didn't answer well enough then you were out.

That's a great question. Because it lets you as a candidate screen out places run by morons.

The followup question would then be "do you currently write end-to-end ML code in raw Python in production?"

The answer will most likely be no.