Chapter 40 Exercises: Building Your Python Business Portfolio

These exercises are organized into five difficulty tiers. Work through them in order, or jump to the tier that matches your current confidence level. There is no single right answer for most of these — they are designed to produce real, useful artifacts.

Tier 1: Foundation (Estimated time: 15-30 minutes each)

These exercises help you reflect on what you have already built and begin organizing it professionally.

Exercise 1.1 — Skills Inventory

List every Python skill or concept you have used at least once during this book. Organize them into three columns: - "I understand it and could explain it to someone" - "I can use it but could not explain it fully" - "I have seen it but still feel uncertain"

Do not look anything up. This is a genuine self-assessment, not a test. The "uncertain" column tells you where to focus next. Compare your results with the skills_self_assessment.py tool in the code/ directory.

Exercise 1.2 — Problem Inventory

Think about your current job, your most recent role, or the business domain you work in. List ten processes or recurring tasks that involve data, reporting, or manual repetition. For each one, write one sentence describing what it does and one sentence estimating how long it takes per week.

You do not need to build any of these yet. This is a backlog of potential portfolio projects.

Exercise 1.3 — GitHub Profile Audit

If you do not have a GitHub account, create one at github.com. If you do have one, review your existing repositories and identify: - Which repositories have no README (or only a default one) - Which repositories you would not be comfortable showing to a hiring manager today - Which repositories represent your best work

Write down three specific actions you would take to make your GitHub profile portfolio-ready.

Exercise 1.4 — The Elevator Pitch

Write a two-sentence description of your Python skills aimed at a non-technical hiring manager or prospective client. It should describe what you can build and the value it creates, not what you have learned.

Model: "I build automated data tools and reporting systems in Python that help business teams spend less time on manual work and more time on the decisions that actually matter. I have built everything from automated weekly reports to deployed web dashboards."

Read it aloud. If it sounds like a resume bullet, revise it until it sounds like something you would say in a real conversation.

Exercise 1.5 — README Audit

Choose the repository you are most proud of and read its README as if you are a hiring manager who has never met you. Answer these questions honestly: - Does it say what the project does in the first two sentences? - Does it explain why the project exists — what problem it solves? - Does it describe any results or outcomes in business terms? - Does it explain how to run the project with working commands? - Does it acknowledge limitations?

Identify the weakest section. You will rewrite it in Exercise 2.1.

Tier 2: Developing (Estimated time: 45-90 minutes each)

These exercises produce tangible portfolio artifacts you can use immediately.

Exercise 2.1 — README Rewrite

Using the template from section 40.4 of the chapter, rewrite the README for your best existing project. Your new README must include all five sections: "What This Does," "The Problem It Solves," "Results" (with at least one quantified outcome), "Tech Stack," and "How to Run" with working commands.

If you do not have an existing project you are satisfied with, build a simple version of the automated report template from code/portfolio_project_template.py first, then write its README.

Exercise 2.2 — Commit Message Practice

On a practice or side repository, make five small changes — each one a single logical unit. Write a meaningful commit message for each change using the imperative verb format from section 40.3. Examples of appropriate changes: add a new function, add a type hint to an existing function, add a docstring, fix a variable name to be more descriptive, add one test.

After completing all five commits, read through the commit history. Would someone who sees this history for the first time understand what you did and why?

Exercise 2.3 — Before/After Write-Up

For any project you have worked on — from this book or from your actual job — write a before/after description following the framework from section 40.5:

Before (3-5 sentences): Describe the situation before you built the tool. What was the manual process? How long did it take? What problems did it cause?

After (3-5 sentences): Describe the situation after. How long does it take now? What was eliminated? What became possible that was not before?

Impact (one sentence): A specific number. Time saved per week, errors reduced, users enabled, or revenue affected — whichever is most honest and most relevant.

This write-up belongs in the "The Problem It Solves" section of your README, condensed to 2-3 sentences.

Exercise 2.4 — Non-Technical Summary

Take any Python project from this book — any chapter's main project will work — and write a technical summary aimed at a VP or director who does not code. Your summary must: - Fit in one paragraph (5-8 sentences) - Contain no unexplained jargon - Lead with the business outcome, not the technical method - Include at least one number (time, cost, users, or frequency) - End with a specific use case or decision this tool enables

Exercise 2.5 — .gitignore Verification

Examine a Python repository you own. Verify that it correctly ignores all of the following. If any are missing, add them: - __pycache__/ directories and *.pyc files - Virtual environment directories (venv/, .env/, env/) - .env files that might contain credentials - Operating system files (.DS_Store, Thumbs.db, desktop.ini) - Jupyter notebook checkpoints (.ipynb_checkpoints/) - IDE configuration files (.idea/, .vscode/ if they contain personal settings)

