09 — study & Assessment Conversion¶

Thirteen months of C is a losing bet if it never converts into something real — a role change, a promotion, a project ownership, a remote job. This file is the conversion strategy. It exists as the final discipline file because it is the last mile, and reading it before Month 8 is premature and mostly a distraction.

Read this file at Month 8. Not before. The rungs you build in M1–M7 are the ammunition; this file is when you learn to aim.

The three conversion vectors¶

You have three plausible paths out of the current position. Rank them by fit, not by aspiration.

Vector 1: Internal Zoho move to a systems-heavy team¶

Zoho has systems-heavy teams: Catalyst infrastructure, ZeptoMail, WorkDrive backend, ManageEngine’s low-level bits, the internal DB/caching teams. An internal move requires: (a) manager alignment, (b) a portfolio the receiving team can evaluate, (c) a real skills gap they need filled.

Easiest to execute — no visa, no relocation, existing trust capital.
Portfolio rungs that unlock it: by Rung 5 (a real network service in C), you have enough to open the conversation. By Rung 7 (something with measurable performance work), you have enough to close it.
Timing: open the manager conversation at Month 9, not before. See below for the 3-question scenario.

Vector 2: External India — infra-adjacent startups and product companies¶

The target list, roughly:

Postman (Bengaluru offices, real systems work in the sync/proxy layer)
Postgres-adjacent Indian companies: EnterpriseDB India, Percona, any FDW-shop
Bengaluru infra startups: Hasura (GraphQL engine in Haskell but with systems roles), Chargebee (data plane), Razorpay (real-time payments), CRED (parts of the stack)
Deep-tech startups: chipset companies (InCore, Mindgrove), embedded/IoT firms
Product companies with real C/C++ needs: Adobe, Autodesk, Nvidia India
Moderate to execute — requires studying, but no visa lift.
Portfolio rungs that unlock it: Rung 7 minimum. Rung 8 or 9 preferred. LinkedIn presence matters here; blog matters more.
Timing: start applying at Month 10, ramp through M13.

Vector 3: International remote at ML-infra and systems shops¶

The target list:

Cloudflare (workers, edge runtime, real C in the stack)
Neon (Postgres-as-a-service, Rust-heavy but C-adjacent)
redis (Redis Ltd, Bengaluru presence too)
ML-infra shops: Modal, Baseten, Together AI, Fal, Fireworks AI — all need C for kernel work
Established remote-friendly infra: Datadog, Elastic, Confluent
Hardest to execute — competition is global, bar is high, time zones matter.
Portfolio rungs that unlock it: Rung 8 minimum, ideally Rung 9. A published benchmark that got HN attention is very close to a golden ticket here.
Timing: M11 onwards. Do NOT apply early with a weak portfolio — rejection here is memory-holed for 12 months by ATS systems.

Which rung unlocks which vector¶

Rung	Zoho internal	India external	International remote
Rung 1–2 (basics + small utils)	—	—	—
Rung 3 (data structures library)	Conversation-opener	—	—
Rung 4 (mini-shell / mini-interpreter)	Signal	—	—
Rung 5 (network service)	Move-ready	Application-ready	—
Rung 6 (concurrency-heavy service)	Move-ready	study-ready	—
Rung 7 (allocator / systems tool)	Strong	Application-ready	—
Rung 8 (measured ML kernel)	Strong	study-ready	Application-ready
Rung 9 (production-shape project)	Very strong	Very strong	study-ready

(Exact rung definitions live in 12_portfolio/.)

The system-design-in-C answer template¶

Expect at least one system-design question in every serious C study. Answer it with this shape:

Clarify the requirements out loud. Throughput target? Latency target? Persistence? Single-node or distributed? What am I optimizing for?
Draw the data flow. In your head or on the whiteboard. Where does the data enter, where does it leave, what’s the hot path?
Name the memory model FIRST. Who allocates what, who owns what, when is anything freed? In C, memory ownership IS the design.
Name the concurrency model. Single-threaded event loop? Thread pool? Fork per connection? Justify.
Name the failure modes. What can crash, what happens when it does, what’s recoverable, what isn’t.
Name the performance ceiling. “This design tops out at ~X requests/sec on 1 core because Y.” study partners listen HARD for this because it signals you understand your own design’s limits.
Only THEN discuss data structures and algorithms. Not first. Data structures come AFTER memory ownership.

