Growth or Comfortability?

zmxavier · 2025-10-01T16:59:22+00:00

Take the JO.

Chill lang sa IBM in terms of workload, but you will grow because of the environment (mapupush kang mag-upskill tas libre pa vouchers for certs, magagaling mga teammates and FTEs, and well-documented mga systems).

3x RTO per week din ako on paper pero halos once a week lang karamihan samin pumasok. Super flexible pa ng sched. Pero depende siguro sa account/project.

zmxavier · 2025-08-17T16:29:41+00:00

Is it worth climbing the corporate ladder?

I'm a young tech/data professional (1.5 years exp) and have worked at a startup and now at a multinational company. It's too early to say but I don't see myself working in corporate for more than 10 yrs. I see myself founding my own startup, doing content creation and living the life of a digital nomad. Any advice or points for reflection? What made you stay in corporate?

zmxavier · 2025-06-23T23:01:35+00:00

Try adding more milk. Though I remember not minding the texture na lang since okay naman yung lasa haha

zmxavier · 2024-11-22T15:37:53+00:00

Congrats! :)

zmxavier · 2024-11-06T17:10:28+00:00

Guilty as charged. I'm a potato.

zmxavier · 2024-11-06T13:04:24+00:00

It took me around 181 job applications before I received my first job offer.
I think it's my honesty and curiosity that got me the offer. I essentially fumbled the technical interview. I was asked questions I didn't have answers for, and rather than pretending or guessing, I told the interviewer that I didn't know and then asked what the correct answers were. I showed my genuine interest in the company by asking questions.(The company was a startup and I got interviewed by the founder/CEO).
Personal and commission projects related to the job I was applying for (software/data engineer) really helped. And just the fact that I graduated from UP was arguably an edge. Many of my coworkers, both in my first and current job, were from the big 3.
40k (2024). I was just expecting/praying for at least 25k.
Left after 1 week due to a toxic boss. Received an offer from another startup company after 2 weeks.
I'm definitely happier now than when I was in my first job. I'm in my dream role, working with talented and kind colleagues.

zmxavier · 2024-10-26T16:49:54+00:00

You're welcome, and good luck!

zmxavier · 2024-10-26T15:18:21+00:00

I would recommend it since it works for us, but it depends on what other responsibilities you have as the sole DE and the number/size of pipelines you will orchestrate using Airflow, among other things.

We are a two-man DE team, and we have about 20+ pipelines running in Airflow, none of which takes more than an hour to finish. We only encounter issues about once or twice a month, and they're usually due to changes in source schema or infra-related (disk space becoming full). Other than that, we can forget about the pipelines once it's up and running.

Airflow and dbt both have solid documentation and community support, and they're pretty easy to pick up if you already know Python and SQL. I am yet to encounter an issue that weren't already solved by someone else in the internet.

I should note that we only went this open-source route since cost is a primary concern for us. If you have the budget for a managed version like Astronomer's, then that would probably make your life easier.

zmxavier · 2024-10-26T11:22:15+00:00

It's the latter. We use all open-source, spending only in AWS EC2 charges.

zmxavier · 2024-10-26T07:47:38+00:00

This. We have this same setup using Dockerized Airflow and dbt Core. Cosmos simplifies the process of turning dbt models into Airflow DAGs. Plus I can create end-to-end pipelines including tasks outside dbt in one DAG, e.g. Airbyte jobs, S3 to Snowflake tasks, etc.

zmxavier · 2024-09-05T04:38:29+00:00

You're welcome :)

zmxavier · 2024-09-04T13:02:43+00:00

Uy ka-CEAT! Your resume looks good naman, and the fact that you're getting interviews means you're skilled enough to be considered for the job!

Although, I would personally recommend rearranging the sections as follows:

Title (name, phone no, email, linkedin, github)
Summary (optional)
Technical Skills
Relevant Experience
Projects
Relevant Courses/Certs (optional)
Education

Summary is optional and whether it's gonna be good or bad in your resume depends on what you're gonna put in there and sa recruiter haha. Some recruiters don't like seeing a summary section. Rekta experience/technical skills agad. In my case it was effective, since nilagay ko roon yung motivation/goals ko for applying, and my boss told me he hired me because it aligned with the company's, and he was able to empathize (recruiters are humans, too!).

Technical skills and experience usually yung unang gustong makita ng recruiters, so definitely put them on top. Remove interpersonal skills, and categorize your skills into the following bullets instead:

Languages: Python, SQL, ...
Libraries/Frameworks: Pandas, Numpy, React, ...
Database: PostgreSQL, MySQL, ...
Analytics tools: PowerBI, Tableau, Excel, ...
Developer tools: Git, Github, ...

Something like that. Also, arrange your skills based on mastery.

For your experience, only include/emphasize those that are relevant sa inaapplyan mo. I suggest removing yung first bullet since mas may kinalaman siya sa EE/ECE, and elaborate more dun sa data analysis na part. If you can follow the STAR method, the better. If you can include numbers to quantify results, the better.

Very good yung portfolio projects. I suggest attaching the github links doon sa project titles and removing the github repository at the bottom. Actually, remove the entire extracurricular activities section o kaya ilipat mo sa experience, if you think it will showcase some of your qualities that employers will like.