If any of these files are already tracked in the repository, look up the git rm --cached command and understand how to untrack a file without deleting it locally.

Tier 3: Intermediate (Estimated time: 2-4 hours each)

These exercises produce complete, portfolio-ready projects.

Exercise 3.1 — Automated Report Project (Full Build)

Choose one data source: - Your own business data (anonymized) - A public dataset from data.gov, the Bureau of Labor Statistics, or Kaggle - The synthetic sales data provided in this book's earlier chapters

Build an automated report script that: 1. Loads data from the chosen source 2. Performs at least three distinct analyses (e.g., aggregation by category, trend over time, outlier identification) 3. Generates a formatted output — Excel, HTML, or PDF 4. Could be scheduled to run automatically (document the scheduling approach in the README even if you do not set it up)

The project must have a complete README following the template from section 40.4. The time savings must be estimated and documented.

Exercise 3.2 — Data Cleaning Pipeline (Full Build)

Find a genuinely messy real-world dataset. Good sources include: - The City of Chicago Data Portal (data.cityofchicago.org) — 311 service requests are reliably messy - Any Kaggle dataset described as "raw" or "uncleaned" - An export from a real system you use at work (anonymized)

Build a cleaning pipeline that: 1. Documents the specific problems found in the raw data 2. Applies cleaning steps in a logical, reproducible order using named functions 3. Outputs a clean dataset alongside a data quality report showing before/after row counts and issue summaries 4. Includes a README that explains not just what you did but why you made each cleaning decision

The reasoning behind your decisions is more valuable to a portfolio reviewer than the code itself.

Exercise 3.3 — LinkedIn Portfolio Post

Write a LinkedIn post about a Python project you have built. Follow these constraints: - 150-250 words - Opens with the business problem, not the technical solution - Includes a specific quantified result - Ends with a brief reflection: what you learned, or what you would tell someone starting where you started - Includes a link to your GitHub repository

This is a post you should actually publish. If you are not yet comfortable with that, write it, wait 24 hours, and then publish it.

Exercise 3.4 — Skills Self-Assessment Revisit

Run the skills_self_assessment.py script from the code/ directory. For any skill where you rated yourself below 3 out of 5: 1. Find the chapter in this book where that skill is covered 2. Re-read the relevant section 3. Write a small function (5-15 lines) that uses that skill in a business context you care about 4. Update your self-assessment score after completing the practice

Track your scores in a plain text file. In 30 days, run the assessment again and compare.

Exercise 3.5 — Open Source Research

Pick a Python library you use regularly. Explore its GitHub repository and answer: 1. How many open issues does it currently have? 2. Are there any issues labeled "good first issue" or "documentation"? 3. What does the CONTRIBUTING.md file say about how to contribute? 4. What specific change could you make that would be genuinely useful?

You do not need to submit the contribution for this exercise. The goal is to familiarize yourself with the contribution process and identify one realistic starting point.

Tier 4: Advanced (Estimated time: 4-8 hours each)

These exercises produce substantial portfolio projects that demonstrate professional-level skills.

Exercise 4.1 — Pipeline with Tests and Logging

Build a complete data pipeline that includes: 1. A data loading stage with error handling for missing files and unexpected formats 2. A cleaning and transformation stage written as individual, named functions 3. An analysis or reporting stage that produces a business-legible output 4. A test suite with at least six tests, including: behavior when input file is missing, behavior when required columns are absent, and verification that at least one analytical result is correct for known input 5. Python's logging module recording each stage with timestamps 6. A command-line interface using argparse with at least two configurable parameters

The README should include a section called "Running the Tests" with the exact command to run the test suite.

Exercise 4.2 — Interactive Dashboard, Deployed

Build a Plotly Dash or Streamlit dashboard that: 1. Loads data from a local file or small database 2. Displays at least three distinct visualization types 3. Includes at least two interactive filters that update all visualizations simultaneously 4. Is deployed to a free hosting service and accessible at a public URL

A dashboard that only runs locally is not a portfolio project. The README must include the live URL and at least one screenshot. Free deployment options include Streamlit Community Cloud (for Streamlit apps) and Render or Railway (for Dash apps).

Exercise 4.3 — Machine Learning Project with Documentation

Build a machine learning project on a business dataset that: 1. Defines the prediction target in business terms — what decision does this prediction enable? 2. Documents the feature engineering decisions and the reasoning behind each one 3. Trains at least two model types and compares their performance 4. Explains the final model's performance in business terms (not just accuracy metrics in isolation) 5. Discusses what the model cannot do and when its predictions should not be trusted 6. Describes how the model's predictions would actually be used in a real workflow

