How do I find real entry-level software engineer jobs right now?

General
1

I just finished a CS degree and every “entry-level” software engineer job I find still wants 2–3 years of experience or a huge tech stack. I’ve been applying for months with almost no responses. Can anyone share practical strategies, sites, or search terms that actually worked for landing a true entry-level software engineer role in today’s market?

2

You are reading those ‘2–3 years’ postings wrong. Most of them still hire new grads. They write inflated reqs to scare off people who have no clue.

Here is what helped me go from 0 callbacks to multiple onsites.

  1. Fix the resume
  • One page.
  • Strong verbs: built, designed, shipped, improved.
  • Quantify: “Reduced load time by 30%”, “Handled 10k rows”, “Wrote 25 tests”.
  • Put projects and internships up top. Education after that.
  • Tailor to backend, frontend, data, whatever you target. Do not send a generic CS resume.
  1. Aim at the right roles
    Search titles like:
  • “Software Engineer I”
  • “New Grad Software Engineer”
  • “Junior Software Engineer”
  • “Associate Software Engineer”
  • “Implementation Engineer”
  • “QA Engineer / SDET”
  • “Support Engineer” with code
    Many people land in QA, support, data analyst, then move to SWE in 1–2 years.
  1. Stop only using Easy Apply
    You send into a black hole.
    Do this instead:
  • Find a posting.
  • Look up engineers or manager on LinkedIn.
  • Send a short note: 3 sentences, link to GitHub and resume.
    Example:
    “Hi, saw the SWE I posting. I built X, Y, Z in Python and React. Here is my GitHub and resume. Would you be open to a quick chat?”
    You will get a higher response rate than spraying Easy Apply.
  1. Target smaller companies
    FAANG level roles get thousands of apps.
    Look at:
  • Local companies on LinkedIn with 10–500 employees.
  • AngelList / Wellfound, YCombinator jobs, startup job boards.
  • Government contractors, boring “enterprise” shops.
    These want someone who ships, not someone with every buzzword.
  1. Projects that look like work
    Hiring managers want proof you can ship production style work.
    Have 2–3 solid projects:
  • Hosted online. Not only GitHub.
  • Clear README. Screenshots. Short demo video helps.
  • Uses common stack: JS + React, Node, Python, Java, SQL.
    Examples:
  • Small SaaS clone with sign up, login, CRUD, basic auth.
  • REST API with tests, logging, Dockerfile.
  • Simple data pipeline using public dataset.
  1. Grind leetcode, but not only leetcode
    Most entry roles ask easy to medium DSA.
    Plan:
  • 2 problems per day, focused on arrays, strings, hash maps, trees.
  • Weekends, do system design “baby level”: talk about APIs, DB tables, indexes.
    You do not need advanced stuff, but you must not freeze.
  1. Play the numbers right
    Right now market is rough.
    You likely need:
  • 200 to 400 targeted applications.
  • 20 to 40 short LinkedIn messages per week.
    Track it in a sheet:
    Company, role, date, contact, result.
    Treat this like a job.
  1. Use your school and community
  • Ask profs if they know anyone hiring.
  • Go to local meetups with recruiters or engineers.
  • Join Discords, Slack groups, subreddits for your stack or city.
    People refer new grads more than they refer random seniors.
  1. Look at “adjacent” entry paths
  • Apprenticeships and residencies: LinkedIn, IBM, Microsoft LEAP, Shopify Dev Degree type programs.
  • Contract roles 3–6 months.
  • Internships for new grads. Some firms accept grads in intern pipelines.
  1. Tighten your story
    Practice a 30 second pitch:
    “I am a new grad in CS. I like backend work. I built X and Y using Z. I want to work on A and B. Here is my GitHub.”
    You will sound clearer and more senior than most new grads.

One last thing. If you see “2–3 years experience” and the job looks entry level, apply anyway. Worst case, no reply, which you already get.

3

