The Experience-Level Round

Earlier lessons covered the tools. This one covers you. The round has many names: "experience round", "manager round", "hiring-bar round", "behavioural round". The questions are about your past work and about how you think when a problem is open. The people who fail it are usually not weak engineers. They tell vague stories, say "we" for everything, never mention numbers, or start coding before they ask a question.

For decision stories at a larger scale (rewrite or refactor, build or buy, zero-downtime migrations) read Debugging, Lesson 14. For incident handling read Production Incidents. This lesson keeps the examples short and full-stack flavoured.

What changes between junior, 4+ years and senior

One public rubric from large companies says the same thing: junior stories are about your own tasks, senior stories are about a team (often three or more people), and staff stories are about several teams. At 4+ years, the safest story size is "a feature or system that I owned, that affected my team and users, with a number as proof."

What the interviewer is really scoring, in plain words:

• Ownership: did you see it through to production and afterwards, or stop at "merged"?
• Judgement: did you weigh options and know what you gave up?
• Debugging skill: do you measure first, then guess?
• Communication: can you explain it so a non-expert follows?
• Learning: what would you do differently now?
• Collaboration: can you disagree without a fight, and can you say no politely?

How to tell a story: STAR with numbers

STAR stands for Situation, Task, Action, Result. It is a way to order a story so it does not wander.

1. Situation (1 or 2 sentences): where and when, and why it mattered.
2. Task: what you were responsible for.
3. Action (the longest part, about half of your time): what you did, step by step, and why. Say "I", not "we". If a team did it, say which part was yours.
4. Result: a number, if possible (time, money, errors, users). Then what you learned or would change.

Rules that help:

• Prepare five stories and reuse them. One story can answer many questions: for example "the checkout outage" can be a hard bug, an outage, a mistake and a lesson about monitoring.
• Front-load the result. Start with "We cut the dashboard load time from 6 s to 1.2 s" and then explain how. If the interviewer interrupts, they already heard the result.
• Be honest. Do not invent numbers. If you do not remember, say "about" and give a range. A small true story beats a big false one, and interviewers ask follow-up questions until the false one breaks.
• Say what went wrong. A story with no mistake sounds untrue. Say your mistake in one clear sentence, then what you changed.
• Keep it under two minutes, then stop and let them ask.

The nine classic questions, with example answers

The model answers are in the Interview questions section below. They are examples: generic, realistic and full-stack flavoured. Use them to learn the shape, then replace the details with your real story. These are the nine:

1. A hard bug you solved.
2. An outage or production incident.
3. A technical trade-off you made.
4. A disagreement with a teammate.
5. Mentoring someone.
6. An estimate that was wrong (or how you estimate).
7. A time you said no.
8. Tech debt.
9. Improving performance, with numbers.

Live coding and take-home tasks for full-stack roles

Live coding means you write code while someone watches, usually for 45 to 60 minutes. A take-home is a small project you do alone at home, usually for two to four hours, and send back.

Live coding tips

1. Repeat the problem and ask 2 or 3 questions before you type. "What is the input size? What should happen on bad input? Do you want it to work, or to be production-ready?" Not asking questions is the most common pitfall.
2. Say your plan in one minute, then start with the simplest version that works. Make it correct, then make it clean, then fast if needed.
3. Think aloud. The interviewer cannot see your thoughts. Say "I will use a Map here because I need lookup by id".
4. Run the code early and often. A small working piece beats a big broken one.
5. Test with your own examples, including an empty input and a bad input. Say the cases out loud.
6. If you are stuck, say what you tried and what you think the cause is. Ask for a hint without shame. A hint costs less than silence.
7. Know your tools: your editor, the test runner, how to read a stack trace. For full-stack tasks, the usual shapes are: build a small REST endpoint with validation, then a React component that uses it with loading and error states.

Take-home tips

• Read the brief twice and write down what is out of scope. Send one short clarifying email if something is truly unclear.
• Do less, but finish it. A small app that runs with one command beats a big one with missing parts. Add a short README: how to run, what you built, what you skipped on purpose, and what you would do next.
• Show the basics: input validation, error handling, a few meaningful tests (not 100 shallow ones), types, clear commit messages, no secrets in the repo.
• Do not over-engineer. Microservices, a message bus and three state libraries for a to-do list make reviewers worry about you, not admire you.
• Keep to the time limit they gave. If you spent more, say so. Mention trade-offs in the README, because the follow-up interview will often be a code walk-through of your own task.