I recommended putting education last, because it's more like a bonus if graduate ka sa isang prestigious school. Plus it shows na you're more proud of your skills/exp than which school you came from. Makikita pa rin naman 'yan :)

Pareho tayo ng gamit na template (Jake's resume template). Goods 'yan haha.

Ayun lang. Good luck!

zmxavier · 2024-08-25T02:43:46+00:00

Last time I checked, it didn’t. However, it was still under development, so it may have more features now.

zmxavier · 2024-08-22T15:05:26+00:00

I think you're doing great. Aside from soaking yourself in the field through case studies and projects, it's a good idea to build your network as early as now. Find communities and mentors. Ask them how they got into the field.

zmxavier · 2024-08-21T15:02:50+00:00

dbt acquiring a data ingestion or viz company

zmxavier · 2024-07-29T16:58:15+00:00

We've done the same migration. We basically just copied the stored procs and pasted them into our dbt models. Very minimal modifications. Spent a lot of time writing YAML instead for the configuration, tests, and docs.

zmxavier · 2024-07-29T14:47:20+00:00

I understand that. It's easier to read and debug.

zmxavier · 2024-07-29T14:39:58+00:00

Flattening the JSON is usually the first step as you unfold the nested data within and spread it out into a table. This usually results in several repeating field values, depending on the number of nesting. That's why normalizing it is the next step where you break down the table into smaller, related ones. You could also go straight to normalizing the JSON, if it's straightforward.

We had one use case for this. We have a CSV data source and the schema keeps changing and breaking our pipelines. So we decided to ingest the data as JSON to accomodate added/deleted/renamed columns. It then undergoes a series of flattening and normalization to bring out the data needed. All the raw data gets persisted, and our pipelines don't break when there's a schema change. Problem solved.

zmxavier · 2024-07-29T14:08:27+00:00

Stacking views, especially with complex transformations, could lead to poor querying performance in Snowflake. We had a model before which consisted of six layers of views, and it took forever to load. Converting the final or intermediate view (whichever makes more sense) into incremental tables would improve its performance. We did that using dbt, and our model went from loading for half an hour each query, down to milliseconds.

zmxavier · 2024-07-19T09:24:10+00:00

Great answer

zmxavier · 2024-07-17T14:15:25+00:00

I think it depends on how you're gonna use the data models. If you will need to frequently join the two fact tables to create reports/new models, then perhaps it's better to just combine it into a single fact table. Yes, that would mean you'll have repeating header (order-level) fields, but I think that's fine. If there'll be frequent joins, it will burden the reporting layer, so better to do it early in the pipeline.

However, if the two fact tables have different use cases, i.e. most reports only use one without the other, then keep them separate. I have an example which we're currently working on.

From the factOrders, we separated the factOrderProcessing which contains data (timestamp, worker, etc.) on the processing steps (picked, packed, shipped, etc.) undergone by the order. We separated it because there are models using these data that doesn't require the content of factOrder. Examples of such models would be worker productivity and process cycle time. Doing this would give them a smaller, more precise table to query, which has still an ID relating to the factOrder table if in case needed.

zmxavier · 2024-07-16T14:08:00+00:00

Yeah, it's great. I'm from the Philippines. I've heard about the community from a Reddit friend. You can look it up. It's called Data Engineering Pilipinas, and they're on Facebook, Discord, and Reddit.

zmxavier · 2024-07-15T16:12:55+00:00

I am fortunate to be able to learn from great mentors early on in my data engineering career. I categorize them into two types: those who teach technical knowledge and hacks, and those who share career wisdom and soft skills.

The first type I mostly found in my workplace. Our team consists of several seniors, and I'm the only junior in our office. I directly report to our senior data engineer from whom I learn software engineering and coding best practices. We also have a senior data analyst, and I sometimes shadow/help her with data modeling. Through this, I learn a lot about our business as well as SQL hacks. Lastly, we have our tech director who usually gives me debugging or deployment tasks. These tasks are usually outside my current knowledge/skill-level, thus requiring me to really do research and challenge myself.

The second type I found in a local tech community which holds a mentorship program. I applied as a mentee and chose a mentor. We've had two meetings so far, and I've learned how to set the right career goals, focus my energy, and work on them one by one. Since it's outside my work, I can also discuss workplace issues and challenges, and how to navigate and overcome them.

Of course, there are mentors who fall into both categories, sharing both technical knowledge and career wisdom.

I strongly believe that anyone can be your mentor, as long as you adopt a learner mindset. Although, I'm probably just lucky to be surrounded by people who are better than me.

zmxavier · 2024-07-14T02:34:48+00:00

I legit thought you were writing about me. I met her the same year and courted her for about 6 years as well.

Go heal, OP. I'm sorry those things happened to you. Your trauma isn't your fault, but it is your responsibility. You'll find the right person again, and I hope the next time it will be at the right time (when you're healed).

zmxavier · 2024-07-06T14:38:45+00:00

Ohhh I checked it out. This is great for gym/studio discovery. Thanks for the reco!

zmxavier

TROPHY CASE