Skip to content
Log in Join free
The Databricks Data Engineer cover art

Jakub Lasak

The Databricks Data Engineer

A Technology podcast

#145 in Technology · 🇳🇬
Good podcast? Give it some love!

About the show

Short episodes on the Databricks skills that get data engineers hired and promoted. One theme per episode, built for a commute: how senior engineers make the calls, what interviews actually test, and the career moves that change your level. By Jakub, a Databricks Data Engineer (ex-Uber).

Newest episodes

Medallion architecture vs. reality - when your Databricks bronze, silver and gold are just folders

12 min

Three schemas. Bronze, silver, gold. The diagram got nods in the architecture review. Then two dashboards land in the same leadership meeting with two different active customer counts, and the head of finance asks which one is right. The trail ends at bronze, where rows that failed parsing were quietly dropped. The vendor keeps thirty days. Every label was there. What the medallion was invented to fix was not, and the pipeline had rebuilt the old mess across three schemas. In this episode: - What pipelines looked like before bronze, silver and gold, and the three pains the diagram was drawn to fix - Why dropping bad rows at bronze feels clean and quietly decides how far back you can rebuild - When skipping a layer is the right call, and why seven layers is not a safer bet than three - The question to ask about every gold table before your next architecture review This episode is for Databricks data engineers who build or inherit a medallion architecture and have wondered what silver is actually for. Whether you're designing a new lakehouse or maintaining one that looks textbook, you'll walk away with a way to check that each layer does a job no other layer does, and to defend it with more than "it's best practice." --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

How the always-sure Databricks engineer caps their own promotion (and never sees it)

10 min

Mark's manager asks the room one question: if we move the biggest fact table onto Liquid Clustering, will it fix the slow dashboards? Mark answers first: yes, problem solved. Sarah says what she'd bet on, what she doesn't know yet, and when she'll know. Sarah claimed less. The decision goes to Sarah. Nobody tells Mark why. The instant-answer reflex that got him to mid-level is the same one that quietly keeps him there, and there's a name for what he's paying. In this episode: - Why a fast, confident answer is right early in a Databricks career, and when it stops paying - What the room needs from you when nobody knows for sure - The difference between being decisive and sounding certain - One sentence, two parts and a date, to carry into your next design review This episode is for Databricks data engineers who answer fast and still watch the risky migration and the design review invite go to someone else. You'll walk away with a way to make your "I'm sure" mean something again. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Two Databricks jobs, one Delta table, same moment: 3 endings (and the 1 that needs a human)

11 min

Two in the morning. A nightly merge is folding yesterday's orders into a Delta table. A backfill someone kicked off before logging off is correcting March. Neither job knows the other exists, and nothing in Delta would tell them. A lot of design around this runs on superstition. Either "it's Delta, it's ACID, relax." Or "never let two jobs touch that table." Both are guesses, and the tidy middle version, same data collides, different data is fine, falls apart the first time the error shows up. In this episode: - What Delta actually does when the second job tries to commit to a table that moved under it - Why two jobs writing completely different months can still collide, and what that error message is really telling you - Why scheduling jobs hours apart is a lock you built by hand, and the cheaper fix - When a retry quietly does damage instead of fixing things This episode is for Databricks data engineers who own a Delta table with more than one writer: a nightly merge, a backfill, a plain append. Whether you're designing a new pipeline or defending one in a design review, you'll walk away with a way to say which endings each writer can produce, instead of hoping. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Similar podcasts

All episodes

Medallion architecture vs. reality - when your Databricks bronze, silver and gold are just folders

12 min

Three schemas. Bronze, silver, gold. The diagram got nods in the architecture review. Then two dashboards land in the same leadership meeting with two different active customer counts, and the head of finance asks which one is right. The trail ends at bronze, where rows that failed parsing were quietly dropped. The vendor keeps thirty days. Every label was there. What the medallion was invented to fix was not, and the pipeline had rebuilt the old mess across three schemas. In this episode: - What pipelines looked like before bronze, silver and gold, and the three pains the diagram was drawn to fix - Why dropping bad rows at bronze feels clean and quietly decides how far back you can rebuild - When skipping a layer is the right call, and why seven layers is not a safer bet than three - The question to ask about every gold table before your next architecture review This episode is for Databricks data engineers who build or inherit a medallion architecture and have wondered what silver is actually for. Whether you're designing a new lakehouse or maintaining one that looks textbook, you'll walk away with a way to check that each layer does a job no other layer does, and to defend it with more than "it's best practice." --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

How the always-sure Databricks engineer caps their own promotion (and never sees it)

10 min

Mark's manager asks the room one question: if we move the biggest fact table onto Liquid Clustering, will it fix the slow dashboards? Mark answers first: yes, problem solved. Sarah says what she'd bet on, what she doesn't know yet, and when she'll know. Sarah claimed less. The decision goes to Sarah. Nobody tells Mark why. The instant-answer reflex that got him to mid-level is the same one that quietly keeps him there, and there's a name for what he's paying. In this episode: - Why a fast, confident answer is right early in a Databricks career, and when it stops paying - What the room needs from you when nobody knows for sure - The difference between being decisive and sounding certain - One sentence, two parts and a date, to carry into your next design review This episode is for Databricks data engineers who answer fast and still watch the risky migration and the design review invite go to someone else. You'll walk away with a way to make your "I'm sure" mean something again. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Two Databricks jobs, one Delta table, same moment: 3 endings (and the 1 that needs a human)

