Career tips for tech starters

It has never been harder to land your first job in tech than it is right now. Fewer junior openings, more applicants per role, hiring managers who can pick from a global pool — if you don't put in real effort, you don't get a chance. The ten moves below are what hiring managers, HR leads, and senior engineers actually tell us they look for.

1. Own the whole problem — agents close the gap specialist roles used to fill

The HR lead and CTO at Kodelab put it bluntly to us: they're not hiring frontend engineers, or backend engineers, or QA engineers as separate roles anymore. What they're hiring for is someone who can take an ambiguous problem, find the right solution, build it across the full stack, test it, and ship it — at warp speed and at high quality. The job spec used to require three people. Now it requires one person with a fleet of agents.

This changes how you pitch yourself. The weak version names a role and a toolbelt: "I'm a frontend developer who uses Antigravity, Gemini, Cloud Run." Hiring managers tune that out — they don't care which tools you used, and the role label tells them nothing about whether you'd actually own the problem if they handed it to you.

The strong version names the capability:

What this pitch signals — and what the Kodelab HR lead said they specifically look for in interviews:

The litmus test the Kodelab CTO uses in interviews is two questions: "Did this person understand the actual problem?" and "Did they own the solution to the end?" If both are yes, the role-label conversation never even comes up. If either is no, the tool list won't save you.

2. Do the homework on every company you apply to

Before you write a single application, do the research. The same NotebookLM you used in step 2 of this workshop is now your job-prep tool. For every company you target, build a small notebook and feed it everything you can find about how they actually operate:

Then ask the notebook the questions a recruiter expects you to already know:

The application that says "I noticed you ship X to customers like Y, and based on their reviews on Z, the bottleneck looks like W — here's how I'd help fix it" beats every "I'm passionate about your mission" cover letter you'll ever write. You're not applying for a job description. You're offering to be the solution to a specific problem this company has.

If you skip this step and send a generic CV with a generic cover letter, you're competing on pure volume against people who didn't skip it. You will lose that competition every time. Effort is the moat.

3. Solve one real problem in public for six months — beats a portfolio of polished demos

The strongest CV signal for a junior right now isn't twelve finished tutorials. It's one real problem you've been chewing on for months, in the open, with a visible thinking trail. Pick a problem — yours, your community's, a workflow you keep doing manually — and stay with it through the awkward middle phase where the obvious answer doesn't work.

Why this works: hiring managers can spot in 30 seconds the difference between "this person follows instructions" (tutorial output) and "this person stays on a problem" (long arc with messy commits, refactors, course corrections). The first describes 80% of your applicant pool. The second describes the people who get hired.

The site you built today is your starting point. Don't freeze it. Find the real problem it could solve for someone — a missing tool in your community, a thing your friends keep asking you to help with, a workflow that nobody's automated yet — and pivot the site into that. Each commit is one more piece of evidence that you stayed on the problem.

4. Pick a problem domain, not a tech stack

"Fullstack JavaScript developer" is a tech stack — there are 800,000 of those on LinkedIn. The way to stand out is to own a problem domain that companies actively pay to solve.

Some problem domains where juniors break in (the technologies vary; the problem is the asset):

Pick one. Make your next three projects about that problem, regardless of which framework you reach for. Two months from now you'll be the person who shows up first when a hiring manager goes looking for it.

5. Talk to humans about problems, not companies about jobs

Sending CVs to job boards has the lowest yield of any channel. The next-cheapest thing — talking publicly about real problems you're working through — has surprisingly high yield because it compounds.

What works:

Hiring is still a network business. Build the network around shared problems, not shared technologies.

6. Be radically honest about who owned what

The defensive posture ("oh, I only used AI a tiny bit") reads worse to interviewers in 2026 than the proud posture ("here's my AI-USAGE.md — these are the problems I owned, this is how I divided the work, this is what I decided").

Hiring managers are now comparing two kinds of candidates: ones who hide AI usage (and look out of touch) and ones who own it explicitly (and look modern). The honest disclosure becomes a positive signal — it shows you've thought about division of labour, you have judgement about what to delegate, and you can name exactly which decisions were yours and why.

Keep the AI-USAGE.md file from step 5 of this workshop. Make it a record of problem ownership: which problem each chunk of work was solving, what the agent did, what you decided and why. Update it as you ship more. It's a hiring asset, not a confession.

7. Lower the bar to your first role — the first owned problem is the unlock

Every step after the first job gets easier. Don't optimise for the perfect first role — optimise to get inside, on any path that lets you own a real problem end-to-end. The "I shipped this thing for a real customer" line on your CV is the unlock; everything after the first one is incremental.

Tactics that work for first-time hires:

Once you've owned one paid problem end-to-end, the second job is dramatically easier than the first — and the conversation shifts from "do you have experience" to "what kind of problems do you want to own next." Don't refuse a stepping stone because it's not your dream role.

8. Read other people's code — to learn how they diagnose problems

Most juniors over-rotate on writing code (their own) and under-rotate on reading code (other people's). This is backwards. Senior engineers read more than they write. The fastest way to close the gap to senior is to start that habit now — and to read for the problem-solving, not the syntax.

What to do this week:

Two months of this and you'll have absorbed more about how senior engineers think about problems than a year of tutorials. Three months and you'll start spotting things in the PR diffs that the maintainers haven't flagged yet — that's when you start commenting, and that's when you start being known.

9. Document the problem you owned, not just the decision

"I built X" is what your code shows. Anyone can see it. The thing only you can document is which problem you were solving and why your decision matched it — that's the part that translates into interview answers later.

Practical habit: every time you make a non-trivial choice, write a one-paragraph note that names three things — what was the problem, what were your options, what specific constraint pushed you to one of them. "The problem was X. I considered Supabase, Firebase, and Postgres-on-Cloud-Run. I picked Supabase because [reason tied to the problem]. I rejected Firebase because [trade-off it would have introduced]." Stash these in a DECISIONS.md in the repo, or a private journal.

Two things happen:

10. Apply at 60% match — and address the problem behind the job description

Job descriptions are not requirement lists; they're wishlists. Hiring managers know they won't get every box ticked, especially for a junior role. Most candidates apply only when they feel they hit 100% — which means most candidates never apply.

Rule of thumb: apply if the core 3 requirements are there (the role, the seniority, the location/timezone). Don't filter yourself out on the nice-to-haves. The nice-to-haves are bargaining chips for the offer conversation later, not gates at the front door.

Then go further: read the job description between the lines for the actual problem the team has. A long bullet list under "Responsibilities" usually points at one or two real pain points the team is hiring to fix — slow onboarding, brittle infra, no design polish, no test culture, growing customer base outpacing the engineering team. Address that in your cover letter, not the bullet checklist. "Reading the description, it sounds like you're feeling X. Here's how I'd help." beats a hundred "I'm passionate about your mission" letters.

And: apply early. Most roles fill in the first two weeks because the hiring manager's energy is highest then. The "I'll polish my CV first" instinct costs more applications than it saves.

Where to start, this week

Don't try to do all ten. Pick two. Make them recurring habits — calendar them weekly until they stick. The career compounds in the gap between "things I read about once" and "things I actually do every week."

Two we'd recommend for everyone leaving this workshop:

Six months of those two and you will be in a different position on the market — not because the world changed, but because you did.