How to Ace Data and ML Behavioural Interviews

How to Ace Data and ML Behavioural Interviews


interviews were stupid.

I thought they would be a walk in the park because who wouldn’t want to hire me? I am so great to work with!

The reality is that you can’t wing behavioural interviews — believe me, I have tried and failed miserably.

Most people neglect behavioural interviews and focus solely on the technical aspects of their applications.

It’s easy to think that because data science and machine learning are technical fields, interviewers and companies only care about your technical abilities.

This couldn’t be further from the truth.

I have seen people get hired solely because they were a good “culture fit” and the hiring team really liked how they approached their work.

My friend Mandy Liu even got a $30k pay bump and was up-levelled from senior to lead data scientist before she was even hired due to her performance in the behavioural interview.

So, in this article, I want to break down the exact strategies and frameworks for you to do the same.

Let’s get into it!

What Are Behavioural Interviews?

Behavioural questions are to assess whether your values align with those of the company and whether the company can provide an environment for you to thrive and deliver your best work.

This interview is by far the most subjective of the whole process and is often conducted last by the hiring manager.

This shows you the importance of behavioural interviews.

The hiring manager wants to ensure you are someone they and the rest of the team can work with.

It’s also the levelling interview.

Perform badly, and they may down-level you from senior to mid-level.

Perform well, and they may up-level you from senior to lead, like what happened to Mandy.

Let’s now go over the key tips you need to ensure you get hired and increase your chances of getting up-levelled.

Story Vault

The first step is actually thinking about the stories you are going to use in the interview.

Behavioural is all about how you work and why you do certain things. This will require you to call up examples from past experiences to bring it to life.

So, I want you to sit down and review your resume to identify the 2–3 most impactful, longest, and most interesting projects you have completed.

They don’t always have to be data science or work-based, but it’s often best to keep them related to the field, as they translate better to what the interviewer is probing for.

These are going to be part of your “story vault” that you are going to use for every single behavioural interview that you will do.

This doesn’t mean you can’t respond to questions from other projects or work you have done, but these 2–3 will form the backbone of your responses, and you should know them inside out.

This will prevent any awkward moments in the interview where you have nothing relevant to draw upon; it’s always about preparation.

The goal is to pick stories with enough depth and technical detail to support multiple questions.

You don’t need a different story for every behavioural question, 2 is completely sufficient (3 even better), and you will tweak your response to align with the question.

If possible, have a story for:

  • One about a success
  • One about a failure
  • One about teamwork or leadership

This will help you cover multiple bases.

Culture & Values Research

It’s unbelievable how many candidates don’t research the company before interviewing.

I have interviewed over 50 people for data science and machine learning roles, and it’s clear that many haven’t researched the company’s values or cultural principles.

So, the obvious first step is to find the company’s values.

This is really simple to do; all you need to do is Google:

“[Company] culture and value principles”

Many companies have an overarching culture/value principle and multiple sub-principles.

For example, DoorDash’s values and culture principles are:

  • We are leaders
  • We are doers
  • We are learners
  • We are one team

These are then further broken down into their own sub-principles.

To be honest, most companies have the same principles, just worded slightly differently.

For example, this is what DoorDash’s ones really mean:

  • We are leaders -> You take initiative and ownership over your work
  • We are doers -> You take action and don’t wait to be told what to do
  • We are learners -> You constantly look to up-skill and improve your abilities
  • We are one team -> You work collaboratively with others

This part is more involved, particularly if the company has many cultural/value principles.

Go over every value and map out something from your “story vault” that demonstrates that particular value or culture principle.

At a minimum, you should include examples of the overarching culture/value principle; ideally, you should also cover the sub-principles.

One example per principle is fine, but two is much better if you have the time and want to over-prepare.

This shouldn’t take you more than one hour, and they don’t need to be fully written out word-for-word; bullet points with rough context are sufficient. It’s more for you to have an idea of what you are going to say.

R-STAR-L Framework

Companies, interview coaches and websites will all tell you to use the STAR method when answering interview questions, particularly behavioural ones.

The problem is that everyone is doing this, so you don’t differentiate yourself at all.

For those of you unfamiliar, the STAR framework is as follows:

  • (S) Situation: What was the scenario
  • (T) Task: What did you have to do
  • (A) Action: What did you do
  • (R) Result: What happened as a result

There is nothing inherently wrong with STAR.

But it’s not optimal.

