Software Engineer (+ Technical PM Track) — Capital Formation Fintech

Answer:

I treat Claude Code as a fast pair-programmer that I steer, not autopilot. My loop is:

• Set context once: I keep a CLAUDE.md at the repo root documenting the stack, conventions, commands, and gotchas. That stops the agent from guessing and keeps output on-pattern.
• Plan before code: For anything non-trivial I have it produce a plan first (files to touch, approach, trade-offs), correct the plan, then let it implement. Cheaper to fix a plan than a diff.
• Thin vertical slices: I scope work to one buildable slice — e.g. "create-deal form → NestJS endpoint → Prisma write → list view" — so I can verify behavior, not just compilation.
• Review critically: I read every diff. The risk with AI dev isn't that it can't write code, it's that it writes plausible-but-wrong code. I check edge cases, auth, and data correctness myself.
• Parallelize: I delegate independent research/exploration to subagents so my main context stays focused on the change.

The result is I take features from wireframe to working MVP in hours instead of days — which is exactly the speed this role is asking for.

Answer:

• Conventions as guardrails: Linting, formatting, and a documented file/module layout in CLAUDE.md mean generated code matches the existing patterns instead of inventing new ones.
• Scope discipline: I instruct it to make the minimal change for the task — no speculative abstractions, no drive-by refactors. Three similar lines beat a premature abstraction.
• Tests & manual verification: I verify the feature actually works in the browser/API, not just that it compiles. For backend logic I have it write tests alongside.
• I own the architecture: The agent implements; the design decisions (boundaries, data model, auth) are mine. That keeps the codebase coherent even at high velocity.

Answer:

• Server Components (default): For anything that fetches data, touches secrets, or renders static/derived content. They run on the server, never ship their code to the browser, and can await data directly. For the Deal Hub I'd render the deal list and detail pages as server components — fast first paint, no API keys exposed.
• Client Components ("use client"): Only where I need interactivity, state, effects, or browser APIs — forms, filters, modals, the document-room viewer. I push the "use client" boundary as low as possible so most of the tree stays server-rendered.

// app/deals/page.tsx  — Server Component
export default async function DealsPage() {
  const deals = await getDeals();           // runs on server
  return <DealList deals={deals} />;          // pass data down
}

// components/DealFilters.tsx — Client Component
"use client";
import { useState } from "react";
export function DealFilters({ onChange }) {
  const [sector, setSector] = useState("all");
  // interactive filtering lives here
}

Answer:

• Typed contract: I share types between front end and back end (a shared package or generated types) so a NestJS DTO change surfaces as a TypeScript error in the UI, not a runtime bug.
• Fetch on the server when possible: Server Components call the NestJS API with the user's token attached server-side, so I never leak credentials to the browser.
• Single API client: One wrapper that attaches the Supabase JWT, sets base URL from env, and maps error shapes to friendly messages — instead of scattering fetch calls everywhere.
• Route Handlers as a thin BFF: For browser-only mutations I expose Next.js route handlers that forward to NestJS, keeping the token handling in one place.

Answer:

• Modules group related features (e.g. DealsModule, CreditModule, AuthModule). Each declares its controllers and providers and what it exports.
• Providers are injectable classes — services, repositories, the Prisma client. NestJS resolves them through its IoC container.
• Dependency Injection: I depend on abstractions and let Nest wire them, which makes services testable (I can inject a mock Prisma in unit tests).

@Module({
  controllers: [DealsController],
  providers: [DealsService, PrismaService],
  exports: [DealsService],
})
export class DealsModule {}

@Injectable()
export class DealsService {
  constructor(private readonly prisma: PrismaService) {}

  findForInvestor(investorId: string) {
    return this.prisma.deal.findMany({ where: { matchedInvestorId: investorId } });
  }
}

Answer:

