Technical Learning Lab

This repo is a personal study project for deep-diving AI/ML and cloud-platform topics, and for interview prep (FDE and similar solutions-engineering / applied-AI roles). It has no application code — the "product" is notes, exercises, quizzes, and flashcards.

How to work in this repo

• Read TRAINING.md first. It's the index of every topic, its status (not started / in progress / reviewed / mastered), and the date it was last touched. Update it whenever a training session ends, even a short one.
• Per-topic material lives under topics/<slug>/. Create the folder the first time a topic is trained; don't pre-generate empty folders for topics that haven't started.
• Code-along books/courses with a chapter sequence and a growing companion codebase (e.g. "Build a Large Language Model From Scratch") live under books/<slug>/, not topics/ — see the book-study skill. Don't treat a book chapter as a standalone train-topic topic; the point of these books is the persistent, incrementally-built code.
• Flashcard exports live under flashcards/<slug>.csv, one file per topic, Anki-importable (see format below).
• If the user attaches a file or link as training material, save a copy or reference under resources/<slug>/ before using it, so it survives past the conversation.
• If the user points at their own existing local project (a live, git-tracked codebase elsewhere on disk) as source material, don't copy it into resources/<slug>/ — write a short resources/<slug>/README.md that references its path instead, so it never goes stale relative to the original.

Topic scope

Group topics into these buckets when creating structure or asking clarifying questions:

• AI/ML foundations: LLMs, Generative AI, Agentic AI, RAG, Embeddings, Vector Databases, Prompt Engineering
• Responsible AI: Ethical AI, AI Safety, AI Governance, AI Law, AI Ethics, AI Policy, AI Regulation, AI Standards, AI Certification, AI Accreditation
• Platforms & basics: AWS, Azure, Google Cloud, IBM, Microsoft, OpenAI, Anthropic, Perplexity, Gemini, DeepSeek, Ollama, Groq — each has a "basics" track and, where applicable, an "AI services" track (Bedrock, AgentCore, Azure AI, Vertex AI, Watsonx, etc.)
• APIs & SDKs: OpenAI API, Anthropic API, Perplexity API, Gemini API, DeepSeek API, Ollama API, Groq API
• Frameworks/libraries: LangChain, provider SDKs (OpenAI, Anthropic, Perplexity, Gemini, DeepSeek)
• Databases: MongoDB, MySQL, PostgreSQL, and vector stores — Faiss, Chroma, Pinecone, Qdrant, Weaviate, LanceDB, Milvus/Zilliz
• Company/role prep: AWS, Azure, Google, IBM, Microsoft, OpenAI, Anthropic, Perplexity, Gemini, DeepSeek — business model, AI product lineup, and likely interview angles for FDE / Forward Deployed Engineer / Solutions Architect style roles

New topics that clearly fit "and similar topics/tools/frameworks as needed" from the original brief are in scope without asking — use judgment, and only ask if it's genuinely ambiguous which bucket something belongs to.

Training workflow

Use the train-topic skill any time the user asks to be trained on, learn, study, or deep-dive a topic. Don't hand-roll a different structure — it encodes the fixed 5-stage flow (overview → deep dive → hands-on → real-world application → validation) the user asked for, plus how to check prior progress from TRAINING.md before starting.

Use mock-interview when the user asks for mock interviews, or interview prep for a specific company/role (including FDE-style roles).

Use quiz-flashcards whenever a training session produces quiz questions or the user asks for flashcards — it owns the CSV format and where files go. Don't invent a different export format.

Use book-study instead of train-topic when the user wants to work through a specific technical book or course sequentially, especially ones with a companion code repo — it handles chapter sequencing, the persistent books/<slug>/code/ project, and validating against the book's own exercises/quizzes rather than inventing new ones.

Use spaced-review when the user asks to review, wants to know what's due, or wants to be quizzed on previously studied material — it manages REVIEW.md's Leitner-style schedule so mastered topics get re-tested before they're forgotten, rather than just once and never again.

Use interview-prep-kit when the user provides a resume and a specific job posting and wants a written prep document — resume-to-JD gap mapping, a STAR story bank, and a cheat sheet. This produces a static artifact; mock-interview is for the live roleplay that follows.

Use quick-recap when the user wants a fast refresher on something already studied — before an interview, before a work meeting, or any quick check — rather than a full re-teach. It's read-only: it condenses existing notes, it doesn't run train-topic's stages or a quiz.

Git workflow

This repo is under git. The user has pre-authorized committing at the end of each session — do this without asking each time, scoped as follows:

• One commit per session, not per file edit. Batch everything a session touched (e.g. TRAINING.md, REVIEW.md, topics/<slug>/README.md, books/<slug>/progress.md, flashcards/<slug>.csv, topics/interview-prep/*) into a single commit at the natural end of that session's work — after a train-topic/book-study/spaced-review/mock-interview/ interview-prep-kit session wraps up, not after every intermediate write.
• Never commit resources/ beyond its README.md — it's gitignored on purpose (see .gitignore) because it may hold copyrighted source material. Don't git add -A blindly; stage the specific tracked files the session touched.
• Commit message: summarize what the session covered, e.g. train: RAG — overview through hands-on practice or review: 3 items due, 2 passed or mock: Amazon onsite coding round. Keep it factual and short — this is a log, not prose.
• If a session made no file changes worth keeping (e.g. pure Q&A with nothing persisted), skip the commit rather than creating an empty one.
• This pre-authorization covers routine session commits only — still ask before anything else git-related (force-push, reset, rewriting history, adding a remote, or pushing anywhere).

Working style for this project

• This is learning content, not production code: prefer clear, runnable, minimal examples over abstracted "reusable" scaffolding. Every code example should actually run — verify snippets before presenting them as working (run them if a runtime is available; say so if you can't).
• Be accurate over comprehensive. If something is uncertain, moved fast, or you're not sure it's still current (pricing, model names, API shapes), say so explicitly rather than presenting it as settled fact — these domains (esp. LLM APIs and cloud AI services) change monthly.
• Validate understanding before marking a topic "mastered" in TRAINING.md — a quiz, a teach-it-back explanation, or a working exercise, not just "we covered it."
• Keep notes skimmable: headers, short sections, code blocks. This is reference material the user will return to, not a transcript.