SESSION 118 — SENIOR DEVELOPER REVIEW

ASSESSMENT.TASKS

System Design Interview (60 min)

▶

Prompt: Design a collaborative image editor like Figma/Canva from scratch. You have 60 minutes.

// Requirements:
// - Multi-user real-time editing
// - 10M registered users
// - 100K concurrent editors
// - Image storage (billions of files)
// - Version history per project
// - Plugin/extension ecosystem

// You must address:

1. HIGH-LEVEL ARCHITECTURE
   Draw the system diagram.
   What services? What databases?
   How do they communicate?

2. DATABASE DESIGN
   What data model for projects,
   users, layers, versions?
   SQL vs NoSQL for each entity?
   How do you handle 1TB+ of images?

3. REAL-TIME COLLABORATION
   How do multiple users edit
   simultaneously?
   Conflict resolution strategy?
   (OT? CRDT? Locking?)

4. FILE STORAGE
   Where do images live?
   How do you serve them fast
   worldwide? CDN strategy?
   Thumbnail generation pipeline?

5. SCALING STRATEGY
   At 10K users vs 1M vs 100M —
   what changes?
   Where are the bottlenecks?
   How do you shard the database?

6. TRADEOFF ANALYSIS
   Every decision has a tradeoff.
   State it explicitly.
   "We chose X because Y,
    accepting the cost of Z."

Evaluation criteria: Structured thinking (top-down decomposition). Tradeoff awareness (no solution is perfect). Scalability reasoning (what breaks at scale). Communication clarity (can you whiteboard this for a non-engineer?).

Production Incident Simulation (45 min)

▶

Scenario: It's 2:47 PM on a Tuesday. PagerDuty fires: "PixelCraft API 500 error rate > 20%." The clock starts now.

// GIVEN:
// (examine these artifacts)

SENTRY ERRORS:
  MongoServerError: pool destroyed
  Frequency: 847 in last 15 minutes
  First seen: 2:32 PM
  Stack trace: → connectDB()
    → getPool() → pool.acquire()

SERVER LOGS (last 30 min):
  14:15 [INFO] Deploy v2.34.1 started
  14:17 [INFO] Deploy v2.34.1 complete
  14:28 [WARN] MongoDB pool: 48/50
  14:30 [WARN] MongoDB pool: 50/50
  14:32 [ERROR] pool destroyed
  14:32 [ERROR] pool destroyed (×847)

DEPLOYMENT HISTORY:
  v2.34.0 → v2.34.1
  Changes: "Update DB connection config"
  diff: maxPoolSize: 50 → 5 (!!!)

DATABASE METRICS:
  Connections: 5 (was 50)
  Query queue: 342 waiting
  Avg query time: 12s (was 8ms)

// YOUR TASK:
// 1. Identify the root cause
// 2. Determine the impact
// 3. Execute the fix
// 4. Verify the fix
// 5. Write the postmortem
//    (timeline, root cause,
//     resolution, prevention)

Evaluation criteria: Systematic debugging (don't guess randomly). Communication (narrate your thought process). Speed (find root cause in <15 minutes). Prevention thinking (how to make sure this never happens again).

Code Review (30 min)

▶

Scenario: A junior developer submitted a PR for a new "Share Image" feature. Find the 5 intentional issues and provide constructive feedback.

// PR: "Add share image endpoint"
// Find and address ALL 5 issues:

app.post('/api/images/:id/share',
  async (req, res) => {
  const image = await db
    .collection('images')
    .findOne({
      _id: req.params.id
      // ISSUE 1: _______________
    });

  const shareUrl =
    `https://pixelcraft.dev/share/`
    + `${image._id}?token=`
    + `${req.query.userToken}`;
    // ISSUE 2: _______________

  await db.collection('shares')
    .insertOne({
      imageId: image._id,
      sharedBy: req.body.userId,
      // ISSUE 3: _______________
      shareUrl,
      createdAt: new Date(),
    });

  // Send email notification
  const html = `
    <h1>Image shared with you!</h1>
    <p>${req.body.message}</p>
    <a href="${shareUrl}">View</a>
  `;
  // ISSUE 4: _______________

  await sendEmail(
    req.body.recipientEmail, html);

  res.json({
    sucess: true,
    // ISSUE 5: _______________
    shareUrl
  });
});

The 5 issues span: security vulnerability, missing error handling, accessibility/UX violation, input validation gap, and code quality problem. For each: identify, explain the risk, and suggest the fix — constructively. Evaluation criteria: Find all 5. Explain why each matters. Suggest fixes, not just complaints. Tone: kind and educational, not condescending.

Architecture Defense (30 min)

▶

Task: Present PixelCraft's complete architecture. Then answer adversarial questions. No "I don't know" — reason through it.

// Present:
// - System architecture diagram
// - Technology stack and WHY each
// - Data flow for key operations
// - Security model
// - Scaling strategy

// Then defend against:

"Why React and not Vue or Svelte?"

"Why MongoDB instead of PostgreSQL?"

"Why both Express AND Next.js?"

"What's your single point of failure?"

"You have 1M users tomorrow.
 What breaks first?"

"Why Zustand over Redux?
 Over Context alone?"

"Why custom auth instead of Auth0?"

"A competitor ships the same features
 but with 50% less infrastructure.
 How do you respond?"

// For each: state the tradeoff.
// "We chose X because Y,
//  accepting the cost of Z.
//  If the situation changed to W,
//  we'd reconsider."

Evaluation criteria: Can you articulate tradeoffs, not just choices? Do you understand what you would do differently with different constraints? Can you admit what's not ideal without losing confidence? Senior engineers say "it depends" and then explain what it depends ON.

Teaching Demo (20 min)

▶

Task: Choose ONE concept from the entire course. Explain it to a simulated beginner in 10 minutes. Then answer 3 questions.

// Choose one:
//
// - How the internet works (DNS,
//   HTTP, TCP/IP)
// - How a database stores data
// - How React renders a component
// - How authentication works (JWT)
// - How Git tracks changes
// - How CSS layout works (flexbox)
// - How images are stored as pixels
// - How WebSockets enable real-time
// - Any other concept from sessions
//   001-117

// Requirements:
// 1. Use at least one analogy
// 2. Build from simple to complex
// 3. Check understanding halfway
// 4. No jargon without explanation
// 5. The listener should be able to
//    explain it back to you

// Evaluated on:
// - Accuracy (is it correct?)
// - Clarity (is it understandable?)
// - Engagement (do they care?)
// - Analogies (do they connect?)
// - Pacing (not too fast/slow?)

"If you can't explain it simply, you don't understand it well enough." — often attributed to Einstein. Teaching forces you to organize your knowledge, fill gaps, and find the clearest path through complexity. This is the most important skill of a senior engineer.