• Resource-oriented routes: POST /deals, GET /deals/:id, GET /deals?sector=&stage=&minSize=, POST /deals/:id/matches.
• Validation at the edge: NestJS DTOs with class-validator so bad input is rejected with a 400 before it reaches business logic.
• Consistent envelope & status codes: 201 on create, 200 on read, 400/401/403/404/409 mapped by error category — never 200 for an error.
• Idempotency on money-adjacent writes: Accept an idempotency key so a retried "commit deal" doesn't double-record.

export class CreateDealDto {
  @IsString() @MaxLength(200) title: string;
  @IsEnum(Sector) sector: Sector;
  @IsEnum(Stage) stage: Stage;
  @IsInt() @Min(0) dealSize: number;     // store in smallest unit
  @IsString() geography: string;
}

Answer:

A discriminated union lets the compiler force me to handle each hub correctly — no "forgot the debt case" bugs.

type EquityDeal = {
  kind: "equity";
  investorId: string;
  valuation: number;
};

type DebtDeal = {
  kind: "debt";
  syndicatorId: string;     // DSA, not a direct lender
  facilityType: "working_capital" | "project_finance" | "growth_debt";
};

type Deal = EquityDeal | DebtDeal;

function route(deal: Deal) {
  switch (deal.kind) {
    case "equity": return matchToInvestor(deal.investorId);
    case "debt":   return matchToSyndicator(deal.syndicatorId);
    // TS errors if a new kind is added and not handled
  }
}

Answer:

I model the actors and the deal, with explicit enums for sector/stage and indexes on the columns the matching engine filters by.

model Deal {
  id            String   @id @default(uuid())
  title         String
  sector        Sector
  stage         Stage
  dealSize      BigInt   // smallest currency unit — never float
  geography     String
  ownerId       String
  owner         User     @relation(fields: [ownerId], references: [id])
  status        DealStatus @default(DRAFT)
  createdAt     DateTime @default(now())

  @@index([sector, stage, geography])   // matching-engine filters
  @@index([ownerId])
}

enum Sector { REAL_ESTATE INFRA SOCIAL_INFRA ENERGY }
enum Stage  { SEED GROWTH LATE }
enum DealStatus { DRAFT OPEN IN_DILIGENCE CLOSED }

Note BigInt for money — I never store currency as a float.

Answer:

• Use include / select to fetch relations in one round-trip instead of looping and querying per row.
• Batch lookups with findMany({ where: { id: { in: ids } } }) rather than a query inside a .map().
• Verify with Prisma query logging — if I see one query per item, that's the smell.

// Bad: N+1 — one query per deal
const deals = await prisma.deal.findMany();
for (const d of deals) {
  d.owner = await prisma.user.findUnique({ where: { id: d.ownerId } });
}

// Good: single query with the relation joined
const deals = await prisma.deal.findMany({
  include: { owner: true },
});

Answer:

RLS enforces access rules in the database itself, so even a bug in the API can't leak another tenant's data — critical when deal rooms contain confidential financials.

• Policies are SQL predicates checked on every row for every query, scoped to the authenticated user (auth.uid()).
• I'd let only a deal's owner and explicitly invited investors read its documents.

-- Only the owner or an invited participant can read a deal's documents
create policy "deal_docs_read"
on deal_documents for select
using (
  auth.uid() = owner_id
  or auth.uid() in (
    select investor_id from deal_invites where deal_id = deal_documents.deal_id
  )
);

The caveat: when I use Prisma with a service-role connection, RLS is bypassed — so authorization must then be enforced in NestJS guards. I'm explicit about which path each query takes.

Answer:

• Private buckets, never public: Due-diligence documents go in a private bucket. Nothing is world-readable.
• Signed URLs with short TTLs: The backend generates a time-limited signed URL only after checking the requester is authorized for that deal. The link expires in minutes.
• Authorize before signing: The NestJS guard confirms the user is the owner or an invited participant before issuing the URL.
• Audit every access: I log who requested which document and when — diligence requires a paper trail.

// NestJS: only sign after an auth check
async getDocumentUrl(userId: string, docId: string) {
  const doc = await this.deals.assertCanAccess(userId, docId); // throws 403 otherwise
  const { data } = await this.supabase
    .storage.from("deal-docs")
    .createSignedUrl(doc.path, 60 * 5); // 5-minute link
  await this.audit.record(userId, "doc.view", docId);
  return data.signedUrl;
}

