Articles
Great Expectations Interview Questions: Batches, Validation Results, and Data Quality Failures
Practice Great Expectations questions on batches, suites, validation results, nulls, empty strings, mostly thresholds, and pipeline failures.
Great Expectations interview questions often sound like vocabulary tests: define a Batch, Suite, Validation Definition, and Checkpoint. The harder task is reading what was actually validated. A green range check can coexist with nulls, empty strings, duplicate identifiers, and the wrong batch.
Quick answer: name the batch and business invariant first. Then inspect success, evaluated and missing counts, unexpected count and values, mostly, and result format. One expectation proves only its own rule for that batch. In our GX Core 1.23.0 lab, an amount range passed at mostly=0.60 even though two of five evaluated amounts were invalid and one of six rows was null.
This guide separates official GX Core behavior, our version-pinned experiment, and editorial interview guidance.
Which batch are you actually validating?
Interview question: What is a Batch in Great Expectations?
A Batch is the concrete set of records supplied for validation. The path to it matters. A Data Source connects GX to data; a Data Asset groups related data; a Batch Definition describes how to obtain a batch; runtime batch parameters select or supply the actual data.
Official GX Core 1.23.0 behavior: the parameters accepted by a Validation Definition are determined by its Batch Definition. The official dataframe example passes {"dataframe": df}; date-partitioned definitions may accept parameters such as year, month, and day. Run a Validation Definition.
A strong answer does not say “the table passed.” It says something like: “We validated the six-row Pandas dataframe passed as dataframe to the current_orders whole-dataframe definition, using suite version X.” In a warehouse, identify catalog, schema, table or query, partition, time window, and watermark.
How can the wrong batch produce a believable result?
A daily definition can receive yesterday's partition parameter. A dataframe asset can receive a filtered dataframe. A query asset can omit rejected records upstream. The expectations may execute perfectly against the wrong population.
Before changing a rule, print or store batch identifiers, row count, selection parameters, maximum event time, and source freshness. Compare them with the pipeline run. A successful result over zero rows or a stale partition is not evidence that today's orders are healthy.
How do Suites, Validation Definitions, and Checkpoints fit together?
Official object relationship: an Expectation Suite contains expectations. A Validation Definition is a fixed reference connecting a Batch Definition to a Suite. Running it validates a selected Batch and returns a Validation Result. A Checkpoint can run multiple Validation Definitions and execute Actions based on their results. Create a Validation Definition.
| Object | Question it answers | Common mistake |
|---|---|---|
| Data Source | How can GX access data? | Treating credentials as part of the business rule |
| Data Asset | Which related data is exposed? | Assuming the asset is one immutable batch |
| Batch Definition | How is a batch selected? | Forgetting runtime parameters |
| Expectation Suite | Which invariants should hold? | Combining unrelated ownership into one pass/fail |
| Validation Definition | Which definition and suite run together? | Describing it as the result itself |
| Validation Result | What happened for this run? | Reading only top-level success |
| Checkpoint | What validations and actions form a workflow? | Treating notification as remediation |
The distinction is useful in an interview failure: first determine whether data selection, rule configuration, execution, or reaction is wrong. A Slack alert failure does not change the expectation result. A correct action cannot repair a validation that checked yesterday's batch.
Which checks catch nulls, empty strings, and invalid values?
Our original six-row batch contains:
order_id: 1, 2, 2, 4, 5, 6
email: valid, NULL, "", valid, valid, valid
amount: 50, 1200, -5, NULL, 200, 300
We ran five Expectations using GX Core 1.23.0, an ephemeral context, Pandas Data Source, whole-dataframe Batch Definition, and COMPLETE result format.
| Expectation | Observed result | Meaning |
|---|---|---|
| email not null | fail; 1 unexpected | Finds NULL, while "" is still a non-null string |
email not in { "" } | fail; 1 missing, 1 unexpected | Ignores the null for this map check and finds the empty string |
| order ID unique | fail; 2 unexpected rows | Both rows containing duplicated ID 2 are unexpected |
| amount between 0 and 1000, mostly 0.60 | pass; 1 missing, 2 unexpected | Three of five evaluated values pass: exactly 60% |
| same range, mostly 0.61 | fail; same counts | The measured 60% is below the 61% threshold |
Why does a not-null check miss empty strings?
Official missingness guidance: GX treats null checks as rules about absent values, while defaulted values such as zero or empty strings can carry different business meaning and need separate expectations. Manage missing data with GX.
Therefore define the business rule precisely. If a trimmed email must contain text, check not-null plus a regex, length, or set exclusion after normalizing whitespace. Decide how strings containing only spaces behave. Do not assume one backend parses empty CSV fields the same way as another.
What does mostly divide by?
For the amount range in our Pandas run, GX reported element_count=6, missing_count=1, and unexpected_count=2. The unexpected percentage was 40%, which is 2 ÷ 5 evaluated non-null values. Three of five pass, so 60% satisfies mostly=0.60 and fails 0.61.
This is local, versioned evidence. Verify expectation semantics for your GX version and execution engine, especially type coercion, null representation, and SQL backend behavior. In the interview, calculate the denominator aloud instead of saying “mostly allows some failures.”
How should you read a passing or failing Validation Result?
Official behavior: calling run() returns a Validation Result and saves it to the Data Context. The default output includes each expectation, success status, and summarized diagnostic information. Result Format controls the detail returned. Run a Validation Definition.
Read in this order:
- Confirm run identity and batch parameters.
- Read overall success, then every failed expectation.
- Compare element, missing, and unexpected counts.
- Calculate evaluated denominator and passing proportion.
- Inspect unexpected examples or rows at a safe detail level.
- Compare the rule and threshold with the business contract.
COMPLETE results can help local debugging but may expose sensitive row values or become expensive. Use SUMMARY or another appropriate format in routine pipelines, and retrieve detailed unexpected rows only under controlled access. Result verbosity changes diagnostics, not which data was selected or whether the rule is correct.
Does overall success false mean every rule failed?
No. Our overall result is false because four of five expectations failed; the 0.60 range rule passed. Conversely, overall true means all configured expectations met their thresholds. It does not prove that missing rules, cross-table relationships, freshness, reconciliation, or downstream consumption are correct.
Name the claim narrowly: “For batch B, every expectation in suite S satisfied its configured threshold.” Then state which high-risk invariant still lacks coverage.
How do you investigate a result that changed overnight?
Compare like with like before blaming the source. Check GX version, suite identity, expectation configuration, Data Source and execution engine, batch parameters, row count, schema, and Result Format. A change from Pandas to a SQL engine can alter parsing or type behavior; a new upstream normalization can turn nulls into empty strings; a changed partition can alter both the numerator and denominator.
Preserve the previous and current counts rather than only the boolean. If unexpected count rose from 2 of 5 evaluated rows to 20 of 5,000, the absolute count increased while the rate improved. The appropriate action depends on whether each invalid row creates direct harm and whether volume itself is expected. Segment by producer, region, schema version, or event time to find where the change entered.
When the expectation configuration changed, treat that as a policy deployment. Review it, version it, and explain whether the new result reflects better data or a looser rule. A threshold change that turns red to green without fixing records is not a data remediation. It may be a valid revised contract, but it needs an owner and evidence.
What should happen when a data quality check fails?
The action depends on impact and confidence. A duplicate order identifier in a financial ledger may block publication. A small optional-description null increase may warn an owner while processing continues. A volume anomaly may quarantine the partition until freshness and upstream status are checked.
Use a policy table:
| Failure class | Immediate action | Evidence to preserve |
|---|---|---|
| Identity or ledger integrity | Block or quarantine | Batch ID, duplicate keys, source run, owner |
| Critical null or schema break | Stop dependent publication | Unexpected rows, schema, producer version |
| Distribution drift | Warn or hold based on impact | Baseline, sample size, segments, freshness |
| Threshold near boundary | Review trend and denominator | Counts, mostly value, historical rate |
| Validator/infrastructure error | Mark validation unknown | Stack, engine, credentials path, retry status |
Do not convert execution error into data failure or success. Distinguish “the data violated a rule” from “the rule could not be evaluated.” Retries may be appropriate for transient infrastructure failure, but repeating a deterministic quality violation wastes time.
How would you choose mostly?
Derive tolerance from the consumer's contract, historical baseline, error cost, volume, and remediation path. Record absolute counts beside percentages: 0.1% can mean one row or one million. Add minimum-volume and freshness checks so a tiny or stale batch cannot pass a generous proportion.
Avoid universal thresholds. The correct value for optional profile attributes is unrelated to the correct value for order identifiers. Revisit tolerances when product behavior, source systems, or consumers change.
Great Expectations interview questions with concise answers
What is the difference between a Batch Definition and Batch parameters?
The definition describes how batches are formed; parameters select or provide the concrete batch for a run. Accepted parameter keys depend on the definition.
Can one range expectation prove a numeric column is complete?
No. Map expectations may exclude missing values from evaluation. Add explicit missingness rules and inspect missing counts.
Why request a richer Result Format?
To retrieve enough diagnostics for investigation, such as unexpected values or rows. Balance that need against cost and sensitive-data exposure.
What should a Checkpoint own?
It orchestrates Validation Definitions and actions. Business rules live in suites; batch selection lives in definitions and parameters; remediation policy should remain explicit.
How do you debug a surprising pass?
Verify batch identity and size, expectation configuration, denominator, mostly threshold, missing behavior, and result detail before adding another check.