Files
calvana/application-answers.md

196 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 🎯 Omair Saleh — Full-Stack Engineer Application @ Calvana LTD
## The Outlaw Application
---
## Field 1: Full Name
```
Omair Saleh
```
## Field 2: Email Address
```
omair@quikcue.com
```
## Field 3: LinkedIn / Personal Site / Portfolio
```
https://www.linkedin.com/in/omair-rescues/
```
> 💡 If quikcue.com is live, use that. Custom domain > LinkedIn every time.
## Field 4: GitHub or Equivalent
```
[Your GitHub URL here]
```
> 💡 Pin the charity platform, the Hub, and the outreach agent. Let the commit history speak.
## Field 5: Location
```
Kuala Lumpur, Malaysia — happy to overlap with London hours. I work when the work needs doing, not when a calendar tells me to.
```
## Field 6: Employment Status
> **Select: "Running my own thing"**
---
## Field 7: 🔥 "Describe something you built end-to-end"
```
A UK charity came to me with a problem: their donation flow was bleeding donors. Poor conversion, no recurring giving, no peer-to-peer fundraising, no Gift Aid automation. They didn't hand me a spec. There was no spec. There was a problem and a deadline.
So I built the whole thing. From the database schema to the Stripe webhook handlers.
Next.js 15 frontend. PostgreSQL with Prisma. Stripe for payments — PaymentIntents for one-off, SetupIntents for recurring. I designed a multi-step checkout with progressive disclosure because I know that every extra field before the payment button is a donor you'll never see again.
Nobody told me to handle Zakat compliance. I just knew that if a Muslim donor selects Zakat, admin fees need to auto-disable — it's a religious obligation, not a suggestion. So I built it. Nobody told me to move Gift Aid capture to post-payment either. But I knew that asking a donor for their home address BEFORE they've committed to giving is how you kill conversion. So I moved it. HMRC still gets what they need. The charity gets more donations. Problem solved.
Then I built the P2P fundraising engine — individual pages, team pages, leaderboards, URL-based attribution — architected as its own domain service because I could see it would need to scale independently. Then an admin dashboard. Then a Chatwoot integration for donor support, white-labeled with a Chrome extension I wrote because the dev workflow needed it. Then a data sync pipeline using Playwright to scrape donor CSVs from LaunchGood and reconcile them into Postgres with strict deduplication.
No PM. No Jira board. No sprint ceremonies. Just me, the problem, and the production environment.
This is what I do. I see a mess, I build the system, I ship it. In a corporate environment, this gets me in trouble — I've been told I "move too fast", I "don't follow process", I "should wait for alignment." At a startup, this is the only speed that matters.
```
---
## Field 8: Link to Something You've Built
```
[Link to your charity donation platform or best GitHub repo]
```
---
## Field 9: 🔥 AI/ML API Experience
```
I don't prototype with AI. I ship with it. There's a difference.
1. AI Outreach Agent: A charity needed to find and contact decision-makers across the entire UK charity sector. Hundreds of thousands of records. I built a Python pipeline that ingests raw Charity Commission data into PostgreSQL, then uses OpenAI to translate natural language queries ("large education charities with income over £1M operating nationally") into SQL filter logic via a custom segment engine. Once leads are qualified, OpenAI generates personalised outreach assets — emails, talking points — based on each charity's actual profile, income band, and sector. Not templated mail-merge garbage. Actually personalised. Then it enriches contacts through Apify to find the CEO, Director, or Head of Fundraising. The whole thing runs from a CLI with deterministic Python scripts underneath — the AI makes decisions, but the infrastructure is boring and reliable. On purpose.
2. Conversation Intelligence (Hub Platform): Built into a B2B customer service platform. When a support agent opens a Chatwoot conversation, the system pulls the customer's order history from Salla, their previous interactions, and uses OpenAI with structured function calling to suggest contextual responses grounded in real data. Not vibes-based autocomplete — actual responses that reference real order numbers and real product names. I built it this way because I've seen what happens when you let AI hallucinate in customer-facing contexts. It destroys trust instantly.
3. AI Command Center: This one's borderline unhinged. An autonomous multi-agent system that runs on a 15-minute cron cycle. Reliability agent monitors Sentry. Code-steward reviews MRs on GitLab. Product-driver agent analyses codebase health metrics from Postgres/MySQL and proposes improvements. But — and this is the part that matters — nothing executes without human approval. I built a full safety layer with auto-pause on excessive API spend, command allowlists, and dry-run mode. Because I learned early that autonomous AI without kill switches is just a very expensive way to break production.
The real lesson across all of these: the API call is the easy part. The hard part is building the deterministic scaffolding that makes AI trustworthy — retry logic, structured outputs, cost ceilings, caching layers, human-in-the-loop gates. Anyone can call OpenAI. I build the systems that make it safe to let OpenAI call the shots.
```
---
## Field 10: Tech Skills Rating
| Technology | Select This |
|---|---|
| **React / Next.js** | **production-level experience** |
| **Python / Django** | **strong experience** |
| **PostgreSQL** | **production-level experience** |
| **AWS** | **decent experience** |
| **REST API design & integrations** | **production-level experience** |
| **OAuth** | **strong experience** |
| **CI/CD & Deployment Pipelines** | **strong experience** |
| **Docker / containerisation** | **strong experience** |
> Don't inflate. Let the project descriptions do the talking. Honesty here builds trust for everything else.
---
## Field 11: 🔥 "Why does this role interest you specifically?"
```
I'll be honest: I'm a terrible employee.
Not in the way you'd think. I ship fast, I write clean code, I own my systems end-to-end. But I've learned the hard way that I don't survive in environments where shipping requires three meetings, two approvals, and a Confluence page nobody reads. I've been told I "go rogue." I've been told I "need to wait for the team to align." I've sat in sprint planning sessions thinking about the three features I could've shipped in the time it took to estimate the story points.
That's not a personality flaw. It's a misallocation.
Your job post reads like someone wrote it specifically for people like me. "This isn't a role where you'll have a dedicated PM writing specs." Good — I've never needed one. "This isn't a role where 'that's not my job' is a useful phrase." I literally built a Chrome extension because my dev workflow for a Chatwoot integration was annoying me. Nobody asked me to. The friction existed, so I killed it.
But here's what actually made me stop scrolling and pay attention:
You have cash, audience, distribution, and PMF. You DON'T have engineers. That's the most dangerous inflection point for a startup — the gap between "this works" and "this scales." That gap gets filled by someone who can pick up an entire problem, architect a solution, ship it as a microservice, and move on to the next one without waiting for permission. I've been doing exactly that for the past year: a full donation platform with Stripe, P2P, and Gift Aid compliance. A multi-service B2B operations hub with 30+ services, AI automation, and real-time event processing. An outreach engine that processes hundreds of thousands of leads with AI. All end-to-end. All without a PM.
Your stack is my stack — Next.js, Python, PostgreSQL, Stripe, OAuth, Docker. Your AI ambitions are things I've already built. Your microservices architecture is how I think.
I watched Charlie's Loom. "We're going to the moon with this thing." I believe it. And I know that the difference between going to the moon and talking about going to the moon is having someone in the engine room who builds without asking for permission.
That's me. I'm the guy in the engine room.
```
---
## Field 12: Salary Expectation
```
£50,000£65,000 GBP/year — flexible on structure. If the equity conversation is real, I'm more interested in upside than ceiling.
```
---
## Field 13: How soon could you start?
> **Select: "Immediately"** — you're running your own thing, you set your own timeline.
---
## Field 14: 🔥 Loom Video Script (THE KNOCKOUT PUNCH)
```
[0:00-0:20]
"Hey Charlie — I'm Omair. I'll be straight with you: I'm a terrible fit
for most companies. I've been told I move too fast, I don't wait for
alignment, I build things nobody asked for. Turns out those are
features, not bugs — just depends on the environment. Your job post
reads like it was written for someone exactly like me."
[0:20-0:55] [SCREEN SHARE: Charity donation platform]
"Quick example. A UK charity had a broken donation flow. No spec, no PM,
no Jira. Just a problem. So I built this — end to end. Next.js 15,
Prisma, PostgreSQL, Stripe. Multi-step checkout, recurring giving, P2P
fundraising, Zakat compliance, Gift Aid for HMRC. Designed the schema,
wrote the webhook handlers, deployed it. That's how I work — give me the
problem, get out of the way."
[0:55-1:25] [SCREEN SHARE: Hub platform or AI outreach agent]
"Then there's this — an AI outreach engine I built. Ingests hundreds of
thousands of charity records, uses OpenAI to segment and qualify leads,
generates personalised outreach. The AI is wrapped in deterministic
Python with cost controls and approval gates — because I've learned that
AI without guardrails is just an expensive way to break things."
[1:25-1:50]
"Your post said 'we have cash, audience, distribution, and PMF — we just
need YOU.' I felt that. I've spent the last year building entire systems
solo — the donation platform, a B2B SaaS hub with 30+ microservices, AI
agents running on cron cycles. No PM, no sprint ceremonies. Just
problems and production. That's the only way I know how to work — and
it sounds like that's exactly what you need."
[1:50-2:00]
"I don't need onboarding. I need a problem and a git repo. Let's talk."
```
---
## ⚡ PRE-SUBMIT CHECKLIST
- [ ] GitHub pinned repos updated and READMEs are clean
- [ ] LinkedIn headline: "Full-Stack Engineer | I build things nobody asked for"
- [ ] All answers proofread — raw ≠ sloppy
- [ ] Loom recorded — show real projects, show real energy, close hard
- [ ] quikcue.com email shows you're a founder, not an applicant
---
## 🎭 THE OUTLAW POSITIONING — WHY THIS WORKS
The entire job posting is a filter for people who **can't survive in corporate**:
| What Their Post Says | What It Actually Means | Your Outlaw Angle |
|---|---|---|
| "No PM writing specs for you" | We need self-starters | "I've never needed a PM. I AM the PM." |
| "Not just one part of the codebase" | Generalists only | "I built frontend, backend, infra, Chrome extensions, data pipelines — in one project." |
| "'That's not my job' isn't useful" | Ego-free builders | "I built a Chrome extension because a workflow annoyed me. Nobody asked." |
| "Ambiguity of early-stage work" | Chaos tolerance required | "Chaos is where I do my best work. Structure is where I suffocate." |
| "No AI screening — we read every app" | Charlie reads this personally | You're speaking directly to a founder. Be human. Be direct. |
**The core message in every answer:** *The things that make me a liability in corporate make me your most valuable hire. I don't wait for permission. I don't need process. I see problems and I ship solutions. That's why big companies don't know what to do with me — and it's exactly why you should.*