← All projects

CreditSea Full-Stack Intern Challenge: Real-Time, Offline-First & Live-Rules Systems

Source: Derived from Resources/CreditSea_Intern_Challenge.docx — a real full-stack intern take-home assessment from CreditSea (a fintech/lending company), asking candidates to build one of three end-to-end systems with Node.js + TypeScript, Next.js + TypeScript, and MongoDB.

Skills Required

Background a Student Needs

A student should be comfortable building a full-stack TypeScript application from scratch: standing up a Node.js API, modeling and querying MongoDB, and wiring a Next.js frontend that talks to it. Beyond CRUD, they need a working mental model of real-time communication (WebSocket/SSE), the reliability problems that appear when data arrives fast or networks drop (duplicates, lost events, reconnection), and at least one approach to making a web app function offline. Familiarity with charts, search/filter UIs, indexing for query performance, and writing a short architecture document with diagrams rounds out the prerequisites.

Task Summary

Choose one of three end-to-end full-stack challenges and build a production-quality application using Node.js + TypeScript, Next.js + TypeScript, and MongoDB. The options are a high-throughput real-time loan-ingestion ops dashboard, an offline-first user-journey analytics portal, or a live fraud-rule composer with a streaming transaction explorer. Alongside the code, you submit a written Solution Blueprint (rationale, diagrams, anticipated challenges, reflections, impact metrics), a seeded GitHub repo, and a 2–3 minute video walkthrough — all within roughly 36 hours and entirely your own work.

The Task

You are an aspiring CreditSea full-stack intern. Pick exactly one of the three challenges below and craft a world-class, end-to-end application using Node.js + TypeScript, Next.js + TypeScript, and MongoDB.

> ⚠️ No AI shortcuts or copying. Submissions containing AI-generated code or borrowed solutions are disqualified instantly. The goal is to evaluate your engineering ability, not your prompting. (The original brief specifically warns against pasting the whole document into an AI model and asking it to pick and build a challenge.)

Before You Code: Your Solution Blueprint

Submit a concise but comprehensive Solution Blueprint (PDF or Markdown) covering:

  1. Your Why & How — In your own words, explain why you chose each component (frameworks, databases, services) and outline your implementation strategy.
  2. Key Flows & Diagrams — Illustrate data movement, API interactions, real-time pipelines, or offline-sync strategies with flowcharts/diagrams.
  3. Anticipated Challenges — Identify hurdles (scaling, consistency, failure modes) and how you will overcome them.
  4. Your Reflections — Trade-offs you weighed, lessons you aim to learn, unique insights.
  5. Impact & Metrics — Expected impact: performance targets, scalability gains, UX improvements.

Perfect grammar is not required — genuine engineer talk is gold. Include scripts/instructions to seed MongoDB with sample data.

Challenge 1 — Ultra-Fast Loan Ingestion & Live Ops Dashboard

Hundreds of loan applications flood in every second; your system must absorb, validate, enrich, and display operational metrics in real time.

Challenge 2 — Offline-First User Journey & Analytics Portal

Craft a smooth, offline-capable experience that tracks users across 5 pages, syncs data later, and powers insightful analytics.

Challenge 3 — Live Fraud-Rule Composer & Transaction Explorer

Empower analysts to craft fraud rules on the fly, see them applied instantly, and drill into decision logic — no restarts.

How to Submit

  1. GitHub Repo — Complete codebase plus seeding/migration scripts.
  2. Solution Blueprint — Architecture diagrams, data flows, rationale, challenges, reflections.
  3. Video Walkthrough (2–3 min) — Showcase architecture, highlight major challenges and trade-offs.
  4. Submission Form — A Google Form with links to the repo, blueprint, and video.

Deadline: 36 hours from receiving the document.

Evaluation Notes

