MERN Stack Interview Questions

Using JavaScript everywhere means developers don't need to context-switch between different languages for the frontend and backend, and code, data structures like JSON, and even some logic can be shared between the client and server. It also simplifies hiring and onboarding, since a full-stack MERN developer only needs deep expertise in one core language.

MongoDB stores application data as flexible, JSON-like documents. Express.js is a lightweight web framework running on Node.js that handles routing and API endpoints. React renders the user interface in the browser. Node.js is the JavaScript runtime that lets Express and the rest of the backend run outside a browser, on a server.

A user interacts with the React frontend, which sends an HTTP request (usually via fetch or Axios) to an Express.js API endpoint. Express processes the request, often querying MongoDB through Mongoose, and sends a JSON response back. React then updates its state with that response, re-rendering the UI to reflect the new data.

Express.js is a minimal web framework for Node.js that simplifies building APIs and web servers. It adds routing, middleware support, and request/response handling utilities on top of Node's built-in HTTP module, which would otherwise require much more boilerplate code to achieve the same functionality.

Mongoose is an Object Data Modeling (ODM) library for MongoDB and Node.js. It lets developers define schemas with defined fields and types for their MongoDB collections, which MongoDB itself doesn't enforce natively, and it provides convenient methods for querying, validation, and middleware hooks around database operations.

A basic Express server is created by importing Express, calling the express() function to create an app instance, defining routes, and calling listen() to start the server. ```javascript const express = require('express'); const app = express(); app.get('/', (req, res) => res.send('Hello World')); app.listen(3000, () => console.log('Server running')); ```

Using Mongoose, you connect with a connection string pointing to your MongoDB instance. ```javascript const mongoose = require('mongoose'); mongoose.connect('mongodb://localhost:27017/mydb'); ``` Once connected, Mongoose models can be used throughout the app to query and modify data in that database.

A REST API exposes endpoints organized around resources, using HTTP methods like GET, POST, PUT, and DELETE to represent different actions on those resources. In a MERN app, Express defines these REST endpoints, and React's frontend calls them to fetch or modify data, keeping the frontend and backend cleanly separated.

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks web pages from making requests to a different domain or port than the one that served the page, unless the server explicitly allows it. Since a React dev server and an Express API often run on different ports during development, the Express server needs CORS middleware configured to allow those cross-origin requests.

React components typically use the Fetch API or a library like Axios inside a useEffect hook to call the backend when the component mounts. ```javascript useEffect(() => { fetch('/api/users') .then(res => res.json()) .then(data => setUsers(data)); }, []); ```

Middleware is a function that has access to the request and response objects and runs during the request-response cycle before the final route handler. It's used for tasks like logging, parsing request bodies, authentication checks, or error handling, and multiple middleware functions can be chained together.

It's middleware that parses incoming request bodies, typically JSON, and makes the parsed data available on req.body. Modern Express versions include this built in through express.json(), so a React app sending JSON in a POST request can have that data read easily on the server side.

State is data a component manages internally and can change over time, often holding data fetched from the Express API. Props are data passed down from a parent component, used to pass fetched data or callback functions between components without each one independently calling the API.

On the backend, Node.js commonly uses the dotenv package to load sensitive values like database connection strings and API keys from a .env file into process.env. On the frontend, React (with Create React App or similar tooling) supports environment variables prefixed with REACT_APP_, which get baked into the build at compile time.

JSON (JavaScript Object Notation) is a lightweight, text-based data format that maps naturally to JavaScript objects. Since MongoDB stores data in a JSON-like format (BSON), Express sends JSON responses, and React consumes JSON data, using one consistent data format throughout the stack avoids constant conversion between different formats.

npm (Node Package Manager) installs and manages third-party JavaScript packages. In a MERN project, it's used on the backend to install packages like express and mongoose, and on the frontend to install React and its supporting libraries, each side typically having its own package.json listing its specific dependencies.

A GET request retrieves data without modifying anything on the server, commonly used to fetch a list of records or a single item. A POST request sends data to the server to create something new, like submitting a form to add a new record, and its payload is sent in the request body rather than the URL.

A schema defines the shape of documents in a collection, and a model is the interface used to interact with that collection. ```javascript const userSchema = new mongoose.Schema({ name: String, email: String }); const User = mongoose.model('User', userSchema); ``` The model, User, is then used to create, read, update, and delete documents.

