1:1 Mentorship · RTL & SoC Engineering

Most engineers write RTL.
Few understand why it breaks.

This is not a course. This is a working session — focused on how you think through design decisions, integration challenges, and real-world constraints. If you want to move beyond execution and start reasoning like a system-level engineer, this is where to start.

Book a 1:1 Session

The Session

What happens in a 1:1

Each session is built around your specific problem — not a fixed curriculum. You bring the context. We work through it together.

Break down where your thinking is getting stuck — in a project, an interview, or a concept
Identify the gap between what you know and how you're applying it
Build a method you can reuse, not a one-time answer
Work through real-world scenarios: timing trade-offs, debug strategies, design decisions under constraints

Focus Areas

What I help with

RTL Design

Writing RTL that holds up beyond simulation
Understanding timing, area, and power trade-offs in context
Common RTL decisions that create downstream problems
Designing for integration, not just for functionality

Debugging

Approaching multi-variable failures systematically
Isolation strategies when the bug isn't obvious
Reducing dependency on others to resolve issues
Reading simulation and synthesis results critically

System & SoC Thinking

How your block fits into a larger system
Integration challenges and ownership boundaries
Cross-team constraints and how to navigate them
STA, CDC, and real-world silicon considerations

Career & Interviews

How senior and staff roles are actually evaluated
Answering design questions with depth, not recall
Positioning your experience to match what matters
Identifying and fixing gaps before the interview

Approach

How I mentor

Every situation is different

Before we work on a problem, I spend time understanding where you actually are — your project, your context, the decisions you're second-guessing. Generic advice doesn't work because no two engineers are stuck for the same reason.

Some gaps take more than one session

If one call is enough, that's what we do. But certain gaps — in how you approach architecture, debug under ambiguity, or position your experience — don't close in 60 minutes. We work through those across sessions, at your pace.

Guidance from real constraints

I don't work from frameworks or templates. What I share comes from navigating actual tradeoffs: synthesis timelines, integration failures, cross-team decisions that had consequences on silicon. That's the frame I bring to your problem.

Progress is built, not instant

A single session can shift the direction. But closing the gap between where you are and where you're trying to be takes consistency — applying, revisiting, refining. That's what we work toward, one session at a time.

Fit

Who this is for

Engineers with 1 to 10 years of experience in RTL, ASIC, or FPGA roles
People who can write code but struggle to explain or defend design decisions
Those targeting Senior or Staff-level roles and unclear on what the gap is
Anyone preparing for ASIC or VLSI interviews who wants structured thinking, not memorized answers
Engineers feeling stuck at the execution level who want to operate more independently

Purpose

Why this exists

The gap between academic learning and real engineering is wider than most people realize. Courses teach syntax. Colleges teach theory. Neither teaches you how to think under constraints, debug in ambiguity, or make decisions that hold at scale.

This mentorship is an attempt to close that gap — one session at a time. No generic advice. No recycled frameworks. Just direct engagement with your actual problem.

Tranquil Light Foundation

A portion of what's earned here funds TLF — a small initiative supporting stray animal rescue and medical care. Every session contributes directly.

Learn more →

Process

How sessions work

You book a slot and come with a specific problem, topic, or question. No prep needed beyond knowing what you want to work on.

We work through it together — live, interactive, no fixed script. The session follows the problem, not a template.

You leave with a clearer approach, not just an answer. The method should work on the next problem too.

Most engineers write RTL.Few understand why it breaks.