The reviewers are judging engineering depth, not surface polish: clean architecture, correct handling of the hard parts (exactly-once processing / reliable offline sync / hot-reloaded rules), honest reasoning about trade-offs, and whether you actually hit the stated performance aims. The blueprint and video carry real weight — they want to hear your engineering story. Originality is a hard gate; copied or AI-generated code is rejected.

Alternate Tasks (Mini-Project Variations)

  1. (Beginner) Loan Application CRUD + Static Ops Dashboard. Build a Node.js + TypeScript REST API over MongoDB that accepts loan-application JSON, validates required fields (amount, applicant ID, tenure), enriches each record with a computed field (e.g., simple risk band from amount/income), and stores it. On the Next.js side, render a dashboard that polls every few seconds to show counts of received vs. validated vs. rejected applications, plus a searchable, paginated error-log table filterable by applicant and error type. No WebSockets and no exactly-once guarantees yet — the point is to nail clean schema design, MongoDB indexes that make search fast, and a tidy, well-typed end-to-end data flow. This is the gentle on-ramp to Challenge 1.
  2. (Beginner–Intermediate) Offline Note/Activity Logger with Replay. Create a small Next.js app of 3–4 pages that records page visits and button clicks into IndexedDB while the browser is offline, then replays the queued events to a Node.js ingest endpoint when connectivity returns. Add a tiny admin view that aggregates events per page and per session and shows simple bar charts. Persistence must survive a page reload. Skip conflict resolution for now and assume the server is the source of truth on replay. This teaches Service Workers, the offline event queue, and reliable replay — the core of Challenge 2 without the hardest 24-hour/conflict-UI requirements.
  3. (Intermediate–Advanced) Real-Time Ingestion Pipeline with Exactly-Once Processing. Implement the heart of Challenge 1 properly: a WebSocket (or SSE) backend that ingests bursts of loan events, deduplicates them using an idempotency key so each record is processed exactly once even when the producer retries or the connection drops mid-stream, and streams live throughput metrics (incoming vs. processed per second) to a Next.js dashboard that auto-reconnects and shows a clear recovery indicator. Include a load script (autocannon/k6) demonstrating sustained throughput toward 500 req/s and measure end-to-end latency, reporting your p95 in the blueprint. This is the real distributed-systems meat: back-pressure, retries, dedup, and reconnection.
  4. (Advanced — MERN twist) Multi-Tenant Live Fraud-Rule Console. Extend Challenge 3 into a full MERN-style product: a Node.js + TypeScript service that hot-loads versioned JSON rules from MongoDB (using change streams so edits propagate in under a second with no restart), evaluates a streamed transaction feed against the active rule set, tags each transaction with the rule IDs that fired plus a composite risk score, and writes an immutable decision trail. The React/Next.js console lets analysts author, version, and enable/disable rules, filter the live feed by score range and rule ID, and drill into any transaction to see the exact firing order. Add multi-tenant isolation (rules and transactions scoped per organization) and role-based access so only admins can publish rules. This stresses dynamic schema evolution, audit-grade logging, and authorization on top of the streaming core.
  5. (Advanced — Agentic AI twist) AI Fraud-Triage Agent over the Live Feed. Reuse the Challenge 3 streaming backend, but add an autonomous triage agent: for every transaction flagged high-risk by the deterministic rules, an LLM-powered agent (built with a tool-calling loop) investigates by calling tools you expose — getApplicantHistory, getRecentTransactions, checkRuleContext — reasons over the evidence, assigns a confidence-scored recommendation (approve / hold / escalate), and writes a natural-language justification into the decision trail. The Next.js console surfaces the agent's verdict alongside the rule output and lets a human accept or override it, feeding that label back as future context. Emphasize guardrails (the agent can read but never auto-approve above a risk threshold), structured tool outputs, token/cost budgeting, and graceful fallback to pure rules when the model is unavailable. This bridges the fintech domain into the Agentic AI track: tool design, agent loops, and human-in-the-loop oversight.

Reference Links