useState declares a piece of local state, commonly used to hold the data returned from an API call so the component can render it. When the state updates after a fetch resolves, React automatically re-renders the component to reflect the new data on screen.

A route parameter captures a dynamic segment of a URL, defined with a colon in the route path. ```javascript app.get('/api/users/:id', (req, res) => { const userId = req.params.id; }); ``` This is commonly used for endpoints that operate on a specific resource identified by an ID.

req.body holds data sent in the request body, typically from a POST or PUT request. req.params holds dynamic segments captured from the URL path itself, like an ID. req.query holds key-value pairs from the URL's query string, like a search or filter term appended after a question mark.

During development, the API might run on a different port (like localhost:5000) than the React dev server, often configured through a proxy setting or an environment variable. In production, both are typically served from the same origin, or an environment variable holds the deployed API's URL so the same frontend code works correctly in both setups.

A .gitignore file lists files and folders that should not be tracked by version control, commonly including node_modules (since dependencies can be reinstalled from package.json), .env files containing secrets, and build output folders, keeping the repository clean and avoiding accidentally committing sensitive credentials.

200 means success, 201 means a resource was successfully created, 400 means the client sent a bad request, 401 means the request isn't authenticated, 404 means the requested resource wasn't found, and 500 means an unexpected server error occurred. Returning the correct status code helps the frontend handle each case appropriately.

package.json lists a project's dependencies, scripts (like start or build commands), and metadata. In a typical MERN project with separate client and server folders, each has its own package.json, since the frontend and backend depend on different sets of packages (React-related packages for the client, Express and Mongoose for the server).

The form's input values are tracked in React state, and on submit, that data is sent as the body of a POST or PUT request using fetch or Axios, typically with the Content-Type header set to application/json so Express correctly parses it. ```javascript axios.post('/api/users', { name, email }); ```

A callback function is passed as an argument to another function and invoked at a later point, typically once an asynchronous operation completes. Express route handlers, MongoDB driver methods, and many Node.js APIs are built around this pattern, though modern MERN code increasingly favors async/await over raw callbacks for readability.

Synchronous code runs to completion, blocking further execution until it finishes. Asynchronous code, common for things like database queries and file operations, lets Node continue handling other requests while waiting for that operation to complete, which is essential for Express to serve many concurrent users efficiently on a single thread.

This usually means either the requested route wasn't defined in Express, there's a typo in the path, or in production, the Express server isn't correctly configured to serve the React build's static files and fallback to index.html for client-side routes. Checking the exact route definitions and static file serving configuration usually resolves it.

useEffect lets a component run side effects, like fetching data from an API, after rendering. It's commonly used with an empty dependency array to fetch data once when a component first mounts, or with specific dependencies to refetch when certain state or props change.

A typical structure defines five routes: GET /items (list all), GET /items/:id (get one), POST /items (create), PUT /items/:id (update), and DELETE /items/:id (delete), each calling a corresponding Mongoose method against the model representing that resource.

MongoDB Atlas is a fully managed cloud database service, handling hosting, backups, and scaling without needing to install or maintain MongoDB yourself. Running MongoDB locally means installing it directly on a development machine, which works fine for local development but requires separately setting up a hosted database for production deployment.

Full-stack means working across the entire application, from the database and server-side API logic (the backend) through to the user interface running in the browser (the frontend). A MERN full-stack developer is expected to be comfortable with all four layers: MongoDB, Express, React, and Node.js, rather than specializing in just the frontend or just the backend.

Typically, you run the Express server (often with nodemon for automatic restarts on file changes) and the React development server (via a command like npm start) as two separate processes, usually in two terminal windows, with the React app configured to proxy API requests to the Express server's port.

401 (Unauthorized) means the request lacks valid authentication credentials entirely, like a missing or invalid token. 403 (Forbidden) means the request is authenticated but the authenticated user doesn't have permission to perform that specific action, an important distinction for an Express API implementing both login checks and role-based permissions.

A common pattern uses JSON Web Tokens (JWT). On login, Express verifies credentials against a hashed password stored in MongoDB (using bcrypt), then issues a signed JWT. The React frontend stores that token (commonly in memory or an httpOnly cookie) and includes it in the Authorization header of subsequent requests, which Express middleware verifies before allowing access to protected routes.

