3 Lessons from a Failed Technical Interview
Learn from my mistakes so you don't do the same thing
The skills that make you successful in a data role are completely different from the skills needed to land one. This disconnect creates a frustrating paradox: landing a data job is often harder than actually doing the work.
In your day-to-day work, you might spend hours thinking through and optimizing your query, carefully analyzing edge cases, and documenting your methodology. But in an interview, you're expected to remember every detail of a project at the drop of a hat.
The real work of analytics engineering rewards deep thinking, methodical problem-solving, and attention to detail. Interview processes reward quick thinking, confident speaking, and the ability to perform under pressure. These are fundamentally different skill sets.
For many of us, myself included, these skills don’t come naturally. We thrive with agendas, preparation time, and the space to showcase our analytical thinking. This is why it’s so important to practice live coding scenarios, memorize STAR method examples, and work on speaking confidently off the cuff.
I recently interviewed for a Senior Data Engineer position and unfortunately didn’t make it past the technical interview. Luckily, the company was kind enough to provide feedback. So, in today’s newsletter, I’m putting myself on blast so you can learn from my mistakes and prepare for the things that may make you fail a technical screen as well.
Back every answer up with your direct contributions.
With technical questions, interviewers could ask you about your experience or more theoretical best practice, ”what would you do” scenarios. When giving your answer, make sure to always back it up with how you’ve used that method in your previous roles. They want to not only hear a strong theoretical answer but for you to prove how you’ve used it in practice.
EX: “How do you deal with stakeholders who don’t have clear asks?”
❌ ”I like to keep asking them questions. I’d hop on a call with them once their request comes in, asking questions about what frustrations they’ve experienced, how they’ve gone about solving them, and what roadblocks they are facing. Often, stakeholders don’t necessarily know what they want and asking a lot of clarifying questions can help you get to the root of it”.
✅ [include the above answer but also add] —> “In my previous role, when a finance stakeholder asked me to write a query in Sigma for refunds in Stripe, I made sure to clarify exactly what he was looking for and how he planned to use it. We jumped on a call and I asked him how he currently looked at refunds, what he does with the data, and why he’s using Stripe Sigma. I was able to understand the bottlenecks in his process that I could fix by moving the query from Stripe Sigma to a dashboard in Quicksight and adding some additional fields to ensure he had everything he needed for the refund process in one central location”.
Write out all of your major projects and the technical concepts used in each before interviewing.
If you’re anything like me, all of your past work tends to blur together. It’s difficult to remember exact projects and what models you transformed into SCD2s or built incrementally.
This is why it’s so important to anticipate the technical questions that they will ask so you can prepare proper examples. Before going into a hiring manager or technical interview, write out all of your major projects and what tools and concepts you used.
Doing this will keep examples top-of-mind for you to pull from in case they come up in an interview. They can also be helpful in scenarios like the one above.
Here are some examples of projects I’ve worked on and the skills used:
building out creator recommendations models —> dbt data contracts with engineering teams, dimensional modeling, cross-collaborations with business teams
migrating from Census to Hightouch —> ephemeral models, sync modes, validation across platforms, cross-collaboration on validating data with business teams
It helps to write down as many details as you can remember because you never know what the interviewer will be most curious about!
Practice the STAR method.
I like to frame every one of my projects as examples using the STAR method. If you aren’t familiar:
Situation- what is the context?
Task- what did you have to do?
Action- what did you do to solve this?
Result- what value did this drive for the business?
This helps me explain situations concisely and clearly, which is sometimes hard for me to do when speaking about a project. I document this method for different scenarios like a time when I’ve worked with a difficult stakeholder, a time when I had to make a technical tradeoff, the project I’m most proud of, etc.
Then, I give this paragraph to Claude to and ask, “How can I make this STAR situation clearer? Does this communicate the value that I provided clearly?”. It will then organize my paragraph into bullet points for each letter, sometimes moving around different points I discussed to the section that makes most sense.
I copy and paste the answer it spits out into a document to then practice rehearsing my different situations. It’s also helpful to think about the different themes in each situation in case you’re asked a question that isn’t exactly like the one you drafted out.
If you are starting out on your analytics engineering journey, I highly recommend reading The ABCs of Analytics Engineering while I review all of the must-know concepts for succeeding as an analytics engineer.
Happy 4th of July! 🇺🇸
Madison