The Code Review and PR Teardown Interview (2026): How Google, Stripe, Meta and London Unicorns Screen Senior Engineers — Real Pull Requests, Scoring Rubrics and Communication Frameworks

The most common failure mode in PR teardown interviews is approaching the review as a linear reading exercise — starting at line one, noting issues as they appear, and working through to the end of the file. This approach is how junior engineers review code, and it produces exactly the kind of shallow, style-heavy feedback that interviews at senior levels penalise.

Strong candidates use a top-down, context-first framework that sequences the review across four stages of progressively increasing specificity.

Stage 1: Business Intent and Architectural Alignment

Before reading a single line of the implementation, you must understand what the pull request is trying to accomplish. Spend the first several minutes reading the PR description, linked ticket, and any associated documentation. Ask yourself three questions: What business requirement does this change address? Is the approach architecturally consistent with the existing system? And critically — does the stated intent and the actual implementation match?

This last question is where many substantive bugs surface. Engineers frequently implement something slightly different from what the PR description says — not out of negligence but because the implementation requires making a decision that the description left ambiguous. Identifying this misalignment and raising it as your first piece of feedback demonstrates exactly the kind of big-picture thinking that senior roles require.

Stage 2: Correctness, Concurrency, and Security

This is the highest-weight section of the review and the area where interviewer attention is most concentrated. You are looking for defects that would cause the system to behave incorrectly in production — not in controlled test conditions, but under the actual operating environment with concurrent requests, partial failures, and adversarial inputs.

Stage 3: Testing and Observability

A pull request that introduces new behaviour without a corresponding test strategy is a liability regardless of how correct the implementation appears. Senior engineers evaluate not just whether tests exist, but whether they test the right things: edge cases, failure modes, and the specific concurrency scenarios that the code is vulnerable to.

Equally important in production environments is observability. Any code that changes system behaviour should emit the metrics, logs, and traces that allow engineers to monitor it after deployment. A pull request that adds a new payment processing flow without emitting latency histograms, error rate counters, and structured log events with the transaction identifiers needed for debugging is incomplete from a production readiness standpoint — even if the logic is correct.

Stage 4: Style, Readability, and Low-Priority Feedback

Style-level feedback is legitimate and important but must be explicitly categorised as low-priority relative to correctness and security issues. The professional way to communicate style feedback is to label it clearly — "this is a minor nit" or "this is a stylistic suggestion, not a blocker" — so the author can triage appropriately. An interviewer who sees a candidate spend equal time on a poorly named variable and a missing transaction boundary will interpret this as a fundamental misunderstanding of engineering priorities.

Real Case Study: PR Teardown of an Order Processing Service

The following is a representative pull request teardown exercise used in senior engineering interviews at fintech and infrastructure companies. Read the code below and identify the defects before reading the analysis section.

// POST /api/orders — Create and process a new order
async function createOrder(req, res) {
  const { userId, items, paymentMethodId } = req.body;

  // Check if user exists
  const user = await db.users.findOne({ id: userId });
  if (!user) return res.status(404).json({ error: 'User not found' });

  // Calculate order total
  let total = 0;
  for (const item of items) {
    const product = await db.products.findOne({ id: item.productId });
    total += product.price * item.quantity;
  }

  // Charge the payment method
  const charge = await stripe.charges.create({
    amount: total,
    currency: 'usd',
    payment_method: paymentMethodId,
    customer: user.stripeCustomerId,
    confirm: true,
  });

  // Save the order
  const order = await db.orders.create({
    userId,
    items,
    total,
    chargeId: charge.id,
    status: 'completed',
  });

  return res.status(201).json({ orderId: order.id, total });
}

Defect 1 — Critical: Non-Idempotent Payment Processing

The most severe defect in this implementation is the complete absence of idempotency protection. If a client sends the same order request twice — due to a network timeout retry, a client-side bug, or a load balancer retry — the system will call stripe.charges.create twice and charge the customer twice. This produces a double-charge, a support escalation, a potential regulatory violation in UK fintech contexts, and a refund cost. The correct implementation uses a client-generated idempotency key stored in the database before the payment call. Stripe natively supports idempotency keys via the idempotencyKey parameter — the complete absence of this mechanism is a critical architectural omission.

Defect 2 — Critical: Missing Database Transaction Boundary

The implementation calls stripe.charges.create and then separately calls db.orders.create. These two operations are not wrapped in a transaction. If the Stripe charge succeeds but the database write fails — due to a network hiccup, a constraint violation, or a connection pool timeout — the customer has been charged but no order record exists. The system has no way to reconcile this without a compensating transaction to issue a refund. The correct architecture uses the Transactional Outbox Pattern: save the order with a pending status and the payment parameters inside a single database transaction, then process the payment asynchronously via a background worker that updates status on success or failure.

Defect 3 — High: N+1 Query Problem

The loop at lines 12-14 executes one database query per item in the order. For an order with 20 line items, this generates 20 sequential database round-trips. Under high request volume, this collapses database connection pool capacity and introduces latency that scales linearly with order size. The correct implementation fetches all required products in a single batched query using an IN clause.

Defect 4 — High: Missing Input Validation

