Interview Insights · Automation Scripts
Why I Always Ask About Failed Automation Scripts, Not Just Wins
Quick summary — Failed scripts
A failed script tells me more about you than a successful one, because failure shows how you think when the happy path ends. Data analysts increasingly automate their routine work: Python scripts that combine daily files, refresh a report, clean an export or send a summary email. When I ask about these scripts, most candidates describe the version that worked. That tells me they can follow a happy path. When I ask about a script that failed, I hear whether they can read an error, find a root cause, own a mistake and protect the next run. This page explains why failure questions matter, the common ways report scripts fail and how to tell your story.
In this guide you will learn:
- Why interviewers ask about failures instead of only successes
- The common ways reporting scripts fail, often silently
- The four-part failure story that shows debugging skill
- Defensive Python habits such as logging and schema checks
- A postmortem template for your own failed scripts
SECTION 01What a failure question reveals that a win cannot
When a candidate tells me about a script that worked, I mostly hear a description of features. It reads files, cleans them, writes an Excel file, done. That proves very little, because a script that works once on clean input can still be fragile. Real data work is mostly about what happens when input changes, a server is slow or a column is renamed overnight.
A failure question gets straight to that. It shows whether you noticed the problem yourself or a manager did, whether you found the root cause or patched the symptom, and whether you changed anything so the same failure would be caught early next time. Those three things matter far more to a hiring manager than how many libraries you used.
| What I listen for | Weak signal | Strong signal | Why it matters |
|---|---|---|---|
| Who noticed | My manager told me the report was wrong | My row-count log looked off, so I checked | Shows ownership and monitoring |
| Root cause | I reran it and it worked | A source column was renamed upstream | Shows real debugging |
| Honesty | It was not my fault | I assumed the file format would never change | Shows maturity |
| Prevention | I fixed that line | I added a schema check and an alert | Shows learning that lasts |
Interviewer: Tell me about a script that failed.
Candidate: Once my sales report script gave an error.
The data team had changed the file. I told them and
they fixed it. Then the script worked again.
Interviewer: How did you find out it failed?
Candidate: My manager said the report had not come.Interviewer: Tell me about a script that failed.
Candidate: My daily sales script ran without errors
but produced a report with zero revenue for one region.
The source team had renamed 'Amount' to 'Net_Amount'.
My code used .get() with a default of 0, so it hid the
problem instead of failing.
I noticed because the row count was normal but the total
was far below the previous day. I changed the script to
check required columns at the start and stop with a clear
message, and to log the daily total so big drops stand out.
The strong answer admits a design mistake: using a default that hid missing data. That is exactly the kind of detail interviewers trust, because nobody invents a mistake that specific.
SECTION 02How reporting scripts usually fail
If you have written a few automation scripts, you have almost certainly met at least one of these failures. If you have not noticed one yet, that may mean it happened silently. Knowing the common patterns helps you recognise your own story and shows the interviewer that you understand where automation is fragile.
The most dangerous failures are not crashes. A crash is obvious. The dangerous ones finish successfully and produce a wrong number that someone uses in a meeting.
| Failure type | Example | Why it is dangerous | Defence |
|---|---|---|---|
| Schema change | A column renamed or removed in the source file | Can silently produce zeros or blanks | Check required columns at start |
| Missing or partial input | Today's file not delivered, or half written | Report built from yesterday or partial data | Check file date and row count |
| Type and format drift | Dates arrive as text in a new format | Rows dropped or misread | Parse with explicit format, count failures |
| Environment issues | Script works on laptop, fails on scheduler | No one notices overnight failure | Log to a file and alert on failure |
import pandas as pd
df = pd.read_csv('sales_today.csv')
# Fragile: if 'Amount' is missing, revenue becomes 0
# for every row and the script still 'succeeds'
if 'Amount' in df.columns:
df['revenue'] = df['Amount']
else:
df['revenue'] = 0
# Fragile: bad dates become NaT and are silently dropped
df['date'] = pd.to_datetime(df['date'], errors='coerce')
df = df.dropna(subset=['date'])
df.groupby('region')['revenue'].sum().to_excel('report.xlsx')import logging, sys
import pandas as pd
logging.basicConfig(filename='sales_report.log',
level=logging.INFO,
format='%(asctime)s %(levelname)s %(message)s')
REQUIRED = {'date', 'region', 'Amount'}
df = pd.read_csv('sales_today.csv')
missing = REQUIRED - set(df.columns)
if missing:
logging.error('Missing columns: %s', missing)
sys.exit(1)
parsed = pd.to_datetime(df['date'], format='%Y-%m-%d', errors='coerce')
bad = parsed.isna().sum()
if bad:
logging.warning('%d rows had unreadable dates', bad)
df['date'] = parsed
df = df.dropna(subset=['date'])
total = df['Amount'].sum()
logging.info('rows=%d total=%.2f', len(df), total)
df.groupby('region')['Amount'].sum().to_excel('report.xlsx')
The defensive version is only slightly longer, but it fails loudly on missing columns, reports how many dates could not be read and logs the row count and total every day. Those logs are what let you notice a problem before your manager does.
Writing to Excel with to_excel needs the openpyxl package installed. Mention dependencies like this in interviews, because a missing package on a scheduler machine is itself a classic failure story.
SECTION 03Telling the story: symptom, cause, fix, prevention
Once you have a failure in mind, structure matters. A rambling failure story sounds like an excuse. A structured one sounds like a professional review. Use four parts: the symptom you saw, the root cause you found, the fix you applied and the prevention you added.
Keep the first telling under ninety seconds. The interviewer will ask about the part that interests them most, usually how you found the cause. Prepare that part in more detail, including the exact checks you ran.
| Part | What to say | Example line | Common mistake |
|---|---|---|---|
| Symptom | What looked wrong and to whom | The North region showed zero revenue on the morning report | Starting with the code |
| Root cause | The real reason, not the trigger | A renamed column met a default value that hid it | Stopping at 'the file changed' |
| Fix | What you changed right away | Mapped the new column name and reran the report | Only rerunning the script |
| Prevention | What stops it happening silently again | Required-column check and a daily total log | No change after the fix |
FAILURE STORY CARD
Script: daily sales report (Python, scheduled)
Symptom: one region showed zero revenue
Noticed by: me, from the daily total in the log
Investigated: compared today's columns with yesterday's
-> 'Amount' renamed to 'Net_Amount'
Root cause: my code defaulted missing column to 0
Fix: handled new name, reran, sent corrected report
Prevention: required-column check, exit with error,
daily rows and total logged
Lesson: fail loudly; never hide missing inputQ: Why did you use a default in the first place?
A: I wanted the script to never crash. I learned that
a crash is better than a wrong report.
Q: How would you know if it failed overnight?
A: The scheduler task returns a non-zero exit code,
and I added an email alert on failure. I also check
the log each morning before the report goes out.
Q: What would you do differently now?
A: Agree a file format with the source team and add
the column check from day one.
The follow-up answers show something interviewers value highly: the candidate changed their belief, not just their code. 'A crash is better than a wrong report' is a lesson that will protect every future script they write.
SECTION 04Postmortem template for your own failed scripts
Write a short postmortem for every script failure you experience, even small ones. It builds the habit of learning from failure and gives you ready interview stories. In Uncodemy mock interviews, trainers often ask candidates to walk through exactly this kind of postmortem.
SCRIPT POSTMORTEM
Script name: ______________________
Date of failure: __________________
What the user saw: ________________
How it was noticed: alert / log / user / me
Time until noticed: _______________
Root cause: _______________________
Why my code allowed it: ___________
Immediate fix: ____________________
Prevention added: _________________
One-line lesson: __________________BEFORE SCHEDULING ANY SCRIPT
[ ] Required columns checked at the start
[ ] Input file date and row count checked
[ ] Dates parsed with an explicit format
[ ] Bad or dropped rows counted and logged
[ ] Key totals logged each run
[ ] Script exits with non-zero code on error
[ ] Failure triggers an alert or email
[ ] Dependencies listed in requirements.txtBREAK YOUR OWN SCRIPT (to find stories)
1. Rename one required column in the input file.
2. Delete the input file before the run.
3. Change dates to a different format.
4. Add duplicate rows.
5. Run from a different folder.
For each: did the script fail loudly, or produce
a wrong result quietly? Fix the quiet ones.
SECTION 05Habits that turn failures into strong answers
These habits make your scripts safer and your interview stories stronger at the same time.
- Log totals, not just errors — A daily log of row counts and key totals lets you spot silent failures that never raise an exception.
- Fail loudly by design — Stop the script with a clear error when required input is missing, instead of filling gaps with defaults.
- Own the design mistake — In interviews, name the assumption you got wrong, because it shows learning rather than blame.
- Keep a failure log — Write two or three lines after every script problem, so you have real stories ready with accurate details.
- Test with bad input — Run your script against broken files on purpose before scheduling it, so you find weaknesses before users do.
SECTION 06Interview Q&A — Failed scripts
Q1Tell me about an automation script that failed.
Describe the symptom, how you noticed, the root cause, the fix and what you added to prevent a silent repeat. For example, a renamed source column that a default value hid, caught by a daily total log, fixed with a required-column check and a clear error exit.
Q2How do you know if a scheduled script failed overnight?
The script exits with a non-zero code on error, which the scheduler records, and it sends an alert email on failure. It also logs row counts and totals each run, so I can spot runs that finished but produced suspicious results.
Q3What is a silent failure?
It is when a script finishes without an error but produces wrong output, such as zeros for a missing column or dropped rows from bad dates. Silent failures are dangerous because people use the wrong numbers before anyone notices.
Q4How do you handle dates in different formats?
I parse with an explicit format where possible, count rows that fail to parse and log a warning with that count. If the count is high, I stop the run, because a large number of unreadable dates usually means the source format changed.
Q5What would you add to a script before scheduling it?
Required-column checks, an input date and row-count check, logging of key totals, explicit date parsing, a non-zero exit on error, an alert on failure and a requirements.txt so the scheduler machine has the same packages.
SECTION 07Test yourself — Failed scripts quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Why do interviewers ask about failures?
Failures show how you debug, how honestly you describe mistakes and whether you learn from them. A success story alone cannot show these things.
What if I have never had an automation script fail?
Test your script with broken input on purpose, such as a renamed column or missing file. Fix what you find and describe that process honestly in the interview.
How do I add logging to a Python script?
Use the logging module with basicConfig to write to a file, then log key events, warnings and errors. Log row counts and totals each run so problems stand out.
What are common automation mistakes for data analysts?
Hiding missing data with defaults, not checking input files, ignoring unparsed dates, not logging results, no failure alerts and missing dependencies on the scheduler machine.
How should I structure a failure story in an interview?
Use four parts: symptom, root cause, fix and prevention. Keep it under ninety seconds and be ready to explain how you found the cause in detail.
Where can I practise answers like these with expert feedback?
Yes. Uncodemy's Data Analytics Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise answers like these with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Write automation scripts that fail safely
Our Data Analytics Training Course teaches Python for analysts, including report automation, logging and data checks, with mock interviews on your own scripts.
₹15,500 · full programme- Python report automation
- Logging and data checks
- Mock technical rounds
- Weekday & weekend batches