How Rustam Zokirov Thinks About Engineering Careers.
Speaker: Rustam Zokirov — Software Engineer at Google (5 years) Previously: built Uzbekistan’s national ID face recognition system. Session: 60+ attendees • 45 Q&A questions.
Most career advice is vague enough to be safe, unlike his.
1. The invitation is the signal. Take it.
If you get invited, you already passed a filter. Asking for two weeks “to prepare” doesn’t make you more ready.
Hiring managers lose enthusiasm. Other candidates advance. Internal priorities shift.
If you need a month to become acceptable, you’re not facing an interview problem. You’re facing a skill gap. Fix that before you apply—not after you’re invited.
2. Stop collecting credentials, and start with hard wins.
What gets you hired: a history of solving problems that were genuinely difficult, at stakes that actually mattered, with outcomes that can be verified.
Rustam built a face recognition system for a national ID program before Google. That communicates more than any degree: real consequences, population-scale, security constraints, production deployment.
The reframe is sharp: credentials optimize for passing resume filters. Problem histories optimize for passing interviews—and for being effective once you’re in.
3. Make your work legible. Or it doesn’t exist.
Most engineers describe work in terms of tools. That’s a mistake.
Forgettable: “Built a dashboard using React and Node.”
Memorable: “Cut page load from 4 seconds to 800ms. Checkout abandonment dropped 23%.”
Your manager tracks eight engineers. The hiring committee reviews forty packets. The recruiter skims two hundred resumes. If your work isn’t legible in seconds, it’s invisible.
Legibility isn’t bragging. It’s the mechanism by which your contributions become visible to the people who decide what happens next.
4. Put one hard decision in every story.
Strong engineers don’t sound smart because they use impressive words. They sound smart because they can explain a moment where the path wasn’t obvious—and walk you through how they chose.
The format:
Here were the options.
Here were the tradeoffs.
Here’s what I picked.
Here’s what happened.
Every serious project has at least one of these moments. If you can’t identify it, you don’t fully understand your own contribution yet.
5. Resumes are filter documents. Treat them like one.
A resume has one job: get you to an interview within 30 seconds of someone looking at it.
That’s it. It’s not a career summary. It’s not a comprehensive history. It’s a filter-passing document, and it should be engineered like one.
Different filters require different emphasis:
Startups filter for speed and tolerance to ambiguity. Lead with breadth and shipping pace.
Big tech filters for scale and collaboration. Lead with system complexity and cross-team work.
Domain-specific companies filter for constraint awareness. Lead with whatever shows you understand their world.
Tailoring takes fifteen minutes. The ROI is asymmetric.
On projects: trivial ones don’t just fail to help—they actively hurt. A to-do app or tutorial project signals exercise completion, not problem-solving. If a project isn’t hard, used, or owned in the long term, remove it.
6. AI compresses code. It doesn’t compress judgment.
The structural shift isn’t “AI replaces engineers.” It’s that certain categories of work get cheaper while others stay expensive.
Getting cheaper: boilerplate, initial implementations, documentation lookup, test generation.
Staying expensive: figuring out what to build, navigating organizational complexity, debugging distributed systems, and translating technical constraints to non-technical stakeholders.
If 60% of code-writing compresses, engineers who only write code become less differentiated. Engineers who excel at the non-compressible parts become more valuable.
Rustam’s tactic: Reverse prompting. Instead of asking AI to generate a solution, show your approach and ask it to find flaws, edge cases, and gaps. This surfaces blind spots that lead to missed generations.
7. Serial depth beats parallel breadth.
The failure mode for ambitious engineers is parallel optimization: learning Kubernetes while studying system design, building a side project, contributing to open source, and preparing for interviews.
Each activity is reasonable alone. Together, they produce shallow progress everywhere and depth nowhere.
The mechanism is the context-switching cost. Deep skill acquisition requires sustained attention over weeks and months. Every shift resets momentum.
The operating model:
Pick one primary skill for 3–6 months.
Define a concrete finish line. (”Design a system that handles 10x load and explain the tradeoffs” — not “learn distributed systems.”)
Put everything else in maintenance mode.
Decline good opportunities that don’t serve the primary goal.
The same applies to job searching. Fifteen focused applications beat fifty scattered ones.
Join the waitlist at buildcored.com
More live sessions? Join us on Telegram!
Notes from the BuildCored engineering series.