Interview Insights · Automation Scripts
What a Great Automation Script Walkthrough Actually Sounds Like
Quick summary — Script walkthrough
A great walkthrough follows the data, not the lines of code. It starts with why the script exists and ends with how you know it worked. When I say 'walk me through your automation script', I am not asking you to read the file aloud. I want to understand the problem it solves, what triggers it, what it reads, what it does to the data, what it produces and how it protects against bad input. Strong candidates explain in that order, at a high level first, then zoom into one or two interesting parts. This page breaks down that structure, gives a complete Python example and shows exactly how to narrate it.
In this guide you will learn:
- The six-part structure of a strong script walkthrough
- How to open with the manual task the script replaced
- A complete Python report script you can practise explaining
- How to zoom in on one design decision without losing the listener
- How to close with safeguards, limits and next improvements
SECTION 01The six parts of a walkthrough that interviewers follow easily
The best walkthroughs I hear share a shape. They begin with purpose: the manual task the script replaced and who benefited. Then trigger: what starts it, whether a schedule, a button or a new file. Then input, process and output, in the order data flows. Finally safeguards: how the script handles bad input and how you know it ran correctly.
This order works because it matches how a listener builds a mental model. Once they know why the script exists and what goes in and out, every detail you add has a place to land. Without that frame, details float and the listener stops following.
| Part | Question it answers | Example line | Time to spend |
|---|---|---|---|
| Purpose | Why does this exist? | Every Monday someone copied branch files into one sheet by hand | About 15 seconds |
| Trigger | What starts it? | Task Scheduler runs it early on Monday morning | A sentence |
| Input and output | What goes in, what comes out? | Branch CSVs in a folder go in; one formatted Excel summary comes out | About 20 seconds |
| Process and safeguards | What happens inside, and what if input is bad? | Clean, combine, pivot; stop with an error if a file is missing columns | Most of the time |
'This script replaced a weekly manual job. Every Monday,
someone downloaded sales files from each branch and
copied them into one Excel sheet, which was slow and
error-prone.
Now Task Scheduler runs the script early on Monday.
It reads every branch CSV in a shared folder, cleans
and combines them, and writes one Excel file with a
summary by branch and product, plus a log of what it
processed.
I will go through it in the order the data flows.''So first I import pandas as pd. Then I import
glob. Then I have a variable called path. Then there
is a for loop. In the loop I read the CSV. Then I
append it to a list. Then I concat the list. Then I
rename columns...'
(After a minute, the interviewer still does not know
what problem the script solves or what it produces.)
The strong opening takes about thirty seconds and gives the interviewer the whole map. Everything after that is detail they can place on the map, and they can ask to zoom into any part.
SECTION 02A complete report script to practise narrating
Here is a realistic script of the kind analysts automate: combine weekly branch sales files, clean them, produce a summary and write a formatted Excel workbook. It is short enough to explain in an interview but has real decisions in it, such as how files are found, how columns are standardised and what happens when a file is wrong.
Read the code, then read the narration beside it. Notice that the narration describes what each block does and why, rather than repeating the code word for word.
| Code block | What it does | Why it is written this way | What to say aloud |
|---|---|---|---|
| load_branch_files() | Finds and reads every CSV in the folder | pathlib glob means new branches need no code change | Adding a branch is just dropping a file in the folder |
| Column check | Confirms required columns exist | Bad files stop the run instead of corrupting totals | A wrong file fails loudly with its name |
| clean() | Standardises names, types and dates | Branches export slightly different formats | This is where most of the real work is |
| write_report() | Writes detail and summary sheets | Managers want both the totals and the rows behind them | One workbook, two sheets, named by week |
from pathlib import Path
from datetime import date
import logging
import pandas as pd
IN_DIR = Path('branch_files')
OUT = Path(f'weekly_sales_{date.today():%Y_%m_%d}.xlsx')
REQUIRED = {'date', 'product', 'qty', 'price'}
logging.basicConfig(filename='weekly_sales.log', level=logging.INFO)
def load_branch_files():
frames = []
for f in sorted(IN_DIR.glob('*.csv')):
df = pd.read_csv(f)
df.columns = df.columns.str.strip().str.lower()
missing = REQUIRED - set(df.columns)
if missing:
raise ValueError(f'{f.name} missing {missing}')
df['branch'] = f.stem
frames.append(df)
if not frames:
raise FileNotFoundError('No branch files found')
return pd.concat(frames, ignore_index=True)
def clean(df):
df['product'] = df['product'].str.strip().str.title()
df['date'] = pd.to_datetime(df['date'], errors='coerce')
df = df.dropna(subset=['date'])
df['revenue'] = df['qty'] * df['price']
return df
def write_report(df):
summary = df.pivot_table(index='branch', columns='product',
values='revenue', aggfunc='sum',
fill_value=0)
with pd.ExcelWriter(OUT) as xl:
summary.to_excel(xl, sheet_name='Summary')
df.to_excel(xl, sheet_name='Detail', index=False)
if __name__ == '__main__':
data = clean(load_branch_files())
write_report(data)
logging.info('rows=%d revenue=%.2f', len(data), data['revenue'].sum())'The script has three steps: load, clean, write.
Load looks in the branch_files folder for every CSV.
I used pathlib's glob, so a new branch just means a new
file; no code change. Each file's columns are lowercased
and stripped because branches typed headers differently.
If a file is missing a required column, the script stops
and names the file. The file name becomes the branch.
Clean fixes product name spacing and case, parses dates
and calculates revenue as quantity times price.
Write builds a pivot of revenue by branch and product
for the Summary sheet and keeps all rows in Detail, so a
manager can check any total. Finally it logs the row
count and total revenue for that run.'
The narration is roughly one minute long and covers every block, yet it never reads a line of code verbatim. It explains decisions: why glob, why lowercase headers, why keep a Detail sheet. Those decisions are what an interviewer will ask about next.
SECTION 03Zooming in and closing well
After your overview, the interviewer will usually ask you to zoom into one part. Sometimes they choose, sometimes they let you pick. If you get to pick, choose the part with the most interesting decision, not the most code. For the script above, that is probably the column standardisation or the decision to stop on a bad file rather than skip it.
Then close. A great walkthrough ends with three things: how you know the script worked, what its limits are and what you would improve next. That ending shows maturity and gives the interviewer good follow-up material.
| Zoom-in topic | The decision | Alternative you rejected | Why |
|---|---|---|---|
| Bad file handling | Stop the whole run with an error | Skip the bad file and continue | A summary missing one branch looks complete but is wrong |
| Header cleanup | Lowercase and strip every header | Rename columns one by one per branch | Handles new branches without code changes |
| Detail sheet | Keep all rows alongside the summary | Summary only | Managers can trace any total back to rows |
| Dropped dates | Drop unreadable dates | Keep them with blanks | Next version will log how many were dropped |
Interviewer: Why stop the whole run for one bad file?
Candidate: I considered skipping it and continuing.
But the summary would then show all other branches,
and nobody would notice one was missing. A wrong but
complete-looking report is worse than no report.
Stopping with the file name in the error means someone
fixes that file and reruns, and the summary is always
complete when it exists.'How I know it worked: the log records row count
and total revenue each run, and I compared the first
few runs with the old manual sheet until they matched.
Limits: it drops unreadable dates without counting
them, and it assumes prices are already in rupees.
Next: log the number of dropped rows, add a check that
every expected branch file is present, and email the
file automatically instead of saving to a folder.'
Notice the candidate names a limit in their own code: dropped dates are not counted. Pointing out your own weakness before the interviewer does is one of the strongest moves in a walkthrough. It shows you understand the code well enough to critique it.
SECTION 04Walkthrough worksheet for your own script
Fill this worksheet for the automation script you are most likely to be asked about. Then practise the walkthrough aloud until the overview takes about a minute. Booking a mock round with an Uncodemy trainer is a good way to test it against real follow-up questions.
SIX-PART WALKTHROUGH OUTLINE
Purpose (manual task replaced): ___________
Who benefits: ____________________________
Trigger (schedule / manual / event): _____
Input (files, source, format): ___________
Process (3 steps max): ___________________
1. ______ 2. ______ 3. ______
Output (file, table, email): _____________
Safeguards (what if input is bad): _______
How I know it worked: ____________________
Limits: __________________________________
Next improvement: ________________________DECISIONS I CAN DEFEND
Block: ___________
I chose: ___________
Instead of: ___________
Because: ___________
Block: ___________
I chose: ___________
Instead of: ___________
Because: ___________
Prepare at least three. These are your zoom-in answers.REHEARSAL STEPS
1. Say the overview without looking at code.
Target: about one minute.
2. Open the code and narrate each block in data
flow order, not line order.
3. Pick one block and explain its main decision
and the alternative you rejected.
4. Close with: how I know it worked, limits, next.
5. Record. Count how many times you read a line
of code aloud. Aim for almost none.
SECTION 05Habits that make every walkthrough sound confident
Confidence in a walkthrough comes from preparation that matches how interviewers listen. These habits help.
- Start without the code — Give the overview with the editor closed or minimised, so the interviewer hears the design before the details.
- Follow the data — Explain blocks in the order data moves through them, which is often different from the order they appear in the file.
- Name functions by job — Use function names like load, clean and write that describe what they do, so the code itself supports your narration.
- Mention dependencies — Say which packages the script needs and how it is scheduled, which shows you have run it outside your editor.
- Critique your own code — Point out one limit and the fix you would make, so the interviewer sees you understand the script deeply.
SECTION 06Interview Q&A — Script walkthrough
Q1Walk me through your automation script.
Start with the manual task it replaced and who benefits, then the trigger, the input and the output. Then explain the processing steps in the order data flows, highlight one design decision and close with how you know it worked, its limits and your next improvement.
Q2Why did you use pathlib glob to find files?
It finds every CSV in the folder automatically, so adding a new branch only requires dropping a new file in the folder. The script does not need a hard-coded list of file names, which reduces maintenance and mistakes.
Q3Why stop the run instead of skipping a bad file?
Skipping would produce a summary that looks complete but is missing a branch, and nobody might notice. Stopping with a clear error naming the file means the problem is fixed and the report is always complete when it exists.
Q4How did you check the script's output was correct?
I compared the script's output with the existing manual sheet for the first few runs until totals matched. I also log the row count and total revenue on every run, so unusual changes are easy to spot.
Q5What would you improve next?
Count and log rows dropped due to unreadable dates, check that every expected branch file is present before running, add unit tests for the clean function and send the report automatically by email.
SECTION 07Test yourself — Script walkthrough quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
How do I explain my Python script in an interview?
Start with the purpose and the manual task it replaced, then the trigger, input and output. Explain processing steps in data-flow order, highlight one design decision and finish with checks, limits and next steps.
How long should a code walkthrough be?
Give an overview in about one minute, then go deeper into whatever the interviewer asks. A full walkthrough of a small script usually fits in five minutes.
What automation scripts should a data analyst build?
Common examples are combining daily or weekly files, cleaning exports, refreshing a report, writing formatted Excel outputs and sending summary emails on a schedule.
Should I read my code line by line in an interview?
No. Describe what each block does and why. Reading lines aloud hides the design and makes it hard for the interviewer to follow.
How do I schedule a Python script?
On Windows you can use Task Scheduler and on Linux or macOS you can use cron. Make sure the script uses absolute paths or sets its working directory and logs its results.
Is there a course that covers answers like these?
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
Automate real reports and explain them clearly
Our Data Analytics Training Course covers Python, Pandas and Excel automation through real reporting tasks, with mock interviews where you present your own scripts.
₹15,500 · full programme- Python report automation
- Pandas and Excel output
- Code walkthrough practice
- Weekday & weekend batches