Entry-level postings that ask for experience usually mean evidence that you can do the work, not years on a payroll. Build that evidence with two real projects, a small piece of work for a real user, and targeted applications to roles where juniors are actually hired, then apply anyway when you meet most of the list.
What people tell me
Every junior or entry-level role I open asks for one or two years of experience. I understand the basics, I have done courses and a couple of small projects, but I have never worked anywhere. It feels like a loop: I cannot get experience without a job, and I cannot get a job without experience. I have started skipping postings because I assume they will reject me anyway, and I am not sure what counts as experience if I have never been employed.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- "1 to 2 years experience" on a junior post is often a wish, not a filter. If you meet about 60 to 70 percent of the list, apply.
- Experience means evidence: shipped work, real users, code others have read. You can create that before your first job.
- Two deep projects with real data and a clear write-up beat ten tutorial clones.
- Unpaid or small paid work for a real person, open source fixes and internships all count and belong on your resume.
- Aim at employers that hire juniors in volume, not only at the companies everyone applies to.
The loop is less closed than it looks
When a job post for a junior developer says "1 to 2 years of experience", it rarely means the company will throw away every application without it. Job descriptions are often written from a template, copied from an older role, or describe the ideal candidate rather than the minimum. What the hiring team actually wants to know is simple: can this person contribute without needing to be taught everything from zero?
That question can be answered without a previous employer. Your task is to replace "years" with evidence.
What counts as experience when you have never been employed
| Type of evidence | Why it counts | How to show it |
|---|---|---|
| A project with real users, even five | Proves you handled bugs, feedback and change | Link, user count, one problem you fixed after launch |
| A deep project with real data | Shows you can go past a tutorial | README with architecture, trade-offs and what you would change |
| Freelance or favour work for a real person | Real requirements, deadlines and a client | Short entry under Experience with outcome |
| Open source contributions | Your code was reviewed and merged by strangers | Links to merged pull requests |
| Internship, part-time or volunteer tech work | It is experience, whatever the title | Normal Experience entry with results |
| Final year project done properly | Team work, scope and delivery | Treat it like a job entry, not a line in Education |
If you have two or three items from this table, you have experience in the sense most junior hiring cares about. Put it in the Experience section, not hidden under "Projects" at the bottom.
Step by step: building evidence in the next two months
- Pick one role title you are targeting, such as frontend developer, backend developer or full stack developer. Evidence only works if it points in one direction. The Frontend and Backend roadmaps show what a hireable junior in each looks like.
- Build one deep project, not a clone. It should have authentication, a database, error handling, some tests and a deployed link. Spend three to four weeks on it, not three days.
- Find one real user. A family business, a society at your university, a friend running a small shop. Build them something small that they actually use. This single step changes interviews, because you will have real stories.
- Make two or three small open source contributions. Documentation fixes and small bugs are fine. The point is that another engineer reviewed your code.
- Rewrite your resume around outcomes. "Built a booking tool used by a local clinic to replace a paper register" is experience. "Worked on a MERN project" is not.
- Apply while you build. Do not wait until everything is perfect. The readiness question is usually answered earlier than people think.
Where juniors actually get hired
Many people only apply to the same handful of famous companies, where competition is at its highest and junior hiring is at its lowest. Spread your list:
- Companies with graduate or trainee programmes, which exist specifically to hire people without experience.
- Service-based and outsourcing companies, which hire juniors in batches and train them on client work.
- Small startups, where one extra pair of hands matters more than a perfect resume.
- Internships, including paid ones after graduation. Many convert to full-time offers.
- Non-tech companies with small tech teams, such as retail, logistics or healthcare firms building internal tools.
Browse /companies/ and /internships/ to build a list of 30 to 50 employers across these groups, not five.
How to read a job description without talking yourself out of it
Split every requirement into three buckets:
| Bucket | Example | What to do |
|---|---|---|
| Core skill | "JavaScript, React, REST APIs" | You need this. If you lack it, do not apply yet. |
| Nice to have | "Docker, AWS, GraphQL" | Apply anyway. Mention anything close you have touched. |
| Wish list | "2 years experience", "worked in agile teams" | Replace with evidence from your projects. |
If you meet the core skills and some of the nice to haves, apply. The worst outcome is silence, which you already have by not applying.
A 30-day plan
| Week | Focus | Output by Sunday |
|---|---|---|
| 1 | Choose role, audit skills against 10 real job posts | A list of the 5 skills that appear most often |
| 2 | Start deep project, find one real user | Deployed first version, even if rough |
| 3 | Finish core features, first open source fix | README with screenshots and trade-offs, one PR opened |
| 4 | Rewrite resume and LinkedIn, start applying | 20 to 30 targeted applications sent |
Keep applying at a steady pace after week four while you improve the project. Applications and building should run in parallel, not in sequence.
Common mistakes
- Waiting for "enough" skills. There is no finish line. Apply at the point where you can build and explain a working app.
- Ten shallow projects. Recruiters skim; interviewers dig. Shallow projects fall apart under two questions.
- Hiding real work. Helping a relative's business with a website or spreadsheet automation is experience. List it.
- Sending the same resume everywhere. Tailor the top third to the role title. The resume shortlisting answer goes through this line by line.
- Only applying through job boards. A short message to an engineer at the company often gets you seen when a portal does not.
What to say in interviews when asked about experience
Do not apologise. Say something like: "I have not held a full-time role yet, but I have built and maintained a tool that a small business uses every day. Let me walk you through a problem I had to solve after it went live." Then tell a specific story. Interviewers remember stories far more than job titles.
If you are still stuck
The end-to-end path from degree to offer is in From CSE graduate to your first software engineering job, and the free Your first tech job roadmap lays it out stage by stage. If you want someone to look at your projects and tell you honestly whether they read as experience, join Sefism. It is free to learn, you get credits on joining and your first roadmap is free, and as a member you can ask your own question or book a 1:1 session.
Was this answer helpful?
Read next
- How to Start Your Career as a Software EngineerHow to start a career in software engineering in 2026: pick one language, build past the tutorial, learn five fundamentals, get real feedback and apply earlier than you feel ready. With a twelve month plan and an honest market read.
- From CSE Graduate to Your First Software Engineering JobHow computer science graduates land their first software engineering job in 2026: run learning, applications and interview practice in parallel, practise DSA by pattern, train the performance part and follow a twelve week plan.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.