STAR doesn’t directly tell the interviewer that you are a culture fit.

All you are doing is walking through previous work experience, which is not at all specific to the company you are applying to.

If an interviewer at one company asked you:

Describe the most difficult challenge you overcame in the workplace.

And another interviewer at a different company asked you the same question. Using the STAR method, your response would be exactly the same.

That’s not good.

This is where the R-STAR-L framework comes in.

This is the framework that I have used in all my behavioural interviews, modifying the regular STAR method into the R-STAR-L framework, which stands for:

  • (R) Repeat: Play back the question to ensure you have understood it and show you are engaged.
  • (S) Situation: What was the scenario
  • (T) Task: What did you have to do
  • (A) Action: What did you do
  • (R) Result: What happened as a result
  • (L) Link Back: Explain why this result and scenario align with the culture and value principles of the company you are interviewing.

It adds two elements:

Let’s break these down further.

Repeat

The reason we want to repeat the question back to the interviewer is to:

  • Show them we are engaged in the interview
  • We know the exact question we are answering
  • Gives us some more time to think about our response

I know this may sound simple, but I can’t tell you how many times a candidate started to answer a different question than the one asked. It’s sloppy and a big red flag.

Don’t repeat the question back verbatim, rephrase it slightly. An example is given below.

Link Back

This is where the magic happens.

After each answer, link it back to their culture/value principles.

However, don’t make it too obvious; slide this “linking” in naturally, or it will seem too scripted and desperate.

Most people will be able to read between the lines to understand what you are doing.

The reason we link back is that we want to show them that we are indeed a “culture fit” for their company.

I mean, who wouldn’t want to hire someone who operates in a manner that the company wants?

By linking/mapping our response to their specific culture/value principles, we are tailoring it and making it no longer generic.

You’re telling them directly what’s in it for them if they hire you.

Example

Let me show you an example.

Imagine you are interviewing at DoorDash for a data scientist position, and they ask you the following question:

“Tell me about a time you identified a problem that wasn’t necessarily your responsibility.”

This is your opportunity to showcase the “Be an owner” principle.

(R) Repeat

“Just to clarify, you’re looking for an instance where I took the initiative to solve a problem or improve a process that fell outside my immediate project scope or ‘ticket’ description, right?”

(S) Situation

“In my previous role, I was assigned to build a dashboard in Tableau to track the delivery success rates for a specific geographic region. While I was auditing the SQL queries powering the dashboard, I noticed a recurring discrepancy that about 4% of orders were being flagged as Failed Delivery, but they had no associated refund or customer support ticket.”

(T) Task

“Technically, my task was just to visualise the data as it existed. However, I realised that if 4% of our data was mislabeled, the dashboard would mislead the operations team. I felt it was my responsibility to investigate the root cause of this ‘ghost’ failure rate before finalising the project.”

(A) Action

“I dug into the raw JSON logs in Snowflake and discovered a logic error in the mobile app’s delivery confirmation event. If a driver lost cell signal at the exact moment of drop-off, the system defaulted the status to Failed even if the customer received the food.

I didn’t just report the bug; I wrote a temporary SQL patch to correctly categorise those specific orders based on GPS coordinates. Then, I presented my findings to the Engineering lead with a clear breakdown of how this was skewing our performance metrics.”

(R) Result

“The Engineering team implemented a fix in the next sprint. By correcting the logic, the Failed Delivery rate dropped to its true level of 1.5%, which saved the Operations team from launching an unnecessary (and expensive) driver retraining program. It also ensured that our regional performance data was 100% accurate for the first time in two quarters.”

(L) Link Back (The “Be an owner” Angle)

I tend to look at projects through a product lens rather than just a technical one. If the underlying data is flawed, the dashboard is just a distraction for the Ops team with noise. I’d rather take the extra time to fix a root-cause issue I’ve stumbled upon than ship something I know isn’t 100% reliable, because at the end of the day, I’m responsible and the owner for the decisions that the data drives.”

Mic drop.

Notice how I slipped in the “owner” word right at the end to implicitly show them how I meet that value/culture principle.

Sometimes it will be hard to do this directly, but you should aim for all your responses to be structured this way.


If you are serious about getting your dream data/ML job in the next 3–6 months, I recommend joining Code To Careers.

This is my coaching programme where you will work personally with my team and me to secure your dream offer.

To apply, click the link in the below, and I can’t wait to speak to you!

https://coaching.egorhowell.com



Source link