11 min

Two in the morning. A nightly merge is folding yesterday's orders into a Delta table. A backfill someone kicked off before logging off is correcting March. Neither job knows the other exists, and nothing in Delta would tell them. A lot of design around this runs on superstition. Either "it's Delta, it's ACID, relax." Or "never let two jobs touch that table." Both are guesses, and the tidy middle version, same data collides, different data is fine, falls apart the first time the error shows up. In this episode: - What Delta actually does when the second job tries to commit to a table that moved under it - Why two jobs writing completely different months can still collide, and what that error message is really telling you - Why scheduling jobs hours apart is a lock you built by hand, and the cheaper fix - When a retry quietly does damage instead of fixing things This episode is for Databricks data engineers who own a Delta table with more than one writer: a nightly merge, a backfill, a plain append. Whether you're designing a new pipeline or defending one in a design review, you'll walk away with a way to say which endings each writer can produce, instead of hoping. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Unity Catalog Can't Manufacture Trust: Your Most-Read Databricks Table Might Be the Least Trusted

11 min

The rollout is done. Every production table migrated to Unity Catalog, every one owned by a team group, and the revenue table carries a certified check mark. The platform lead posts in Slack: fully governed. Monday morning, finance replies in the thread. The revenue on the finance dashboard and the revenue in the sales deck are about three percent apart. Which one's real? The catalog has something to show for every field: an owner, a check mark, a health indicator that says healthy, a beautiful lineage graph. None of them answers that question. Unity Catalog might be the best thing your platform team ever shipped, and it still can't make one person believe a number. The missing piece isn't a feature. It's the habit of treating every trust complaint like one. In this episode: - Why an owner, a certified check mark and a healthy indicator can all look right while the number is still wrong - Why the most-read table in your catalog might be the least trusted one - What a metric view settles when two teams define revenue differently, and what it leaves to humans - The one question to ask before you touch the platform for any governance request This episode is for Databricks data engineers who work in Unity Catalog and keep getting governance requests another tag won't fix. Whether you just finished the migration or you're the one answering "which number is real?" in Slack, you'll walk away with a way to sort every request before anyone opens a ticket. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Your Databricks director: what they fear, why they fund the duller proposal, what gets yours through

11 min

Two proposals sit on a head of data's desk, both about the nightly pipeline that feeds the finance dashboard. One swaps the full reload for incremental loads with Auto Loader: it finishes in a fraction of the time and it's cheaper every month after the first. The other keeps the full reload, puts it on a bigger job cluster and starts it an hour earlier. It costs more. Forever. She asks one question, "What happens if this breaks on quarter close?", and approves the second one. It's tempting to call that ignorance or politics. It's neither. The better proposal was arguing merit to someone who gets asked a completely different question upstairs, in a meeting the engineer who wrote it will never be in. In this episode: - The fear that filters every proposal on your director's desk, and why it isn't fear of change - The question a tech lead, an engineering manager and a director each get asked, and why pitching a director like a tech lead loses - Three kinds of data leader, and how to tell which one you work for from the first question they ask about any proposal - Three things to add to any proposal with a real spread, so it gets funded without getting duller - A two-sentence test to run before anything goes upstairs This episode is for Databricks data engineers who have watched a better proposal lose to a duller one and couldn't explain why. Whether you're the mid-level engineer writing the pitch or the senior trying to get a platform change funded, you'll walk away able to read your leader's decisions and write proposals they can say yes to. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Data skew is a checkout line - how to unjam Databricks jobs without bigger clusters

12 min

Your nightly Databricks job ran long, so you open the Spark UI. Two hundred tasks. One hundred ninety-nine finished in about a minute. One is still running, and it's been running for forty. You double the cluster and rerun it. Same forty minutes. Nearly twice the bill. The cluster was never the problem. The rule that keeps your joins and group-bys correct is the same rule that lets one task carry the whole job, and no amount of extra workers moves that work off it. Sometimes the stuck task turns out to be worse than slow. In this episode: - Why more workers and more shuffle partitions both leave the stuck task exactly where it was - Where heavy keys come from, and the one source that is usually a bug in a performance costume - Why plenty of skewed aggregations never slow down, and where adaptive query execution on Databricks does and doesn't split the load - When salting pays, when a different approach beats it, and when the right call is to leave skew alone This episode is for Databricks data engineers whose reflex for a slow Spark stage is a bigger cluster. Whether you're mid-level and tired of paying for compute that changes nothing, or senior and about to be asked "how do you handle data skew?" in an interview, you'll walk away able to tell a skew problem from a capacity problem before you touch the cluster settings. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Can You Reach Senior Databricks Engineer Without Ever Leading an Architecture Review?

11 min