System-design-lite prompts for 4+ years

Full system design (millions of users, sharding) is for senior roles. At 4+ years you get "system-design-lite": one feature, one team, a normal database, with a few thousand to a few hundred thousand users. They want a clear structure and good questions, not a perfect diagram. See also the frame in How to Run a Practical Design Interview.

Use this order:

1. Clarify (users, the main flows, size, what is out of scope).
2. Data model (tables or collections, main fields, indexes).
3. API (endpoints, request and response, errors, pagination).
4. Main flow (what happens on the server and in the UI).
5. Problems at scale and failure (slow queries, duplicates, retries, permissions).
6. Trade-offs and what you would do first.

Prompt A: a dashboard with filters and CSV/Excel export

• Clarify: how many rows (thousands or millions)? How fresh must the data be? Who may see which rows? Is the export small enough to download at once?
• Data and API: GET /reports?from&to&status&cursor&limit with server-side filtering and paging (see Cursor pagination). Put indexes on the columns used in filters. Put filters in the URL so links can be shared and the back button works.
• UI: debounce text filters, cancel older requests, keep the previous data visible while loading (no flicker), show an empty state and an error state.
• Export: small (under a few thousand rows) can be a streamed response. Large exports are a background job: POST /exports returns 202 with an id, a worker builds the file and stores it, the UI polls or gets a notification, and the user downloads from a time-limited link. Stream the rows to the file instead of loading all into memory.
• Gotchas: check permissions in the export too (a common leak), escape cells that begin with =, +, - or @ (CSV formula injection), keep the same filters in the export as on screen, and use the same query code for both.

Prompt B: a comments system (with replies)

• Clarify: only top-level comments, or replies? Edit and delete? Moderation? Mentions? Real-time updates?
• Data: comments(id, postId, parentId nullable, authorId, body, createdAt, deletedAt). Index (postId, createdAt). Limit nesting to one or two levels in the UI; deep trees are hard to read and to query.
• API: GET /posts/:id/comments?cursor returns top-level comments with a few replies, and GET /comments/:id/replies?cursor loads more. POST needs authentication, a length limit and rate limiting. Use soft delete (keep the row, hide the body) so replies stay attached.
• Safety: treat the body as text and escape it on output; if you allow markdown, sanitize the HTML. Add spam control (rate limits, links limit, report button).
• Freshness: start with refetch on focus or a manual refresh; add SSE for live updates only if needed. Optimistic UI for the author's own comment.
• Counts: keep a commentCount on the post or compute it with a cached query; do not COUNT(*) on every page view.

Prompt C: notifications

Details are in Design a Notification System. The short structure: an event happens (someone replied), a notification record is created for each recipient (userId, type, payload, readAt, createdAt), and delivery channels (in-app, email, push) are separate jobs on a queue with retries. The user can set preferences per channel. In-app: a bell with an unread count (GET /notifications?cursor, POST /notifications/read), updated by polling or SSE. Watch out for: duplicates (use a unique key such as type + entity + recipient), spam (group "5 new comments"), and sending email inside the HTTP request, which makes the request slow and unreliable.

Prompt D: a file import (CSV with 100,000 rows)

• Clarify: file size, columns, what to do with bad rows (reject all, or import good ones and report bad ones), can the user import the same file twice?
• Flow: upload the file straight to object storage with a pre-signed URL (Design File Upload), then POST /imports with the file key. A worker streams the file, validates each row with a schema, and writes in batches (for example 500 rows per insert) inside short transactions.
• Idempotency: use a natural key (email, SKU) with an upsert, so a retry or a second upload does not create duplicates.
• Feedback: an imports record with status, total, processed, failed; the UI shows progress; a downloadable error report lists row number and reason.
• Failure: the worker can crash midway, so save progress (last processed row) and make the job resumable. Limit file size and rows. Treat the file as untrusted (formula injection, encoding, huge cells).

Code-review exercise

Many companies show you a short, flawed snippet and ask "review this like a pull request". They want to see a sensible order (security and correctness first, then performance, then style), clear comments with reasons, and kindness. Try to find the problems yourself before you read the list.