The bcrypt library is the standard choice, hashing a password with a configurable number of salt rounds before storing it in MongoDB. ```javascript const hashedPassword = await bcrypt.hash(password, 10); ``` Plain-text passwords should never be stored, and bcrypt's built-in salting protects against precomputed rainbow table attacks even if the database is compromised.

A middleware function checks for a valid JWT in the request (typically from the Authorization header), verifies it, and attaches the decoded user information to the request object before calling next() to proceed. Routes requiring authentication include this middleware, and requests without a valid token are rejected with a 401 status before reaching the actual route handler.

A common pattern wraps protected routes in a component that checks whether a valid authentication token or user session exists, redirecting to a login page if not, before rendering the actual protected content. This is often implemented alongside React Router, wrapping specific Route elements with an authentication check component.

Mongoose supports referencing other documents by their ObjectId, similar to a foreign key. ```javascript const postSchema = new mongoose.Schema({ title: String, author: { type: mongoose.Schema.Types.ObjectId, ref: 'User' } }); ``` Using .populate('author') on a query then replaces that ObjectId with the actual referenced document's data.

Embedding nests related data directly within a document, good for data that's always accessed together and doesn't grow unbounded. Referencing stores just an ObjectId pointing to a separate document, better for data that changes independently or is shared across many parent documents. This choice affects how queries and API responses in the Express layer are structured, and how much data the React frontend receives per request.

Validation is typically layered. React handles client-side validation for immediate user feedback, using either manual checks or a library like Formik or React Hook Form. Mongoose schema validation and custom Express middleware provide server-side validation as the authoritative check, since client-side validation alone can always be bypassed by a direct API request.

For simpler apps, React's Context API combined with useReducer or useState is often sufficient to share authentication state across components without prop drilling. For larger apps with more complex state interactions, a dedicated state management library like Redux Toolkit or Zustand is common, storing things like the current user, cached API data, and UI state centrally.

On the Express side, middleware like multer handles parsing multipart form data and saving uploaded files, either to local disk or directly to cloud storage like AWS S3. On the React side, a form using FormData sends the file as part of a POST request, and the Express route processes it through the multer middleware before storing a reference to the file's location in MongoDB.

A centralized error-handling middleware, defined last in the middleware chain with four parameters (err, req, res, next), catches errors passed via next(err) from anywhere in the app and formats a consistent JSON error response. This avoids scattering try-catch blocks with duplicate error formatting logic across every individual route handler.

React Router handles client-side routing within the single-page React application, letting different URL paths render different components without a full page reload. It works independently of Express's own routing, which handles API endpoints, though care is needed in production to make sure the Express server correctly serves the React app's index.html for all client-side routes.

Axios interceptors let you run logic automatically before a request is sent or after a response is received, across every API call. A common use is automatically attaching an authentication token to every outgoing request's headers, or automatically redirecting to a login page whenever a response comes back with a 401 status.

The Express API accepts query parameters like page and limit, uses Mongoose's skip() and limit() methods to fetch only the relevant slice of data from MongoDB, and returns both the data and metadata like total count. The React frontend tracks the current page in state, requests the appropriate page from the API, and renders pagination controls based on the returned metadata.

A common approach builds the React app into static files and serves them directly from the Express server, so the whole application runs as a single Node.js process, often deployed to a platform like Render, Railway, or a cloud VM. Alternatively, the frontend and backend can be deployed separately, React to a static host like Vercel or Netlify and Express to a separate backend host, communicating over the network.

Server-side rendering (SSR) renders HTML on the server before sending it to the browser, while client-side rendering (CSR), the default for a standard Create React App setup, sends a mostly empty HTML shell and lets JavaScript build the page in the browser. A standard MERN stack uses CSR by default, though frameworks like Next.js can be introduced to add SSR to the React portion if needed.

Socket.IO is a common addition, running alongside the Express server to maintain persistent WebSocket connections with connected clients. The React frontend uses the Socket.IO client library to listen for and emit events, enabling real-time updates like new messages appearing instantly without the client needing to poll the API repeatedly.

The React frontend captures search input, typically debounced to avoid firing a request on every keystroke, and sends it as a query parameter to an Express endpoint. On the backend, MongoDB's text indexes or a regex-based query filter the collection, with a $text search index being far more efficient than a regex scan for larger collections.

