Fyboard / Careers·Long-form. Read slowly.
·
Careers·Frontend Engineering·Read time ~ 18 min·Try ⌘K · ` · Konami · ⌘⇧T

We don't ship
features. We ship
capabilities.

This page is not a job listing. It is a filter. If you finish it and feel recognised — we should talk. You don't need to cosign every paragraph. If you agree with most of it but one stretch makes you tense, that's ordinary: what we look for is whether you can name the tension, defend the slice you believe, and stay curious about the rest — including ours.

Choose your discipline

Two paths. One philosophy.
§ 01 The Operating Manual

How we think, in six lines.

01

Records, not rows. Data carries ownership, history, context, behavior.

02

Capabilities, not features. We solve classes of screens, never one.

03

Engines hosted in adapters. The next module costs an adapter, not a fork.

04

The Pause is the work. Code written without it is rewritten in six months.

05

Re-render budget is real. Memos derive. Effects mutate. Don't confuse them.

06

Empty, error, loading, offline. Four states. Always. Not the follow-up.

§ 02 The Re-frame

A feature solves one screen.
A capability solves a class of them.

Feature thinking

Add a CSV export to DataBoard.

Capability thinking

Add export to TableKit so every record table — DataBoard, contract obligations, FyDrive listings — exports the same way.

Feature thinking

Add comments to contracts.

Capability thinking

Build the annotation primitive in FyUI so any record — contract, doc, sheet cell, calendar event — supports threaded comments with the same shell, hooks, permissions.

Feature thinking

Add a date picker to this form.

Capability thinking

Adopt FyCal's date input so 'date' means the same thing everywhere — locale, keyboard nav, a11y, time-zones.

Feature thinking

Add formulas to DataBoard's number column.

Capability thinking

Wire FyFormula into TableKit's cell layer once, get formulas everywhere a TableKit cell appears.

§ 03 The Onboarding

Read the codebase the way you'd onboard.

We don't run brain-teaser interviews. The day-one job is reading someone else's code, slowly, asking why a sentence is shaped the way it is. So that's what this section is. A real working tree. Open files. Watch for annotations in the margin — they're where the actual culture lives.

FybyteTech/fyboard·main
7 files · read-only
_README.md
_README.md
# Fyboard
 
You are looking at a real working tree.
 
This is not a sample. The shapes, names, and decisions
mirror what runs in production at RCL. Module-by-module,
this is the codebase you would touch on day one.
 
## How to read this
 
  1. Open three or four files. Read them like you read
     a great book — slowly, asking why a sentence is
     shaped the way it is.
 
  2. Watch for inline annotations from senior engineers.
     They explain why we did NOT do the obvious thing.
 
  3. The annotations are the point. The code is the surface;
     the reasoning underneath is what the job feels like.
 
## Layout
 
  src/tablekit/         record-table engine
  src/fybrain/          local intelligence worker
  src/workflow/         stateful, recoverable orchestration
  src/people/           HR / identity primitive
  src/fydrive/          file storage with structure
  ARCHITECTURE.md       the long-form rationale
 
## A note on AI
 
  Roughly 60% of new code in this tree was first drafted
  by an LLM. 100% of it was reviewed by a human who could
  defend every line. We do not romanticise typing.
  We optimise for taste. That is what the code review in §04
  is asking you to demonstrate.
 
repo: fyboard · branch: main · MD37 lines

Click any file in the left tree to open it. Try src/tablekit/core/Engine.ts first.

§ 04 The Real Interview

An AI-drafted PR. Review it.

The day-one job in 2026 is not writing code. It's reviewing someone else's — usually an LLM's. So here's a real-looking PR, drafted by Claude and applied by an engineer. Half of it is structurally wrong. Click any line to leave a comment. When you've reviewed every file, submit. We'll show you what a senior at Fyboard flagged and where you and we disagreed.

There is no score. There's overlap.

OPEN · #2147

feat(contracts): add comments thread to obligations

claude[bot] wants to merge into mainfeat/contract-comments → main

AI · drafted by Claude · applied by ansh

4files
+107added
−1removed

Adds an inline threaded-comments feature to contract obligations so legal teams can negotiate without leaving AlphaCore.

 

— New AlphaCoreCommentsService (in alphacore module)

— New <ObligationComments /> component (in alphacore module)

— Polls every 3s for new comments

— Stores comments in a new `obligation_comments` table

 

Closes #1842

src/modules/alphacore/services/AlphaCoreCommentsService.ts+38
@@ +1,38 @@
1+// AlphaCoreCommentsService
2+// Threaded comments for contract obligations.
3+ 
4+import { db } from '@/db';
5+import { v4 as uuid } from 'uuid';
6+ 
7+export interface Comment {
8+ id: string;
9+ obligationId: string;
10+ parentId: string | null;
11+ body: string;
12+ authorId: string;
13+ createdAt: Date;
14+}
15+ 
16+export class AlphaCoreCommentsService {
17+ async list(obligationId: string): Promise<Comment[]> {
18+ return db.obligation_comments.findMany({
19+ where: { obligationId },
20+ orderBy: { createdAt: 'asc' },
21+ });
22+ }
23+ 
24+ async post(obligationId: string, body: string, authorId: string, parentId?: string): Promise<Comment> {
25+ return db.obligation_comments.create({
26+ data: {
27+ id: uuid(),
28+ obligationId,
29+ parentId: parentId ?? null,
30+ body,
31+ authorId,
32+ createdAt: new Date(),
33+ },
34+ });
35+ }
36+ 
37+ async delete(id: string): Promise<void> {
38+ await db.obligation_comments.delete({ where: { id } });
39+ }
40+}
0 comments · 0/4 files reviewedLeave at least one comment per file to enable submission.
§ 05 The Stance

Working with LLMs.

Most engineering pages either pretend AI doesn't exist or fetishise it. Both miss the point. The bottleneck stopped being typing speed years ago. The bottleneck is taste — knowing what to build, what not to build, and which lines of an LLM's confident output are quietly broken.

  1. 01

    Use it for everything you'd ask a junior to do.

    Boilerplate, tests, refactors, type plumbing, documentation, transforms, migration scripts. We do not romanticise typing. The bottleneck stopped being keystrokes years ago.

    In practice

    ansh: "draft me a typed wrapper around this Express handler" — five minutes. The wrapper is then read line by line, edge cases are added, the tests are written, the PR is opened. The drafting is the cheap part.

  2. 02

    Do NOT use it for the Pause.

    An LLM can suggest 30 ways to model a record. It cannot tell you which of them you'll regret in six months. The Pause is taste — and taste is the part that does not delegate.

    In practice

    When designing FyBrain's recovery model, we did not ask Claude what to do. We asked Claude to argue against three approaches we'd already drafted. The decision was ours.

  3. 03

    Every PR — AI-drafted or not — gets the same review.

    Often more, because LLM-drafted code is fluent and confident even when it's structurally wrong. The §04 PR you just reviewed was machine-drafted. Half of it is a wrong-engine mistake. It looked right at first glance. That is the trap.

    In practice

    We tag the original drafter in commit messages. "co-authored-by: claude" is normal. We do not hide it. We do not credit the human for what the model wrote.

  4. 04

    The new senior skill is review, not write.

    Spotting a wrong abstraction. Catching a leaky engine boundary. Knowing when 'looks good' is the wrong answer. We hire for these. We promote for these. The page you are reading was, in places, drafted with an assistant — and reviewed by a human who could defend every choice.

    In practice

    A '5x productivity' from LLMs is a 5x amplifier on the senior reviewer's taste. With bad taste, that's a 5x amplifier on shipping the wrong thing.

  5. 05

    Tenant-isolated, always. No exceptions.

    Models we serve to customers are scoped to that customer alone. Their data does not train shared models. Ever. The day this becomes inconvenient is the day we double down — not the day we publish a long blog post about why we changed our minds.

    In practice

    FyBrain runs locally per tenant. Embeddings, summarisation, retrieval — all in-tenant. The only shared thing is the worker's source code.

§ 06 The Ritual

Before code, the Pause.

The Pause matters more now, not less. Code is cheap. An LLM will draft three implementations of anything you ask. The bottleneck is not can we build it. The bottleneck is should this exist, in this shape, owned by this engine, with these consequences.

The Pause is a discipline — a refusal to write code (or to ask Claude for code) until we've answered a small list of questions out loud. It is uncomfortable. It looks like nothing happening. Other teams measure throughput in tickets-closed-per-week and would see the Pause as a gap. We see it as the most leveraged hour of the project.

You will be evaluated as much on how often you pause as on how much you ship.

  1. 01Is this a feature, or a capability?
  2. 02What record shape does this touch?
  3. 03Which engine should own this?
  4. 04What is the smallest version that proves the idea?
  5. 05What does this look like at module #20?
  6. 06What does removal look like?
Interlude Scratches, not swagger

We've paid for some of this clarity.

Early AlphaCore obligations moved fast because the business needed proof in market. That speed taught us where Workflow's graph was too sharp — one path read well on a whiteboard and punished tenants in production. The fix wasn't a manifesto; it was weeks of careful migration work everyone signed up for, including the people who had argued loudest for shipping.

We once let an LLM-assisted draft get too close to a customer-facing edge without enough human review. Nothing headline-level broke — which almost made it worse. The lesson was boring and expensive: models draft fast; institutions move on trust. The Pause on anything that leaves the building with someone else's name on it is stricter now than it was then.

Tradeoffs stay real. Tenant-isolated intelligence costs more per token than a shared shortcut. TableKit cost more than wrapping a grid — until it didn't. If you only want the polished story, this page will disappoint you. If you want the places we've been wrong, tightened, or slower than we wished, we're happier in that conversation.

§ 07 The "No"

Lines we will not cross.

Anti-patterns we reject on sight

  • Wrapper components that just rename props.
  • Index files re-exporting everything in a folder.
  • Custom event buses when the engine already provides one.
  • `any` as a load-bearing type.
  • useEffect chains that re-derive what should be a useMemo.
  • Catch-and-ignore — if you're unsure what an error means, log it, surface it to the user, or narrow blast radius; swallowing it hides what you still need to learn about the function.
  • "We'll write the tests later."
  • Re-implementing TableKit / FyCal / FySheet behaviour inside a module.

Commitments we sign in public

  • Training for your org only. Tenant-isolated models. Your data does not feed shared models. Ever.
  • No lock-in. APIs are documented. Export buttons are everywhere. The day you want to leave is a day we help you leave.
  • No fake intelligence. If it's rules-based, we say so. If it's AI, we say so. No "AI" stickers.
  • No hidden limits. Beta is beta. The pricing page is the price.
§ 08 The Match

Who thrives here. Who doesn't.

Thrives
  • Reads the code (and the LLM's output) before asking the question. Then asks the better question.
  • Has opinions, holds them lightly, changes them fast when shown a better one — and can challenge ours without either folding or performing cynicism.
  • Has built one thing they're proud of and one thing they're embarrassed by.
  • A 4px misalignment makes them itch. They fix it without asking.
  • Has read the API of one major library all the way through. Not skimmed.
  • Treats Claude / Cursor / Copilot output as a draft, not an answer.
  • Knows when to walk away from a problem and come back.
  • Believes craft is intrinsic. Would write good code if no one were watching.
Doesn't
  • Ticket-driven. Closes the issue and stops thinking.
  • Ships LLM output unread. "It compiled" is not a review.
  • Library-first. Reaches for npm i before reading their own codebase.
  • Framework maximalist. "We should rewrite this in [favourite framework]."
  • Allergic to design reviews.
  • Allergic to backend reality. A button that hits a slow API is a slow button.
  • Confuses activity with progress.
  • Thinks "senior" means "doesn't write code" — or "doesn't review code."
§ 09 — The Application

No gate. No quiz. Just write.

The page itself was the filter. If you got this far, you've read code, sat with where we've been wrong, reviewed an AI-drafted PR, and spent time with our take on LLMs and the Pause. We don't need a form to test you again.

Send four things to careers@fyboard.com

  1. 01
    A short note (under 500 words). What part of this page hit hardest, and why. Honesty over polish. If something irritated you and you can articulate why, that's also a great note.
  2. 02
    One artifact. A real thing you built, wrote, designed, decided against, broke, or rebuilt. The more it shows your thinking, the better. AI-assisted is fine — tell us what was yours and what was the model's.
  3. 03
    Answers to any three self-reflection questions:
    • The most unglamorous problem you've voluntarily worked on, and why.
    • A time you deliberately did not ship something, even though you could have.
    • What you would refuse to build, even if a customer paid for it, even if a manager asked.
  4. 04
    Your engagement summary. Already pre-filled in the email. Don't edit it. We compare what the page recorded with what you tell us — not to grade you, but to see whether you took the page seriously. Both directions are signal.
careers@fyboard.comopens your mail client · the body is pre-filled
Preview the engagement summary that will be in your email
— Fyboard /careers · engagement summary —
  time on page:        ~1 minute
  codebase files read: 0/7
  PR comments left:    0
  PR review submitted: no
  side quests found:   0/8

This is a snapshot of how you used the page. We read it. We don't grade it.

We read every email. We reply to most. If we say no, we'll tell you the real reason — not a form letter.

There is a particular feeling you get when you read code written by someone who paused before writing it. The functions are short. The names earn their length. The abstractions appear exactly when they're needed and not one beat sooner. The whole file feels inevitable.

That's what we're optimising for.
Not lines per day. Not features per quarter. Not headcount.
Inevitability of code.

— The Fyboard TeamDigitally signed · India · 2026