Sam is four years into a Databricks role, up for senior this cycle. Merged pull requests on the ingestion layer. The nightly job he rescued at three in the morning when the orders table stopped landing. Then his manager asks for one call where the answer wasn't obvious, he framed it, and he lived with the result. Sam starts three different sentences. None of them finish. The packet is full of work and empty of decisions. Sam thinks what he's missing is a chair at the architecture review table. It isn't. In this episode: - What the architecture review was ever supposed to prove, and why the room was never the proof - The one test to run on any call you've made, with no meeting, no invite and no template required - The two paragraphs that turn a design doc from a build plan into a decision somebody can audit nine months later - How to run the whole thing in a Slack thread on a four-person team with no review process For Databricks data engineers building a case for senior, especially where architecture reviews are rare or don't exist. You'll walk away able to tell work you did apart from a decision you can prove you owned. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Why Databricks serverless exists, and which of your jobs should stay on classic clusters

12 min

Open the workspace. Start a cluster. Get coffee. Come back, and sometimes it's ready. If you've been doing this a few years you can feel that wait in your shoulders, and it's the least interesting part of the story. Before any of it, you had to answer a question you could not possibly answer: how big should this be? Start small and you pay in latency. Start big and you pay for machines that are barely breathing for most of the run. Wait, or waste, and there was never a third option. In this episode: - Why the cluster wait was only the receipt, and what classic Databricks compute never actually solved - Why Databricks can keep compute warm when your own team never could, and what that shows up as in the rate - What "serverless" means here, jobs and notebooks, and why a serverless SQL warehouse is a different conversation - The thing a fixed cluster was quietly doing for your budget that serverless stops doing, and why the policy you're thinking of doesn't cover it - Three tests to run on your own workloads this week, plus the ones that can't move at all no matter what the math says This episode is for Databricks data engineers who have serverless sitting in a dropdown and no real argument either way. Whether you're defending a migration in an architecture review or explaining next month's bill, you'll walk away able to say which of your jobs should move, which should stay on classic, and why. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

How Databricks engineers lose the final round (and the 4 places it happens)

10 min

You cleared the recruiter screen. You cleared the Databricks technical round, and cleared it well. Then the final round, then the email that says strong candidate, tough decision. You go back looking for the mistake and there isn't one. You were good. Somebody was just easier to picture. That sentence never makes it into the feedback. And it isn't a bad panel or a bias against you. It's a belief you carry into the room: that the final round is the last exam, the hardest one. If your last stage is still a coding or SQL round, that one is an exam, go and study. But most of these emails come out of a different loop, where the technical question was settled and the form closed well before you walked in. In this episode: - What that last round is actually deciding, and why it rarely shows up on a rubric - The four places a strong candidate loses it, ordered from the most common to the one that stays invisible longest - How an unnarrated trade-off reads as taste instead of judgment, and the one sentence that fixes it - The single behavior to take into your next final round, and why trying to fix all four is the wrong move This episode is for Databricks data engineers who keep reaching final rounds and keep getting the same email. Whether you're three no-offers into a year of interviewing or prepping for a loop that starts next week, you'll walk away with one concrete thing to change in the room, not another weekend of Spark internals. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The real reason your Databricks week never got simpler - it isn't the lakehouse

11 min

Your org finished the migration. Two systems became one. The nightly copy nobody wanted to own is gone, and so is the quarterly meeting where finance and the data science team each showed up with a real revenue number from tables in different buildings. That pain was real, and it is genuinely dead. So why does your week feel heavier than the deck promised? Because most of what got sold as simplification was a relocation. The copy didn't die, it turned into an argument about which schema in which catalog is the real one. The sync job didn't die, it became a maintenance calendar that pages nobody as an alert and pages you months later as the job that got a little slower every week. In this episode: - Why every architecture in this field gets sold on removal, and what the slide never names - How to tell the work that genuinely died in the lakehouse from the work that only changed address - Why a heavier week after a clean migration is not a verdict on you - The two questions to run on the next architecture pitched to your org, and why the second one is about names, not tasks This episode is for Databricks data engineers who got the win the lakehouse promised and still can't explain why the calendar filled back up. Whether you ran the migration or inherited it, you'll walk away with a lens you can run on any architecture sold as the thing that finally makes data simple. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Databricks incident where the most senior engineer never touched the keyboard

11 min

Thursday, just after two in the afternoon. The first message doesn't come from an alert, it comes from a person in revenue operations: the biggest region jumped overnight and nobody sold anything new. Nobody answers. The engineer who owns the nightly Lakeflow job finds it in the run history. An overnight failure, a restart before anyone was awake, a window of orders written a second time under every executive dashboard in the company. So the fixing starts immediately. Head down, no message, because typing in the channel feels like stealing time from the fix. Which is how a second engineer joins a silent channel, starts the same correction, and lands the same window twice again. Effort was never the scarce thing in that channel. In this episode: - Why every outage is really two problems running in parallel, and only one of them has an owner - What a staff engineer did in ninety seconds without opening a notebook, and why the slower fix was the point - How to state an impact boundary a non engineer can repeat, including the bucket everyone skips - The one sentence that takes the most underpriced role in an incident, at any level This episode is for Databricks data engineers who have sat in a chaotic incident channel watching questions pile up faster than anyone can answer them. Whether you own the broken job or you're wondering if it's your place to speak, you'll know which seat in that channel is empty and how to take it. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