If you answer in this order, you will sound like a systems engineer. If you jump to “I’d use a hash table” first, you sound like a bootcamp grad.

Common C study questions in 2026¶

Post-LLM-hiring-shift, the questions have moved. Old-style trivia (“what does static mean in this context”) is less common because everyone knows LLMs answer trivia. What’s up:

“Read this snippet and find the bug.” Very common. Usually a subtle UB, use-after-free, off-by-one, or integer overflow. Practice this weekly from M6 onwards.
“Design a memory allocator.” Classic, still asked, now with a follow-up: “okay, now make it thread-safe. Now make it lock-free for allocations under 64 bytes.”
“Given this function, how would you make it 10× faster?” They want to hear: profile first, then hypothesize, then measure. They want cache reasoning and branch reasoning. They do NOT want you to guess.
“Walk me through what happens when you call malloc(1024).” From libc entry to sbrk/mmap to page fault to return. Old-school but still separating.
“Debug this segfault — you have gdb, go.” Live debugging. Do a couple of mock sessions before you study.

What is LESS common now: syntactic gotchas, printf format-string trivia, obscure operator-precedence puzzles. Do not over-invest in these. Invest in bug-finding, design, and profiling.

The Zoho manager conversation — the 3-question scenario¶

At Month 9, you request a 30-minute conversation with your manager. Bring three questions. Do not lead with “I want to move teams.” Lead with the work.

“Here are three things I’ve built in the last 9 months that I think are relevant to the systems side of our infrastructure. Where do you see this landing at Zoho?” — Bring GitHub links, one blog post, one benchmark. Let the work do the pitch.
“Which teams inside Zoho do you think would value this kind of skill set?” — Now they name the team. You didn’t ask to leave; they suggested a home. Political difference is enormous.
“What would I need to demonstrate over the next 3–4 months to make a move like that credible?” — Now you have a specific ask and a specific timeline, agreed to by your manager.

What to bring, physically: a one-page PDF with the 3 projects, the 3-line description of each, and the link. Do not bring a resume; a resume signals departure. A one-pager signals ambition.

Mock study cadence¶

From M9 onwards: one mock every 3 weeks. Not weekly — weekly mocks are unrehearsed and produce noise. Every 3 weeks means you have time to process the last one before the next one.

Options, by cost and quality:

Pramp — free, peer-to-peer, quality varies wildly. Fine for reps.
studying.io — paid, real senior engineers, best signal quality. Worth 1–2 paid mocks around M11 as final calibration.
A Bangalore peer who is also studying — free, high signal if they’re strong, low signal if they’re not. Filter carefully.
A senior engineer at Zoho you trust — informal, low pressure, real insight into what senior study partners actually value. Ask.

After every mock: write a retro in your notebook. What went well, what fell apart, what you’d do differently. Same discipline as the sprint retros.

LinkedIn and resume phrasing¶

What to write:

“Built a multithreaded HTTP server in C achieving X req/sec on Y hardware” — concrete, measured, verifiable.
“Contributed to <open source project>: PRs merged: N” — links to PRs.
“Wrote about C systems programming; <X> readers, published on <personal blog + LinkedIn>” — signals output habit.

What NOT to write:

“Expert in C.” You are not, no one is, and calling yourself one to strangers is the exact tell that you aren’t. Even Linus doesn’t use that word.
“Deep understanding of the Linux kernel.” Not from this roadmap. You have a working understanding of userspace and syscalls. That is a lot; don’t inflate it.
“Designed and implemented X” when you followed a tutorial for X. Rename it: “Implemented X following <tutorial>, then extended with <my additions>.” Honesty here compounds.

The general rule: overclaiming is the fastest way to get filtered by senior study partners, because they can smell it in the first five minutes. Underclaim and let the work show its own weight.

The one-line pitch you rehearse¶

By M12, you should be able to say this in one breath, in an elevator, without notes:

“I write C that ships in production — from SIMD-accelerated ML inference kernels to multi-threaded network services — and I can debug someone else’s segfault at 2 AM without flinching.”

Say it out loud until it feels boring. When it feels boring to you, it will sound confident to them. That’s the whole trick.

Return to README.md · Next: ../99_pre_mortem/README.md