#1 India's Top IT Training Institute

×

About Uncodemy

Know more about who we are and what we stand for.

About Us

About Us

Discover our mission to equip individuals with essential IT skills and industry expertise.

Read More →
UnCodeMy Gallery

UnCodeMy Gallery

Explore highlights from our IT training sessions and success stories.

Read More →
×

Free Resources

Learn, practice and plan your career — bilkul free.

Tutorials

Tutorials

Step-by-step written tutorials to learn any technology at your own pace.

Read More →
Free Counselling

Free Counselling

Book a free video counselling session and pick the right course for you.

Read More →
Online Compiler

Online Compiler

Write, run and test your code online — no setup required.

Read More →

Interview Insights · Full Stack Developer

Why Most Full Stack Developer Candidates Can't Defend Their Own Numbers

'Improved page load time by 40%' looks great on a resume until I ask how you measured it. Most candidates cannot say. Here is what I expect behind every number, and how to measure your own full stack project so your claims hold up.

Tracks
Defend the Number · Live Interactive
Resume claim
—
The number written
I ask
—
The first follow-up
Answer shows
—
How solid the claim is
Baseline→Change→Re-measure→Explain
Click a claim to see the follow-up question I ask and what each kind of answer reveals.

Home / Tutorials / Career Guides / Why Most Full Stack Developer Candidates Can't Defend Their Own Numbers

Interview Insights · Full Stack Developer

Why Most Full Stack Developer Candidates Can't Defend Their Own Numbers

METRICBASELINECHANGEAFTERWhat exactly?API p95, LCPBundle KBDefineBeforeSame tool, dataSeveral runsMeasureWhat you didIndex, cacheCode splitFixRe-measureSame setupHonest resultProve
A defendable number has four parts: what you measured, the baseline, the change you made, and the measurement after the change.

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:

  1. Why vague percentages hurt more than they help
  2. The four parts of a defendable performance claim
  3. How to time API requests in Express and read p95
  4. How to prove a database fix with EXPLAIN ANALYZE
  5. 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 lineFirst question I askWeak replyDefendable reply
Improved performance by 40%Performance of what?The whole appMedian response time of GET /api/orders
Reduced load time significantlyFrom what to what?It felt much fasterLighthouse LCP on the home page, before and after
Optimised database queriesWhich query, which change?Used indexesAdded an index on orders(user_id, created_at)
Handled 1000 usersConcurrent or total? Tested how?Our app can handle itRemove 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.
defend-the-number.txt

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.

Key insight: Interviewers do not need big numbers. They need true numbers with a method behind them. A small, measured improvement with a clear cause beats a large, unexplained percentage every time.

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 measureToolWhat to reportCommon mistake
Response time per routeTiming middleware or APMp50 and p95 in millisecondsReporting one manual request
Behaviour under loadautocannon or k6Requests per second and latency percentilesTesting with an empty database
Slow SQL queryEXPLAIN ANALYZEScan type and execution timeAdding indexes without checking the plan
MongoDB queryexplain('executionStats')COLLSCAN vs IXSCAN, docs examinedIgnoring 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.
measure-backend.js

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.

Remember: Always measure before and after with the same data, the same machine and the same command. If anything changed between runs, say so. Consistency is what makes a number defendable.

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.

ClaimMetricHow to measureTypical cause of improvement
Faster first loadLargest Contentful PaintLighthouse, several runs, same settingsSmaller hero image, fewer render-blocking scripts
Smaller app downloadJavaScript bundle sizeBuild output from Vite or webpackCode splitting, removing heavy libraries
Smoother typing in searchRequests per keystrokeNetwork tab while typingDebouncing the search input
Fewer API callsRequest count on page loadNetwork tab, filter by fetchCombining 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.
measure-frontend.js

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.

Pro move: Keep a small performance notes file in your repository with the date, command, before value, change and after value. If an interviewer asks, you can open it and show your method.
How Uncodemy helps: At Uncodemy, the Full Stack Development Training Course in Noida builds this into the batch: you practise Full Stack Developer interview answers in live mock interviews with trainers, get feedback on every answer, and work on real projects you can explain with confidence.

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 / N
defendable-numbers.md

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.
Pro tip: Before every interview, pick one number from your resume and rehearse the full story: metric, tool, baseline, change, after value and caveat. A mock interview with an Uncodemy trainer is a good place to test whether that story holds up under follow-up questions.

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 / 5

Pick 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.

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