Junior developer skills that matter in your first job

When you learn to code, you mostly solve exercises: a function, an algorithm, a clearly bounded problem. Your first task at work looks different. You get a ticket, work in an existing codebase, have to pass tests, and colleagues review your code. These skills can be practised once you know what matters.

How a typical task runs

1. A ticket describes what's needed, usually with acceptance criteria.
2. You clear up open questions before you start.
3. You plan briefly how to do it, in writing for bigger tasks.
4. You work on your own branch and write tests.
5. You open a pull request, and someone else reviews the code.
6. After review, the code is merged and shipped.

Read tickets, take acceptance criteria seriously

Acceptance criteria say when a task is done, for example: “codes only use letters and digits”, “the same URL gets the same code”, “reject anything that isn't http(s)”. Read them like a test list. Anything that isn't in there is a question for whoever wrote the ticket, not an invitation to guess.

Plan first: the design note

Before bigger changes, many teams write a short design note. It catches mistakes before they're in the code and makes the review easier. Half a page is enough: the problem, your approach, alternatives you rejected, risks and how you'll test.

Ticket HOP-101: Short links for campaign URLs

Problem:   Marketing needs short links for printed flyers.
Approach:  Base62 code from a counter; store code → URL in a table
           with a unique index on the URL, so the same URL gets the same code.
Rejected:  Random codes: need collision checks, no benefit here.
Risks:     Invalid input → accept only http(s) URLs.
Tests:     same URL twice → same code; ftp:// → rejected;
           code uses only letters and digits.

Tests as your working base

At work, tests run on every change. Get used to running the existing tests first, writing a test for each acceptance criterion next, and only then building the solution. A red test turning green is the clearest proof that a ticket is done.

Giving and taking code reviews

In a review, someone checks your code before it's merged. Comments aren't a verdict on you; they're part of the work. Review your own code first with the same questions an experienced colleague would ask:

• Would someone without context understand what the code does? Are names clear?
• Are edge cases covered: empty input, errors, very large values?
• Are errors handled sensibly rather than swallowed?
• Are there tests for the acceptance criteria?
• Does the pull request contain only what belongs to the ticket?
• Is it small enough to review in one sitting?

Tools you're expected to know

• Git: branches, clean commits, resolving conflicts, pull requests
• Your language's build system, such as CMake for C++ or npm for JavaScript
• A debugger, not just print statements
• The terminal for builds, tests and logs

How to practise this on purpose

• Build projects end to end and write yourself tickets with acceptance criteria.
• Write a short design note before each feature and compare it with the result afterwards.
• Review your own code the next day with the review checklist.
• Contribute to open-source projects that label beginner issues: that's where you meet real reviews.

Algorithm puzzles or projects?

Algorithm puzzles train problem solving and come up in some interviews. Projects show that you can work the way a team does: with tickets, tests and reviews. Both are worth it for your first job, but day-to-day work is almost entirely the second.