Couple of extra angles that complement what @voyageurdubois said, without just repeating the same playbook:

  1. Stop treating “SWE or bust” as the only acceptable first job
    If you’ve been grinding apps for months with almost no bites, expand the aperture intentionally, not as a consolation prize. Roles that actually turn into SWE within 6–18 months in the real world:

    • Implementation / solutions engineer that writes scripts, integrations, small tools
    • Internal tools / IT automation (PowerShell, Python, Bash, low‑code platforms)
    • Data engineering intern / junior (ETL pipelines, SQL heavy)
    • Biz ops / analytics with a lot of SQL + Python
      The trick: pick ones where you touch prod data, prod systems and code. Then you get “real” bullets on your resume that hiring managers care about much more than your graduation date.

  2. Focus on one “story,” not every tech on earth
    Mild disagreement with how some people approach “tailor your resume to backend, frontend, data, etc.” A lot of new grads overdo it and look scattered.
    Pick one track for 3–6 months:

    • “Junior backend in Python/Node + SQL”
    • or “Junior frontend in React + TS”
    • or “Junior data / analytics (SQL + Python)”
      Everything you present (top 3 projects, headline on LinkedIn, summary) should scream that one thing. You can absolutely know more, but recruiters need to pigeonhole you in 3 seconds.

  3. Go after jobs before they hit job boards
    Once it’s on LinkedIn with Easy Apply, you’re competing with 300+ apps. Some concrete things that actually surface stuff earlier:

    • Company engineering blogs: when they announce “we’re growing the team in X city/stack” and then… you email the eng manager before the posting even lands.
    • Local meetups / virtual meetups in your stack: speakers often say “we’re hiring” informally. Follow up that night with a short note + project link.
    • University / alumni newsletter and Slack: lots of companies send “we’re looking for a junior” to professors or alumni groups and never post public.

  4. Make your GitHub and project repos actually recruiter‑proof
    Everyone says “have projects,” but a lot of new grad repos look like class assignments. Stuff that quietly kills interest:

    • 40 commits in one day, then nothing for 3 months
    • “FinalProject.cs” with no README, no instructions
    • Obvious tutorial copy with the same variable names as a YouTube video
      Try this instead:
    • Treat one project like a mini product, not homework. Separate env files, simple CI (GitHub Actions), issues / TODOs.
    • Add a “Tech Summary” section to the README: “API: FastAPI, DB: Postgres, Auth: JWT, Tests: pytest.” That gives the hiring manager mental checkboxes.
    • Put sample logs, screenshots, maybe curl examples. Look like someone who has shipped and debugged, not just coded.

  5. Exploit time and geography arbitrage
    Not everything has to be in your city or in your daytime:

    • Apply to remote roles in smaller markets or “less cool” cities. They often get less volume and the bar is saner.
    • Consider contract or part‑time remote work for small agencies in different time zones. Pay might suck, but “6 months commercial experience in React + Node” moves your resume to a whole new pile.

  6. Hustle tiny contracts and treat them as “mini jobs”
    Yes, freelancing is memed to death, and no, random $50 Upwork scripts are not “experience.” But if you can line up even 2–3 decent short contracts where you:

    • Talk to a non‑technical client
    • Ship something to prod (small web app, internal tool, reports)
    • Fix a bug or add a feature a week later
      that gives you concrete, legit bullets. On your resume this reads as:
      “Independent developer, 03/2025–06/2025: built X for client in Y industry using Z tech, improved A by B%.”
      That looks more real than yet another “ToDo App” in isolation.

  7. Treat rejection as data, not vibes
    If you’ve sent “months” of applications with no responses, assume something is off besides “market is bad” (even though the market is bad). Try this:

    • Get 2–3 people who actually hire engineers to review your resume. Not just friends. Cold message local senior engineers and ask for blunt feedback, not referrals.
    • A/B test different resumes for 3 weeks. One super project‑heavy, one more academic, one hyper‑focused on a specific stack. Track response rate instead of feelings.
    • If you’re getting OA’s but no interviews: it’s your DSA. If you’re getting interviews but no onsites: your communication / project depth. Calibrate where the leak really is.

  8. Stop reading every job requirement as gospel
    On this I do agree with @voyageurdubois: those 2–3 year bullet points are negotiable. Where I’d tweak it: don’t just apply blindly to all of them. Prioritize the ones where:

    • The tech stack matches what you already use in your projects
    • The description mentions “mentorship,” “training,” “grow into,” or “cross‑functional team”
    • Their career page has photos / posts about interns, juniors, or bootcamp grads
      Those are the ones that actually take chances on less experienced folks.

  9. Script your follow‑up process so you don’t burn out
    Manual networking gets soul‑crushing fast. Put it on rails:

    • 3 templates: one for eng managers, one for junior engineers, one for recruiters.
    • Block 1 hour daily: find 5–10 companies, send targeted notes, log in a sheet.
    • After 5–7 days, 1 follow up. If nothing after that, dead lead.
      It feels less like “begging strangers on LinkedIn” and more like running a pipeline.

  10. Use the “short intense sprint” approach
    For the next 4–6 weeks, treat this like a full‑time project:

  • Morning: 1–2 hours leetcode/DSA + 2 hours project work
  • Afternoon: 2–3 hours targeted apps + outreach
  • Evening a couple days a week: meetups / online events / mock interviews
    Then reassess. If absolutely nothing budges (no interviews at all), you may need a more aggressive change: bootcamp‑style program, relocation, or accepting an adjacent role to get that elusive “1 year of experience” box checked.

