Where Is Python Applied in Industry?

Most data work in Python looks like this. You take some text from a source, you parse it with the csv module, and you turn each row into a dictionary that is keyed by the column names. The csv module is worth learning properly, because it handles quoted values, commas inside a field, and line breaks inside a field, none of which a plain split on commas can manage.

import csv
import io

raw = """team,member,points
red,Ada,12
blue,Grace,7
red,Linus,9
"""

totals = {}
for row in csv.DictReader(io.StringIO(raw)):
    team = row['team']
    points = int(row['points'])
    if team not in totals:
        totals[team] = 0
    totals[team] = totals[team] + points

for team in sorted(totals):
    print(team, totals[team])

The output shows a red total of 21 and a blue total of 7, printed in the order of the team names.

Look at the shape of the code, because it is the shape of most real pipelines. The rows arrive one at a time instead of being loaded into a list first. A plain dictionary does the counting, so the first time a team appears you add it with a value of zero. The totals are built while the rows arrive, rather than in a second pass over the data. For anything bigger than a small example, the same idea is written with pandas and its vectorised operations, or with DuckDB when you want to run SQL over Parquet files.

What an interviewer is really checking is whether you know two things. First, that the standard library is enough to build a prototype. Second, that you know when to move to a specialised library. Both halves of that answer matter.

The standard library covers a surprising amount of ground. Plain text is the obvious one, with read, readline, and readlines for reading, and write and writelines for writing. On top of that you get JSON through the json module, which both reads and writes it and can keep the order of your keys. You get CSV through csv, which supports different dialects, different quoting rules, and writing to a file. And you get binary data through struct for records with a fixed layout, and through pickle for saving whole Python object graphs.

import csv
import io
import json
import sqlite3

payload = {'name': 'Ada', 'score': 99}

# JSON
text = json.dumps(payload)
print(text)
print(json.loads(text)['score'])

# CSV
buffer = io.StringIO()
writer = csv.DictWriter(buffer, fieldnames=['name', 'score'])
writer.writeheader()
writer.writerow(payload)
print(buffer.getvalue().strip())

# SQLite, with no server to run
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE notes (body TEXT)')
conn.execute('INSERT INTO notes VALUES (?)', ('Ada',))
print(conn.execute('SELECT body FROM notes').fetchone()[0])

It prints the JSON text, then the number 99 from the round trip, then the CSV header and row, and then the name Ada from the in-memory database.

You also get a full relational database in sqlite3, which is part of the standard library and gives you SQL without installing or running a server. XML comes through xml.etree.ElementTree for parsing and xml.dom.minidom for small documents, plus xml.sax for reading a large file as a stream. Configuration in the INI format is handled by configparser. Email is a first-class citizen through the email package, which can read, change, and write messages that follow the RFC rules.

Two more are worth naming in an interview. The tarfile and zipfile modules handle archives, and pathlib gives you path handling that reads cleanly. The archive formats matter because the packaging and deployment pipelines in the Python ecosystem are built on top of them.

The formats that need a third-party package are equally worth naming, because that boundary shows you where the standard library stops. Excel files need openpyxl or xlrd. Parquet needs pyarrow or fastparquet. Working with PDF files needs pypdf or pdfplumber. YAML needs PyYAML.

Start with the measurement, because it decides everything else. The team should profile the service first, and find out whether the latency budget is really used by Python code. It might be used by something that a rewrite would not change at all, such as a database round trip, a call to another service, a lock, or a step that turns data into text. Rewriting a service that is slow because of a missing index is very expensive and buys nothing.

If Python really is the slow part, then separate the work into two kinds. Handling a request, checking the data, and applying the business rules are usually not the hot path, and they can stay in Python. A tight numeric routine or a cryptography routine can be moved into a compiled extension, a Cython module, or a native library that you call through ctypes, and you can do that without changing the way the service talks to the rest of the system. A full rewrite only makes sense when the whole workload is genuinely limited by the speed of the language runtime.

Then weigh the costs that a rewrite always brings with it. It is not only a new language. It is a second implementation to maintain, a second deployment pipeline, a second set of people on call, and a migration in which the two systems have to agree about the data while you move across. Money being handled correctly also raises the bar for testing and for rolling back.

The strongest recommendation for an interview is a staged one. Profile the service. Pull the slow part out on its own. Hide it behind the same interface it had before. And only rewrite the whole service if the measurement still asks for it after that extraction. Say that, and you sound like an engineer instead of a loyal supporter of one language.