Prepares for "reverse system design" rounds where you present YOUR past technical work. Use for project selection, narrative arc structuring, whiteboard diagrams, depth calibration, and hostile Q&A handling. Activate on "tech presentation", "present your work", "reverse system design", "project deep dive". NOT for designing hypothetical systems, resume writing, or career narrative extraction.
Prepares for "reverse system design" rounds where you present YOUR past technical work. Use for project selection, narrative arc structuring, whiteboard diagrams, depth calibration, and hostile Q&A handling. Activate on "tech presentation", "present your work", "reverse system design", "project deep dive". NOT for designing hypothetical systems, resume writing, or career narrative extraction.
allowed-tools
Read,Write,Edit
metadata
{"gated":true,"category":"Career & Interview","pairs-with":[{"skill":"interview-loop-strategist","reason":"Upstream orchestrator that routes to this skill for presentation rounds"},{"skill":"ml-system-design-interview","reason":"Complementary -- this presents real systems, that designs hypothetical ones"},{"skill":"hiring-manager-deep-dive","reason":"Similar depth-testing but conversational rather than presentational"},{"skill":"career-biographer","reason":"Upstream -- extracts the raw project narratives this skill structures"},{"skill":"interview-simulator","reason":"Runs timed mock presentations with realistic Q&A scoring"}],"tags":["interview","presentation","system-design","storytelling"]}
The tech presentation round is a reverse system design: instead of designing a hypothetical system on a whiteboard, you present a real system YOU built. This tests three things no other round can: genuine depth of understanding, ability to communicate complex ideas under pressure, and authentic ownership versus inherited knowledge.
When to Use
Use for:
Selecting which project to present from your career
Structuring a 25-45 minute technical presentation with narrative arc
Calibrating depth -- which components to go deep on, which to skim
Preparing whiteboard/virtual-board diagrams with progressive disclosure
Rehearsing answers to hostile follow-up questions
Adapting presentation to different audience compositions (researchers, engineers, managers)
NOT for:
Designing a system you haven't built (use ml-system-design-interview)
Writing your resume or extracting career stories (use cv-creator or career-biographer)
Coordinating across multiple interview rounds (use interview-loop-strategist)
Practicing coding problems or behavioral STAR stories
Conference talk preparation (different format, different evaluation criteria)
Project Selection
The most common failure mode is choosing the wrong project. Use this decision tree:
flowchart TD
A[List your top 5 projects] --> B{Did YOU make key<br/>technical decisions?}
B -->|No, I inherited it| SKIP[Skip this project]
B -->|Yes| C{Can you explain<br/>alternatives you rejected?}
C -->|No, I just used<br/>what was standard| SKIP
C -->|Yes, I evaluated<br/>tradeoffs| D{Are there interesting<br/>failure modes or<br/>unexpected challenges?}
D -->|It went smoothly| WEAK[Weak choice --<br/>no drama = no depth]
D -->|Yes, things broke<br/>or surprised us| E{Can you fill 30+ min<br/>of technical depth<br/>on 2-3 components?}
E -->|No, it was<br/>straightforward| WEAK
E -->|Yes| F{Is it relevant to<br/>the target role?}
F -->|Not really| BACKUP[Keep as backup --<br/>use if nothing<br/>better qualifies]
F -->|Yes, strong match| PICK[Strong candidate --<br/>select this project]
Selection Criteria Scorecard
Rate each candidate project 1-5:
Criterion
Weight
What to evaluate
Personal ownership
5x
YOUR decisions, not team consensus or inherited architecture
Business impact (revenue, users, customer satisfaction)
Team impact (adoption, developer experience, operational burden)
6. What I Would Change (2 min) -- The most important 2 minutes.
1-2 specific technical decisions you'd reverse with hindsight
Why you made the original decision (it was rational at the time)
What you learned that changed your thinking
This section builds more credibility than all your wins combined
7. Q&A (15+ min) -- Where the real evaluation happens.
See "Handling Deep Follow-Ups" section below
Depth Calibration
The cardinal sin is covering everything at surface level. Pick 2-3 layers to go DEEP.
Component Type
Skim (1-2 sentences)
Medium (2-3 min)
Deep (5+ min)
Standard infra (load balancer, CDN)
Almost always skim
Only if custom config
Never unless this IS the project
Data storage layer
If standard SQL/NoSQL
If sharding, replication, or hybrid
If you designed the storage engine
ML model architecture
If off-the-shelf
If fine-tuned or modified
If custom architecture or novel approach
Data pipeline
If standard ETL
If real-time or complex transforms
If you solved a hard data quality problem
API/interface design
If REST/GraphQL standard
If complex versioning or contracts
If protocol design was the core challenge
Monitoring/observability
Usually skim
If anomaly detection is core
If this IS the system
Rule of thumb: Go deep on the parts where YOU made a non-obvious decision. Skim the parts where you used an industry-standard tool in the standard way.
Handling Deep Follow-Ups
The Q&A is where interviewers separate builders from bystanders. Prepare for these patterns:
"Tell me more about X"
This is an invitation, not a trap. Go one level deeper on implementation.
Structure: "The key challenge with X was [constraint]. We solved it by [approach] because [reason]. The tricky part was [non-obvious detail]."
If you genuinely don't remember a detail: "I'd need to check the specifics, but the design principle was [principle] and the implementation followed [pattern]."
"Why didn't you use [alternative]?"
Never dismiss the alternative. Acknowledge its strengths first.
Structure: "We considered [alternative]. It's strong for [use case]. We chose [our approach] because in our context, [specific constraint] made [alternative] less suitable. Specifically, [concrete reason with numbers if possible]."
If you hadn't considered it: "That's a good option I hadn't evaluated at the time. Based on what I know now, the key tradeoff would be [tradeoff]. I think for our constraints, [assessment]."
"That seems over-engineered"
Don't get defensive. Restate the constraint that justified the complexity.
Structure: "I understand that reaction. The complexity was driven by [specific requirement]. Without [the complex part], we would have hit [concrete failure mode]. That said, if [requirement] changes, I'd simplify by [specific simplification]."
"What would you do differently?"
NEVER say "nothing." This is the most important question.
Prepare 2-3 specific technical changes with reasoning.
Structure: "Knowing what I know now, I'd change [specific decision]. At the time, [why it was rational]. Since then, [what changed -- new tooling, learned lesson, scale changed]. The new approach would be [specific alternative]."
"What's the failure mode?"
Describe actual failures that happened, not hypotheticals.
Structure: "The primary failure mode is [X]. We hit it [frequency]. When it happens, [impact]. Our mitigation is [approach]. The residual risk is [what's still unprotected]."
Model architecture, training pipeline, data challenges, serving infra
Business impact, team dynamics
Engineering managers
Decision-making process, team coordination, technical risk management
Low-level implementation details
Mixed panel
Start broad, let Q&A reveal where each panelist wants depth
Don't pre-optimize for one audience
Anti-Patterns
Demo Reel
Novice: Presents all wins, no failures or trade-offs. Every decision was optimal. The system performed beautifully from day one. Metrics only go up and to the right.
Expert: Proactively discusses what didn't work, what surprised them, and what they'd change. Treats failures as evidence of genuine engagement, not embarrassment. Shares specific metrics for both successes AND shortcomings.
Detection: When asked "what would you do differently?" the answer is vague ("maybe better testing") or unconvincing ("honestly, I'm pretty happy with how it turned out"). No failure stories surface organically during the presentation.
Team Credit Confusion
Novice: Uses "we" for everything. "We designed the architecture." "We chose Kafka." "We solved the latency problem." Unclear what THEY specifically did versus what the team did collectively versus what a teammate owned entirely.
Expert: Clear ownership markers throughout: "I led the design of the serving layer, collaborated with our data team on the pipeline, and my teammate Sarah owned the model training infrastructure. Let me focus on the serving layer since that was my primary contribution." Uses "I" for decisions they drove, "we" for genuine collaboration, and names teammates for their contributions.
Detection: Under follow-up questioning, cannot explain specific technical decisions in detail. When asked "why Kafka over RabbitMQ?", answers with "that was the team's decision" or gives a generic textbook comparison rather than the specific evaluation they ran.
Architectural Tourism
Novice: Covers every component at surface level. "And then we had a cache, and a queue, and a database, and a load balancer, and a model server, and a feature store..." Each component gets 1-2 sentences. Runs out of time before reaching anything interesting. The whiteboard looks like a busy subway map.
Expert: Draws the 3-box overview, explicitly says "I'm going to focus on two components where the interesting engineering happened," and goes DEEP. Spends 5 minutes on one component explaining the tradeoffs, alternatives considered, failure modes, and what they learned. The interviewer leaves understanding that component thoroughly.
Detection: Presentation runs over time. All component descriptions are surface-level. Whiteboard has 15+ boxes with no zoom-in area. When asked to go deeper on any single component, the candidate has nothing beyond what they already said.
Rehearsal Protocol
Solo run-through (3x minimum): Present to an empty room, timed. Target: 20-25 min for the structured portion, leaving 15-20 min for Q&A.
Record yourself: Watch the recording. Note filler words, hand-waving over gaps, and moments where you lose the thread.
Peer mock (2x minimum): Present to a technical friend. Have them play hostile questioner. Track which questions you fumble.
Q&A stress test: Have someone rapid-fire 10 questions from the hostile questions list. Practice composure under pressure.
Timing gate: If your structured presentation exceeds 25 min in rehearsal, cut content. You WILL run longer in the real thing.
Reference Files
File
Consult When
references/project-narrative-template.md
Structuring a project presentation from scratch; filling out the narrative arc; preparing Q&A answers; worked example of an ML pipeline presentation
references/whiteboard-diagrams.md
Planning what to draw during the presentation; progressive disclosure strategy; physical and virtual whiteboard tips; common diagram patterns for ML systems
Output Contract
This skill produces:
Visual output files (SVG, PNG, or canvas/WebGL code)
Rendering code with configurable parameters for style and layout
Asset pipeline for generating and optimizing visual artifacts
Style configuration with color palette, dimensions, and export settings
