Giving and Receiving Feedback Questions

Situation: In a recent review I saw a colleague’s report query that used many deeply nested CTEs, ran slowly for large date ranges, and was hard for others to follow. The slow query delayed a recurring dashboard refresh and increased load on the warehouse.

Task: My goal was to give constructive feedback that improved performance, readability, and maintainability while keeping the teammate supported and respected.

Action:

• I started with positive context: praised correctness and clear business intent in the comments.
• Performance-first suggestions (concrete):
  • Run and share the EXPLAIN/PROFILE output so we know hot spots; point to expensive steps (hash joins, wide sorts).
  • Push selective predicates (WHERE date ranges, customer filters) as early as possible to reduce row counts entering joins.
  • Replace chained CTEs that re-scan the same base with temporary/materialized intermediate tables or persistent staging tables when the data is reused across steps.
  • Consider rewriting multiple CTEs into window functions or single-pass aggregations to avoid repeated scans.
  • Remove SELECT *; project only needed columns to reduce I/O.
  • Add appropriate indexes/cluster keys or ensure distribution/keying aligns with join columns (for distributed warehouses).
  • Limit use of DISTINCT and ORDER BY; move sorting to final step or use TOP/N.
• Readability & maintainability:
  • Flatten CTE depth: name CTEs clearly, keep each CTE to a single responsibility, and add brief comments describing purpose and cardinality expectations.
  • Break the logic into well-named views or modular SQL files if reused by other reports.
  • Add lightweight unit tests or assertion queries (row counts, key uniqueness) and example input/output for critical transformations.
• Communication & follow-up support:
  • Offered to pair-program for 30–60 minutes to run EXPLAIN together and prototype an alternative.
  • Provided a small benchmark script to compare runtimes and explain plans between original and refactored queries.
  • Suggested creating a short doc or README next to the SQL explaining assumptions, expected data size, and refresh cadence.
  • Suggested opening a ticket to track moving reusable steps into a materialized table if refactor shows consistent benefit.

Result: By pairing and implementing two targeted changes (pushing filters earlier and materializing an intermediate result), we reduced runtime from ~6 minutes to ~45 seconds and made the final query easier for others to audit. The teammate appreciated the collaborative approach, and the changes were adopted into the production report.

This approach balances empathy, concrete technical fixes, measurable validation, and ongoing support so the codebase and our team’s capabilities both improve.

Hi [Name], I reviewed the dashboard and noticed several labels are ambiguous (e.g., “Conversion” vs. “Conversion Rate”) and key filters (date range, region, product line) are missing. Stakeholders are frequently misinterpreting metrics, leading to incorrect conclusions and follow-up clarification requests. Could you 1) standardize metric names and add brief tooltips/definitions, 2) add essential filters with sensible defaults, and 3) include a short legend or example use case? I’m happy to help map the definitions and test the filter behavior—want to pair on this for 30 minutes tomorrow?

Situation/Goal: My team produces SQL scripts, ETL jobs, and dashboards that business users depend on daily. My goal when giving/receiving feedback is to keep artifacts correct, performant, and understandable for both engineers and non‑technical stakeholders.

Process & Tools:

• Work lives in Git (feature branches + pull requests) for SQL/ETL (we use dbt for models; raw SQL stored in repo) and in Tableau/PowerBI with versioned workbooks on Tableau Server/PowerBI Service.
• I open a Jira ticket describing the change, link the PR/workbook, and assign reviewers (usually 1 peer analyst + 1 data engineer or stakeholder).
• Reviews happen in the PR: inline comments, suggested commits, and acceptance checklist. For dashboards I use Tableau comments + a short PR describing changes and screenshots.
• We run automated checks where possible: sqlfluff for style, dbt tests and CI for model validation, and automated row-count/integrity tests for ETL.

Evaluation Criteria:

• Correctness: Does the SQL/transform produce expected results? Are tests present?
• Readability & Maintainability: Clear naming, modular CTEs/functions, comments explaining non‑obvious business logic.
• Performance: Use of appropriate joins, predicates, indexes; consider pushdown, limiting row scans; check explain plans for slow queries.
• Business Clarity: Metrics match definitions in the data dictionary; visualizations answer the business question with clear labels and filters.
• Reproducibility & Monitoring: Seeds/tests, lineage, and alerting are included.

Giving Feedback:

• I write actionable, prioritized comments (bug/critical first; then improvements).
• I cite examples (sample rows, explain plan snippets, screenshots) and propose specific fixes or alternatives.
• For cross-team impacts I summarize in the PR description and tag impacted stakeholders.

Receiving & Implementing Feedback:

• I acknowledge comments in PR, make small commits addressing each point, and mark items resolved in the PR checklist.
• For larger disagreements I schedule a short pairing session to iterate quickly rather than long comment threads.

Tracking & Closure:

• Every feedback item maps to Jira subtasks when non‑trivial, so nothing is lost.
• PRs require automated tests passing and at least one approval; merge is gated.
• Post‑merge, I monitor data quality dashboards and set a brief follow‑up review with stakeholders after deployment (smoke checks, KPI comparisons).
• We keep a changelog in the repo and update the data dictionary/dashboard release notes so downstream users are informed.

Outcome/Learning: This process balances speed with rigor — automated checks catch regressions, code reviews improve quality and knowledge sharing, and ticketing ensures accountability and traceability.