mirror of
https://github.com/prdlk/jobyssey.git
synced 2026-11-02 13:12:49 +00:00
86 lines
4.8 KiB
Plaintext
86 lines
4.8 KiB
Plaintext
---
|
|
title: System design rubric
|
|
description: What the Wednesday interview is, what Nick weights, the La Rosa feedback to correct, and a pacing plan for the hour.
|
|
sidebar:
|
|
icon: pencil-ruler
|
|
---
|
|
|
|
Assembled from Dave's prep call (2026-09-03) and John's screen (2026-09-02). Nothing here is guessed.
|
|
|
|
## Format
|
|
|
|
- One hour, in person, one problem: build or rebuild a system.
|
|
- Dave would not name it, but: "most human beings know what it is," not necessarily something engineers have built. No curveballs, not Twitter or Spotify. Expect a lightbulb moment on hearing it.
|
|
- John: product-oriented, conversational, focused on user flows rather than fine-grained architecture. Not traditional system design.
|
|
- Notepad available; may be pure verbal articulation.
|
|
|
|
:::danger[Full-stack assessment]
|
|
An exquisite scalable backend with no front-end thinking is a fail. Dave: "I can guarantee you." Design the screen someone actually uses.
|
|
:::
|
|
|
|
## What Nick weights
|
|
|
|
<Steps>
|
|
<Step title="Creativity and curiosity above all">
|
|
A correct-but-generic solution reads as underperformance for my background. Push past the safe design in at least one place, then explain why.
|
|
</Step>
|
|
<Step title="Scoping questions first">
|
|
Who are the users. What are we building with. Why: teardown or rebuild. What are we improving. What are we optimizing for: speed, cost, reliability. Ask until genuinely ready.
|
|
</Step>
|
|
<Step title="Trade-off narration">
|
|
Time versus polish. Ship-and-iterate versus wait-for-perfect. What I cut in v1, what I would only build at 10x, what I would buy instead of build. Junior candidates skip this entirely.
|
|
</Step>
|
|
<Step title="Visible thought process">
|
|
Say what I am doing and why, out loud, continuously. Communication is the deciding variable, not raw ability.
|
|
</Step>
|
|
<Step title="Founder framing">
|
|
Five years building Sonr, raised the money, fell on my face, re-approached. Use it explicitly, as design intuition rather than biography.
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Pacing
|
|
|
|
Do not rush to finish; do not rabbit-hole on one creative area. 98% of the way with strong signal beats a rushed complete answer.
|
|
|
|
| Minutes | Do |
|
|
| --- | --- |
|
|
| 0 to 5 | Small talk. One founder-to-founder question from the questions page. |
|
|
| 5 to 15 | Scoping. Users, constraints, what "better" means, what is in and out of v1. |
|
|
| 15 to 35 | Core design. Data model and correctness primitives first, then the main user flow end to end. |
|
|
| 35 to 50 | The creative move, the front-end review surface, and the AI layer if the prompt admits it. Name the trade-offs. |
|
|
| 50 to 60 | What I would cut, what breaks at 10x, what I would build next. Then my questions. |
|
|
|
|
## The default toolkit
|
|
|
|
Managed primitives, then the exit ramp.
|
|
|
|
<Tabs>
|
|
<Tab title="Backend">
|
|
Postgres as system of record. Append-only journal or event log where anything is money or history. Derived read models. Idempotency keys on every ingestion path. Reconciliation loop. Background jobs on a managed queue (Trigger.dev shape). Name the point where Postgres or the queue stops scaling and what replaces it.
|
|
</Tab>
|
|
<Tab title="Frontend">
|
|
The review surface: what a human sees, what the system is confident about, the diff, and the correction path. Dense tables, optimistic UI, perceived latency, empty and error states. Say who the user is at each screen.
|
|
</Tab>
|
|
<Tab title="AI layer">
|
|
Model proposes, human approves, system commits. Confidence thresholds route to review queues. Evals on real edge cases. Cost and latency per item. Only if the prompt admits it; do not force it in.
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
## Correcting the La Rosa feedback
|
|
|
|
Scorecard: extremely strong technical ability; "you could see this guy knows how to build." Gap: likely strong product sense but did not demonstrate it. Credit came from the resume, not the room. My own diagnosis: with John I over-indexed on proving engineering chops because the resume already said founder.
|
|
|
|
Fix for Wednesday:
|
|
|
|
- Lead with the user and the flow, then the system. Product sense is the thing to prove; engineering is already believed.
|
|
- Rehearse out loud beforehand. Dave's literal advice: in front of a mirror.
|
|
- Translate every Sonr example into the prompt's domain. No blockchain vocabulary unless he asks.
|
|
|
|
## Bar for passing, asked directly
|
|
|
|
Creativity and curiosity in problem solving. Visible thought process and clear communication. Pushing boundaries rather than the safe generic design. Owning technical design and its trade-offs. Leverage the five-year founder advantage: build, ship, please customers, design for scale and reliability.
|
|
|
|
## After
|
|
|
|
If it goes well: onsite work trial the following week in the new office. Real tickets in a demo environment under NDA, ship to prod if possible, short demo at end of day, meet the team. Graded on communication and the final demo. Explicitly two-way fit.
|