The function accepts req.body without any validation. A malicious actor could send a negative quantity to produce a negative total — effectively requesting a refund disguised as a purchase. They could send a productId that does not belong to the authenticated user's accessible catalogue. They could omit required fields entirely, causing the function to throw an unhandled exception that leaks stack information. Every field must be validated against an explicit schema before any database or payment operations are performed.

Defect 5 — Medium: No Observability

The function creates a Stripe charge and saves an order but emits no metrics or structured logs. At minimum, the function should emit a duration metric for the payment processing step, a counter for successful and failed charges broken down by error type, and structured log events containing the orderId and chargeId at each significant state transition. Without these, debugging a production incident involving this code requires speculative log searching rather than targeted metric investigation.

The Scoring Rubric Used by Hiring Committees

How to Communicate Code Review Feedback Professionally

The most technically capable candidates fail PR teardown rounds because their communication style signals poor interpersonal judgment. An interviewer watching a code review is explicitly evaluating whether they would want this person reviewing their own code — and a review that is technically correct but delivered with arrogance, vagueness, or excessive negativity fails on the communication dimension even if the technical findings are accurate.

The Three-Part Comment Structure

Strong code review feedback follows a consistent three-part structure: state the issue precisely, explain the failure mechanism or impact, and propose a specific remediation.

Weak structure: "This needs a transaction."

Strong structure: "The Stripe charge call and the subsequent database write are not atomic. If the database write fails after a successful charge, the customer will be billed without an order record being created. The system cannot recover this state without a manual reconciliation process. I would recommend wrapping both operations in a database transaction, or implementing the Transactional Outbox Pattern to decouple the payment execution from the database write entirely."

Language Patterns that Signal Seniority

• Explicit severity labelling: "This is a P0 blocker", "This is a medium-priority improvement", "This is a minor nit and entirely optional." Severity labels demonstrate that you understand not all issues require equal urgency and that you can communicate priority to a team operating under time pressure.
• Impact quantification: "Under ten thousand requests per minute, this N+1 pattern generates approximately 200,000 database queries per minute — at our current connection pool limit of 100, this will saturate connections within seconds." Quantified impact demonstrates that your concerns are grounded in production reality rather than theoretical correctness.
• Constructive framing: "I would consider..." rather than "You should have...", "One approach that addresses this constraint is..." rather than "This is wrong because...". Constructive framing makes the review feel collaborative rather than adversarial, which is the professional engineering standard.
• Acknowledgement of trade-offs: "The Transactional Outbox Pattern adds complexity and requires background worker infrastructure — if this endpoint is low-volume and called by a trusted internal service only, a simpler compensating transaction may be sufficient." Acknowledging trade-offs demonstrates that you understand there are no universally correct solutions, only solutions appropriate for a given context.

Four-Week Preparation Framework

Week 1: Defect Pattern Recognition

Spend one hour per day reviewing open-source pull requests in your primary technology stack. For each PR, before reading any comments, write your own review. Then compare your findings with the comments left by the project maintainers. Track the defect categories you miss consistently — these are your preparation priorities for the following weeks.

Week 2: Severity Calibration

The most common calibration error is treating all defects as equally important. Practice explicitly assigning severity levels to each finding using a consistent framework: P0 for production down or data loss, P1 for incorrect behaviour under specific conditions, P2 for performance degradation at scale, P3 for maintainability or readability. Practice until severity assignment becomes intuitive rather than deliberate.

Week 3: Communication Refinement

Record yourself conducting code reviews aloud and review the recordings critically. Identify moments where your feedback is vague, where you state a problem without explaining its impact, or where your language is more adversarial than collaborative. The target communication style is the tone of a senior engineer who is genuinely trying to help a capable colleague improve their code — authoritative but supportive, specific but not pedantic.

Week 4: Full-Format Mock Interviews

Complete three to five full-format PR teardown sessions under realistic timed conditions. Each session should conclude with detailed feedback on defect detection rate, prioritisation accuracy, and communication quality. Use the feedback from each session to calibrate the specific improvements for the next.

What Separates Senior-Level Code Review from Junior-Level Code Review

The senior engineering interview rubric is ultimately calibrated around a single question: would this candidate's code reviews make the team better? The answer is determined not just by whether they find bugs, but by how they think about code in relation to the system it operates within, how they communicate findings in a way that is educational rather than merely corrective, and whether they demonstrate the judgment to distinguish between issues that must be resolved before merge and issues that can be addressed in a follow-up.

Junior engineers review code at the level of individual functions. Senior engineers review code at the level of system behaviour. When a junior engineer sees the N+1 query loop in the order processing example, they note that it is inefficient. When a senior engineer sees it, they estimate the database query volume at production scale, assess whether the current connection pool configuration can sustain it, identify the specific request volume threshold at which the system degrades, and propose a remediation that addresses the root cause rather than just the symptom.

This systemic thinking — the habit of always connecting individual code decisions to their production operating context — is what interviews at senior levels are ultimately designed to detect. It is the characteristic that separates engineers who can implement features from engineers who can architect systems that remain reliable at scale. And it is precisely what MockExperts' senior interview format is designed to surface, measure, and help you improve.