Your resume is the syllabus: turn each line into a deep dive

Many interviewers read your resume before the round. They choose one or two lines and ask about them for ten minutes or more: "You wrote that you cut latency by 40 percent. How did you measure it? What would break at ten times the size?" A syllabus is the list of topics in an exam. Your resume is the syllabus of this exam, and you wrote it.

A weak candidate cannot explain their own lines. Their numbers do not add up, or they list tools that they never used. A strong candidate talks about one line for ten minutes: the problem, their own part, how it works, one choice, the numbers, a failure and what they would change.

Tradeoff has a mock for this. You paste your resume. Personal details such as phone numbers and links are removed first. The mock picks two lines and asks about them for about 35 minutes. The report says how convincing you were, and rewrites each line using only the facts you said.

Think of a shop sign that says "Fresh fish". A visitor walks in and asks to see the fish. If the shelf is empty, the visitor stops trusting everything else in the shop. A resume line is that sign. The interviewer walks in.

How interviewers use a resume

The interviewer picks lines that have a number or a tool they find interesting. Then they ask the same kinds of questions every time: What did you do? How does it work? What were the numbers? What did you choose, and what did you reject? What would you change? In Tradeoff's resume mock the steps are:

1. First project: what you did, how it works, the numbers, a trade-off, a failure, what you would change.
2. Second project: the same questions on your second line.
3. Make it 10x: what breaks first if it is ten times bigger.
4. Wrap-up: what you would say differently and which line you would fix.

Write a line you can defend

A good line has three parts: what you did (a verb), how (the tool or method), and a number. Compare:

• Weak: "Responsible for improving the performance of APIs using Redis (a popular program that works as a cache)."
• Better: "Cut the average response time of the product-list API from 800 ms to 480 ms by adding a Redis cache."

Rules:

• Use "built" or "led" only if it is true. If the team built the API and you added the cache, write "Added a cache to...".
• Remove tools you cannot discuss for five minutes. Every tool is a door the interviewer may open.
• One line, one claim. A line with three claims gives the interviewer three things to test.
• Avoid empty openers such as "responsible for", "worked on" and "helped". They give the interviewer nothing to ask about.

The deep-dive card

A deep dive is a long, detailed look at one part. For each important line, write one card. It should let you talk for ten minutes. A baseline is the number before your change.

Numbers that add up

Interviewers check numbers in their head. Three checks:

1. A percent is a percent of what? "Reduced cost by 50 percent" needs a before and an after, in rupees, over a period.
2. An average is not a percentile. "Latency 200 ms" can be an average. The slowest users may wait longer. Say which number it is (lesson 4: p95 is the time that 95 of 100 requests are as fast as, or faster than).
3. A rate times a time. "1,000,000 requests" a day is 1,000,000 / 86,400 seconds = 11.6 requests per second (lesson 30). "10,000 records in 2 minutes" is 10,000 / 120 = 83 records per second.

The mock's report marks numbers that do not add up with a flag.

Be honest

Say what you did not own: "The API was built before I joined. I changed the cache part." If you are asked the same number twice, give the same number. Never invent one. "I am not sure" is a good answer. The mock's report scores "Honesty about limits", and it treats an honest limit as a good sign.

Freshers

A project is worth a line when four things are true:

• it has real users or real data (even 20 users in your hostel),
• you made a choice between options,
• you measured one number,
• the code runs, and you can open it and explain it.

For a hackathon, say what you built in the time and which part was yours. For an internship, say your task and what shipped.

A 20-minute exercise

1. Pick two lines (2 minutes).
2. Write a card for each (10 minutes).
3. Say aloud your answers to five questions (8 minutes): What did you personally build? How did you measure it? What did you reject, and why? What went wrong? What breaks at ten times the size?

The line is "Reduced API latency by 40 percent with caching." All numbers are Assumptions.

Before the cache, almost every request took about 800 ms. So the average and the p95 were both about 800 ms. A cache hit takes 20 ms. A miss takes 800 ms, the same as before. A cache (lesson 57) keeps copies of answers so that repeat requests are fast. The hit rate is the share of requests that the cache answers.

Average after = hit rate x 20 + (1 - hit rate) x 800.

How to read it:

• At 41 percent: 0.41 x 20 + 0.59 x 800 = 8.2 + 472 = 480.2 ms. The cut is (800 - 480.2) / 800 = 40 percent. So "40 percent" fits the average when the hit rate was about 41 percent.
• The p95 stays at 800 ms while more than 5 percent of requests miss. At a hit rate of 41 percent and of 70 percent, 59 percent and 30 percent miss, so the slowest 5 percent are all misses.
• The p95 falls only when 5 percent or fewer miss. At a hit rate of 96 percent, 4 percent miss. The 95th request of 100, from the fastest, is a hit, so p95 is 20 ms. That is a cut of 97.5 percent, not 40 percent.

So the interviewer asks two questions: "40 percent of what: the average or the p95?" and "What was the hit rate?" This answers the predict box. In this simple model, a 40 percent cut of the p95 cannot come from a cache alone. If a candidate says it did, the interviewer asks what else changed. Real systems have more spread than two speeds, but the questions still apply.

The card says which number the claim means. The line becomes: "Cut the average response time of the product-list API from 800 ms to 480 ms (40 percent) with a Redis cache. The cache answered 41 percent of requests, and the p95 stayed near 800 ms."

The 10x check, with Assumptions: peak traffic is 30 requests per second, and the database can run 100 of these slow queries per second.

• Now: misses = 0.59 x 30 = 17.7 per second. This is below 100.
• At 10 times: traffic is 300 per second, and misses = 0.59 x 300 = 177 per second. This is above 100. The database breaks first.
• With a 90 percent hit rate: misses = 0.1 x 300 = 30 per second. This is fine.

So "what I would change" is the hit rate, not a bigger database.

• A card for each line solves the freeze when an interviewer asks about it. It also finds weak lines before the interviewer does. It costs about 10 minutes for each line. I would rewrite the card when the resume changes, or when a number cannot be explained.
• Numbers in a line solve vague claims and give the interviewer something to check. They cost that every number can be tested. I would remove a number that I cannot explain.

"More lines and more tools impress more." Every line is a door the interviewer may open. A tool you cannot discuss costs you more than it gives. Five lines you can defend are better than fifteen you cannot.

"I should round a number up to look better." Interviewers ask for the number twice, in different ways. A number that changes loses trust. "About 40 percent" is fine if it is true.

"On a team project I can say 'I built' for everything." The interviewer then asks what you did, and your real part looks small. Say your part and the team's part.

1. Name the three checks for numbers that add up.
2. A resume says "Handled 2,000,000 requests a day." How many requests per second is this on average? Assumption: the busiest time has 5 times the average. How many requests per second is that?
3. The interviewer asks about a message queue that is on your resume, but you used it only in a tutorial. What do you do before the interview, and what do you say if asked?