Software Engineering

What the job is actually like

Far less typing of new code than most graduates expect. A large part of the work is reading code someone else wrote, working out why something behaves the way it does, and making a careful change without breaking the six things attached to it. Meetings, code review and writing things down take real hours. The satisfying part is that problems stay solved once you solve them properly.

A roadmap

Lengths are what this typically takes alongside other commitments, not a promise. The "prove it" line matters more than the timeline — that is what someone hiring will look at.

1. One language, properly

   Pick one language and go deep rather than sampling five. Python or JavaScript are the easiest to get feedback from quickly. Depth means understanding how it handles memory, errors and types — not finishing a syntax tutorial.

   Typically

   Two to four months of consistent work

   Prove it

   Three small programs you wrote without following a tutorial, each solving a problem you actually had.

2. The fundamentals under the language

   Data structures, how a database stores and finds things, how HTTP works, what happens between typing a URL and seeing a page. This is the layer that transfers when the fashionable framework changes.

   Typically

   Three to six months, overlapping with building things

   Prove it

   Being able to explain out loud why your code is slow, and being right.

3. Version control and working with others

   Git properly, not just three memorised commands. Branching, resolving conflicts, reading a diff, writing a commit message someone else can use.

   Typically

   Weeks, then permanently

   Prove it

   A commit history that reads like a record of decisions rather than a series of "update".

4. One real project, finished

   Something with a database, authentication and a deployment — end to end, handling the boring cases. Finished and deployed beats ambitious and abandoned, every time.

   Typically

   Two to three months

   Prove it

   A working URL, a README explaining the decisions and what you would do differently, and honest notes on what is broken.

5. Reading unfamiliar code

   Contribute a small fix to an open source project. The skill being built is arriving in a large codebase you did not write and finding your way.

   Typically

   Ongoing

   Prove it

   A merged pull request, however small, in someone else's repository.

What AI has changed

The tasks most exposed are exactly the ones juniors were traditionally hired to do: boilerplate, simple CRUD, translating a clear spec into code. That is genuinely harder for entry-level candidates than it was, and pretending otherwise does not help anyone. What has become more valuable is the judgement around the code — deciding what to build, reviewing output you did not write, knowing when a confident-looking answer is wrong, and holding the whole system in your head. Being able to use these tools well is now table stakes rather than an advantage. Being able to verify what they produce is the differentiator, and you cannot verify what you do not understand, which is why skipping the fundamentals is now a worse bet than it used to be.

Common mistakes

• Collecting certificates instead of finishing projects. Nobody hiring reads them.
• Starting five projects and finishing none. One finished thing is worth more than five repositories with a README and nothing else.
• Learning a framework before the language underneath it, then being helpless when it behaves oddly.
• Treating AI output as finished work rather than a first draft you are responsible for.
• Applying only to the famous companies, which is also where every other graduate applies.