Junior frontend job posts in Turkey keep piling Docker, CI/CD, GraphQL and Cloud on top of React. This roadmap sorts through that list: the foundation you really need to get hired, the things that show up in posts a lot but aren't required, and the things you'll learn once you're on the job.
Knowing 20 technologies on the surface isn't worth more than knowing none of them properly. Go in order, click each topic to see what you need to know, and check off what you've learned.
Click a topic to see what you need to know and where to learn it.
What everything else is built on. Skip it, and you'll keep coming back to it at every stage after.
The everyday tools you need to work on a team.
The part job posts are really asking for. If your foundation is solid, this goes faster than you'd think.
Things that show up a lot in job posts and set you apart from other candidates.
Things you see in job posts but don't need to get hired. You'll learn them in production, as the need comes up, together with your team.
Every topic on the map with its description, what to know and resources — in one list.
Knowing what happens when you type an address into the browser helps you make sense of half the errors you'll run into. You don't need depth here — the big picture is enough.
The language the frontend speaks. If you can read methods and status codes, you can debug API errors on your own.
How a domain name gets resolved to a server. The first thing you'll run into when you put your project online.
The path from HTML to the DOM, and from CSS to pixels on the screen. Whenever performance comes up, everyone ends up back here.
The skeleton of the page. People skip it because 'HTML is easy', yet it's the topic that exposes the most gaps in interviews: picking the right tag decides both accessibility and SEO.
header, nav, main, article, section, button — each one means something. Screen readers and search engines both read that meaning.
You'll write these at almost every job. label, input types and the browser's built-in validation save you from writing a lot of JavaScript.
A page you can get around with a keyboard and read with a screen reader. Nobody expects a junior to be an expert, but they do expect the basics.
title, description, heading structure and meaningful URLs. If you're writing semantic HTML properly, you're already halfway there.
Turning a design into code. Even if you use Tailwind, there's CSS underneath — if you don't get the box model and layout, you'll get stuck in Tailwind too.
Every element is a box: content, padding, border, margin. Most layout bugs come from here.
Alignment along one axis. Most of the layouts you'll write today are flexbox.
Layout on two axes. For card grids and page skeletons it's much simpler than flexbox.
The same page, from a phone to a wide screen. Writing mobile-first isn't a preference anymore — it's the default.
It's in most job posts, and if you know CSS you'll pick it up in a week. The order matters: CSS first, then Tailwind.
The most important stop on the map. Most people who get stuck in React are really stuck in JavaScript. Don't rush this one.
Things you'll see on every line of React code. If you can't read these comfortably, React is going to feel hard.
map, filter, reduce, find. This is how you render lists and reshape data in React.
React does this for you — but you should do it by hand first, so you understand what React is actually solving.
Fetching data, waiting for it, catching errors. Interviewers' favorite topic.
import / export. This is how the files in every modern project connect to each other.
You'll use it on day one. Saving your code, creating branches, merging and sharing with your team. Your portfolio lives here too.
add, commit, status, log, diff. Making small commits that each mean something.
Creating branches, merging them and resolving conflicts. Not being scared of conflicts is a skill in itself.
This is how code gets merged on a team. Opening a PR, writing a description and responding to review comments.
The tools you use to set up a project, run it and track down bugs.
Installing packages, reading package.json, running scripts.
Today's default way to start a React project. Knowing roughly what a build tool does is enough.
Letting a tool settle the code-style arguments. Most projects come with them already set up — knowing what they're for is enough.
It's in nearly every junior frontend job post in Turkey. The official docs on react.dev are worth reading cover to cover.
Breaking the UI into small, reusable pieces.
Interactivity with useState. The real skill is deciding where a piece of state should live.
When you need useEffect — and, more importantly, when you don't.
useRef, useMemo, useContext, and writing your own hooks.
Apps with more than one page. React Router, or your framework's own routing.
Context is enough most of the time. If you see Zustand or Redux in a job post, understand the idea; no need to memorize the API.
It's in almost every job post now, and most new projects start with TypeScript. Nobody expects advanced type gymnastics — everyday use is what counts.
Describing the shape of your data. Being able to write a type for the response an API sends back.
Prop types, state types, event types. That's most of the day-to-day work.
Being able to read them is enough. Nobody expects a junior to write their own generic types.
Most of frontend work is showing data that comes from an API and sending data back. Not writing the backend — talking to it.
Endpoints, methods, request bodies, JSON responses. Poking at an API with Postman or a similar tool.
What do you show while the data is on its way, and what happens when an error comes back? The part junior projects skip the most.
Handles data fetching, caching and retries for you. Shows up a lot in job posts.
What a token is, what a cookie is, how you can tell a user is logged in. Not building it — understanding it from the frontend side.
Learn it after React, not before. It's in a good share of job posts; understanding why server-side rendering exists is a good enough start.
Where and when a page gets generated. Knowing the concepts goes a long way in interviews.
Nobody expects a junior to have a testing strategy; they do expect you to write a simple component test and know why tests get written.
I'd rather see a junior who can explain why they picked each technology in one real project than a CV listing 15 frameworks. This is where the whole roadmap is taking you.
If your project doesn't open at a URL, it might as well not exist. With Vercel, Netlify or Cloudflare Pages it takes a few minutes.
What the project does, how to run it, and why you made the decisions you made. The first file a recruiter reads — and often the only one.
“Why Zustand?”, “Why this folder structure?” What an interview is really measuring is how you answer questions like these.
Understanding the backend is really useful for a frontend developer. But writing APIs and setting up databases and authentication is a full-stack job.
Writing a simple API and hooking your frontend up to it will open your eyes. Not required for a junior frontend role.
If your company uses it, you'll learn it in a week. Knowing REST comes first.
There's usually someone on the team who sets this up. What's expected of you is being able to use what's already there.
Running a project in a container. Being able to read an existing Dockerfile is enough to start with.
Tests running on every push, a deploy on every merge. At your first job you'll find it already set up.
AWS, GCP, Azure. For frontend, it usually comes down to a CDN and static hosting.
Architecture, scalability, code review, mentoring. These come with experience; if you see them in a junior job post, something's probably gotten mixed up.
Keeping a growing codebase manageable. You need to have worked in a big codebase first.
Core Web Vitals, bundle analysis, render optimization. Basic performance common sense is enough — you'll learn the rest on the job.