Your First Tech Job
Before you start
You need: Start here, if you have not read it. That page explains what an application is made of and introduces the school system every example uses. This page assumes those few ideas and nothing else.
If a word here is unfamiliar, the glossary has it in one line.
Who this is for: final-year students and fresh graduates — anyone zero to twelve months away from their first software job. If you are in first or second year, there is a section for you near the end.
Time: about 30 minutes. Read it properly before choosing a path.
Learning objective
Understand what the job actually is, what employers are looking for in a fresher now, and decide honestly whether to commit six months to this.
Topics
- What a junior developer does all day
- What changed in fresher hiring
- The AI question, answered straight
- What this programme does and does not give you
- The real cost in hours
- If you are not in your final year yet
What a junior developer actually does
The picture most students have is someone typing code for eight hours. That is not the job.
| Activity | Roughly |
|---|---|
| Understanding what is needed | A quarter |
| Reading existing code | A quarter |
| Writing new code | A fifth |
| Testing and fixing | A fifth |
| Meetings and coordination | The rest |
Reading outweighs writing. You join a team whose codebase — all the code making up their application — already exists: three years old, half a million lines, written by people who have left. Your first task is not to build something new. It is to change one screen without breaking four others.
A realistic first month:
Week 1 Set up your machine. Get the project running on it.
Read code. Attend the daily team meeting, understand a third of it.
Week 2 Fix a small bug someone else found. Submit your first change
for review. Get twelve comments back. This is normal.
Week 3 Fix a second bug. Fewer comments.
Week 4 Build a small feature end to end — a filter on an existing screen.
Two words from that week, because you will hear them constantly: a stand-up is the short daily team meeting where everyone says what they did and what is blocking them; a pull request is how you submit a change so colleagues read it before it goes in. Getting comments on one is the normal, expected process — not a verdict on you.
Nobody expects you to be productive in month one. They expect you to be teachable, to ask good questions, and not to break production. A fresher who says "I am stuck, here is what I tried" on day one is doing better than one who says nothing for three days.
What changed in fresher hiring
Two things, and both matter for how you prepare.
Routine code stopped being valuable. In 2020, "I can build the screens that add, list, edit and delete students" was a reasonable fresher pitch. Now anyone can generate that in a minute. The skill was never the typing, but the typing used to be the proof.
The interview moved to judgement. Employers now assume you can produce code. What they test is whether you can tell correct code from plausible code — because plausible code is now free and infinite.
That is a harder thing to fake, and it is the entire design of this programme. Every track threads through failures that produce no error message:
| The mistake | What happens |
|---|---|
| A student who was absent is recorded as having scored zero | Every class average comes out wrong, and nothing warns anyone |
| The program trusts the browser about which school is asking | One school can read another school's children's records |
| Fee amounts stored in a number type that rounds | Totals drift by a few paise a month; nobody notices for a year |
| A payment is saved but the balance update fails | The receipt exists and the balance is wrong |
None of those crash. The program keeps running and reports success. Spotting them is judgement, and judgement is what gets you hired now.
You are not expected to know how to prevent these yet. You will build all four situations yourself over the next six months and see each one fail.
The AI question, answered straight
You have heard that AI is taking developer jobs. You are deciding whether to enter an industry that might not want you. Here is the honest position, without doom and without a sales pitch.
What actually changed:
Routine code is cheap. The ordinary plumbing — a screen with a form on it, the code that fetches a student record, the shape you send back to the browser — took an hour each and now takes a minute. The market has repriced that work, and it has repriced it to nearly zero.
What did not change:
Someone has to decide what correct means. Someone has to notice that the generated grading code marks an absent student as Fail. Someone has to say, in a code review, why this approach and not that one — and be right.
An AI will write you a fee calculation. It will not know that your school records an absence as "no mark recorded" rather than a mark of zero, and that the check for it must come first — unless you tell it. And it cannot be held responsible when the report cards go out wrong.
So the bar moved, not the door.
| Then | Now |
|---|---|
| "I can write the ordinary code" | "I can tell you what is wrong with this code" |
| Typing speed | Reviewing judgement |
| Knowing the language's rules | Knowing what correct looks like |
| Building from a tutorial | Building, then defending it in review |
This is harder than it was. Pretending otherwise would not help you. A fresher in 2020 could get hired on enthusiasm and a bootcamp certificate; that is less true now.
But it is also more learnable than it looks, because the thing being tested — can you spot the wrong answer — is exactly what six months of deliberate practice builds. Enthusiasm was never trainable. This is.
And there is an opportunity in it. Most fresher candidates still present as if it is 2020: a tutorial project, a certificate, and no ability to explain a single decision. A candidate who says "I had Claude write the code that fetches students, and I caught it trusting the browser about which school was asking — which would have let one school read another's records" is doing something the other candidates in the queue are not.
That sentence is a real one from this programme. You will be able to say it, and mean it, by month four.
How AI fits into this programme
Not as a final chapter. As the way you study, from week one.
| From | You will |
|---|---|
| Week 1 | Use AI to explain code you do not understand, and to quiz you |
| Month 2 | Generate code and review it against a checklist |
| Month 4 | Add a real AI feature to your project |
| Month 6 | Answer "do you use AI?" in an interview with evidence |
The rule that makes this work, stated once and repeated everywhere: if you cannot explain it, you have not learned it — and the interview will find out.
Using AI to learn faster is a genuine advantage. Using AI to avoid learning produces a candidate who falls apart on the first follow-up question, and interviewers ask follow-up questions precisely because they know this.
Learning with AI covers the prompts that teach rather than answer.
What this programme gives you
By the end you can:
- Build a complete application — browser to API to database — and explain every layer
- Read an unfamiliar codebase and change it without breaking things
- Debug a failure across five layers instead of guessing
- Use Git the way a team uses it: branches, pull requests, recovery
- Use AI to work faster while staying responsible for the code
- Answer fresher interview questions with evidence from your own project
What it does not give you:
- A guarantee of a job. The market varies by city and by year, and effort is necessary but not sufficient
- Senior-level depth. "Intermediate" here means intermediate within a fresher's scope
- Data science or machine learning. That is a different path, and the Python route says so plainly
- A shortcut. Six months at two hours a day is the real cost
The honest version: this makes you a credible junior candidate with something real to show. Whether that converts depends on how many roles are open where you are, how you interview on the day, and some luck. Anyone promising more than that is selling something.
The real cost
2 hours per weekday 10 hours
3–4 hours at the weekend 3–4 hours
─────────
~13 hours per week
× 24 weeks
≈ 310 hours
Consistency beats intensity. Two hours a day for six months works. Twelve hours every third Sunday does not — you spend the first three re-learning what you forgot.
Missing a week is normal. Missing three is a restart. The schedule has a section on catching up, because you will need it at some point.
If you cannot find thirteen hours a week right now, that is worth knowing before you start rather than in month three. Start when you can, or take the slower path in the schedule.
If you are not in your final year yet
This playbook is written for people close to their first job. If you are earlier, you have something better than urgency — you have time.
| Year | Do this now |
|---|---|
| First | Track 02 and Track 03. Get genuinely good at one language. Nothing else matters yet |
| Second | Add Track 06 SQL and Track 09 web. Start Track 16 Git — put everything on GitHub from now on |
| Third | Take the full .NET route or Python route at a relaxed pace. Aim to finish before final-year placements begin |
The advantage of starting early is not finishing sooner. It is that you get to build three projects instead of one, and the third is much better than the first.
Common mistakes
- Deciding whether to start based on a headline about AI rather than the actual work
- Expecting to write code all day, and being disappointed by the reading
- Collecting certificates instead of building one thing you can explain
- Using AI to finish the exercise rather than to understand it
- Treating "I finished the tutorial" as the same as "I could rebuild this"
- Planning twelve-hour weekends instead of two-hour weekdays
- Starting a second course before finishing the first
Practice
- Write down, in your own words, what a junior developer does all day. Compare it with the table above.
- Write your honest answer to "will AI take this job?" now. Keep it. Read it again in month six.
- Count the hours you can genuinely give each week. Not the hours you would like to.
- Read the four silent-failure examples again. For each, say why no error appears.
- Decide your finish date — 24 weeks from your start — and write it somewhere you will see it.
- Say out loud: "if I cannot explain it, I have not learned it." You will need it in week three when a generated answer is tempting.
You can now
- Describe what a junior developer actually does all day
- Say what changed in fresher hiring, and what did not
- Give an honest answer to the AI question, in either direction
- State what this programme does and does not promise
- Name the real weekly hour cost
- Decide whether to commit — and know what you are committing to
Review questions
- Why does reading code take more of the week than writing it?
- What did AI make cheap, and what did it leave untouched?
- What do the four silent-failure examples have in common?
- What does "if you cannot explain it, you have not learned it" protect you from?
Next: Choose your path