How to give a meaningful Data Science interview (or any interview)
Avoid these mistakes that I observed from 100+ interviews
Over the course of the last two years, I have interviewed a lot of candidates for entry-level data science roles. I noticed a few completely avoidable mistakes being repeated frequently by many candidates.
Here are some of those mistakes and ways to avoid them.
#1: Diving way too deep, way too early
Too often I see the following conversation:
“Can you tell me a little bit about XYZ project on your resume?”
“OK, so we start by converting PDF to images using pdf2image library and then run Tesseract OCR on it to convert the image into text. Then we start to preprocess the data by stemming, lemmatizing, blah blah blah …”
Don’t do this. This is very confusing for the interviewer. They have no context about the project. They are not really even interested in the project (yet).
They may pretend as if they understand what you are saying, but they don’t. So they just start waiting for you to finish and move onto the their questions.
Start with an elevator pitch
The best way to begin to explain a project (in my opinion) is with an elevator pitch. Your opening statement should have enough details to rouse curiosity in the listener, but no more!
This gives the interviewer the choice to dive deep into the project or move onto something else.
An easy way to do this is to answer each of the following questions in ONE short(ish) sentence:
- If the project did not exist, why would the world be worse off?
- How does the project solve that?
- How did you measure the project’s impact?
For example:
“When a new customer joins our client, they have to manually extract a lot of information from poorly scanned and unstructured documents. Our project automates this process by extracting relevant information like names & addresses, etc. We achieved 90% accuracy and saved more than 5000 work-hours per year.”
Ask for a deep dive
Now that the interviewer is finally in a position to understand your project in depth you can ask if the they want to dive deep in to the project.
If they say yes, shine bright!
Be sure to break down your project into familiar subtasks that the interviewer can understand, e.g. classification, regression, object detection, clustering, etc. For example:
“We convert the image to text by OCR. Then classify the text into several categories. For each category, we perform Named Entity Recognition to retrieve person names, followed by object detection to extract their signatures.”
This helps the interviewer to quickly link their existing knowledge to your particular problem. They may choose to focus on the part which seems the most interesting to them.
For each of those subtasks which you end up discussing, here is a (non-exhaustive) list of things you should convey.
- Data:
a) Source: Where did you get the data? Was it an open source dataset? Or did you collect the data yourself?
b) Characteristics: Was there an imbalance in the dataset? Did it have too many missing values?c) Preprocessing
2. Algorithm:
a) Well known algorithm (like YoLo) or designed from scratch?b) Transfer Learning or trained from scratch?c) How much training?d) Any pre-training?
3. Performance
a) Which metrics were used? Why those metrics?b) How much performance was achieved on those metrics?c) How did this performance compare with the business requirements? Were all the stakeholders satisfied?
4. Unique Constraints
a) Data privacyb) production/development environments constraintc) Issues with handling scale (of the data or the model)
Think about the project critically from a third person’s POV
The thing to constantly keep in mind is that the interviewer here is an outsider looking in. What is obvious to you may be confusing to them. You have lived through the project, they have not.
The objective here is to explain your work as clearly as possible, not to (just) brag about the complexity of the project or your technical skills.
#2: Not understanding the context of the question
The same question can have different right answers under different contexts. As they say,
“Before climbing the ladder to success, make sure that it is leaning against the right building”
For every question, think of the following:
Do I understand the question *exactly* ?
Answering a question without understanding its contents is worse than giving a wrong answer.
Unless the question is extremely obvious, rephrase it in your own words and confirm with the interviewer if you are on the same page. If you are not sure about a specific part of the question, ask for clarification.
This is also helpful in case you don’t know the answer, because you can at least show that you understand the content of the question.
Is this an open-ended question?
Ideally, the interviewer should make this clear in the question itself. In case they don’t, don’t hesitate to confirm.
I was myself stumped in an interview when an interviewer asked me how I would build a particular solution. It didn’t occur to me that it was an open ended question and that I was allowed to answer with my imagination.
Is this question connected to a previous question?
Sometimes an interviewer asks a follow-up question if the candidate was struggling with a previous question. This actually makes your job easier, as the search-space for the answer is reduced if you know that it is linked to a previous question.
#3: Not understanding the context of the interview
It’s important to tailor your answers to the interview in which they are asked. Your answers may be technically correct, but not productive for the context of the interview. Keep in mind the following things:
Type of interview
Is this a brief telephonic interview or is it a deep technical interview? Short & crisp answers are expected in the former while detailed & nuanced answers in the latter.
Who is the interviewer?
Is the interviewer your potential team-mate or say, the CEO?
The team-mate may be more interested in the technical details of the answer, but the CEO may be interested in your overall understanding of the problem.
This is just my guess, so take it with a pinch of salt!
#4: Misplaced priorities
The final answer (almost) doesn’t matter
A good interviewer is looking for a competent human, not a parrot. The final answers to questions in a (good) interview are almost irrelevant. What matters is how well you can navigate toward the answer with the given information.
Don’t bluff
I can’t believe I have to spell it out, but DO NOT BLUFF. If you don’t know the answer to a question, just say so plainly! It’s perfectly OK. Nobody has unlimited knowledge.
It’s painfully obvious when someone is bluffing. The interviewer has thought through their own questions carefully. They have asked the same question to multiple other people. They are not under pressure, you are. You can count on them to catch the bluff.
Demonstrate you thought process instead
That being said, if you don’t know the answer to a question, you don’t need to draw a complete blank either. You can say something like
“I don’t know the answer exactly, but my best guess is XYZ because of ABC reasons.”
Even though you may not know the answer, you may still display your ability to think clearly about a problem and work towards a solution.
Conclusion
- Don’t bombard the interviewer with details without context.
- Understand the question thoroughly.
- Understand the relationship between the question and the interview.
- Demonstrating a well-grounded thought process is more important than knowing the final answer.
The idea is to make it really easy for the interviewer to hire you. These are simply my views and by no means hard & fast rules. Please do let me know if there is anything you don’t agree with and would like to discuss further with me. Thanks for reading!
