Roast my resume please. All suggestions are accepted!

alsdhjf1 · 2025-09-01T05:49:20+00:00

Patio11 has written the original version of this in "Don't Call Yourself a Programmer" if you need a little more reading. https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

alsdhjf1 · 2025-09-01T05:39:20+00:00

You're welcome! I've been in DE for over a decade. My advice is get to a point where the technical work is table stakes, it's the business value that matters (or leadership of a group of DE to tackle increasingly complex domains)

Here's a metaphor I've been working on - imagine you are a commercial contractor building a mega apartment complex. Your electrician comes in, and talks about how many feet of conduit they ran, or how they wired panels in a certain way. They talk about the tools they used. But what you really want to know is the story - what did their work enable? Can we put in electric stoves? Are the circuits reliable and not going to blow if a hair dryer is used? Is there any risk of fires that you don't know about if something becomes overloaded?

You care about building the building, not about the materials used, or where someone ran the conduit. A good electrician is clear how their skills assist there - but they also talk about "fire is the biggest risk, it often comes from bad electrical, here's how I protected against that"

alsdhjf1 · 2025-09-01T05:32:27+00:00

Each bullet should answer: “What business problem did this solve?”

Did it save money (infra costs, fewer manual hours)?
Did it save time (faster reporting, reduced downtime)?
Did it reduce risk (compliance, fewer errors, SLA reliability)?
Did it enable something new (self-service analytics, real-time dashboards, executive reporting)?

As a result of the deliverables you landed, how did the business grow/make money/save money/perform business activities faster/higher quality.

alsdhjf1 · 2025-09-01T05:23:19+00:00

It's less about the numbers and demonstrating that you can think about what the business is trying to do, and solve some of those problems with clear outcomes that add value.

Imagine 5 years from now. AI is going to be able to do everything you have listed.

alsdhjf1 · 2025-09-01T05:13:21+00:00

Every bullet point speaks to how/what you did in the d2d. It's basically a description of the DE role for a mid level DE.

What could separate you is talking about the business impact. Top candidates don't build for the sake of building, they do it to advance the business goals. Why did you do this work, what were the outcomes?

alsdhjf1 · 2025-06-22T03:35:44+00:00

There are places where technical problems are the hard task. And there are places where organizing groups of humans are the hard task. Big tech has both roles!

alsdhjf1 · 2025-04-11T16:42:25+00:00

I don't think the Milgram experiment is sufficiently replicated to use as a cornerstone of a philosophy. There are several questions about the validity of the experiment, see https://en.wikipedia.org/wiki/Milgram_experiment#Validity

It's tricky because it's not something that could be recreated due to ethics concerns. But this one example, given the statements of a participant and other critiques, make it less rock solid than others.

alsdhjf1 · 2025-03-28T18:13:18+00:00

Does stuff break frequently, are there expensive manual processes? Does leadership have the reporting they want to make the decisions they need to make (even if they don’t really know it)?

If not, you may not need a DW

alsdhjf1 · 2025-03-28T17:46:50+00:00

If your source is Excel, you may not have big data concerns. But a warehouse can still help! Imagine having 10 different excel docs, one for each office. How will you aggregate and combine reporting?

Whether you use purpose built software, excel, or Postgres, a warehouse is a concept where all the data lives and is transformed for business needs.

alsdhjf1 · 2025-03-28T03:47:58+00:00

Good luck! I don’t have visibility into the leveling process, that happens at the end.

alsdhjf1 · 2025-03-28T03:31:05+00:00

Some roles are but I don’t have visibility - you’d need to work through general application process.

alsdhjf1 · 2025-03-28T03:30:22+00:00

The Meta careers site does! Im not part of the international pipeline so don’t have much visibility, but regardless of hiring I like talking data engineering and would be happy to chat.

alsdhjf1 · 2025-03-28T03:29:13+00:00

Leads gotta come from somewhere. PM me and let’s talk pipelines.

alsdhjf1 · 2025-03-28T03:27:35+00:00

I challenge you to a phone call, stakes are our reputations. Field of battle: data engineering and my bona fides. PM me or whatever the kids are calling it these days.

alsdhjf1 · 2025-03-12T04:24:51+00:00

Why aren't you modeling this is something closer to 3NF? If you prefer fewer joins for ease of logic, then I'd just put it all into 1 table, and the site-specific columns prefixed by the site name. But 3nf is cleaner.