Environment-specific .env files (or environment variables set directly in a hosting platform) hold values like database connection strings and API URLs, loaded through a package like dotenv on the backend. The React frontend similarly uses build-time environment variables, so the same codebase can be built and deployed differently for each environment without hardcoding values.

A role field on the User model in MongoDB stores each user's role, like 'admin' or 'user'. Express middleware checks the authenticated user's role (decoded from their JWT) against what a given route requires, rejecting the request if the role doesn't have sufficient permission. The React frontend can also conditionally render UI elements based on the current user's role, though the backend check remains the authoritative enforcement point.

The N+1 problem happens when fetching a list of items requires one query to get the list, then a separate query for each item's related data, resulting in many more database round trips than necessary. In Mongoose, this often shows up when looping over documents and calling .populate() or a separate query individually instead of batching the related lookups into a single query.

Using a tool like Supertest alongside a test framework like Jest, tests typically first obtain a valid token by simulating a login request, then include that token in the Authorization header of subsequent test requests to protected endpoints, verifying both successful access with a valid token and rejection with an invalid or missing one.

Optimistic updates immediately update the UI state as if an API call succeeded, before the actual server response arrives, giving a snappier feel. If the API call fails, the UI state is rolled back to its previous value and an error is shown. This pattern works well for actions like liking a post or adding an item, where failures are rare and quick visual feedback matters.

A middleware like express-rate-limit tracks requests per client, typically by IP address, over a defined time window, rejecting requests that exceed a configured threshold with a 429 status code. This is commonly applied more strictly to sensitive endpoints like login, to slow down brute-force attempts, than to general read-only endpoints.

On the backend, unit tests cover individual functions and controllers, while integration tests using a tool like Supertest verify actual API endpoint behavior against a test database. On the frontend, React Testing Library tests component behavior and rendering, and end-to-end tools like Cypress or Playwright test full user flows across the whole stack, from the browser through to the database.

I'd start by profiling to isolate whether the bottleneck is database queries, missing MongoDB indexes on frequently filtered fields being a common culprit, application logic, or network overhead. Adding appropriate indexes, implementing caching (like Redis) for expensive or frequently repeated queries, and adding pagination to endpoints returning large datasets are typical fixes once the actual bottleneck is identified.

MongoDB supports multi-document ACID transactions within a replica set, accessed through Mongoose sessions. ```javascript const session = await mongoose.startSession(); session.startTransaction(); try { await Model1.create([data1], { session }); await Model2.updateOne(query, update, { session }); await session.commitTransaction(); } catch (err) { await session.abortTransaction(); } ``` This ensures multiple related writes either all succeed or all roll back together.

I'd add Redis as a caching layer in front of MongoDB for expensive or frequently accessed queries, with a clear invalidation strategy so cached data doesn't go stale after a write. On the frontend, React Query or SWR can handle client-side caching of API responses, reducing redundant network requests and giving a smoother experience through features like background refetching.

Common approaches include putting the version directly in the URL path (/api/v1/users, /api/v2/users) or using a custom header to specify the desired version. URL-based versioning is simpler to reason about and debug, and it lets you run multiple API versions side by side while clients migrate to a newer version at their own pace.

On the backend, that means validating and sanitizing all input to prevent NoSQL injection, using parameterized queries through Mongoose rather than raw string concatenation, rate limiting sensitive endpoints, and setting security headers with middleware like helmet. On the frontend, sanitizing any user-generated content rendered as HTML prevents XSS, and storing JWTs carefully (favoring httpOnly cookies over localStorage) reduces token theft risk.

React's lazy() and Suspense let you split the bundle so route-level components load on demand rather than all at once in the initial bundle. This is particularly valuable for larger MERN applications with many distinct pages or admin sections that most users won't visit in a given session, keeping the initial load fast.

I'd watch for patterns like storing every comment or every order directly as an embedded array within a parent document, which can eventually exceed MongoDB's 16MB document size limit and hurts read performance well before that. Referencing a separate collection with a foreign key back to the parent, and paginating queries against it, avoids this problem for any relationship that can grow without a reasonable bound.

For simpler needs, a library like node-cron can schedule recurring tasks directly within the Node process. For more demanding workloads, a dedicated job queue like Bull or BullMQ, backed by Redis, handles background processing more reliably, including retries, prioritization, and running jobs across multiple worker processes separate from the main API server.

