Giving and Receiving Feedback Questions

Situation: In a recent review I saw a very dense SQL query in a pipeline DAG written by a senior engineer. It used multiple nested subqueries and cross-joined large tables — fine on small dev data but risky at scale.

Task: My goal was to surface the performance risk, suggest safer alternatives, and keep a collaborative relationship with the author.

Action:

• In the PR comment I started with appreciation: “Nice work putting the business logic into one readable query — great clarity.” Then I asked a clarifying question rather than accused: “Have we run this on a production-sized dataset? I’m worried the current plan might trigger full table scans / shuffles.”
• I pointed to the risk concretely and non-judgmentally: “Given our table sizes (100M+ rows) this pattern has caused long-running Spark shuffles before.”
• I proposed options with trade-offs: “Options we could try — add selective predicates or indexes, refactor into staged incremental joins, pre-aggregate with a materialized view, or push heavy joins into a dedicated analytics cluster. I can run a quick explain/profile and benchmark any of these.”
• I offered help and next steps: “If you’re open, I can run EXPLAIN/EXPLAIN ANALYZE on staging and pair with you to test a refactor. I’ll also draft a small benchmark script.”

Result: The author appreciated the constructive framing. We paired for 2 hours, ran an EXPLAIN, and refactored to a two-stage aggregation and a partitioned materialized table; execution time dropped ~8x and we avoided adding ad-hoc indexes. The relationship stayed collaborative — framing with respect, asking questions, and offering help turned a potential conflict into a learning opportunity.

Situation: At my previous company, a critical nightly ETL pipeline owned by a senior engineer was intermittently failing and producing corrupted customer segment tables used by analytics and billing. The issue had been flagged by downstream teams for weeks and caused inaccurate reports and at least one billing discrepancy.

Task: As the data engineer responsible for platform reliability, I needed to give difficult feedback to the pipeline owner, restore data quality, and put in place safeguards so this wouldn't reoccur.

Action:

• I prepared evidence first: a timeline of failures, error logs, sample corrupted rows, and business impact (2% of daily reports affected; one customer billed incorrectly by $1.2k).
• I requested a private, scheduled meeting and framed it as collaborative: “I want to walk through what I found and work with you on remediation.”
• I led with facts and impact, avoided blame, and acknowledged constraints (the pipeline had been rushed for a product launch).
• I proposed concrete, low-friction fixes: add schema validation, promote atomic writes, add end-to-end tests in CI, and create an alert for row-count/column-CRC drift.
• Together we created a prioritized remediation plan with clear owners, deadlines, and rollback strategies. I volunteered to implement the monitoring and pair on the schema validation.
• To maintain trust I solicited their input, incorporated their expertise about legacy components, and kept communication transparent—daily check-ins until stable and shared progress with stakeholders.

Result: Within two weeks the pipeline stopped producing corrupted data; alerts caught a related upstream schema change the next day. Downstream report accuracy returned to baseline, and billing errors dropped to zero. The senior engineer appreciated the collaborative approach; we later formalized a pre-deploy checklist and added pipeline health dashboards, reducing similar incidents by 70% over the next quarter.

This taught me that difficult feedback works best when grounded in data, offered as collaboration, and followed by concrete, shared actions.