// server.jsconst express = require('express')const jwt = require('jsonwebtoken')const cors = require('cors')const app = express()app.use(cors())app.use(express.json())app.post('/api/login', async (req, res) => {  const user = await User.findOne({ email: req.body.email, password: req.body.password })  const token = jwt.sign({ id: user._id }, 'secret123')  res.json({ token, user })})app.get('/api/orders', async (req, res) => {  const orders = await Order.find({ userId: req.query.userId })  for (const o of orders) {    o.customer = await User.findById(o.customerId)  }  res.json(orders)})app.put('/api/orders/:id', async (req, res) => {  await Order.findByIdAndUpdate(req.params.id, req.body)  res.send('ok')})app.listen(3000)

// Orders.jsxfunction Orders({ userId }) {  const [orders, setOrders] = useState([])  useEffect(() => {    fetch(`/api/orders?userId=${userId}`)      .then(r => r.json())      .then(setOrders)  })  return (    <div>      {orders.map((o, i) => (        <div key={i} dangerouslySetInnerHTML={{ __html: o.note }} />      ))}    </div>  )}

What to point out, in a good order

Blockers (must fix before merge):

1. Passwords compared in plain text in the login query (password: req.body.password). Passwords must be stored as a slow hash (bcrypt, scrypt or argon2) and compared with the library's compare function.
2. Query injection risk. With MongoDB, a body like {"email":"a@b.co","password":{"$ne":null}} is an operator, not a string, and can match any password. Validate that the fields are strings (a schema such as Zod) before querying. See Validation at the Edge.
3. Wrong login crashes. If no user matches, user is null and user._id throws. I ran the same shape on Express 5: the client gets a 500 HTML page that includes the stack trace outside production. It should be 401 with a generic message, the same for "no such user" and "wrong password".
4. Hard-coded secret and no expiry in jwt.sign(..., 'secret123'). Read the secret from the environment, and set expiresIn (short, for example 15 minutes). Also the token is never checked anywhere: there is no auth middleware at all.
5. The user object is sent back, probably including the password hash. Return only the fields the client needs.
6. IDOR (insecure direct object reference): GET /api/orders?userId=... trusts the id from the client, so anyone can read anyone's orders. Take the user id from the verified token.
7. PUT has no ownership check and allows mass assignment. Anyone can edit any order, and req.body can set userId, total or status. Check that the order belongs to the caller (403 otherwise), and accept only a whitelist of fields.
8. React: useEffect without a dependency array runs after every render, and the fetch sets state, which renders again, so it loops forever. I tested the same shape: more than ten requests in two seconds. Add [userId].
9. dangerouslySetInnerHTML with server data is stored XSS. Render {o.note} as text, or sanitize the HTML.

Should fix:

10. N+1 queries in the loop: one extra query per order. Fetch all customers in one query ($in, include, or a lookup). See Prisma in Production.
11. No pagination or limit on the list. No validation on params and query. No 404 when the order does not exist.
12. cors() with no options allows every origin. Use an allow-list.
13. No error handling in the React fetch: no r.ok check, no loading state, no error state, and no abort of old requests (a race condition when userId changes).
14. key={i} (index as key) causes wrong updates when the list changes. Use o.id.

Nice to have: res.send('ok') should be JSON with the updated order, use async error handling (Express 5 forwards rejected promises to the error handler, Express 4 does not), add tests for the permission rules, and log with a request id.

I wrote a fixed version of the server and ran it with in-memory fakes. A wrong password gave 401; an operator object as the password gave 400; no token gave 401; the list used the id from the token and loaded customers in one query; a body with userId and total gave 400; a valid { "status": "paid" } gave 200; and another user's token gave 403. The key pieces:

const Login = z.object({ email: z.email(), password: z.string().min(1) })app.post('/api/login', async (req, res) => {  const body = Login.safeParse(req.body)  if (!body.success) return res.status(400).json({ error: 'invalid_input' })  const user = await db.userByEmail(body.data.email)  const ok = user && (await bcrypt.compare(body.data.password, user.passwordHash))  if (!user || !ok) return res.status(401).json({ error: 'invalid_credentials' })  const token = jwt.sign({ sub: user.id }, JWT_SECRET, { expiresIn: '15m' })  res.json({ token, user: { id: user.id, name: user.name } })})const Patch = z.object({ status: z.enum(['new', 'paid', 'shipped']) }).strict()app.put('/api/orders/:id', auth, async (req, res) => {  const order = await db.order(String(req.params.id))  if (!order) return res.status(404).json({ error: 'not_found' })  if (order.userId !== (req as any).userId) return res.status(403).json({ error: 'forbidden' })  const body = Patch.safeParse(req.body)  if (!body.success) return res.status(400).json({ error: 'invalid_input' })  Object.assign(order, body.data)  res.json(order)})