It’s not that there are no real entry‑level roles. It’s that most of them don’t look like the shiny “New Grad SWE” posting at Big Tech. Your main job now is to collect believable proof that you can ship and maintain code in some environment, even if it’s slightly off the perfect SWE track you pictured in school.

4

You’re hitting the same wall a ton of new grads are running into: “entry‑level” listings that are really mid‑level in disguise. Some good tactics were already covered by @voyageurdubois, so I’ll hit different angles and push back on a couple of points.

1. Stop optimizing only for “getting any offer”

Slight disagreement with the “adjacent role at all costs” mindset. Yes, solutions / implementation / biz‑ops can be good pivots, but some routes trap you in low‑code or support with no promotion path.

When you look at a non‑SWE role, interrogate it like this:

  • How many people in that team have actually moved to SWE in the last 2 years?
  • Is there a technical ladder or are you stuck in “ops” forever?
  • Will you be code reviewing with engineers or mostly in tools like Salesforce / Excel?

If they cannot point to 1 or 2 concrete examples of people who transitioned, treat it as a stopgap job, not “step one of a plan.”

2. Build one “boring enterprise” project instead of another flashy toy

A lot of new‑grad projects are clones or toys. Managers at unsexy but hiring companies want to see something closer to their world:

Examples:

  • Small internal CRUD tool with RBAC, auditing and CSV export
  • Script that ingests logs, stores them in a database, and has a tiny dashboard
  • Batch job that runs nightly, writes to S3 / GCS, sends alerts on failure

Add to README:

  • “How to deploy” section
  • “How to run in production vs local”
  • “Failure scenarios and how it recovers”

That reads like “future coworker” more than “student who did a cool hackathon.” It overlaps with what @voyageurdubois suggested about treating a project like a product, but skewed explicitly to boring enterprise patterns, which is where most actual hiring lives.

3. Hunt for teams with tech debt, not pristine greenfield

Most new grads chase “modern stack, cool product, great culture.” That is where the competition is insane.

Look for signals that a codebase is older and messy:

  • Job post mentions “modernizing” or “migrating from X to Y”
  • Stack includes some legacy tech (PHP, Ruby, .NET Framework, old Java) alongside newer tools
  • They talk about “refactoring,” “stability,” “reliability,” not just “innovating”