Apollo Server integrates with Express to expose a single GraphQL endpoint, with resolvers pulling data from MongoDB through Mongoose models much like REST controllers do. GraphQL's main advantage here is letting the React frontend request exactly the fields it needs in a single query, which can reduce over-fetching and the number of round trips compared to composing several REST calls.

I'd use Node's built-in --inspect flag with Chrome DevTools or a tool like clinic.js to take heap snapshots over time and compare them to see which objects keep growing unexpectedly. Common causes in an Express app include event listeners or database connections that aren't properly cleaned up, or caches that grow unbounded without any eviction strategy.

I'd first make sure indexing and query patterns are genuinely optimized, since that alone resolves a surprising number of scaling problems before infrastructure changes are needed. Beyond that, MongoDB's native sharding distributes data and write load across multiple servers based on a chosen shard key, and read replicas can offload read traffic from the primary, though the shard key choice needs careful thought since a poor one can create hot spots that undermine the whole point of sharding.

MongoDB's flexible schema fits well when requirements are genuinely still evolving and the data doesn't have strong relational integrity needs. But if the domain has clear relational structure and requires strong transactional guarantees across many entities, forcing it into MongoDB's document model just because it's part of the MERN acronym can create more friction than it saves. I'd evaluate based on the actual data model, not stack convention alone.

I'd run multiple Node.js instances behind a load balancer, using a process manager or container orchestration to handle rolling deployments where new instances come up and pass health checks before old ones are terminated. MongoDB replica sets provide database-level high availability with automatic failover, and stateless API design (no session data stored in server memory) is what makes horizontal scaling behind a load balancer actually work cleanly.

I'd weigh the benefits, server-side rendering for better SEO and initial load performance, built-in routing and API route conventions, against the migration effort and the fact that Next.js blurs the traditional separation between the Express backend and React frontend. It's a strong fit when SEO or initial page load performance genuinely matters for the product, and a less clear win for something like an internal admin dashboard where those concerns barely register.

I'd design a transition period where both authentication mechanisms are supported simultaneously, issuing new tokens for users who log in during the transition while honoring existing sessions until they naturally expire. Rushing a hard cutover on a system as central as authentication risks locking out active users, so a gradual, monitored rollout with an easy rollback path is worth the added short-term complexity.

Early flexibility often turns into inconsistent, poorly enforced data shapes across a large collection once many developers have touched it without strict discipline. I'd push for stronger schema enforcement through Mongoose validation and stricter code review over time as an application matures, treating the initial schema flexibility as a development-speed convenience rather than a long-term architectural principle to lean on indefinitely.

Node's single-threaded event loop handles I/O-bound work well but struggles with CPU-intensive operations, like image processing or complex calculations, which block the event loop and stall every other request being handled. I'd offload that kind of work to worker threads, a separate job queue, or a dedicated service in another language better suited to the task, rather than trying to force it through the main Express process.

I'd build a single, well-designed API with proper role-based access control distinguishing what public users versus admin users can do, rather than building two separate backends. Shared business logic stays in one place, and the two frontends, the public React app and an internal admin React app, simply call different subsets of the same underlying API based on the authenticated user's permissions.

I'd look at actual CI run times and how often flaky tests cause false failures that erode trust in the suite. Common fixes include parallelizing test execution, moving more coverage toward fast, isolated unit tests rather than slower end-to-end tests, and periodically auditing for tests providing little real value relative to their maintenance cost.

TypeScript adds real value in catching a class of bugs at compile time and improving editor tooling, particularly valuable as a codebase and team grow. The migration cost and short-term velocity hit are real, though, so I'd typically favor an incremental adoption, new code written in TypeScript with a gradual migration path for existing code, rather than a disruptive big-bang rewrite of an already-working application.

I'd invest in a solid CI pipeline running the full test suite automatically on every pull request, feature flags to decouple deployment from release for riskier changes, and a staging environment that closely mirrors production for final verification. Automated rollback capability, so a bad deploy can be reverted quickly without a manual scramble, is what actually makes frequent releases feel safe rather than risky.

I lean strongly toward incremental modernization in almost every case, since full rewrites carry a well-documented pattern of running over budget and over timeline while the business keeps needing the old system maintained in parallel. I'd look for the specific pain points actually hurting the business, then modernize those pieces first, an aging authentication system, a particularly brittle module, rather than treating the whole application as needing replacement at once.

