Review a Sample Python Function Aloud and Label Every Finding by Severity

You are given a short piece of existing code and asked to review it while the interviewer listens. The point is to hear how you read unfamiliar code, what you notice, and how clearly you would communicate it to the code's author. The interviewer pays particular attention to severity. Sort what you find into problems that should be fixed, things that could be improved, and stylistic preferences you would still mention, and make sure the author could tell those three apart from your words alone. The code used in the interview was not reported, so practice on the hypothetical Python function below. It is meant to return one user's profile, including their billing plan, to its callers. `db` is an open database connection that uses `?` placeholders (sqlite3 style). ```python import os import requests BILLING_URL = os.environ["BILLING_URL"] _cache = {} def get_user_profile(user_id, db): if user_id in _cache: return _cache[user_id] row = db.execute(f"SELECT * FROM users WHERE id = {user_id}").fetchone() try: resp = requests.get(BILLING_URL + "/plan/" + str(user_id)) plan = resp.json()["plan"] except: plan = "free" profile = {"id": row[0], "name": row[1], "email": row[2], "plan": plan} _cache[user_id] = profile return profile ``` ### Constraints and Clarifications - You are speaking, not only writing: narrating your reasoning is part of what is assessed. - Time is limited, so you will not comment on everything, and your prioritization will be visible. - Produce actual review comments on this function, each labeled with its tier, not only a description of how you would review. - Assume the first three columns of the `users` table are currently `id`, `name` and `email`, in that order. ### Clarifying Questions - Can `user_id` reach this function straight from a request parameter, or is it always an integer the application has already validated? - Is this function on a user-facing request path, and is it served by several threads or several worker processes? - When the billing service is slow or down, what should callers receive: an error, a profile whose plan is marked unknown, or the last plan seen? - How soon after a user changes their email or plan must this function return the new value? - Are there tests for this function, and does a linter or formatter already run on it? ### Part 1 — Reading the code aloud Talk through how you approach this function from the first minute: what you read first, how you state what it promises its callers, and what you say out loud as you go. Show how you surface assumptions and questions instead of reading in silence. ```hint Start from the contract Before any line comment, say in one sentence what a caller can rely on, then walk the function once for the normal case and once for each input or dependency that might be missing or slow. ``` #### What This Part Should Cover - Stating the function's purpose, inputs, outputs and callers before line-level detail - A narrated sequence that moves from correctness and safety toward readability - Stating assumptions and open questions explicitly, and saying how their answers would change severity ### Part 2 — Feedback with clear severity Present your findings on this function as review comments grouped into the three tiers: should be fixed, could be improved, and preference. For each comment, give the reason, the consequence of leaving the code as it is, and a suggested change, and explain the rule you use to decide which tier a finding belongs in. Close with an overall verdict for the author. ```hint Tie the tier to a consequence For each finding, picture a real request hitting that line after it ships unchanged, and ask who pays for the result; the answer usually decides the tier. ``` #### What This Part Should Cover - An explicit, defensible rule for each severity tier - Comments that are specific, actionable and tied to a consequence - Preferences labeled as preferences, not presented as requirements - A short overall verdict that tells the author what must happen next ### What a Strong Answer Covers - Prioritizes correctness, security, failure handling and resource use over style - Makes reasoning audible throughout, including uncertainty - Uses severity labels consistently so the author can triage at a glance - Recognizes specifically what the function already does well - Keeps comments about the code, never about the person ### Follow-up Questions - The author replies that billing is flaky and showing a free plan is better than failing the page. How do you respond, and does your label change? - How would your review change if this function decided which paid features a user may access? - Which of your comments could a linter or static analyzer raise automatically, and which still need a human reviewer? - The author's revision adds a time-to-live to the cache. What do you check when you review that revision?