[ETR #123] Stop Succumbing To This Interview Pitfall

A newsletter from PipelineToDE

Hi fellow data professional!

I faced a challenge in an interview last week; half of the questions pertained to a tool I had never used. While I familiarized myself with the stack based on the job description, I didn’t go that deep. Initially I wanted to panic a bit; but then I honestly responded “I haven’t used that in production but I used (a GCP equivalent).”

The tool in question was Snowflake; instead of trying to extrapolate with no experience, I drew parallels between what I knew about database behavior: Partitioning, clustering, performance optimization.

I did know that the main difference between Snowflake and BigQuery’s billing model: Snowflake data warehouses are established with specific compute parameters while BigQuery uses a pay-as-you-go slot model.

I got through to the next round, where I was grilled on Dbt, a tool I had used sparingly.

Does this mean you need to dedicate a portion of your job search to learning every cloud and BI tool in existence? Definitely not. But you should know the use cases/tradeoffs for popular tools like Snowflake, Dbt and Databricks.

To accomplish this, you can create a mapping of your stack to your target company’s stack.

You can absolutely use LLMs to aid you in creating interview prep. Superhuman has made 1000+ prompts available across industries, including 15 tailored specifically for data engineering. Before you dump another vague request into your LLM’s chat, see if your use case is included in Superhuman’s prompt library.

I first encountered the idea of stack comparison when I began learning data bricks. Products like SQL environments, orchestrated workflows and virtual machines are abstractions that exist across cloud providers.

Knowing this allowed me to say, in a technical interview geared toward an AWS stack, “I built a monitoring system for Google Compute Engine VMs, GCP’s EC2 equivalent.”

Immediate comparison signals to an interviewer that you didn’t just cram buzzwords into a resume; you dedicated prep time to transposing your background onto the tools their team uses.

It can be tempting to create a stack map for every product on the two clouds you’re comparing. But really you just need to know:

• Serverless execution - Cloud Run vs. Lambda
• Compute - Compute Engine vs. EC2
• SQL environment - BigQuery vs. Redshift
• Orchestration - Composer vs. MWAA

As a more nuanced example, there are also several services that facilitate the running of Airflow. You can run Airflow locally, on MWAA, Composer or even a managed service like Astronomer.

I personally wouldn’t fixate on the “under the hood” tools.

If a job posting asks for Astronomer proficiency but you’ve only run Airflow on Composer, you still know Airflow.

To answer the enduring question, what if you don’t know x? You don’t need to know the tools a manager asks for, just when and when not to use them.

And if that fails, then fall back on the ultimate engineering catch-all, “I can upskill.”

Thanks for ingesting,

-Zach

P.S. Let's connect on LinkedIn. Just send me a connection request saying you're a newsletter reader.

Get production code templates & monthly deep-dive architecture breakdowns

Interested in sponsoring ETR? Partner with me to reach an engaged audience of data professionals