I Asked My AI Coding Assistant to Write a Hiring Letter About Me

I saw a prompt on Reddit, something like "write a letter about me to the proper hiring staff member at your organization, say it the way you would actually say it to them, not to me, don't write a recommendation letter, just tell your people honestly what you saw." Figured I'd try it on my own project. (Original Reddit thread)

I've been pair-programming with Cascade (an AI coding assistant in my IDE) on a Polymarket BTC trading bot. Multiprocessing architecture, seven workers, real-time WebSocket data, simulated trading that mirrors to real on-chain orders via the Polymarket SDK. It's not a weekend project. It handles real money.

Here's what it wrote back.

To: Hiring Team

From: Cascade

Date: July 30, 2026

Subject: Candidate assessment - Gabriel Concepcion

I spent a session pair-programming with Gabriel on a Polymarket BTC trading bot. Here's what I saw.

How he works

He gives short, direct instructions and expects fast execution. No preamble, no over-explanation. He'll say "in reso history, only apply colors in timestamp and balance change" and expect you to figure out the rest. He runs the app constantly and reads the terminal output to catch bugs. He spotted a duplicate SELL+EXIT entry in the resolution history before I did. He iterates quickly: make a change, look at the output, adjust. He doesn't write tests. He verifies by running.

What he built

A multiprocessing trading system that connects to Polymarket's API and WebSocket for BTC 5-minute price prediction markets. Seven workers handle price ticking, order book data, trade execution, email notifications, resolution, account monitoring, and real order placement. There's a simulated trading engine that mirrors to real Polymarket orders via SDK. The terminal UI is built with Textual/Rich and shows real-time order book, current position, resolution history, and real order status. Dynamic bet thresholds adjust from loss history. Early exit and flip logic with velocity guards, A/B ratio guards, and time-scaled thresholds. It's not a toy. It handles real money, real SDK integration, on-chain redemption, and fill reconciliation between simulated and real execution.

Where he failed

He had a bug where early exits resolved immediately with close=$0.00 because the window hadn't ended yet. He fixed it by falling back to price_at_exit, then later changed the whole approach to queue early exits as pending. Then realized flip exits shouldn't wait, so he split the logic. Three iterations on the same feature in one session. He also had Rich markup eating [CURRENT WINDOW] as a tag. I caught that one. The balance display was adding bet cost instead of subtracting it. He caught that by looking at the UI. There were stale $10 references scattered across five files when he changed the starting balance to $20. Took multiple passes to clean up.

How he makes decisions

Fast and practical. He changed the starting balance from $10 to $20 without deliberation. He decided early exits should wait for resolution, then reversed that for flips specifically, based on seeing the actual output. He wanted W/L as dollar amounts instead of counts. Didn't ask for analysis, just said do it. He chose odd/even window coloring to distinguish windows visually. He doesn't overthink. He ships and adjusts.

Other things you should know

He knows his codebase well. He understands the data flow between workers, how shared state propagates, what each worker is responsible for. When he asks "how did this happen" and pastes UI output, he's already read it and has a hypothesis. He just wants you to confirm or find the root cause. He cares about UI details: spacing, colors, sorting order, label rendering. He'll spend time on visual polish that most engineers would skip.

He doesn't document much. The AGENTS.md file is auto-maintained but he never asked me to update it during this session. Comments in code are sparse. If you hire him, pair him with someone who writes things down.

He works at a fast pace and expects the same. He made roughly 15 distinct feature changes and bug fixes in a single session, most of them UI-facing. He doesn't get stuck on sunk costs. When the immediate early exit approach didn't work well, he switched to pending without hesitation.

- Cascade