9 Databricks decisions that reveal your real seniority (and one that only looks senior)

11 min

Three in the morning. The nightly job that loads the orders table died halfway. Half the tasks are green, and the rerun button is right there. What you do in the next ten seconds says more about your level than anything on your resume. Nobody places you by your title or your years. They place you by a pattern of routine calls made fast, in the dark, and everyone around you can read it except you. In this episode: - The ten-second question to ask before you rerun anything that writes - Why the fastest fix for a slow Databricks job is often the one that renews its cost every month - How the flaky job you quietly restart every week stops being a defect and starts being weather - What it means that most data engineers cannot price their own job, and what changes when they can - The one call that reads as the most senior contribution in the room and almost never is This episode is for Databricks data engineers who have the title, or want it, and want to know how hiring managers actually place them. Whether you are prepping for a senior interview or wondering why your level has not moved in two review cycles, you will walk away with a lens for your very next decision. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Databricks job market in 2026: there are two of them, and only one answers

11 min

One engineer tells you hiring is back and recruiters are warm again. The next one is sixty applications deep and hearing nothing. Same month, same platform, sometimes the same city. That sounds like noise. It isn't. It's a split, and what sorts you onto one side of it has almost nothing to do with how good you are. In this episode: - Why forty applications in a week returns two dead screens, while a smaller and pickier search gets answered - The three things that changed in the last year and turned the generic Databricks data engineer posting into a stack of a hundred before lunch - Why fewer postings can be the better market for you, and the one condition that has to hold for it - The honest case against specializing, plus the test for which second surface is actually safe to bet on - The one resume sentence to rewrite this week, using work you already did and never wrote down This episode is for Databricks data engineers hearing two contradictory versions of the 2026 market and unsure which one is theirs. Whether you're mid-level and stuck in the application pile, senior and getting less traction than your years should buy, or early career and facing the most crowded entry market in a while, you'll walk away knowing which market your resume is sitting in and what it costs to move. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Databricks broadcast joins: when the memo beats the meeting (and when it kills a task)

10 min

Two engineers on the same team join the same big orders table to the same small lookup table. Same cluster, same data, one line of code different. Sarah's finishes in the time it takes to get a coffee. Mike's dies, and the error isn't about the data at all. A task ran out of memory building a hash map. Broadcast joins get passed around as a tip instead of a model: small table equals fast, flip the switch when a join runs long. But the mechanism in almost every write-up is years out of date, and the size Spark checks is not the size that has to fit in memory. In this episode: - How to explain broadcast versus shuffle joins at standup, in one sentence, without a whiteboard - What actually happens on a current Databricks runtime when a join broadcasts, and why the popular explanation stopped being true - Why the size estimate Spark trusts is not the size that lands, and where to read the real payload - What adaptive query execution rescues you from, and the two places its hands are tied - The question to ask before you add a broadcast hint, and the failure signature that tells you a broadcast is what broke This episode is for Databricks data engineers who write joins every week and treat the broadcast hint as a speed switch. Whether you're mid-level and tired of guessing why one join flies and an identical one falls over, or senior and about to be asked in an interview why Spark chose a sort merge join, you'll walk away able to predict the call before you run the query. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake1

Build the platform or use the platform: the two Databricks data engineer tracks nobody names

11 min

Two Databricks engineers sit at adjacent desks. Same title, same pay, same words in the ladder document. Watch a year go by, and they are not doing the same job. Both get rated strong. Both get told they're ready for more scope. Nobody says the useful thing: the evidence those two are stacking isn't interchangeable, and one of those years makes no sense on the other one's promotion packet. In this episode: - Why the data engineering ladder quietly forks, and why that fork is missing from every ladder document - The five-minute question that tells you which track your last year of Databricks work actually built toward - How each track reaches staff, and the very different proof each demands - Where each track stalls a good year, and what to say in your next one on one to get moved off it This episode is for Databricks data engineers past the junior stage who keep getting strong reviews and vague answers about what's next. Whether you write the cluster policies and ingestion frameworks or ship the tables the business argues from, you'll walk away able to name your track and ask for the work that gets you to the next rung. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Why Unity Catalog exists: the Databricks governance chaos it was built to end

10 min

You inherited Unity Catalog already switched on. You learned the catalogs, the schemas, the grant statements, and never once saw the problem all of it was built to solve. Then someone in a review asks why the company suffered through that migration, and the best you've got is one word: governance. Here's what that word hides. Before Unity Catalog, one company ran five separate Databricks workspaces, each walled off - its own tables, its own users, its own rules, and nothing connecting them. A new analyst couldn't find where a table lived without three Slack threads. An auditor's one question - who touched customer data last quarter - cost two weeks of digging through old notebooks. In this episode: - Why every Unity Catalog design choice is scar tissue over a specific pain from the workspace-per-team era - How to explain what the migration actually bought your company in sixty seconds, to a product manager or a staff engineer - The difference between the engineer who says "governance" and the one who gets handed the next platform decision - Why turning Unity Catalog on does not automatically give you what it promises, and what actually does This episode is for Databricks data engineers who use Unity Catalog every day but couldn't explain to a product manager why it exists. Whether you joined after the migration and only ever saw the dropdowns, or you're heading into a design conversation where you'll need to justify the work, you'll walk away able to name the world that came before and read every feature as an answer to it. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