Answer:

• Pooled (PgBouncer, transaction mode): Use this for the serverless/runtime path — short-lived requests share a small pool, which prevents exhausting Postgres connections under load.
• Direct connection: Use this for prisma migrate and any operation needing prepared statements / a session, which the transaction pooler doesn't support.
• In practice: I set DATABASE_URL to the pooled connection (with pgbouncer=true) and DIRECT_URL to the direct connection in schema.prisma so migrations and runtime each use the right one.

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")     // pooled — runtime
  directUrl = env("DIRECT_URL")       // direct — migrations
}

Answer:

• The engine filters deals by sector, stage, deal size, and geography, so I add a composite index covering the common filter combination (respecting the left-most prefix rule).
• I run EXPLAIN ANALYZE on the real query to confirm it uses the index instead of a sequential scan.
• For range filters like deal size I order the composite index so equality columns come first, then the range column last.
• As data grows I'd consider partial indexes (e.g. only status = OPEN deals, since closed ones are rarely searched).

Answer:

• Migrations in version control: prisma migrate dev locally generates a reviewable SQL migration; prisma migrate deploy applies it in CI/prod.
• Expand/contract for breaking changes: Add the new column nullable, backfill, switch reads/writes, then drop the old column in a later migration — never a single destructive step on a live table.
• Backfills are idempotent and batched so reruns are safe and a long migration doesn't lock the table.
• Use the direct connection for migrations (not the transaction pooler).

Answer:

• Supabase Auth issues a signed JWT on email/password login. The front end sends it as Authorization: Bearer <token>.
• In NestJS I write a guard that verifies the JWT signature against Supabase's JWT secret/JWKS, extracts the user id and role from claims, and attaches the user to the request.
• Verification is stateless — no DB round-trip per request — and I layer an RBAC check on top for portal-specific permissions.

@Injectable()
export class SupabaseAuthGuard implements CanActivate {
  canActivate(ctx: ExecutionContext): boolean {
    const req = ctx.switchToHttp().getRequest();
    const token = req.headers.authorization?.replace("Bearer ", "");
    if (!token) throw new UnauthorizedException();
    const payload = jwt.verify(token, process.env.SUPABASE_JWT_SECRET);
    req.user = { id: payload.sub, role: payload.role };
    return true;
  }
}

Answer:

• One identity, scoped roles: A user has a role plus the portals/permissions they're entitled to. I encode role in the JWT and keep fine-grained permissions in the DB.
• Guard + decorator pattern in NestJS: A @Roles('admin') decorator with a RolesGuard declares the requirement at the route, applied at the controller level so it's auditable rather than copy-pasted per handler.
• Defense in depth: RBAC in the API plus RLS in Postgres, so a misconfigured route still can't leak cross-portal data.
• Never trust the front end for authorization — hiding a button is UX, not security.

Answer:

• Never use floats. Floating point can't represent decimal currency exactly. I store amounts as integers in the smallest unit (paise) using BigInt, or Postgres NUMERIC for fractional rates.
• Compute in integer space and format to currency only at the display edge.
• Wrap multi-step writes in a transaction so a partial failure (e.g. record deal closure + write ledger entry) never leaves inconsistent state.
• Append-only audit ledger for anything money-related — corrections are new entries, not edits.

Answer:

Network retries and double-clicks happen. For a financial action like committing a deal or recording a payment, processing the same request twice is dangerous.

• The client sends an Idempotency-Key header (a UUID) with the request.
• The server stores the key with the result on first processing; a repeat with the same key returns the stored result instead of re-executing.
• I make consumers of any queue/event idempotent the same way, keyed on a business id.

Answer:

• No secrets in code or git — only env vars, with .env gitignored.
• Right scope: The Supabase service-role key lives only on the NestJS server (Railway) — never in the Next.js client bundle. Only the anon key and public URL are exposed client-side, and only via NEXT_PUBLIC_-prefixed vars.
• Per-environment config: Separate Supabase projects / env values for dev, staging, prod so a test never touches production data.
• Rotate on leak: If a key ever lands in a diff, rotate it immediately.

Answer:

• Clarify the problem: Confirm with the Founder what user pain we're solving and what "done" means.
• Wireframe the flow: A low-fidelity sketch of the screens and the happy path — cheap to change, fast to align on.
• Thin vertical slice (MVP): Build one real end-to-end path (UI → API → DB) with Tailwind for speed and Claude Code to move fast. Validate it live with the Founder.
• Harden: Add validation, auth, edge cases, error states, and audit logging. Then ship behind a flag if risky.
• Iterate on feedback rather than gold-plating up front — speed and learning beat perfection.

Answer:

• Set guardrails up front: An agreed architecture, conventions, and a definition-of-done so reviews aren't subjective.
• Review for the things that bite later: data-model decisions, auth/authorization, money handling, migration safety, and security — not bikeshedding on style the linter already enforces.
• Track delivery transparently: Clear scope, milestones, and a visible board so timelines slip loudly, not silently.
• Unblock fast: My job is to remove ambiguity for them — sharp specs, quick answers, and decisions made and owned.
• Verify, don't assume: I pull their branch and run it, rather than trusting a status update.

Answer:

• Frame it in terms of outcomes: speed, cost, risk, and what the user feels — not jargon.
• Offer 2–3 concrete options with the trade-off of each ("Option A ships this week but we'll revisit search performance at 10k deals; Option B takes two more days but scales").
• Give a clear recommendation and the reasoning, so the Founder can decide quickly.
• Make the decision reversible where possible so we can move fast without betting the company on it.

Answer:

• In-house: Fast-iterating, product-defining pieces — wireframes, MVPs, the matching-engine logic, anything the Founder and I need to learn from quickly.
• Agency: Larger, well-specified build-out where the requirements are stable and parallel capacity helps.
• The deciding factor is iteration speed and ownership: if rapid back-and-forth with the Founder is the bottleneck, I keep it in-house so there's no agency round-trip.

Answer:

• Unit tests for business logic with the Prisma client mocked, so I test the matching rules in isolation.
• Integration tests against a real Postgres (a disposable test database or a container) so I exercise actual Prisma queries and migrations — mocking the DB hides query bugs.
• E2E tests for critical flows (create deal → match → invite → view doc) hitting the booted Nest app.
• Regression test on every bug: a test that fails before the fix and passes after.

Answer:

• Build from git: Railway builds the NestJS service on push; env vars are managed in the Railway dashboard, separated per environment.
• Health checks & migrations: Expose a health endpoint and run prisma migrate deploy as a release step so schema and code ship together.
• Stateless service: No in-memory session state, so it scales horizontally; session/auth state lives in Supabase.
• Observability: Structured logs and error tracking so I can debug production quickly with a small team.

Answer:

• Cache the safe stuff: Reference data and read-heavy, slow-changing lists (sector taxonomies, public deal summaries) — not live balances or deal status.
• Short TTLs + explicit invalidation on write, so a deal update busts its cache entry immediately.
• Never cache authorization decisions across users — a cache key always includes the requesting user's scope.
• Measure first: I'd only add caching where profiling shows a real hotspot, to avoid correctness risk for no benefit.

Answer (STAR):

• Situation: At 1Finance I owned full modules (Magazine, In-the-News V3, HR Conclave admin) where requirements were loose and I was the sole engineer on them.
• Task: Take each from a rough product ask to a shipped, production feature without a detailed spec handed to me.
• Action: I clarified the actual user need, designed the schema and API, built the Fiber endpoints with DB-backed JWT + per-endpoint RBAC, wrote idempotent encryption backfills for legacy rows, and shipped iteratively — validating with stakeholders rather than guessing.
• Result: Each module shipped end-to-end and is in production. That's exactly the "own it, move fast, fill the ambiguity yourself" posture this first-engineer role needs.