# Data Science #2.2 Interviewing - The Tech Screen

So let's set a few things straight before we have too many false assumptions:

I'm coming for you, tech screen! |

**I am no genius**. There are actually many things I don't know or understand as well as others. For example, my boyfriend sometimes goes to a cross-bike clinic on Thursday called CXPX. I can't wrap my head around this name, so I call it "CXBX" or "CPBX" or "CXXP". Really, it's not that hard and I just can't get it.

*However, I am a reasonably intelligent person. Please don't assume that because I smile and brush my hair that I don't understand Physics or C++. Ugh.

(2)

**The following works for me, it may not work for you.**Try to hear what I'm saying and adapt it to your own needs. There can't be 10,000 Lo's out there, the world would be messy and collapse.

Now...

*the dreaded tech screen*. This is what people agonize over for months and spend hours upon hours working practice problems for, trying to 'guess' what their interviewer will ask them. If you're trying to be a software engineer, your tech screen is going to involve things like "white board code a binary search tree". You need to know the basic 20ish potential interview questions (basic SQL queries, write a merge sort, write a quick sort, build a linked list class, etc.) Google 'hacker rank' and poke around for a few minutes, you'll get a good sense.

However, this is about data science, which [SECRET] isn't actually about coding. It's about solving problems, sometimes using code but sometimes using math. What does a data science tech screen look like? ANYTHING. It's about being on your toes and working through problems you probably don't know the answer to (woo! I love having people watch me struggle! Esp when my future depends on it!). Here are some sample *real* questions I've gotten and I'm going to talk about how I approached them:

**(1) You have 10 Mb of storage space on your computer but need to sort a 50 Gb list. Please write code on that there white board to show us how to do this (great question!).**

Questions ON |

In the span of 45 minutes, I really muddled my way through this problem. Ultimately, I wrote pseudo code doing a bubble sort which I told them was awful and I would never actually implement under any circumstance. The trick was that we needed to take 10 Mb of data at a time, sort it, and then merge it together. I knew this was what needed to be done, but I was struggling on how to effectively implement this (interview stress!).

In this case, I relied heavily on the interviewer to guide me where to go. I would ask the two gentleman judging me if they wanted me to proceed even though my method was cumbersome. Often, they would perk up and be like "You're right, this isn't the best way. Can you think of another way to store ordered data?" and eventually we'd cobble together something beautiful. The trick was not giving up, not getting frustrated, and speaking coherently despite my internal panic ("GAH I'm failing again").

**(2) Select all rows and columns from Table A using SQL**

**This is literally just Select * from Table A. I actually had to ask the interviewer to repeat the question because it was so easy. I pretty much just stated the answer here (confidently...) and then we immediately went on to the next question (like an iota harder). The goal here was he was trying to warm me up and ask me incrementally harder questions until I messed up (I think Query 6 I lost the game. Shucks).**

(3) What is the probability it is raining outside if 3 of your friends say it's raining outside and there's a 25% chance it's raining and a 30% chance each of your friends are lying to you?

(3) What is the probability it is raining outside if 3 of your friends say it's raining outside and there's a 25% chance it's raining and a 30% chance each of your friends are lying to you?

**This is not an easy Bayesian Probability Problem (if it is for you, great. Let the rest of us wallow in our ineptitude). I identified it pretty quickly as being a Bayes problem with probability but then floundered on how to get P(B|A) and P(B) [got P(A) like it was my job!]. Once again, being methodical and leaning on the interviewer for help goes a long way when you're faced with a problem you don't know. Ultimately I got the right answer, but I probably took 4x longer than I was supposed to. They just want to spend some time with you and see how you'd go about solving a problem.**

(4) I'm having this problem at work right now, how would you solve it?

(4) I'm having this problem at work right now, how would you solve it?

**What an awesome question, really. By asking me this, my (potentially future) co-worker got to see what it would be like to work with me on a day-to-day basis. He had a tough problem, and I was able to help him solve it (incrementally) in a unique approach he hadn't considered by the end of the interview. That's a win for him (hey! I made progress on this problem!), a win for me (hey! A question I can answer!) , and a win for both of us - we know we can work well together now. This kind of problem requires on-the-spot creativity, but it's really a test for how you'll perform day to day.**

**(5) We need a way to detect Fake products, how would you do this (using Machine Learning, this was implicit although not explicitly said).**

**Another awesome and involved problem during a tech screen. This entire interview consisted of answering this question with increasingly specific edge cases and/or things to consider. We had coderpad opened, and I was writing pseudo Python code to address unique situations ("what if the product is an artificial tree? How then do you determine if the product is fake?"). This interview was a ton of fun, I was genuinely excited to write the code and come up with a working prediction model that combined machine learning and NLP (natural language processing). I told the interviewer at the end: "Wow, this was great. This was an excellent problem - is this what your day to day work is like?". Huge selling point.**

You can get used to anything |

**Summary:**

**Did you pick up a theme on my answers to these five questions? I was initially scared or intimidated by almost every problem I got, but then calmed down and found my center as I started to solve the problem. By the end, I was**

*excited*to be in the interview answering the questions... maybe this is why I'm going to be a data scientist ;) You don't have to listen to my advice or you can say I was just lucky, but I've made it to the next stage of every interview or given a job offer off of the responses I gave above -

*even when I blatantly didn't know the answer.*

Don't fear the tech screen - they aren't an intelligence check (that's your resume). Instead, they are

**an opportunity for you to shine and demonstrate how you communicate and solve problems.**This isn't a math proof and you're not being graded on the thoroughness of your comments (usually...) - the goal of the interviewer is to get you to a place where you're struggling and then watch you make it through.

## 21 Comments