Honest Numbers: Measuring and Quantifying Student Projects

"Quantify your achievements" is the most repeated resume advice there is. For a fresher it creates a trap. Your project has no revenue, a handful of users and no production traffic. So people reach for numbers that sound good: "improved performance by 60%", "handled 10,000 users", "99.9% uptime". The interviewer asks one question ("how did you measure that?") and the number collapses, taking your credibility with it.

There is a better way. Student projects can produce many real numbers. You just have to measure them on purpose.

• Which kinds of numbers a student project can honestly report.
• How to measure each one so that it survives a follow-up question.
• Why medians and percentiles beat averages, with a short program.
• The X-Y-Z pattern for turning a measurement into a resume bullet.
• How to use AI to shape bullets without letting it add numbers.

What you cannot honestly report: users you do not have, uptime you never monitored, "scalability" you never tested, or a percentage improvement against a baseline you never measured.

Every number needs four things you can say out loud:

1. The tool. "I used k6", "I used EXPLAIN ANALYZE in PostgreSQL", "I timed it with a script".
2. The conditions. Your laptop or a server, what data, which endpoint, how many concurrent users.
3. The sample size. One run tells you almost nothing. Twenty or more requests tell you something.
4. The summary statistic. Median, 95th percentile, or a count.

"Median response time of 15 ms over 200 requests on my laptop, with 10,000 seeded rows" survives any follow-up question. "Fast" does not.

Response times have outliers: the first request after start-up, a garbage-collection pause, a background task. One slow outlier drags an average up a lot, and a single best run is just luck. The median (the middle value) tells you what a typical request experiences. The 95th percentile (p95) tells you what the slowest one-in-twenty experiences, which is what users notice.

This program summarises recorded response times. The data is a sample for illustration: 20 requests before and after adding a database index.

# File: latency_summary.py# Summarise response times you recorded (in milliseconds).# The two lists are sample data for illustration: 20 requests each,# measured before and after adding a database index.import statisticsbefore = [412, 398, 405, 420, 391, 388, 1450, 402, 415, 399,          410, 395, 401, 407, 390, 404, 396, 409, 1380, 403]after = [16, 14, 15, 17, 13, 15, 210, 14, 16, 15,         15, 14, 13, 16, 15, 14, 15, 17, 198, 16]def percentile(values, p):    """Nearest-rank percentile: the value below which p% of samples fall."""    ordered = sorted(values)    rank = max(1, round(p / 100 * len(ordered)))    return ordered[rank - 1]def summary(name, values):    print(f"{name:<7} n={len(values)}  median={statistics.median(values):.0f} ms  "          f"p95={percentile(values, 95)} ms  mean={statistics.mean(values):.0f} ms")summary("before", before)summary("after", after)change = 1 - statistics.median(after) / statistics.median(before)print(f"median improvement: {change:.0%}")

before  n=20  median=404 ms  p95=1380 ms  mean=504 msafter   n=20  median=15 ms  p95=198 ms  mean=34 msmedian improvement: 96%

Look at the "before" line: two slow outliers push the mean to 504 ms although a typical request took about 404 ms. The median is the honest headline; the p95 shows the outliers are still there after the change (198 ms), which is a good follow-up topic in an interview: "What causes the slow tail?"

A load test sends many requests at once to see how your service behaves. Two rules:

• Test your own machine or your own paid resources. Sending heavy load to a free hosting tier can break the provider's terms and get your account suspended, and it measures their throttling, not your code. Run the service locally (or in a container with fixed CPU and memory) and load test that.
• Report the conditions. "On a laptop with 8 GB RAM, the API served 150 requests per second with a p95 under 200 ms at 50 concurrent users" is honest. "Handles 10,000 users" is not.

An illustrative fragment of a k6 test script, to show what one looks like (k6 scripts are written in JavaScript):

import http from "k6/http";export const options = { vus: 50, duration: "60s" };export default function () {  http.get("http://localhost:8080/api/events?page=1");}

The tool prints the median, p95 and requests per second at the end. Copy that summary, with the conditions, into your README.

For a query you improved (an index, a rewritten join), use your database's query-plan tool before and after. In PostgreSQL, EXPLAIN ANALYZE runs the query and shows the time and whether an index was used. Seed enough data to make the difference real: on 50 rows, everything is fast. Run each version several times and report the median.

For anything that classifies or extracts (a transaction categoriser, a resume parser), label a sample by hand, say 100 items, and count how many your program gets right. Report it with the sample: "92 of 100 hand-labelled transactions categorised correctly". Also note what it gets wrong; it makes an excellent interview discussion.

GitHub shows repository owners recent traffic (views and clones) under the repository's Insights. Use these numbers with care. Clones include automated tools, views include your own visits, and the window is short. "Viewed by 400 people" is rarely accurate; if you mention traffic at all, say exactly what the page shows, or leave it out. Real usage is a stronger signal than page views.

A widely used pattern for achievement bullets is: accomplished X, as measured by Y, by doing Z.

• X is the outcome.
• Y is the number, with enough context to be checkable.
• Z is what you did, which is the part that shows skill.

If a bullet has no honest number, use impact without a number: "Made booking cancellations safe to retry, so a timeout no longer creates duplicate bookings." That is far better than an invented percentage.

Assistants are good at tightening wording and very willing to add impressive figures. Give it your numbers, forbid additions, and check the output.

Turn these measured facts into 3 or 4 resume bullets using the pattern"accomplished X, as measured by Y, by doing Z". Rules:- Use ONLY the numbers below, exactly as given. Do not round them up,  combine them into new percentages, or add any number.- If a fact has no number, write an impact bullet without a number.- Under 25 words each. Start with a strong past-tense verb.- After the bullets, list any word you used that I might not be able to defend  in an interview (for example "scalable", "robust").Facts:- Search endpoint: median 404 ms before, 15 ms after a composite index on  (title, event_date); 200 requests; 10,000 seeded rows; my laptop.- 34 tests added; branch coverage of booking module 41% to 86% (JaCoCo).- Cancellation endpoint is idempotent: retrying with the same key returns  the original result.

How to check it: compare every number in the output against your facts. If the assistant wrote "a 96% reduction", it calculated a new figure: fine if it is correct and you can explain it, but check the arithmetic. If it wrote "for thousands of users", delete it.

Numbers go stale as you change your code. Before an interview, spend half an hour re-running your main measurements and checking that the README and resume match. If an interviewer opens your repository during the call, your numbers should be reproducible from it.

• Averages from a handful of runs, which outliers and luck distort.
• Percentages without a baseline. "60% faster" than what, measured how?
• Load testing someone else's free servers.
• Counting page views as users.
• Accepting numbers an assistant added. If you did not measure it, it does not go in.

## ResultsSearch endpoint (GET /api/events?q=...), measured with k6 on my laptop(Ryzen 5, 16 GB RAM), PostgreSQL 16 locally, 10,000 seeded events,200 sequential requests:- Before composite index on (title, event_date): median 404 ms, p95 1380 ms- After: median 15 ms, p95 198 msSlow tail still under investigation (likely first-request warm-up).

• Next: The ATS-Friendly Fresher Resume: How Screening Really Works puts your proof and numbers onto one page.
• For estimating load and capacity in design interviews, see Back-of-the-Envelope Estimation: From Users to Peak QPS.
• For how indexes speed up queries, see Database Indexes and Query Performance: How to Make Reads Fast.