--- title: "Fresher in the AI Era: A 12-Month Plan to Become a Junior" url: https://www.thinnd.site/en/journeys/fresher-ai-era-12-month-plan/ language: en author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "Journeys" tags: ["fresher", "junior", "AI", "roadmap", "learning to code", "career"] summary: "A fresher in the AI era should spend 12 months on four things in order: foundations written by hand (quarter 1), small projects with AI as a tutor (quarter 2), near-real practice such as reviews, bug fixing and open-source contributions (quarter 3), then portfolio and interviews (quarter 4). The rule throughout: write first, ask AI to explain afterward, and always be able to explain your own code. A small randomized trial by Anthropic found people who let AI write for them scored lower on a knowledge quiz than people who wrote it themselves." license: "Cite with the author name and the canonical URL above." --- # Fresher in the AI Era: A 12-Month Plan to Become a Junior > For students, new hires and career changers. Every technical term gets a short explanation. > > The plan is my own reasoning from the public studies listed at the end and **has not been tested on many people**. The character "Minh" is an illustration rebuilt to be easy to picture, not a real person. Treat this as a starting point and adjust it to you. --- ## Quick summary - The way into the field is **narrower**: a Stanford study found employment of 22 to 25 year olds in the most AI-exposed occupations fell about 13% relative to other groups. That is a correlation, not necessarily a cause. - The 12-month plan has **four quarters**: hand-written foundations, small projects with AI as a tutor, near-real practice, then portfolio and interviews. - The rule throughout: **write first, ask AI to explain afterward**, and always be able to explain your own code in words. - Learning with AI can leave you weaker if it writes for you: the AI group in a small Anthropic trial did worse on a quiz than the group who wrote by hand. - Each month, check yourself with **three questions** (section 6), not by feel. --- ## Hard words, plain meaning | Term | Plain meaning | |---|---| | **Fresher / junior** | A newcomer / someone who can do small tasks with guidance. | | **Open source** | A project anyone can read and contribute to. A good place to practice in near-real conditions. | | **Code review** | Reading someone else's code and commenting before it joins the project. | | **Debugging** | Working out why a program does the wrong thing and fixing it. | | **AI tutor** | Using AI to explain, ask questions back and point out errors, not to do your homework. | | **Correlation** | Two things move together. It does not mean one causes the other. | --- ## 1. What is happening to newcomers There are two groups of evidence, both to be read with care. - **Jobs.** "Canaries in the Coal Mine" by Brynjolfsson, Chandar and Chen (Stanford, August 2025) uses ADP payroll data. They found employment of 22 to 25 year olds in the most AI-exposed occupations fell about 13% relative to other groups, after removing company-level shocks, while older workers in the same occupations stayed steady. Press coverage often names programmers, but the paper's summary does not single out the profession. The data is American and correlational. I have not found an equivalent figure for Vietnam, so check the hiring market around you. - **Learning.** Anthropic published (January 2026) a randomized trial of 52 programmers, mostly early-career, learning an unfamiliar Python library called Trio. The AI group averaged about 50% on a knowledge quiz and the hand-coding group about 67%, with the largest gap on debugging questions. The AI group was about two minutes faster, but that difference was not statistically significant. The sample is small (26 per group), and I have read the summary, not the full paper. Read together: **the door is narrower, and the shortcut (letting AI do it) may leave you short on exactly what employers test**, which is understanding and debugging. --- ## 2. Rules for using AI while learning 1. **Write first.** Even 20 minutes. You need a version of your own to compare. 2. **Ask AI to explain, not to write.** "Explain this line by line", "point out what could go wrong", "give me three similar exercises". 3. **Explain it back in words.** If you cannot say why the code works, you have not finished learning, even though it runs. 4. **Debug by hand first.** Print values, read the error message, test a guess. Ask AI after 15 minutes of trying. 5. **Keep a log.** One line a week: what I can do this week that I could not last week. A post in this blog, [Why you should not trust AI blindly](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/), explains why AI can sound fluent and still be wrong, so always verify. --- ## 3. The 12-month plan, four quarters Assume about **15 to 20 hours a week**. With less time, stretch each quarter instead of dropping steps. ### Quarter 1 (months 1 to 3): hand-written foundations - Pick **one** language and stay with it. For example Python or JavaScript. - Learn: variables, functions, loops, lists and dictionaries, reading and writing files, error handling, the command line, Git. - Each week: 5 small exercises **without AI writing them**. Using AI to explain afterward is fine. - Read other people's code: one 50 to 100 line file from a small project each week, and restate in words what you understand. - **Quarter goal:** write a command-line program of 100 to 200 lines with simple tests, pushed to Git. ### Quarter 2 (months 4 to 6): small projects, AI as tutor - Build **two small projects** whose real users are you and your friends: a web app with data and a tool that automates something you do often. - Learn more: HTTP, basic databases, APIs, writing tests, reading official documentation. - Use AI this way: sketch the design yourself, write the hard part yourself, ask AI to review and point at weak spots. - Give each project a README explaining **why** it is designed that way and what you tried that failed. - **Quarter goal:** two working projects, and you can explain every part without looking at the code. ### Quarter 3 (months 7 to 9): near-real conditions - Practice **reading and fixing other people's code**: pick a small open-source project, fix an easy bug or documentation, send the change and receive a review. - Practice **reviewing**: read other people's changes weekly, using the [15-point checklist](https://www.thinnd.site/en/engineering/reviewing-ai-written-code/) to train your eye. - Practice **systematic debugging**: reproduce the bug, narrow the scope, form a hypothesis, test. - Try an internship, a short freelance job or a joint project with friends. Working with others teaches what books do not. - **Quarter goal:** at least three real contributions accepted, or an internship, and you have received and acted on a review. ### Quarter 4 (months 10 to 12): portfolio and interviews - Choose your **two or three** best projects, clean them up, write the README and note how you explain them. - Practice interviews: explain your code, debug live, answer "how do you use AI at work". - Apply steadily, and ask for feedback after each rejection. - **Quarter goal:** a tidy portfolio, three mock interviews with other people, and a list of target roles. --- ## 4. Illustration: two ways to do the same task *An illustrative example with a rebuilt character.* Minh is given a task: read a revenue CSV file and print totals by month. - **Way A.** Minh pastes the task into AI, gets 30 lines of code, the output is correct, and submits. A week later a similar task has another date format and Minh does not know what to change. - **Way B.** Minh writes it alone for 20 minutes, gets the date parsing wrong, asks AI to explain the error rather than hand over new code, fixes it by hand, then asks AI for two similar exercises. It takes three times as long on day one. After a month, B-Minh fixes the other date format in minutes. Way A is faster at first, but what way B buys with the extra time is **debugging ability**, exactly where Anthropic's trial saw the biggest gap. --- ## 5. What a portfolio needs in the AI era Employers can hardly tell whether you or AI wrote the code, so the best evidence is that **you can explain and debug in front of them**. A tidy portfolio has: - **Two or three small working projects**, each with a README stating the goal, the design and what failed. - **Real contributions**: bug fixes, docs, reviews, however small. - **A short learning log**: what you learned each month. - **A paragraph on how you use AI**: what for, how you verify, when you do not use it. The Stack Overflow 2025 survey, with more than 49,000 respondents, found 46% do not trust the accuracy of AI and 66% hit "almost right but not quite" answers. Interviewers know this, so they care about how you **verify**, more than how much AI you use. --- ## 6. A monthly self-check Answer three questions and write them down: 1. **What can I do this month that I could not last month** (without AI)? 2. **How much of the code I submitted can I explain** without looking back at it? 3. **How did I handle the hardest bug this month**, how long did it take, who helped? If questions 1 and 2 do not move for two months, reduce AI writing and increase hand-writing. If question 3 is always "asked AI to fix it", practice debugging by hand. --- ## 7. A balanced view - **The plan is untested.** It rests on reasoning from a few small studies and American data. For you, the order may differ. - **Not everyone needs 12 months.** Someone with a base can start at quarter 2 or 3. - **The market moves.** Employment figures change over time. Follow the source rather than memorizing one number. - **Using AI is not bad.** What to avoid is letting it do the part you need to learn. Once you are fluent, AI makes you much faster. - **Experienced people slow down too when AI is used in the wrong place.** METR's study (July 2025) of 16 experienced developers found them about 19% slower with early-2025 AI tools, even though they believed they were faster. The sample is small and tools have changed, but it is a reminder that feeling fast is not a measurement. --- ## 8. Conclusion The door into the field is tighter, but what employers still have to test is **understanding, debugging and explaining**. Use AI as a patient tutor, not as someone who does your homework: write first, ask afterward, explain back in words, and log your progress each week. Start this week: pick a language, pick a small exercise, write it yourself for 20 minutes, and only then ask AI. --- ## References - [Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of AI (Stanford Digital Economy Lab)](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/) and [The Register's coverage](https://www.theregister.com/2025/08/26/ai_hurts_recent_college_grads_jobs/) - [Anthropic: AI assistance and coding skills (January 2026)](https://www.anthropic.com/research/AI-assistance-coding-skills) - [Stack Overflow Developer Survey 2025, AI section](https://survey.stackoverflow.co/2025/ai) - [Simon Willison on the METR productivity study](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - Related posts in this blog: [Why you should not trust AI blindly](https://www.thinnd.site/en/engineering/why-not-to-trust-ai-blindly/), [Reviewing AI-written code](https://www.thinnd.site/en/engineering/reviewing-ai-written-code/), [A handbook for AI](https://www.thinnd.site/en/engineering/writing-agents-md/)