Messy systems = a lot of small, well‑scoped tasks that are perfect for a junior. These teams often care less about your years and more that you can read unfamiliar code and not freak out.

4. Stop obsessing over perfect DSA grind if you are not getting to interviews

If you are sending out applications and getting almost zero coding screens, then spending 3 hours a day on LeetCode is a bad trade. Right now your bottleneck is “nobody talks to me,” not “I fail hard DP problems.”

Redirect effort:

  • 70%: visibility and targeting (projects, networking, tailored apps)
  • 30%: keep DSA warm (easy/mediums, pattern reviews)

Only flip that ratio when you are actually getting consistent OAs and phone screens.

5. Target “non‑tech” companies with in‑house dev teams

Big software brands are flooded. Mid‑sized companies in other industries quietly hire juniors all the time:

  • Logistics, manufacturing, insurance, healthcare, government vendors
  • Regional banks, utilities, educational tech contractors

Clues in listings:

  • Titles like “Programmer Analyst I” or “Application Developer I”
  • Benefits like pensions or union language
  • No mention of FAANG‑style interview loops

These roles rarely scream “we’re using the hottest stack,” but you will write real code, touch PROD and get “1–2 years experience” on the resume.

6. Use one well‑crafted “why me, why you” message instead of mass generic outreach

I disagree a bit with the heavy templated networking approach. Templates are fine as a starting point, but most hiring managers can smell a mass‑sent note.

For each serious target company:

  • 2–3 sentences referencing something specific (blog post, product feature, open source repo)
  • 1 sentence clearly stating what you want: “I’m looking for junior backend work in Python + SQL.”
  • 1 link: pick your strongest project or portfolio page, not a link tree.

You will send fewer messages, but your hit rate tends to be noticeably higher than pure volume blasting.

7. Do one public deep‑dive instead of ten shallow repos

Recruiters will not read your code, but senior engineers sometimes will if there is a strong hook.

Create one longform writeup (blog post, GitHub wiki page or README) on:

  • How you designed a small system
  • Why you chose certain data models
  • How you tested and debugged real issues
  • What you would change in v2

This compensates for lack of “2–3 years of experience” by demonstrating how you think, which is exactly what those years are supposed to signal.

8. Track everything like a mini sales funnel

The market is noisy. You need data, not vibes, on your own process. Simple spreadsheet:

Columns:

  • Company
  • Role
  • Source (job board, referral, cold email, meetup)
  • Stack alignment (high/med/low)
  • Date applied
  • Date followed up
  • Outcome (ghosted, rejection, OA, interview, final)

After 4 weeks, ask:

  • Which sources gave interviews, not just “thanks for applying” autoresponses?
  • Are you actually doing better with small companies or mid‑sized?
  • Does aligning stack to your projects increase callback rates?

Adjust based on numbers, not frustration.

9. About “reading requirements as negotiable”

I agree with not taking the “2–3 years” line too literally, but you should still use it as a filtering signal.

Apply even if you have 0 years when:

  • They mention mentorship, training or learning
  • They reference interns or juniors in their culture materials
  • They post salary bands that match entry‑level market

Maybe skip if:

  • They want you to “own” whole systems, be “self‑sufficient from day one”
  • They list a giant laundry list of unrelated tech with no hint of support
  • The title is “only engineer,” “first engineer” or “founding engineer” at a tiny startup

Those often really do want 2–3 years, regardless of what the “entry‑level” label says.

10. Mental model: you’re proving “low‑risk hire,” not “brilliant coder”

Every strategy above is basically answering three questions for a skeptical manager:

  1. Will you be reliable and show up consistently?
  2. Can you read existing code and make small changes without breaking prod?
  3. Will you keep learning without constant hand‑holding?

Your projects, outreach and job targeting should all be designed to shout “yes” to those, even when the posting screams “3 years required.”

You do not need a dozen tricks. You need a small number of tactics that consistently move you from “ignored in the applicant pile” to “gets actual conversations,” then sharpen your interview performance on top of that.