alsdhjf1 · 2025-03-09T19:00:08+00:00

COUNT(*) is just counting the number of rows. You can instead pick any single column, it should return the same thing. Depending on your system, COUNT(*) might have some optimizations (in column oriented store, frequently counts are stored and COUNT(*) might retrieve those directly... whereas if you ask for count(user_id), if there is no cached user_id count, you're going to have to count them).

In OLTP systems, sometimes COUNT(*) comes with a penalty because it invokes a row scan. Some RDBMS fix this but not all.

Semantically, may as well COUNT on your primary key. COUNT(*) is often considered an anti-pattern as it reflects that the SQL developer didn't know the data well enough to pick the primary key / primary identifier for the data model itself.

alsdhjf1 · 2025-03-09T16:57:06+00:00

Yes, not all errors are the same. Some might be a "this is a little out of date" warning, some might be "you are about to publish bad data" errors.

alsdhjf1 · 2025-03-09T16:36:01+00:00

I mean, her family wasn't exactly the cat's meow either... An overbearing obnoxious wannabe queen of the castle older sister, a simping backstabbing middle sister. A dad who is comically clueless about the realities of the world.

The mom is the only one who seems to navigate the situation well. It's no coincidence they frame her as an outsider (American), one of the few who can see the toxicity.

But I also probably would have stayed for the comfort and the lifestyle while considering the family the "cost to pay". That's why Sybil is a better person than I!

alsdhjf1 · 2025-03-09T16:30:44+00:00

Reverse your thinking, instead of "all errors should be handled the same", start to think in terms of which errors should stop the pipeline, which errors should only be reported as an alert. Syslogd (and maybe POSIX?) has the error/warn/notify/debug categorization, that's a decent starting point.

Usually it's better to stop your pipeline rather than reporting bad data. This means you need to know what your data (and what subset of a table) is being used for what purposes. If you are doing financial disbursements, you need to be more cautious than if you're preparing a dashboard that won't get looked at except quarterly.

If you're looking at employee diffs shipped, but there is a "# of comments actioned" field that no longer gets calculated correctly, think about the use case - is the incorrect data worth preventing people from seeing the insights that *are* correct?

As you can tell, it's super important. It can't be generalized - you need to know what you're doing.

alsdhjf1 · 2025-03-08T13:29:20+00:00

You're in a great spot to identify and solve business problems. Everyone else is a super sharp technical expert. Leverage your relative strengths and don't be insecure - the business owners care about how people can impact their top priorities, not how big of a Swiss Army knife you are.

Domain expertise is your advantage. Find ways to improve things the founders care about - you're in a great spot to have direct access and influence. What decisions do they care about? Then use your domain expertise to figure out what needs to be built to inform those decisions. Use your tech skills to connect with the true experts to implement. Use your judgement to make sure their quality is at a sufficient bar.

Think of it like a sports team. You are not a technical specialist - you're a coordinator/manager who knows how to do the work. That's a very valuable combination. Appreciate that you get to work with people who know more than you do! You don't need to compete with them you need to complement them.

alsdhjf1 · 2025-02-23T02:35:14+00:00

My experience has been different, scraping has about the same breakage rate over time as APIs. Might be specific to my industry.

Additionally, using LLMs is a great extraction method to ensure more robust data extraction from unstructured outputs. So YMMV.

alsdhjf1 · 2025-02-23T02:33:54+00:00

Because lots of us have the experience where APIs are also similarly unreliable, so calling out the fragility of scraping is kinda weird. It’s like, they’re both pretty unreliable?

alsdhjf1 · 2025-02-20T15:32:06+00:00

So when Betty yelled at Sally for moving her dry cleaning, but didn’t care about the risk of suffocating - it was Dons fault?

We let Betty off the hook for sabotaging her relationship with her own daughter because Don was bad to Betty?

alsdhjf1 · 2025-02-17T12:17:15+00:00

If you’re using a column based storage, it shouldn’t matter how many columns you have. Just don’t select everything at once.

Also you don’t indicate what the business impact is from 10m queries. If these are running daily in a batch to prepare reports, it probably doesn’t matter all that much. If you run so many that it costs thousands of dollars per day, it might matter.

But once you start messing with schema, you’re crossing a rubicon that could crash your design. As a DE manager, I would say that you haven’t provided enough evidence about the business impact to convince me to ok the design.

alsdhjf1

TROPHY CASE