How to get credit for Databricks platform work without becoming the on-call martyr

11 min

Your pipeline hasn't failed in months, and nobody noticed. Then it breaks at 2am, you fix it in twenty minutes, and Slack fills with fire emojis and thank-yous. You're the backbone of the team. You've also been at the same level for three years, and nobody can quite explain why. It's not bad luck, and it's not a skill gap. The exact thing everyone praises you for, being the one who can always fix it, is the reason they can't afford to move you up. In this episode: - Why being the indispensable on-call hero quietly caps the level you can reach - How one engineer systematized a whole class of Databricks incidents out of existence and got promoted for it - The difference between measuring your work in saves and measuring it in risk retired - How to make yourself removable from the hero seat without handing away your job security - The one self-test that tells you whether your recognition depends on things staying broken This episode is for Databricks data engineers who carry the pager and keep the platform standing, but keep watching less essential peers get promoted first. Whether you're the war-room legend or the quiet engineer whose prevention work goes uncredited, you'll walk away with three concrete moves to turn indispensability into a promotion case. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Why Databricks Built Delta Lake When Parquet Was Already Good Enough

9 min

A nightly job is halfway through writing a batch when the cluster dies. Nobody runs a rollback, because there's nothing to roll back to. The next morning a dashboard is quietly serving half-written garbage, and no one can tell the good files from the wreckage. That's not a bug in Parquet. Every one of those files is valid, beautifully compressed, doing its job perfectly. The problem lives one level up, in the one thing a folder of Parquet files has never had and a real table cannot live without. In this episode: - Why a folder of Parquet files was never actually a table, and what a crashed write silently does to it - The single idea that turns ACID, time travel, and concurrent writes from three separate Delta features into one - How Delta really protects you when two pipelines write at once, and why your code should expect a "no" and retry - A portable question you can point at any storage system to know in one sentence whether you can trust it - The difference between how junior and senior engineers explain why their team runs on Delta This episode is for Databricks data engineers who write to Delta tables every day and have never had to explain why it exists. Whether you're prepping for an interview or sitting in a migration meeting, you'll walk away able to explain in sixty seconds what Delta actually bought you, and why the thing that came before it was quietly lying to everyone. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Databricks pipeline that ran green for a year and was wrong the whole time

8 min

A revenue-attribution pipeline runs overnight, bronze to silver to gold, and lands a clean set of numbers the whole company uses to decide where the money goes. Every morning: green. Every morning, everyone moves on with their day. For a year, nobody looked any closer. The job succeeded every single night, so everyone trusted the data. But "finished" and "correct" are two different words, and the space between them had been quietly swallowing a slice of revenue for eleven months, with no error, no warning, and not one alert. In this episode: - Why a Databricks job can run green every day and still feed wrong numbers into decisions that matter - The one question that separates "did it run" from "is it right" and cracks silent failures wide open - How an ordinary upstream schema change and an inner join can drop rows for months without tripping anything - The single correctness check that would have caught this on night one instead of month eleven - What to say in the room after an incident like this if you want leadership to trust you with the next hard problem This episode is for Databricks data engineers who own pipelines whose numbers someone actually makes decisions on. Whether you've ever said "the pipeline's fine, it's probably the dashboard" or you're staring at an all-green run history right now, you'll walk away knowing exactly what to check before you trust it again. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

