The Data Engineering Interview Preparation Guide
Everything you need to be ready for a Data Engineering job interview
👋 Hey, this is David. Welcome to the next edition of the Data Engineering With David newsletter. The plan for Data Engineering With David is to create the resource I wish I had when I was in grad school learning to be a Data Engineer.
Introduction
The purpose of this article:
Outline everything you need to be ready to interview for an entry-level Data Engineering job.
What this article is not:
This is not an article about how to crush the Big Tech/FAANG interviews. I don’t have any experience working for Big Tech, so I’m not really qualified to write about it. But, if that’s what you’re interested in, there are lots of Big Tech interview prep guides floating around on the internet.
What this article is:
What I’ve written here is drawn from my experience as both a job seeker and also as someone who has interviewed multiple people for Data Engineering roles.
I have experience working at two different Fortune 500 companies, and I also interviewed at a variety of startups and some medium-sized businesses while job searching. Most Data Engineers don’t end up working in Big Tech—they work for one of these kinds of companies. This article will be focused on the interview cycle at those companies, and how to showcase the skills those companies look for.
How to use this article:
For technical skills, this article is a checklist with links to resources. In cases where this article doesn’t go into great detail, I’ve inserted links to my favorite examples/resources.
For behavioral questions, this article will give you:
Common behavioral questions you should be ready for
Examples of things I’ve actually said in interviews that got me an offer
How to think about these questions in order to construct your own answers
Technical skills
This section is broken down into subsections: must have, nice to have, and position specific. Before you even interview, you need a baseline level of technical skills.
In cases where there’s no resource linked below, you can see this edition of the Data Engineering With David Newsletter for links to learn all of the technologies listed: The Entry-Level Data Engineer Roadmap
Must have:
SQL
Joins: inner join, left join, and self-joins
Grouping and aggregating data
HAVING vs. WHERE
Basic window functions are a plus
Python
Jupyter Notebooks
Pandas
Virtual environments are a plus
Cloud
AWS, GCP, and/or Azure familiarity
Your cloud skills will be showcased through your projects
GitHub Projects
At least two solid, well documented, thoroughly commented Data Engineering projects
Nice to have:
Docker
Exposure to Airflow
Exposure GitLab CI/CD
Exposure to Terraform
Exposure to Spark (PySpark)
Position specific:
Some roles will explicitly ask for experience with these, though it’s not necessarily standard:
Looker / Tableau (these tools are more common for BI and Analytics Engineer roles)
Machine learning experience (Scikit-learn), familiarity with R
The Interview Cycle
The interview cycle has a few stages and typically looks like this:
Vibe check phone call with a recruiter from the company (15 minutes)
Technical round, sometimes with a coding test (1-2 hours)
Interview with the hiring manager (1-2 hours)
Meet with potential coworkers for culture fit (1 hour)
Meet with more senior leaders for final approval (30 minutes)
Some companies combine the technical round and hiring manager interview.
Some companies don't have you meet senior leaders at all.
Here’s what you can expect during each stage:
The vibe check:
This is typically informal. Be prepared to give the “elevator pitch” version of your career story.
The primary purpose is for the interviewer to gauge that you are: A) capable of basic human communication, B) have some degree of technical know-how, and C) aren’t completely lying on your resume. Once these goals are accomplished, it’s on to the next round.
The technical round:
This might be a coding test in Python (think FizzBuzz) and/or SQL.
If you don’t have a coding test, be prepared to speak at length about all the technical details from one of the projects in your GitHub portfolio/on your resume.
The hiring manager interview:
This inteview might be combined with the technical round.
Be prepared to discuss technical questions, technical details about your project, and behavioral questions.
Don’t forget to ask your own questions about the company, the role, team culture, etc.
The culture fit interview:
You may be interviewed by multiple people simultaneously during this round.
You might get behavioral and/or technical questions. The main focus is not necessarily to get the technical questions right, but to test how you communicate about technical concepts with others.
Your answers to behavioral questions will weigh heavily in this round. The interviewers are likely your future team members. They want to know if they’ll be able to get along with you, or if you’ll be difficult to work with.
The senior leader approval interview:
This is less likely to happen at a larger company. At small companies, it’s almost a guarantee.
If you get to this stage, you’ve basically got the job. You’ve passed the earlier rounds and the hiring manager has recommended hiring you, as long as you pass this final step.
Even though meeting with a senior leader feels scary and high stakes, this round is just a final vibe check and an opportunity for you to meet the Big Boss.
Concluding thoughts, thank you notes:
These steps may unfold over the course of days or weeks. Anytime you speak with someone or meet a new person, send a brief thank you note later that night via email or LinkedIn if you don’t have an email address. This is considered basic etiquette and companies might think less of you if you don’t follow it.
An example thank you note:
Hi [Susan],
It was great getting an opportunity to speak with you today. Thank you so much for taking the time to meet with me. I especially enjoyed learning more about how [Great Company Inc.] uses data for making key business decisions. I’m excited about the prospect of joining the Data Engineering team, and I’m looking forward to hearing from you soon.
Thank you,
[Your name here]
Behavioral Questions
The behavioral questions during the interview process all lead back to answering one question: would I like working with this person?
A lot of sub-questions flow from the goal of answering that one question.
To be clear: it’s not a popularity contest. The interviewers are genuninely trying to evaluate whether you will be a good culture fit. They also want to know if you’re going to be a nice person, or if you’re going to be a bit of a pain. Your potential future coworkers will be spending 40+ hours a week with you. They want to make sure you’ll be a positive influence who pulls their own weight, and not someone who will make those 40+ hours even harder.
Here are some characteristics they’re looking for/not looking for:
Does this person take responsibility, or do they blame others when mistakes occur?
Will this person be supportive of others, or will they isolate themselves and refuse to help anyone else?
Is this person persistent and resourceful, or do they just give up when they encounter hard problems?
Is this person legitmately friendly, or are they going to be mean and snarky for no reason?
Well, obviously you’re awesome, responsible, supportive, persistent, friendly, etc. But anyone can say, “I’m friendly. I really get along with others. I work hard. I own my mistakes. Hire me!” The purpose of the behavioral section is to provide you with an opportunity to tell stories that will prove you are this kind of person.
Here are some of the behavioral interview questions you should be ready to answer. The best answers provide specific examples, and they tell a story. Don’t just tell me you’re resourceful. Give me an example.
Question: Tell me about yourself and your career so far.
You always need to be prepared to give a short, medium, and long version of “your story.”
For story structure, I prefer to start with where I am currently in my career journey and what I’d like to do immediately next. Then I go back to the beginning and move forward chronologically. This gives the interviewers a clear idea of who I am and what my goals are, but it also allows me to tell my career journey story.
When describing transitions, I make sure to give reasons for why I moved from one step of my journey to the next. I keep these reasons positive. I try to show I was always running toward something I wanted, even if the full truth is that I was also running away from something I didn’t want anymore.
I try to portray that I’m an ambitious person who has gone through a journey of growth and self-discovery. Examples:
I left teaching because it was all I’d ever done and I wanted to try out something different. I’ve always loved technology, so I found a job at a tech startup.
At my startup job, I saw what the Data Scientists did. I thought it was really cool, and I wanted to learn how to do that myself, so I went to grad school.
When I was in grad school, I learned about Data Engineering. It was even more interesting to me than Data Science, so I pivoted my focus.
Question: Tell me about a really difficult problem you solved. How did you handle it, and what did you learn?
The interviewers are not truly judging you on the difficulty of the problem you solved here, though having solved a really difficult one doesn’t hurt. What they’re looking for is to see inside your problem solving process. A good answer will show that:
You don’t back down from tough problems
You have some basic level of technical skills
You know how to teach yourself new skills to solve problems
You can iteratively test solutions (try again until you succeed)
You can reflect on what happened and learn from experiences
Question: Tell me about a time you had to collaborate with others. How did you work together with them to reach a goal?
With this question, they’re mostly trying to figure out if you’re a brave little toaster who only does things all on your own, or if you know how to be a team player. For this question, the problem solving process is less important. What’s more important is gauging how you contributed and interacted with others:
Did you support others to assist them, or did you just bulldoze the situation?
If you were the expert, did you step up to be a leader?
If you were not the expert, how did you still manage to play a supporting role?
Did you bring a win-win mindset to the situation, or were you critical of others?
Question: Tell me about a conflict you had with a coworker. What was the conflict and how did you resolve it?
This question is tough, because you basically need to admit to friction with someone else without getting defensive or blaming the other person. But it’s pretty much guaranteed that at some point in your career, your working style will be completely different from someone else’s, and that will cause tension, or maybe even outright conflict.
My advice for this question: describe what it was like to work with a coworker who has a very different “work personality” than you, and how you figured out a way to work together. Here’s an example:
I am a pretty “Type A” thinker. I’m very linear. This is great for getting things done, but I’m rarely spontaneously creative. When I’ve worked with people who are more “Type B,” they are typically strong in creative/divergent thinking, but they’re not as goal focused. Because our natural thinking styles are so different, this makes it hard when we have open-ended discussions about a project. I’m focused on driving toward the goal to the exclusion of all else. Meanwhile, my Type B coworkers keep coming up with creative ideas that might make a big impact, but to me, feel like off-topic distractions.
The solution I’ve found is to set aside deliberate time during the discussion for planning project execution, and deliberate time for creative thinking. This has allowed our team to leverage my Type A strengths and my coworker’s Type B strengths without us stepping on each others’ toes.
Question: Tell me about a time you made a mistake. What was it, and what did you learn?
This question feels like a trick. I’m supposed to tell you about a time I really screwed up? Why would you hire an idiot like that!
Eventually, every single person makes a mistake at work. Sometimes these mistakes even cost the company thousands of dollars. They want to know that, when you inevitably make this mistake, you are going to tell them right away, own up to it, and learn from it. Ideally, you even participated in creating a solution which prevented others from making the same mistake.
Question: Tell me about your short and long term career goals. Why do you want [working at Data Company Inc.] to be your next step?
The interviewers aren’t looking for you to suck up. You don’t need to tell them their company is the most amazing company ever. A positive attitude about possibly working there is a minimum requirement though.
They’re trying to find out if you’ve got a plan for yourself. We all need to get paid, but they don’t want to hire someone whose career plan isn’t any more deliberate than: “I need a paycheck and I heard you guys have those.”
Describe your plan. Right now, you’re at X place in your career. But in Y years, you want to be at [insert place] in your career. And eventually, in Z years, you’d like to [insert your bigger goal].
If you don’t have a plan, then your plan is to learn more about the landscape of opportunities, and you think this company would be a great place to make an impact while growing your perspective.
Question: Tell me about something you’re currently working on improving.
The purpose of this question is to see if you are self-aware and improvment-focused enough to have goals and plans for your own growth and development.
Are you someone who needs to be told to improve? Or can you diagnose the parts of yourself you want to be better, and start working toward improving them?
Are you someone who thinks they are perfect? Nobody is, so if you think there’s nothing for you to improve, you’re not very self-aware and you’re probably insufferable to work with.
Answering this question is not confessing a weakness. It is showing that you have a growth mindset, and a plan for becoming better.
Discussing Your Portfolio Projects
Of course, you need to be ready to talk about your GitHub project portfolio.
Make sure you have a profile README set up on your GitHub profile. The hiring manager isn’t going to spend much time looking at your GitHub (assuming they do at all). You want whatever they see to be a good looking advertisement about you as an engineer. Here is my GitHub profile as an example.
If your hiring manager actually looks at your projects, you want to make sure the project repositories are buttoned up. Tips:
Have clear descriptions and README files that look clean, professional, and largely devoid of writing mistakes. This is an opportunity to show how you would write documentation for a work project. Use Grammarly to clean up your writing if needed.
Have comments in the code. Nobody wants to hire an engineer that doesn’t comment their code! Most of the code you write will be maintained by someone else. You need to be a good commenter.
If anyone actually looks at your code, mostly they are going to glance at the structure of the code. Are your variable names atrocious? Do you know how to properly format SQL or use a linter so it’s readable?
When talking about your projects in interviews, you will want to highlight these attributes:
The purpose of the project
The technologies you used and why
The tradeoffs of using those specific technologies and not others
How the code works and how you structurd it (the actual technical details)
The challenges you overcame while doing the project
What you learned and what you would do differently next time/with more time
Notice that only one of the bullet points above even deals with the technical details. While talking about your project at length with interviewers will help them understand your technical skills, a lot of this is about everything surrounding the project. It’s not enough to just be able to code. You need to be able to organize your work and describe your thinking.
Questions to Ask the Interviewers
At the end of every interview, you will be asked if you have questions.
You should always have questions.
Here are some of my favorite questions to ask:
Culture:
Can you give me an example of what [insert value from the company/team culture] has looked like on this team?
Can you tell me about a time someone made a mistake and how the team or leadership handled the situation? (Note: this will tell you a lot about how you might be treated when you inevitably make a mistake.)
Evaluation, Promotion, Progression:
Can you tell me about a really stellar Data Engineer on this team/at this company who got promoted to more responsibility? What attributes did they have that made them a success? (Note: if they can’t, this may be a red flag that it could be hard to get promoted.)
Expectations and Evaluation:
What would someone who is really successful in this role look like at 90 days, six months, and after one year?
What does the evaluation cycle look like? How do you communicate with employees about their performance? (Ideally performance communications happen repeatedly, even if there’s only one formal end-of-year meeting.)
Company Plans, Long Term Focus:
What is the company’s top focus for the next 6 months?
What is our team’s top focus for the next 6 months?
What is the company’s longer term (5-year) vision?
If you’re planning to work at a startup, the answers to these questions can matter a lot. Does the company have a realistic vision? Are they working on something you feel you can believe in?
My favorite question to end the interview:
What am I not asking that I should be?
Final Note: Interview Nervousness
This seems strange to hear, but the interviewers are actually rooting for you at every step of the process.
Hiring a new person is a risk. The people doing the interviewing would like nothing more than for you to crush it and impress the hell out of them.
They are going to get a new team member. They would really prefer if that person were a great hire. They’re hoping that you’ll be the one they want to pick. And if you’ve ever interviewed people, you know that watching someone give a great interview can make you feel inspired.
Keep these thoughts in the back of your mind. It’s normal to feel nervousness, but hopefully reminding yourself what the people on the other side of the table are thinking will put you more at ease.
While I think this article covers nearly everything you need to be prepared for Data Engineer job interviews, it’s possible I’ve missed some details. You might even disagree with some of my advice. Feel free to add your thoughts to the comments.
Best of luck! Let me know how your Data Engineer journey goes.