useEffect(() => {  const ctrl = new AbortController()  fetch('/api/orders', { headers: { authorization: `Bearer ${token}` }, signal: ctrl.signal })    .then(r => { if (!r.ok) throw new Error(`HTTP ${r.status}`); return r.json() as Promise<Order[]> })    .then(setOrders)    .catch(e => { if (e.name !== 'AbortError') setError(e.message) })  return () => ctrl.abort() // cancel the old request when token changes or the component unmounts}, [token])

Pitfalls that cost offers

• Over-engineering. Proposing queues, caches and microservices for a problem with 500 users. Start simple and say when you would add more ("if exports grow past 50,000 rows, I would move them to a job").
• Not asking questions. Jumping into code or a diagram without clarifying. Ask two or three, state your assumptions, and move on.
• Saying "we" for everything, so the interviewer cannot see your part.
• No numbers. "It was faster" is weak. "p95 went from 2.4 s to 600 ms" is strong.
• Blaming others, or no mistakes in any story.
• Rambling. Stories over three minutes. Practise with a timer.
• Knowing tools but not reasons. "I used Redis" with no answer to "why, and what if it was down?".
• Arguing with the interviewer. Disagree with facts and calm; accept a hint.
• Hiding what you do not know. Say "I have not used that; I would approach it like this" and show your thinking.

Questions to ask the interviewer

At the end you are almost always asked "do you have questions?". Having none looks like you are not interested. Good questions show what you care about, and they help you learn if the job is good. Pick four or five:

• What is the biggest technical challenge the team faces now?
• What was the worst production incident in the last year, and what changed afterwards?
• What is the most expensive early technical decision you are still living with?
• How does the team balance new features and maintenance (tech debt)?
• What would you want the person in this role to solve in the first three months?
• How do code review, testing and deployment work here? How often do you deploy?
• How are on-call and incidents handled? Is there a post-incident review without blame?
• What does growth look like here, and how is performance judged?
• Who would I work with most closely, and how do product and design work with engineers?

Level and salary conversation basics

Keep this short and calm.

• Know the level before you talk about money. A title like "Software Engineer II" or "Senior" means different things at different companies. Ask how the company defines the level and what scope it expects. Many companies call roughly 2 to 5 years "mid" and 5+ years "senior", but the scope matters more than the years.
• Know the market. Look at pay ranges for your city, level and stack (public salary data, job posts that list a range, people you know). A range is more useful than one number.
• Do not give your current salary first. Say "I am looking for a role in the range of X to Y for this scope". If the law or the form asks for it, answer honestly, but you can say what you are targeting.
• Think in total pay: base, bonus, equity, benefits, leave, learning budget, remote policy, notice period. Get the offer in writing.
• Negotiate once, with reasons, after you have an offer: your scope, market range and other options. Be polite and keep the door open. A "no" on one item can become a "yes" on another (sign-on bonus, review date, level).
• Do not accept or refuse in the call. Say thanks and ask for a day or two.

Interview questions

The answers are examples written in the first person. The numbers are made up to show the shape. Replace them with your own true story.

Key takeaways

• At 4+ years you are judged on ownership, judgement, debugging, communication and collaboration, with stories about a feature you owned and a number to prove it.
• Use STAR: situation, task, action (about half), result with a number and a lesson. Say "I", be honest, and keep it under two minutes. Prepare five reusable stories.
• In live coding: ask questions first, think aloud, run early, test your own cases. In a take-home: finish a small thing well, with a README.
• For system-design-lite use one order: clarify, data, API, main flow, scale and failure, trade-offs. Keep it simple and say when you would add more.
• In a code review put security and correctness first (auth, injection, IDOR, mass assignment, XSS), then performance (N+1, pagination), then style. Explain every comment and label its weight.
• Avoid over-engineering, silence instead of questions, "we" for everything and blame.
• Ask good questions at the end. For pay: know the level, know the range, think in total pay, negotiate once, and get it in writing.

What's next

You have reached the end of the Full-Stack Interview Questions series. Go back to Lesson 0 for the map of all topics and mark the areas where your stories are weakest. Then practise out loud: five stories, two system-design-lite prompts and one code review, each with a timer.