How Photon actually makes your Databricks queries faster (and when it silently doesn't)

10 min

Two engineers run the same SQL on the same Delta table. Same data, same cluster size, copy-pasted code. Alex goes to make a coffee and comes back to a query still running. Sam's is done before they finish reading the first Slack message. The only difference is one checkbox on the cluster called Photon. Most Databricks data engineers have that box ticked, pay a premium for it on every DBU, and could not explain in plain English what it actually does. "Photon makes it faster" isn't an answer - it's just saying the box does what the box does. And there's one thing it quietly stops doing while you keep paying for it. In this episode: - The single architectural change underneath Photon, explained without one line of code or config - A mental model that lets you explain Photon to a PM in 60 seconds flat - Why Photon flies on scans, filters, joins, and aggregations but does nothing for certain custom code - The silent fallback that charges you the fast-engine premium for slow-engine work, with nothing on screen to warn you - The one query to open in the query profile this week, and the single question to ask of it This episode is for Databricks data engineers who run Photon every day and treat it as a speed toggle they never think about. Whether you're a mid-level engineer who clicks the box and moves on, or a senior who's never checked whether the premium is paying off, you'll walk away knowing exactly how to tell when Photon is doing the work you're being billed for - and when it isn't. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Databricks interview round nobody studies for (and almost everybody fails)

11 min

Picture the debrief room after a Databricks loop. Two candidates went through that day. On paper, a coin flip: SQL tied, Spark internals solid, system design clean for both. Score only the rounds with a rubric and you cannot separate them. And yet the room isn't split. One gets the offer, and the thing that decided it wasn't any of the rounds they studied for. It was the conversation everyone treats as filler. There's a reason your strongest technical answers can't win it for you, and it's not the one you'd guess. In this episode: - Why the round with no whiteboard and no visible rubric is the one that decides close calls - What it actually measures, and why your best technical round can't test it - The three ways strong engineers fail it without ever noticing - Why "tell me about a decision you'd make differently" is a trap baited with your own best work - The one prep move that needs zero new facts, just a few honest walks This episode is for Databricks data engineers cleared past the technical bar who keep losing the close calls. Whether you're prepping for your next loop or wondering why a strong interview still ended in a no, you'll walk away with a specific way to rehearse the conversation everyone treats as a throwaway. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Spark Shuffle is baggage claim: why your job waits instead of computes (and more workers won't fix it)

11 min

Your Spark job has been running for forty minutes. The dashboard shows your cluster isn't even busy. So you do the obvious thing: add more workers. And it changes nothing. Here's why. During a shuffle, Spark is barely computing at all. It's tagging every row by destination, piling rows together, spilling the overflow to disk, and hauling data across the network between executors. It's an airport rerouting every passenger's bag to a new carousel, and more baggage handlers can't speed up a single overloaded belt. In this episode: - Why your slowest wide transformation spends most of its time on logistics, not computing - The four-step model that lets you explain the shuffle to a teammate in sixty seconds - Why adding workers can make a skewed job slower, not faster - The two numbers in the Spark UI that tell you whether it's skew, partition count, or spill - The one diagnostic to run before you ever resize the cluster again This episode is for Databricks data engineers whose joins and aggregations crawl for reasons the cluster size never seems to fix. Whether you're mid-level and tired of guessing, or senior and tired of paying for compute that doesn't help, you'll walk away able to read a slow shuffle instead of throwing hardware at it. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Your Databricks data quality framework is a Yeti: everyone talks about it, nobody has seen it work

11 min

An architecture review. A platform team is presenting their data quality setup, and honestly, it's impressive. Expectations on every ingestion table. Drift metrics on the dashboard. A dedicated alerts channel. Then a finance engineer asks the only question that counts: when did this last catch something before one of us did? Silence. That silence is the whole problem. The decks, the suites, the dashboards are everywhere. The proof that any of it actually works is somewhere else entirely. In this episode: - Why the discipline every Databricks team talks about is the one with the fewest confirmed wins - A 30-second test that tells you if your data quality framework is alive or just well documented - Why checks chosen by what's easy to write miss the incidents that actually break you - The one deadline-night decision that quietly kills more frameworks than any outage - The reframe that separates teams who get caught off guard from teams who don't This episode is for Databricks data engineers who own pipelines feeding the numbers their company argues about. Whether you've got expectations in warn mode you never reverted, or a monitoring dashboard nobody reads, you'll walk away with a way to tell whether your framework is real and what to do if it isn't. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #DataQuality #ApacheSpark #DeltaLake

Why senior Databricks engineers write less code than mid-level ones

11 min

Two engineers, same team, both five years in. Last quarter Mark shipped forty-seven pull requests across three pipelines. Sam shipped nine. On any dashboard, Mark wins by a mile. Sam got the staff offer. Mark got a kind note about continuing to demonstrate impact. This isn't politics, and it isn't luck. It's a pattern that specifically catches the engineers who are best at shipping, because the most valuable work a senior Databricks data engineer does is invisible by construction. You can't put a ticket number on a problem that never happened. In this episode: - Why the exact behavior that makes you great at mid-level is the behavior that keeps you stuck there - The three categories of senior work that produce zero lines of code but move the entire platform - How to tell leveraged work apart from work that just feels safe to ship - Why "less code" is a symptom and not a goal, and the failure mode of engineers who get that backwards - The one question to ask before your hands hit the keyboard that changes what you volunteer for next sprint This episode is for Databricks data engineers who ship more than anyone on the team and quietly wonder why it isn't landing at review time. Whether you're a mid-level engineer optimizing the wrong line on the chart, or a senior tired of watching your highest-leverage work go uncounted, you'll walk away with language to make prevented work legible and a lens for spending your hours where they actually compound. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

4 habits that quietly turn your Databricks Delta Lake into a swamp

11 min

You built the table right. Well-partitioned, documented, fast enough that the row count came back before you finished reading your own Slack. Six months later it takes four minutes to return that same count, and nobody on your team ever decided to make it that way. There was no meeting, no design doc, no ticket titled "let's make this unqueryable by Q3." A swamp is not a decision. It's the sum of a few dozen reasonable shortcuts that compound into something nobody would have signed off on if you'd proposed it all at once. Which is why telling people to "be more careful" never fixes it. They were already careful. In this episode: - Why your slowest Delta table isn't slow because the data is big, and what it's actually choking on - The storage-bill surprise that's invisible in every query until the invoice lands - How the most generous thing you do for a blocked teammate quietly destroys whether anyone can trust the table - Why nobody can clean up a swamp where nobody knows what's load-bearing, and the cheapest fix in the whole estate - When you should ignore all of this advice, because over-governing a throwaway table is just a different swamp This episode is for Databricks data engineers staring at the one table everyone groans about, the one that actually matters, wondering how it got like this. Whether you run batch, streaming, or DLT, you'll walk away able to name exactly which kind of rot is filling your worst table and the specific senior counter-move that reverses it. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

Liquid Clustering vs Z-Ordering: 4 questions that decide

18 min

You open your Databricks workspace. Two Delta tables. Same size, same downstream BI workload. Table A was partitioned and z-ordered in 2023, runs fine. Table B is greenfield this quarter, liquid clustering by default. Your tech lead asks how aggressive you want to be with migration tickets. Whatever you type back is probably wrong. This is not a feature swap. It's a paradigm shift, and the migration math only makes sense once you can name what actually moved underneath you. Migrate-everything is wrong. Migrate-nothing is wrong. The right answer is per-table, with named criteria. In this episode: - What actually changed when liquid clustering shipped, and the one phrase that simplifies every migration debate you'll have for the next two years - The four-question filter to run table by table, in order, before you commit to a layout decision - The surviving cases where the old paradigm still wins, including the one the evangelism crowd never names - Why liquid clustering and partitioning on a Delta table are mutually exclusive, and the operational property you give up if you migrate the wrong tables - The named audit that turns six hundred legacy tables into three buckets in an afternoon - What kind of senior engineer your tech lead remembers when the promotion conversation happens This episode is for Databricks data engineers staring at a migration backlog, defending a greenfield default, or trying to explain to a platform team why some tables shouldn't be touched. Whether you're a mid-level engineer running your first migration, or a senior engineer setting the standard for the next two years of greenfield Delta tables, you'll walk away with a defended per-table answer and the vocabulary to back it up. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jrlasak Newsletter:...

The compounding curve: why some Databricks engineers' salaries grow 5x faster than others

22 min

Year one. Two new juniors join the same Databricks platform org. Same starting salary, same skills, same desk. Year three, five thousand bucks apart. Year eight, household-car-and-a-half apart. Every year. Forever. Both worked hard. Both stayed technical. Both got positive reviews. Neither did anything wrong. So what happened? Salary in this field isn't one curve. It's two that look identical for the first three years, then peel apart. The choice between them gets made on a handful of small Tuesdays most engineers don't even remember. In this episode: - Why skill is the floor and leverage is the ceiling, and why the better technician is often the worse-paid engineer - The four small Tuesday choices that decide which curve a Databricks data engineer walks up - The difference between expanding what you ship and expanding what you own, and why your manager only fights for one of them - How a junior with twelve hours of writing across four years out-leveraged engineers with twice her tenure - The compass question to run on every career fork before the curve runs you This episode is for Databricks data engineers who suspect their salary trajectory isn't matching their effort, and who want to know what the highest-paid engineers on their team are doing differently. Whether you're a mid-level wondering why peers at the same level make fifty grand more, or a senior trying to understand why your raises keep shrinking, you'll walk away with a four-part audit you can run on your last six months and your next decision. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The 90/9/1 rule of Databricks performance work - how to triage Spark optimization in 60 seconds

17 min

Your team is three weeks into a Databricks performance push. Broadcast hints in PRs. AQE flags toggled like christmas lights. Partition counts re-tuned for the third time. The manager is asking, gently, when the gains are showing up in the bill. The staff DE on the next team finished theirs in two afternoons. Same workloads, bigger drop. They were running a triage you have never been taught. In this episode: - Why most of what your team calls Spark optimization is cosmetic and will never move the bill, no matter how clean the PR - The two named tests senior Databricks engineers run on every workload before they touch a config - Why the same change (caching, salted joins, skew handling) can be cosmetic on one workload and structural on the one next to it - Where the real leverage in a Spark workload actually lives, and why it is almost always visible from outside the code For Databricks data engineers stuck in a performance push that is not converting effort into runtime or bill drops. Whether you are mid-level drowning in config tweaks, or senior watching the bill refuse to move, you will walk away with a one-minute triage you can run on any Spark workload tomorrow morning. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Databricks data engineer in 2026 - the four shifts that just changed your job

18 min

You scroll past the cancelled junior req, the "serverless first" line on your director's planning slide, and the third Lakebase mention from your Databricks rep this quarter. Each one looks like a news item. None of them feel like they're about you. They are. Four structural shifts have already happened in the field, and the words "Databricks data engineer" don't mean what they meant in 2024. Most engineers haven't named them out loud yet, which is why their next promotion packet is going to read a year out of date. In this episode: - Why the junior hiring pipeline didn't pause - it closed, and what that does to mid-level reqs - How serverless quietly turned cost discipline into the new performance tuning, and why your manager wants it in your promo packet - Where Unity Catalog fluency crossed from "nice differentiator" to "you get filtered in the screen without it" - What the data engineering and backend convergence (Lakebase, serving layers, operational reads on the lakehouse) opens up for engineers who move first - The diagnostic question to ask yourself about the skill you're betting your next two years on This episode is for Databricks data engineers planning their 2026, whether you're a senior wondering where your value is moving, a mid-level engineer trying to pick the right thing to learn next, or a junior staring at a hiring market that doesn't look like the one you trained for. You'll walk away with a four-part map of the field and a concrete next move for your career segment. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake #UnityCatalog #Lakebase

9 Behaviors Quietly Killing Your Promotion To Senior Databricks Data Engineer

14 min

Mid-level is a down escalator. It looks like flat ground. You feel productive, your tickets close on Friday, your burndown chart is healthy, and your review says "reliable executor of well-defined work" for the third cycle in a row. That sentence is the official label for "not getting promoted this year" - and most Databricks data engineers never decode it. It isn't a skill gap. It's nine habits that each feel like professionalism, compound against you across review cycles, and separate the engineer up for staff next quarter from the engineer still stuck at mid three years from now. In this episode: - Why the ambiguous ticket nobody wants is the senior-engineer starter pack, and the clean ticket is the trap - How silent 2 a.m. pipeline fixes disappear from your promotion packet, and what to post the next morning instead - The difference between how mid-level and senior Databricks engineers spend a Tuesday afternoon - Why mid-level excellence is senior mediocrity at the same quality bar - The one ceiling-breaker behavior that predicts mid-to-senior promotion more reliably than tenure, tech depth, or luck This episode is for Databricks data engineers who ship solid work, get "solid performer" reviews, and can't name why they're still at mid. Whether you're one cycle in and want to avoid the trap, or three cycles in and wondering what went wrong, you'll walk away with a named taxonomy to audit your last six months against and one concrete move to run this Thursday afternoon. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Dashboard Theater: What Databricks Engineers Build That Nobody Opens

15 min

You check the usage logs on a dashboard you spent two weeks building. Zero views. Not low views. Zero. The stakeholder who requested it hasn't logged in once. Three months later they ask the exact question the dashboard answers, in a meeting, out loud, as if the dashboard doesn't exist. Because for them, it doesn't. In this episode: - Why the most technically impressive Databricks dashboards are often the least used - The single question senior engineers ask that changes every BI request from ticket to strategic decision - How to spot the three tells of dashboard theater before you commit a single hour - Why a thirty-table automated data quality report got replaced by one Slack message - The taxonomy senior engineers use to price their time: decision instrument, political prop, or habit that doesn't exist yet This episode is for Databricks data engineers who build what stakeholders ask for and wonder why some of it vanishes. Whether you're mid-level trying to understand why your best work goes unnoticed, or senior wanting a named framework for intake conversations, you'll walk away with a diagnostic that saves weeks of invisible work. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every Monday, Wednesday, and Friday. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Preparation Gap: What Interviewers Actually Evaluate in Databricks Data Engineers

15 min

She could explain shuffle hash join versus sort merge join. She knew when Adaptive Query Execution kicks in. She had six weeks of notes on Delta Lake, Spark memory, and cluster configs. She walked into the Databricks senior interview feeling genuinely confident. Then the interviewer asked her to walk through a diagnosis, not recite a definition, and everything she studied was aimed at the wrong target. In this episode: - Why senior Databricks interviews test judgment, not knowledge, and what that means for your prep - The exact moment an interviewer recategorizes you from senior candidate to mid-level - How a debugging scenario exposes the preparation gap in under sixty seconds - Three examples of flipping memorization into scenario-based practice with the same material - The self-assessment that tells you whether your study ratio is working against you This episode is for Databricks data engineers who've been studying hard for a senior interview but aren't confident it's the right kind of preparation. Whether you're building your first study plan or revising one that didn't work last time, you'll walk away knowing exactly how to shift your prep toward what interviewers are actually scoring. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki #DataEngineering #Databricks #DataEngineer #CareerGrowth #ApacheSpark #DeltaLake

The Invisible Engineer: Why Your Best Work Gets the Least Recognition

15 min

She kept a terabyte-scale pipeline running for six months without a single incident. Not one page, not one late dashboard. Then review season came and the engineer who spent two weekends fixing an outage he partly caused got the promotion instead. Her name wasn't in a single incident report, because when you prevent problems, there's no report to put your name on. In this episode: - Why the skills Databricks data engineers are hired for produce structurally invisible output - The pattern behind how promotion rubrics reward firefighters and ignore fire preventers - How to keep an incidents-prevented log that turns "nothing broke" into a track record - The communication shift that makes your manager appreciate flawless execution instead of dismissing it as easy - How to frame infrastructure wins in business-outcome language that shows up in reviews This episode is for Databricks data engineers who consistently deliver solid work but feel overlooked at review time. Whether you're mid-level wondering why flashier peers get promoted faster, or senior and tired of your best infrastructure work going unnoticed, you'll walk away with a concrete visibility system you can start this week. --- Helping 18,000+ Databricks data engineers become seniors: interview like seniors, execute like seniors, think like seniors. Follow The Databricks Data Engineer for new episodes every week. LinkedIn: linkedin.com/in/jakublasak Newsletter: dataengineer.wiki Independent educational resource. Not affiliated with or endorsed by Databricks, Inc.

–

0 ratings from members

5
4
3
2
1

Rate this podcast

Log in to rate and review the shows you listen to.

No reviews yet — be the first member to rate "The Databricks Data Engineer".

This podcast, its content and its artwork are not owned by, affiliated with, or endorsed by Castquire.

Keep listening

Discover more podcasts like this.

Browse podcasts See the charts

Up next

  1. Nothing queued. Use + Queue on any episode to line it up.

0:00 0:00

Cookies

We set only what the site needs to sign you in and remember your theme. No advertising, no analytics. Read more.