The Titanic dataset is acceptable only if a more domain-relevant dataset is genuinely unavailable. A model predicting a real business outcome is more compelling than a canonical tutorial example.

Exercise 4.4 — API-Integrated Tool

Build a tool that integrates with at least one real external API. Practical options with free tiers: - Weather data from OpenWeatherMap combined with sales or operational data - Financial and economic data from the Federal Reserve FRED API (no authentication required) - GitHub's API to analyze patterns in a public repository - The OpenAI API for text classification or summarization

Your tool must handle authentication securely (credentials never in the repository), handle errors gracefully (network failures, rate limits, unexpected responses), store results locally to avoid unnecessary API calls, and produce a business-legible output.

Exercise 4.5 — Technical Writing: Tutorial or Blog Post

Write a technical tutorial of 800-1200 words aimed at a business professional learning Python for the first time. Choose a specific skill from this book as your topic.

Your tutorial must: - Open with the business problem this skill solves, not "in this tutorial we will learn" - Include at least three working code examples with the expected output shown - Explain the reasoning behind key design decisions in the code - Anticipate and address at least two common mistakes or points of confusion - Close with a practical next step the reader can take immediately

Publish this on Medium, dev.to, Substack, or a personal blog. Include the published URL in your GitHub profile README.

Tier 5: Mastery (Estimated time: 8-20 hours each)

These are capstone-level projects. Complete one and you have a centerpiece portfolio project — the kind that opens real professional conversations.

Exercise 5.1 — Deploy a Complete Business Application

Build a complete web application that: 1. Solves a real, specific problem for a real or realistic user 2. Has user authentication (login, session management, logout) 3. Persists data in a database between sessions 4. Has at least three distinct user-facing features 5. Is deployed to a production environment at a public URL 6. Has a README that includes the live URL, screenshots of each main feature, the complete tech stack, and an honest reflection on what you would improve with more time

The deployment requirement is firm. An application that only runs on your laptop is not a portfolio project. Free deployment options include Render, Railway, and fly.io.

Exercise 5.2 — Contribute to an Open-Source Project

Make a genuine contribution to an open-source Python project that is accepted and merged by a maintainer. The contribution can be a documentation improvement, a bug fix, a new test, or a small feature. What matters is that a real maintainer reviewed your work and merged it.

Document the full experience: which project, what you contributed, how long the review process took, what feedback you received, and what you revised in response. This documentation belongs in your portfolio as evidence of collaborative software development.

Exercise 5.3 — Teach Python to Someone Else

Design and deliver a 45-60 minute learning session teaching one Python skill to someone who has not used it before. Prepare: - A structured outline with time allocations - At least two live coding demonstrations - One hands-on exercise for your learner to complete during the session - A brief resource list for follow-up

After the session, write a 300-word reflection: what your learner struggled with most, what explanation worked better than you expected, and what you would change in a second session. Teaching is one of the clearest demonstrations of real understanding — you cannot fake it the way you can fake recognition.

Exercise 5.4 — The Six-Month Project Challenge

Choose one project from Exercise 3.1 or 4.1. Commit to actively maintaining and improving it for six months. Follow this development arc:

Month 1: Build the initial version. Write complete documentation. Month 2: Get feedback from at least one person who uses it or would use it. Identify the three most valuable improvements. Month 3: Implement the improvements. Add tests for the new functionality. Month 4: Add one integration with another system you did not originally plan (an API, a different output format, an email notification, a database you were not using). Month 5: Address one real performance or reliability issue you have encountered in actual use. Month 6: Write a retrospective: what the project looks like now versus month 1, what you learned about maintaining software that you could not have learned from building it once, and what you would tell someone starting the same project today.

This exercise produces not just a portfolio project but a documented journey of growth. That journey, honestly described, is one of the most compelling things any professional can share.

Notes for All Exercises

On real data: For any exercise that asks for real data, synthetic data made to look realistic is fully acceptable when real data is confidential or unavailable. The goal is a realistic problem, not necessarily real personal information.

On time estimates: The estimates are genuine approximations for a practitioner at this stage. If you find an exercise taking twice as long, that is normal — complexity is not always visible until you are inside it. If it takes half as long, you may have more background than the estimate assumed, or you may have simplified the problem more than intended.

On getting stuck: Getting stuck is part of the process. When you are stuck, try in sequence: re-read the relevant chapter section, read the library's official documentation, search the specific error message on Stack Overflow, and ask in the Python Discord or r/learnpython community. Document what you tried and what eventually worked. That documentation is itself a learning artifact worth keeping.

On the portfolio mindset: Every exercise in this set is designed to produce something real — something you could show to a hiring manager, a client, or a colleague and say "I built this." That framing is not accidental. The goal is not practice for its own sake. The goal is a body of work that demonstrates who you have become.