Interview Insights · Full Stack Developer
Why Most Full Stack Developer Candidates Can't Defend Their Own Numbers
Quick summary — Resume numbers
A number on your resume is a promise that you can explain how you got it. Candidates often add percentages to look impressive, but cannot name the metric, the tool, the baseline or the cause of the improvement. That turns a strong-looking line into a credibility problem. A defendable number answers four questions: what exactly did you measure, what was it before, what did you change, and what was it after, measured the same way. This page shows how to measure API response times, database queries and page speed in a typical React and Node project, so you can write numbers you can actually defend.
In this guide you will learn:
- Why vague percentages hurt more than they help
- The four parts of a defendable performance claim
- How to time API requests in Express and read p95
- How to prove a database fix with EXPLAIN ANALYZE
- How to measure frontend speed and bundle size honestly
SECTION 01Why a resume number invites the hardest questions
When I see a percentage on a fresher resume, I do not read it as an achievement yet. I read it as a topic for questions. Which page? Which metric: time to first byte, largest contentful paint, API response time? Measured on what machine, with how much data? What was the number before and after? What caused the change?
Most candidates have no answers, because the number was estimated or borrowed from a tutorial. The problem is not that the number is small. It is that an unsupported number makes me doubt the rest of the resume. An honest 'I did not measure it formally, but here is what I changed' is safer than a number you cannot defend.
| Resume line | First question I ask | Weak reply | Defendable reply |
|---|---|---|---|
| Improved performance by 40% | Performance of what? | The whole app | Median response time of GET /api/orders |
| Reduced load time significantly | From what to what? | It felt much faster | Lighthouse LCP on the home page, before and after |
| Optimised database queries | Which query, which change? | Used indexes | Added an index on orders(user_id, created_at) |
| Handled 1000 users | Concurrent or total? Tested how? | Our app can handle it | Remove the line, or describe the load test honestly |
Q: You wrote 'improved load time by 40%'.
How did you measure that?
A: We checked it and it was faster.
Q: Which page? What was the time before?
A: I don't remember exactly. Around 5 seconds
maybe, then 3.
Q: What caused the improvement?
A: We optimised the code.
Result: the line now hurts more than it helps.Q: You wrote 'cut orders API p95 from about
800 ms to about 300 ms'. How did you measure it?
A: Locally, with a seeded database of my test
orders. I logged response times with a small
Express middleware and ran a short load test.
The slow part was a query without an index on
user_id plus a sort on created_at. EXPLAIN ANALYZE
showed a sequential scan. After adding a composite
index it used an index scan.
Caveat: local numbers, not production.
The numbers in the second answer are only an example of the format. What makes it strong is that every part can be checked: the endpoint, the tool, the cause and an honest caveat about where it was measured.
SECTION 02Measuring the backend: API timing and query plans
For backend claims, two measurements cover most cases. First, response time per endpoint. You can log it with a tiny middleware, then run a short load test to collect many samples. Report the median (p50) and a high percentile such as p95, because averages hide slow requests that users actually feel.
Second, query plans. If you claim a database optimisation, show the plan before and after. In PostgreSQL, EXPLAIN ANALYZE runs the query and reports whether it used a sequential scan or an index, plus the actual time taken. That is direct evidence an interviewer can trust.
| What to measure | Tool | What to report | Common mistake |
|---|---|---|---|
| Response time per route | Timing middleware or APM | p50 and p95 in milliseconds | Reporting one manual request |
| Behaviour under load | autocannon or k6 | Requests per second and latency percentiles | Testing with an empty database |
| Slow SQL query | EXPLAIN ANALYZE | Scan type and execution time | Adding indexes without checking the plan |
| MongoDB query | explain('executionStats') | COLLSCAN vs IXSCAN, docs examined | Ignoring documents examined vs returned |
// Logs how long each request takes (Node.js + Express)
function timing(req, res, next) {
const start = process.hrtime.bigint();
res.on('finish', () => {
const ms = Number(process.hrtime.bigint() - start) / 1e6;
console.log(`${req.method} ${req.originalUrl} ${res.statusCode} ${ms.toFixed(1)}ms`);
});
next();
}
app.use(timing);
// Short load test from the terminal:
// npx autocannon -c 20 -d 15 localhost:4000/api/orders
// autocannon prints latency percentiles, including p50 and p99,
// plus requests per second.-- PostgreSQL: before adding an index
EXPLAIN ANALYZE
SELECT id, total, created_at
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 20;
-- Look for: Seq Scan on orders ... and the
-- 'Execution Time' line at the bottom.
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at DESC);
-- Run the same EXPLAIN ANALYZE again.
-- Look for: Index Scan using idx_orders_user_created
-- and compare Execution Time with the first run.
-- Use a realistic number of rows, or the planner
-- may choose a seq scan anyway on a tiny table.
The comment about tiny tables matters. On a table with a handful of rows, PostgreSQL may correctly decide a sequential scan is cheaper. If you seed realistic data before measuring, your before and after comparison means something.
SECTION 03Measuring the frontend: page speed and bundle size
Frontend claims usually involve load time. 'Load time' is vague, so pick a defined metric. Lighthouse in Chrome DevTools reports Core Web Vitals such as Largest Contentful Paint (when the main content appears) and gives you a repeatable lab measurement. Bundle size is another clean metric, because the build tool prints it.
As with the backend, measure several runs, because lab results vary a little each time. Note the conditions: Lighthouse uses simulated throttling by default, which is different from your fast laptop connection. If you split code or compressed images, say exactly which change affected which metric.
| Claim | Metric | How to measure | Typical cause of improvement |
|---|---|---|---|
| Faster first load | Largest Contentful Paint | Lighthouse, several runs, same settings | Smaller hero image, fewer render-blocking scripts |
| Smaller app download | JavaScript bundle size | Build output from Vite or webpack | Code splitting, removing heavy libraries |
| Smoother typing in search | Requests per keystroke | Network tab while typing | Debouncing the search input |
| Fewer API calls | Request count on page load | Network tab, filter by fetch | Combining calls or caching results |
// Load the admin page only when it is visited.
// Before: imported at the top, so every user
// downloaded admin code.
import { lazy, Suspense } from 'react';
const AdminPage = lazy(() => import('./pages/AdminPage'));
// In the router, wrap it in Suspense with a fallback
// component, for example a Spinner.
// Measure: run `npm run build` before and after.
// Vite prints each output chunk with its size,
// so you can show the main chunk got smaller and
// a separate AdminPage chunk appeared.// Send one request after the user pauses typing,
// instead of one request per keystroke.
function debounce(fn, wait) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), wait);
};
}
const searchProducts = debounce(async (term) => {
const res = await fetch(`/api/products?q=${encodeURIComponent(term)}`);
setResults(await res.json());
}, 300);
// Measure: type the same word with the Network tab
// open, before and after. Count the requests.
A count of requests is a perfectly good number for a resume, as long as you describe it accurately: 'search sends one request after the user pauses typing instead of one per keystroke'. That is specific and easy to verify.
SECTION 04Worksheet: make every number on your resume defendable
Go through your resume line by line. For each number, fill in the claim sheet. If you cannot fill it in, either measure it now or rewrite the line without a number.
RESUME LINE: _____________________________
Metric (exact name): ___________________
Where measured: local / staging / prod
Tool and command: ___________________
Data used: ___________________
Before value: ___________________
Change I made: ___________________
After value: ___________________
Number of runs: ___________________
Honest caveat: ___________________
Can I explain this in 60 seconds? Y / NBEFORE -> AFTER
"Improved performance by 40%"
-> "Added a composite index on the orders query;
EXPLAIN ANALYZE showed an index scan instead
of a full table scan"
"Made the app much faster"
-> "Lazy-loaded the admin dashboard so regular
users no longer download its code"
"Handled heavy traffic"
-> "Load-tested the orders API locally with
autocannon and fixed the slowest query"PERF-NOTES.md (keep in your repo)
## Orders API
Date: ____
Command: npx autocannon -c 20 -d 15 .../api/orders
Data: seeded test orders, local Postgres
Before p50 / p99: ____ / ____
Change: index on orders(user_id, created_at)
After p50 / p99: ____ / ____
## Home page
Tool: Lighthouse, mobile preset, 3 runs
Before LCP: ____
Change: compressed hero image, lazy admin
After LCP: ____
SECTION 05Habits for honest, convincing numbers
Measured numbers are some of the strongest lines on a resume when they are done right. These habits keep them honest.
- Name the metric exactly — Say p95 latency of one endpoint or LCP of one page, not 'performance'. Precision itself shows you measured something real.
- Measure the baseline first — Before you optimise anything, record the current value with a fixed command. Without a baseline there is no improvement to claim.
- Use realistic test data — Seed enough rows to make queries behave like they would with real users. Empty databases make every query look fast.
- State where you measured — Local, staging or production numbers mean different things. Saying which one is honest and avoids awkward follow-ups.
- Drop numbers you cannot explain — A clear description of what you changed is better than a percentage you cannot defend in the interview.
SECTION 06Interview Q&A — Resume numbers
Q1Why report p95 instead of average response time?
The average hides slow outliers. If most requests are fast but some are very slow, the average still looks fine while those users have a bad experience. p95 tells you the time within which 95 percent of requests finished, so it shows the slow tail clearly.
Q2How do you know whether a query is using an index?
In PostgreSQL I run EXPLAIN or EXPLAIN ANALYZE and look for an Index Scan or Index Only Scan rather than a Seq Scan on the table. In MongoDB I use explain with executionStats and check for IXSCAN instead of COLLSCAN, and compare documents examined with documents returned.
Q3What is Largest Contentful Paint?
It is a Core Web Vitals metric for when the largest visible element, often a hero image or main heading block, finishes rendering. It is a good proxy for when the user feels the main content has loaded. Lighthouse and the browser's performance tools report it.
Q4What does code splitting do in a React app?
It breaks the JavaScript bundle into smaller chunks that load on demand. With React.lazy and dynamic import, a page like an admin dashboard is only downloaded when someone visits it, so the initial download for everyone else is smaller.
Q5How would you load test an API endpoint locally?
I seed realistic data, start the server, and use a tool like autocannon or k6 to send concurrent requests for a fixed duration. I record requests per second and latency percentiles, change one thing, and run the same test again with the same settings.
SECTION 07Test yourself — Resume numbers quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Should I put percentages on my developer resume?
Only if you measured them and can explain the metric, tool, baseline and cause. Otherwise, describe the change clearly without a number. An unsupported percentage often leads to tough questions.
How do I measure API performance in Node.js?
Log request durations with a small middleware using process.hrtime, then run a load test with a tool like autocannon or k6 against a seeded database. Report median and high percentile latencies, not one manual request.
How do I check website load time for my project?
Use Lighthouse in Chrome DevTools, run it several times with the same settings and note metrics such as Largest Contentful Paint. The Network and Performance tabs show what is slowing the page down.
What are common performance interview questions for full stack developers?
Expect questions on database indexing, N+1 queries, caching, pagination, code splitting, image optimisation, debouncing and how you would find a slow endpoint. Interviewers often ask how you measured any improvement you mention.
Is it okay to say my performance numbers are from local testing?
Yes, and it is the honest thing to do. Local measurements are still useful to show a before and after with the same setup. Just do not present them as production results.
Does Uncodemy help with Full Stack Developer interview answers?
Yes. Uncodemy's Full Stack Development Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Full Stack Developer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Learn to measure what you build
Our Full Stack Development Training Course teaches React, Node and databases with hands-on performance work, so you can measure improvements and explain them clearly in interviews.
Talk to a counsellor for current fees- API and query profiling
- Frontend performance labs
- Resume and project review
- Weekday & weekend batches