I'd assess how much that organic growth is actually costing in bugs, onboarding time, and slowed feature delivery, versus treating messiness as purely an aesthetic concern. Where the cost is real and rising, I'd advocate for a deliberate, prioritized cleanup effort. Where the system is messy but stable and rarely a source of real problems, I'd focus investment elsewhere rather than fixing something mostly for the sake of tidiness.

I look at where real friction is showing up, whether that's MongoDB's model straining against genuinely relational data needs, Node's single-threaded model becoming a bottleneck for CPU-intensive work, or React's ecosystem no longer fitting the team's needs, rather than assuming the stack itself is the problem just because scaling got harder. Most scaling pain in a MERN application comes from architecture and operational practices rather than the stack's fundamental technology choices, so I'd rule those out first before considering a genuine stack migration.

I'd pair them on features that require touching every layer, from the MongoDB schema through the Express API to the React UI, rather than letting them stay in their comfort zone on every project. Having them own an entire feature end to end, including its API design and data model decisions, builds the broader intuition faster than incremental exposure to just the parts adjacent to what they already know well.

Signals include rising bug rates concentrated in specific areas, engineers routinely avoiding certain files out of fear of breaking something, and feature velocity visibly slowing in parts of the codebase that used to move quickly. I generally favor incremental, scoped refactors targeting the worst offenders over a full rewrite, since rewrites carry high risk and rarely land on their originally promised timeline.

I'd push for a small, contained pilot rather than a binding upfront decision, letting the team gather real evidence on maintainability and developer experience before committing broadly. Framing the discussion around what concrete evidence would change each person's mind tends to move things forward faster than a purely principled argument grounded in preference.

Early on, I'm comfortable with some deliberate shortcuts to validate product direction quickly, as long as the team is honest with itself about what's a shortcut versus what's a considered decision. As the product and team mature, I shift the balance toward stronger conventions, testing discipline, and architectural rigor, since the cost of moving fast and loose compounds much faster once a codebase and its user base have real scale.

I'd point to the compounding cost of duplicated, slightly inconsistent implementations across teams, the onboarding friction for new engineers relearning conventions team by team, and the maintenance burden of many near-identical solutions to the same problem. Shared tooling investment tends to pay for itself once an organization crosses a handful of product teams working in the same stack, and I'd frame the case around velocity and consistency rather than engineering elegance alone.

I weigh how someone reasons about tradeoffs across the whole stack, like when to embed versus reference data in MongoDB, or how an API design choice ripples into frontend complexity, over how many library names they can recite. Walking through a real system they designed end to end, and the reasoning behind specific decisions, tells me far more about their depth than isolated trivia questions about any single piece of the stack.

I weigh the actual cost of keeping it running, engineering time spent working around its limitations, bugs traced back to it repeatedly, against the risk and cost of replacing it. If it's stable and rarely touched, I'd rather leave it alone than destabilize something working purely for tidiness. Once it's become a recurring source of friction or incidents, that's when the cost of leaving it alone starts outweighing the risk of change.

I lead with business impact in plain language, what's broken, who's affected, and the expected timeline to resolution, before getting into technical root cause. Detailed technical explanation belongs in a follow-up postmortem for those who want it, since overloading an in-the-moment update with implementation detail usually adds confusion rather than the clarity stakeholders actually need.

I push for that knowledge to become documentation, architectural decision records, and shared ownership of the most critical parts of the system well before it becomes urgent. Pairing a senior engineer with someone earlier in their career on the trickiest production issues, rather than always having the expert handle it solo, spreads the knowledge naturally instead of relying on a single point of failure sticking around indefinitely.

Standardization earns its place where inconsistency creates genuine risk or cost, authentication patterns, deployment processes, core data modeling conventions. Beyond that, I'd rather let teams move quickly within their own domains than impose uniformity that mostly serves aesthetic consistency. The test I use is whether a given standard is protecting something concrete or just making the codebase look tidier.

I try to lead with specific, observable consequences rather than a general critique, pointing to the performance or maintenance cost the current approach is actually producing rather than framing it as a judgment on the original decision. Most engineers respond well to being shown a concrete problem and invited to help solve it together, rather than being told after the fact that their design was wrong.

The work shifts from personally writing most of the code to multiplying the team's effectiveness, through better architectural decisions, mentoring, and removing organizational obstacles that slow the team down. I measure my own impact less by lines of code I've personally written and more by whether the team and the system are healthier and more capable than before I got involved.