Day 2 at VATICO: When the Details Are the Work

There is a particular kind of learning that only happens when you are forced to slow down and study the fundamentals. Today was that kind of day — spent reviewing and reflecting on the data analytics training slides. It was not packed with grand revelations, but full of small, precise details that revealed the discipline that serious data work quietly demands.

Through these slides, I touched topics ranging from performance expectations for data analysts at Vatico, to defensive SQL edge cases (like division-by-zero handling with NULLIF), data modelling pipelines (using dbt’s ref() and source() functions), and dashboard design philosophy (a dashboard is not a dump of data — it is an insight to gather). On the surface, these topics feel unrelated. But running through all of them was the same idea: the visible output is never the whole story. What matters is what happens underneath.

What Excellence Actually Looks Like Here

The first part of the day gave me the clearest picture yet of what Vatico expects from its data analysts. It is not an expectation for any intern to hit IC3 performance; rather, these guidelines and key elements are presented as benchmarks for us to strive toward and improve every day. To provide a clear, grounded view of these performance standards, both IC2 baseline expectations and IC3 aspirations are outlined below.

IC2 Expectations: Intermediate Baseline

Accuracy

0–1 accuracy issues/mo; 100% proactive error and gap communication; statistical significance applied.

Timeliness

90% delivered on agreed timelines; ≤ 10% projects exceeding 14 working days; proactive ETA delay communication.

Communication

Meeting notes/Trello updates after discussions; confirmed stakeholder understanding.

Dashboard Quality

100% accurate metrics, no duplicate data, clear instructions on what each dashboard is for and who it serves.

Reducing Redundancy

Every data request starts with an approved skeleton before any pulling begins; max 1–2 logic redos; queries < 2 hours.

IC3 Expectations: The Autonomy Standard

The core of IC3 is not extra process, but autonomy. Rather than over-expounding, the target rests on four essential pillars:

Independent Execution

Scoping and completing tasks end-to-end without requiring hand-holding.

Problem Identification

Uncovering key business problems independently before being assigned.

Task Prioritization

Managing competing requests and prioritizing tasks independently.

Proactive Leadership

Proactively engaging stakeholders and seeking alignment to guide decisions.

SQL That Defends Itself

Another key lesson of the day came from a slide on common SQL errors — specifically, division by zero. I have encountered the error before, but I had never thought carefully about the idiomatic solution until today.

NULLIF(expr, 0) returns NULL when the expression equals zero — and NULL instead of zero means the division never crashes. The query protects itself by refusing to divide.

Paired with this was a subtler trick: multiplying a value by 1.00 before dividing. In SQL, integer division truncates — 1 / 2 yields 0, not 0.5. By forcing the calculation into decimal space first, you preserve precision that would otherwise silently vanish.

-- Safe division with decimal precision
1.00 * quantity_decrease / NULLIF(sum_of_drop, 0) * 100

-- Without NULLIF: crashes when sum_of_drop is 0
-- Without 1.00 *: integer truncation silently loses decimal places

What I appreciated about this is that both patterns are defensive. They do not change what the query is trying to compute — they simply ensure it computes it honestly, even in edge cases. Good SQL, I am beginning to understand, anticipates failure.

dbt and the Discipline of ref() vs. source()

Following that, we covered how dbt references tables using ref() and source() instead of hardcoding database queries.

ref() is used when referencing models within your dbt project across schemas (examples of schemas are staging and report, with examples of databases being bb_sg and va_vn). source() is used when dbt needs to reference an external table from another raw schema — where the source_name acts as the schema name during test and query execution.

For instance, in a dbt project:

{{ ref('stg_orders') }}: Refers to another model inside the same project. In Vatico’s workflow, when building a table in the report schema, using ref() allows dbt to locate and connect to another table within the project/schema (such as another report table).
{{ source('raw_sales', 'orders') }}: Directs dbt to pull raw data from an external schema/project. Here, raw_sales acts as the schema name when tests and queries run against the warehouse.

The core rule is clear: use ref() for project models (like staging and report tables) so dbt manages lineage automatically, and use source() whenever pointing to external tables in another schema.

A Dashboard Is Not a Dump of Data

A dashboard is an insight to gather, not a data dump. Every design choice either clarifies decision-making or obscures it. Below are visual examples of how intentional design transforms raw data into instant business clarity:

Intentional Titles

Replacing generic headers like “Sales Data Table” with “Monthly Spend of AWS” instantly communicates the core question the data answers.

Color-Coded Indicators

Using green / red status highlights on variance columns to surface performance at a glance, rather than forcing stakeholders to scan raw numbers.

What Can Be Improved

English translations for CRM and payment request flows — The onboarding materials reference these processes, but the guidance for how stock movements should be recorded in CRM remains fully in Vietnamese. For a non-native speaker, or for any new intern trying to self-onboard, this creates unnecessary friction at a stage where clarity matters most.
A consolidated day-one link page — The materials needed on the first day are spread across several documents. A single curated page — access checklist, tool links, key contacts — would reduce the time an intern spends hunting and let them focus on learning faster.
Clearer task ordering for dependent work — Some onboarding tasks need input or access from other team members. It is not always obvious which tasks are waiting on someone else. Highlighting these dependent tasks early, and suggesting interns start them first, helps new joiners organize their work much better from day one.

None of these are complaints — they are observations from the vantage point of someone new enough to notice the gaps that familiarity tends to paper over. The foundation is strong. These are suggestions for the last mile.

Edit (as of 21 Jul 2026): All of these onboarding resources and improvements should already be implemented and available to new interns. If you do not have access to them yet, please ask your supervisor first.

Training Data