1. Depth Is Not What It Looks Like
The three signals most often mistaken for engineering substance: effort, a working demo, and fluent vocabulary.
Misconception 1
Hard to build means deep
Implementation effort measures friction, not insight. Wiring APIs, fighting environment errors, and chasing deployment bugs can consume weeks without ever exercising a non-trivial engineering decision.
Misconception: The harder something was to implement, the deeper the engineering behind it. Sounds like: “It took me three weeks, so it must be advanced.”
Reality: Depth lives in the decisions you can justify: the constraints you identified, the alternatives you rejected, and why. Mantra: “Measure depth in decisions, not in hours.”
Misconception 2
A working demo proves engineering skill
Generative tools produce polished, runnable artifacts in an afternoon. A demo shows that something runs. It says nothing about whether you can explain it, defend it, extend it, or debug it when it breaks.
Misconception: If the demo works, the engineering part is finished. Sounds like: “Look, it runs.”
Reality: You are assessed on the reasoning behind the artifact: why this design, these parameters, this evaluation. Mantra: “The demo is evidence, not the argument.”
Misconception 3
Sounding technical means understanding
Technical vocabulary is easy to reproduce and hard to earn. Naming a method fluently and being able to state what it assumes, when it fails, and what it costs are entirely different capabilities.
Misconception: If I can discuss it in the right terms, I understand it. Sounds like: “We used a contrastive objective with attention over the embeddings.”
Reality: Understanding shows when you explain the idea plainly, state its assumptions, and predict where it breaks. Mantra: “If you cannot say it simply, you are quoting, not knowing.”
2. Positioning the Project
Where the project sits relative to the course, the literature, and the work that already exists.
Misconception 4
The project stands apart from the course
The project exists to apply what the course teaches. A project that could have been built before the first lecture demonstrates initiative, but it does not demonstrate learning.
Misconception: The project is an independent deliverable that simply has to be handed in. Sounds like: “The project has nothing to do with the lectures.”
Reality: Use the course concepts, methods, and vocabulary deliberately, and make that connection explicit in your work. Mantra: “The project is where the syllabus becomes yours.”
Misconception 5
Novelty can be claimed after a quick search
“Nobody has done this” is a strong claim about the state of the art. Earning it requires a real search of academic literature, open-source repositories, and shipped products, not one query and a scroll.
Misconception: I did not find it quickly, therefore it does not exist. Sounds like: “I searched and found nothing similar.”
Reality: Survey the field first, then position your contribution precisely against what you found. Mantra: “Novelty is what survives a real search.”
Misconception 6
Building from scratch shows more skill
Starting from zero is usually a cost, not a virtue. Established models, libraries, datasets, benchmarks, and the methods from the course are the baseline you are expected to stand on.
Misconception: Writing every part myself proves more capability than reusing what exists. Sounds like: “I wanted to build it all on my own.”
Reality: Reuse deliberately, then spend your effort on the one part that is genuinely yours. Mantra: “Earn your originality where it counts.”
3. How Learning Actually Works
What to do with confusion, with the time in the room, with an AI assistant, and with the gaps you already know you have.
Misconception 7
Staying confused is part of the subject
A persistent fuzzy feeling around a concept is information: the mental model is incomplete. Left alone, that fuzziness becomes the foundation for everything built on top of it.
Misconception: Feeling permanently unsure about the core ideas is normal here. Sounds like: “Nobody really understands this part anyway.”
Reality: Treat every persistent confusion as a defect to fix, until you can explain the concept without hedging. Mantra: “Fuzzy is a bug report.”
Misconception 8
Taking a course means consuming its content
Slides, recordings, and notes are the most replaceable part of a course; equivalent content is available anywhere. What you cannot get elsewhere is the questioning, argument, and direct feedback on your own work.
Misconception: If I get through all the material, I have taken the course. Sounds like: “I will just watch the recordings later.”
Reality: Ask, challenge, present, and collect critique while you still have access to the people who can give it. Mantra: “Content is everywhere. Feedback is not.”
Misconception 9
AI is a tool for producing work
Generation is the least interesting thing a capable model does. The same tool will critique your design, surface failure modes, argue the opposing case, and find the hole in your evaluation, but only if you ask it to.
Misconception: The point of an AI assistant is to generate the artifact faster. Sounds like: “Write this part for me.”
Reality: Make the model your harshest reviewer before a human becomes one. Mantra: “Ask it to break your work, not just to build it.”
Misconception 10
Gaps can be closed later
An unresolved gap rarely stays a single gap. Later material assumes it, so the cost of leaving it open compounds every week until the topic becomes unreachable without going back.
Misconception: Missing pieces can be picked up at the end, when there is time. Sounds like: “I will figure that out before the exam.”
Reality: Close the gap the week you find it, using notes, references, peers, and AI as an on-demand tutor. Mantra: “Debt compounds. Pay it the same week.”
