How do I use Claude to be a better SDE?

Good question. The honest answer is — Claude Code can nudge you, but you have to build the habits into the system deliberately. Here's how:

1. Update your global CLAUDE.md right now

This is the highest leverage thing. Add a section that encodes everything mentioned previously as standing instructions. Every project you ever build will inherit it automatically.

2. What Claude Code can actively do

If the instructions are in your files, Claude Code will:

• Flag when you're skipping fundamentals — "before we use this library, here's what it's doing under the hood"

• Force systems thinking at every component — "here's what breaks at 10,000 users and why"

• Remind you to write tests — every single time, not just when you ask

• Name every pattern it uses — Repository, Factory, Dependency Injection — and explain why

• Give you the interview angle — after every significant component

• Call out technical debt explicitly — "this is the MVP shortcut, here's the production version"

• Make you reason about tradeoffs — never just picking one approach silently

3. What Claude Code cannot do

Be honest with yourself about this:

• It can't make you read the explanation — it'll write it, you have to actually read it

• It can't stop you from copy-pasting without understanding — that choice is yours

• It can't replace breaking things and fixing them yourself — real learning happens when something goes wrong and you have to dig

• It can't build your communication skills — you have to write the LinkedIn posts, the README, the design docs yourself

4. Habits to build alongside Claude Code

• After every component Claude Code builds — close the chat, open a blank doc, and explain what was just built in your own words. If you can't, go back and ask Claude Code to explain it again

• One "why does this work" question per session — go one level deeper than the code. "Why does FastAPI use async def here and not regular def?"

• Weekly commit message review — read your git log. Can you explain every commit? If not, you didn't learn it

• Monthly README update — rewrite the architecture section in your own words. Forces you to consolidate what you've learned

5. A practical accountability prompt

At the end of every build session, run this prompt in Claude Code:

We just built [X]. Quiz me on it.

Ask me 3 questions a senior engineer or interviewer

would ask about what we just built.

Don't give me the answers yet.

Then answer them. Then ask Claude Code to evaluate your answers. That loop — build, explain, get quizzed, get feedback — is how you actually retain it.

The one thing that will determine everything

Whether you treat Claude Code as a teacher or a code generator.

If you use it to ship fast without understanding, you'll have a portfolio but no depth. If you use it the way we've set it up — with the teaching format, the decision breakdowns, the interview angles — you'll come out of every project measurably better.

The system is set up right. The question is just whether you use it that way consistently.