Explain pricing fit and ETL architecture

A strong answer is not about sounding fancy; it is about sounding precise. ## What the interviewer is really testing They want evidence of: - honesty about gaps - transferability of your skills - understanding of business constraints - end-to-end ownership of data flow - ability to distinguish real automation from résumé inflation ## Recommended answer structure Use a simple 5-part structure: 1. **Acknowledge the gap directly** 2. **Bridge with transferable skills** 3. **Show tool pragmatism** 4. **Walk through one concrete ETL example end to end** 5. **Close with trade-offs and lessons learned** ## 1) Address the pricing gap well Bad answer: - "No, I do not have pricing experience." Better answer: - "I do not have direct ownership of pricing strategy, but I have worked on adjacent problems that are highly relevant: data cleaning, KPI reporting, demand/behavior analysis, margin-sensitive reporting, and building reliable pipelines for decision-making. I understand that pricing work requires accurate data, clear metric definitions, and careful interpretation of business trade-offs such as revenue, margin, and volume." This works because it is honest and reframes the gap as a learning curve rather than a disqualifier. ## 2) Handle the Google Sheets question correctly The trap is acting like Sheets is beneath you. A strong answer says: - Sheets is often the business interface because it is collaborative and fast. - You are comfortable meeting stakeholders where they work. - You know both the strengths and the limits of Sheets. Mention concrete capabilities if true: - pivot tables - lookup formulas - array formulas - QUERY - data validation - conditional formatting - protected ranges - Apps Script automation - lightweight scenario models Also mention limits: - weak version control - performance issues at larger scale - reproducibility challenges - auditability concerns - harder testing than SQL/dbt/Python pipelines Good framing: - "I am comfortable using Sheets as the business-facing layer, but I would still prefer validated data to be produced upstream in SQL/Python so the logic is reproducible and the Sheet is mainly for consumption, exception handling, or scenario analysis." That shows pragmatism, not tool snobbery. ## 3) Explain infrastructure with a data-flow mindset The interviewer wants a mental model like: **Source -> Ingestion -> Staging -> Transform -> Warehouse/DB -> Reporting/Consumption** If you say only "I used Python and SQL," that is too shallow. A better explanation includes: - source system - file/interface type - landing zone - transformation logic - load destination - scheduling or event trigger - downstream users - monitoring and failure handling ## 4) How to answer the 25,000-CSV ETL question A strong ETL answer needs specificity. Example structure: - "The source data arrived as CSV files from [hospital systems / vendors / internal exports]." - "Files were delivered via [SFTP / shared bucket / manual upload portal]." - "We landed raw files in [cloud storage/local staging area] before processing so we preserved an immutable raw layer." - "A Python job validated schema, standardized column names, parsed timestamps, handled missing values, deduplicated records, and logged bad rows for review." - "After transformation, the cleaned tables were loaded into [Postgres / BigQuery / Snowflake / SQL Server]." - "The job was triggered by [daily cron / Airflow schedule / event on file arrival]." - "It was semi-automated because file delivery was manual but ingestion and downstream processing were automatic once the file appeared." - "It was fully automated only after file delivery itself was integrated." - "The output was used by [analysts / dashboards / operations teams], and production readiness included monitoring, retries, and alerts." ## 5) Be very clear on automation levels This is a common interview probe. ### Manual A human downloads, cleans, and uploads files each time. ### Semi-automated A human still initiates one step, but once the input appears, scripts run automatically. ### Fully automated The pipeline ingests, transforms, validates, loads, and alerts without human intervention under normal conditions. This distinction matters because many candidates overstate automation. ## 6) Mention production-quality concepts If the project was real, you should be able to discuss at least some of these: - schema validation - idempotency - deduplication keys - retry logic - logging - alerting - backfills - data quality checks - access control / PHI or PII handling if relevant - SLA or refresh frequency - lineage to downstream reports Even if the project was academic or internship-scale, showing awareness of these concepts strengthens your answer. ## 7) Trade-offs the interviewer wants to hear Examples: - **Sheets vs SQL/Python**: Sheets is collaborative and fast; SQL/Python is more scalable and reproducible. - **Cron vs event-driven**: cron is simpler; event-driven is faster and more responsive but can be more complex to operate. - **Local DB vs cloud warehouse**: local is cheap/simple for small prototypes; cloud is better for collaboration, scaling, and governance. - **Raw file retention vs overwrite**: retaining raw files improves auditability and debugging. ## 8) A concise sample answer "I do not have direct pricing ownership, but I do have relevant analytical experience building reporting pipelines and translating messy operational data into decision-ready outputs. I am comfortable working in Google Sheets when that is the team's operating tool, especially for lightweight models and stakeholder collaboration, though I prefer core transformations to happen upstream in SQL or Python for reproducibility. One example is an ETL workflow I built for about 25,000 CSV files. The files came from [source] and were delivered via [method]. We first stored the raw files in [staging layer], then a scheduled Python job validated schema, standardized fields, handled nulls, and deduplicated records before loading curated data into [database]. The trigger was [cron / file-arrival], so I would describe it as [semi-automated / fully automated] because [reason]. Downstream analysts consumed the cleaned data through [dashboard / Sheets / SQL queries]. The key design choice was keeping the pipeline simple and reliable rather than overengineering it." ## Final coaching note The best answers sound like someone who has actually operated the system: - specific nouns - explicit triggers - clear users - honest limitations - justified trade-offs That is usually what separates a credible résumé project from a weak one.