The entry-level software engineering market is the most brutally competitive it has been in a decade: fewer junior openings, more graduates, and screening pipelines tuned to filter at scale. That context should change how you write the resume. A junior engineering resume cannot win on credentials, because credentials are identical across thousands of applicants; it wins on evidence of shipping, which most candidates fail to provide. The example below is built around one idea: make every project read like a job, with users, constraints, and numbers.
Know the pipeline your resume enters. At most companies hiring juniors, an ATS parses your PDF into text and a recruiter, often non-technical, searches and skims that text for stack keywords, education, and anything resembling real-world usage. Survivors go to an engineer who reads differently: they open your GitHub, judge your best project's README in thirty seconds, and look for signs you have debugged something that mattered. The page must serve both readers: literal keywords in plain text for the first, depth signals (deployment, users, tests, tradeoffs) for the second.
Section order for a new grad: header with GitHub and LinkedIn links, an optional two-line summary, education with graduation date and relevant coursework, projects as the load-bearing section, then any experience (internships first, but ordinary jobs too), then skills grouped by category. Bootcamp grads run the same order with the bootcamp listed as education plus their prior career kept, compressed, as experience. Once you hold your first engineering job for a year, the order inverts and this page's mid-level counterpart takes over.
The projects section decides junior applications, so build it before you polish it. Three projects beat eight: one substantial (deployed, with real or test users, and a README that explains decisions), one collaborative (team capstone, hackathon, or open-source contribution, proving you can work in someone else's codebase), and one that matches your target stack. Each gets one heading line with a link and two or three bullets shaped like work: what it does, what it is built with, and one number (users, requests handled, test coverage, load time, stars, data volume).
Write project bullets as engineering decisions, not feature lists. "Built a recipe app with React and Firebase" describes ten thousand identical resumes. "Cut initial load from 4.1s to 1.3s by code-splitting routes and lazy-loading images, measured with Lighthouse" describes an engineer. Every project has decisions hiding in it: a schema you redesigned, an API you paginated, a race condition you found, a deploy you automated. Surface one per bullet with its measurable effect. The quantification guide applies to side projects too: instrument them, then quote them.
Treat internships and even non-tech jobs as evidence. An internship entry follows normal experience rules: scope first, then outcomes with numbers, however small the codebase. No internship? Your restaurant, warehouse, or retail history still belongs, compressed to two lines, because engineering teams hire juniors partly on reliability and teamwork, and verified employment is the only proof of either that a new grad owns. One bullet can even bridge domains: "built the Excel schedule tracker the store still uses" is a tiny engineering story inside a non-engineering job.
Keep the skills section honest and grouped, because it is your interview menu. Three labeled lines: languages (only ones you can code an interview problem in), frameworks and tools, and practices (Git, testing, CI, agile rituals you have actually done). Order by strength, not alphabet. Every listed item is an invitation for a question, and a junior who lists eight languages then stumbles in two reads worse than one who lists three and holds depth in each. The skills guide covers calibration; the short version is: list what you would bet an interview on.
Make education do specific work. Degree, school, graduation month and year in plain text (it is a screening field), GPA if 3.0+, and a relevant-coursework line chosen for the target role: data structures and algorithms always, then whatever matches the posting (databases, operating systems, ML, security). Bootcamp grads list the program like a degree: name, length in weeks and hours, stack covered, and the capstone as a project entry. Self-taught candidates replace this section with certifications and let projects carry everything, which works more often than forums suggest, but only with a genuinely strong projects section.
Format for parsers with zero exceptions. One column, standard headings, standard font, one page, PDF. Junior tech applications hit the most automated screening in hiring, and the dense single-column silhouette is also what engineers expect culturally; a designed resume signals unfamiliarity with the field's norms. Link GitHub and LinkedIn as clean URLs in the header. Name the file LastName-FirstName-Resume.pdf. Every rule and its reasoning is in the format guide; junior candidates get zero credit for creativity here and real penalties for parse failures.
The summary question for juniors: skip it if your page is self-explanatory, write two factual lines if you need to bridge a gap the page cannot, such as a bootcamp pivot, a non-CS degree, or a stack transition. Never write a paragraph of adjectives; a recruiter who has read four hundred junior summaries this week can no longer see the word "motivated". The summary variants further down this page show the factual style at three levels, and the objective examples cover the pivot cases where an objective genuinely helps.
Tailoring for junior engineering roles is mostly keyword honesty: read the posting, identify its three core stack demands, and make each visible in your top half where truthfully yours, in the posting's exact form ("Go (Golang)", "React.js", "PostgreSQL"). If the posting's stack and yours differ, lead with your transferable evidence (APIs, databases, testing, deployment) and add one honest line about learning velocity backed by a project in an unfamiliar stack. The tailoring guide turns this into a ten-minute routine per application.
Use this page as a kit. The resume below is a complete, realistic new-grad example rendered by our real template engine; the "Use this example" button opens it in the builder so you can swap in your own projects and history. Pull phrasing from the bullet bank, check the keyword list against your target postings, and read the ATS extract at the bottom to see exactly what the screening layer receives, because in this market the difference between interviewed and invisible is often just whether the parser kept your projects.
Frequently asked questions
- How many projects should I list, and what makes a project resume-worthy?
- Two or three, and the bar is decisions plus evidence, not size. A project earns its place when you can write at least two bullets that name an engineering decision and its measured effect: a performance number improved, a bug class eliminated by a design change, tests enforced in CI, real users served, data at some scale processed. Under that bar, projects blur into the same tutorial-shaped apps every reviewer has seen a thousand times, and listing five of them dilutes the one that matters. The strongest portfolio shape for a new grad: one substantial deployed project (your flagship, with users even if they are friends, a thorough README, and a live URL), one collaborative entry (capstone, hackathon, or an open-source contribution, because working in code you did not write is the actual job), and one aligned to your target stack. Upgrade what you have rather than starting new: deploy the existing app, add tests and a CI gate, instrument it so you can quote numbers, and rewrite the README to explain tradeoffs. A weekend of that work converts a homework project into a resume project. And prune ruthlessly: the tutorial todo app, the unmodified course assignment, and anything you cannot discuss for ten minutes should come off, because interviewers pick the weakest listed project as often as the strongest.
- Do I need a GitHub profile, and what will reviewers actually look at?
- For entry-level roles, effectively yes: it is the only verifiable work sample a junior owns, and enough reviewers click it that an absent or empty link is a real cost. What they look at, in the thirty to ninety seconds they spend: your pinned repositories (curate two to four best, never the default recent list), the flagship's README (what it does, how to run it, one screenshot, and ideally a short decisions section), whether commits are real work with sane messages or a graduation-week dump, and any contribution to code that is not yours, since a single merged PR into an established project outweighs several solo repos. What they do not care about nearly as much as students fear: the green contribution graph, follower counts, and volume. One well-maintained deployed project beats fifteen forks. Preparation checklist before applying: pin deliberately, delete or archive abandoned tutorial repos, confirm the flagship actually clones and runs on a fresh machine (a broken quickstart is worse than no link), make the profile name match your resume name, and add a two-line profile README pointing at your best work. If your situation limits public code, say so on the profile and show the closest approximations; reviewers in security-adjacent and enterprise tracks understand, but the burden shifts to your interview performance.
- Bootcamp grad vs CS degree: how should each write this resume differently?
- Same skeleton, different emphasis, and both should stop apologizing. A CS grad leads with education (degree, graduation date, algorithms coursework) because new-grad pipelines screen on it, then makes projects prove practical shipping ability, which is the degree's known gap. A bootcamp grad lists the program in education with full specifics (name, weeks, total hours, stack) and leads the page with deployed work, because shipping is the bootcamp's strength while the known gap is fundamentals; one visible signal of CS depth (a data-structures-heavy project, a solid algorithmic solution linked, or supplementary coursework) buys real credibility. The bootcamp grad's secret weapon is the prior career: keep it, compressed, and mine it for engineering-adjacent evidence (operations, deadlines, clients, any tooling you built), then target the intersection where the old domain plus new skills beats any pure new grad, like restaurant-tech roles for the former restaurant manager. Where each gets screened out unfairly: some new-grad programs are degree-gated, and bootcamp grads waste cycles there; smaller companies, agencies, and startups weight demos over pedigree and interview bootcamp grads readily. Both profiles fail identically when the projects section is weak, which is the honest common denominator: reviewers hiring juniors are buying evidence of shipping and learning velocity, and the credential mostly decides which pile gets checked for that evidence first. The career change guide covers the pivot-framing details.
- The posting asks for 1-2 years of experience. Can a new grad apply?
- Yes, and you should, because "1-2 years" postings are where most juniors actually get hired. Experience requirements on postings are written as wishes, calibrated loosely, and routinely waived for candidates who show equivalent evidence; recruiters themselves treat the entry-level band (0 through 2 years) as one market. Your job is to make the equivalence easy to see: a deployed project with users, an internship, a merged open-source contribution, and enforced tests in CI collectively read as the practical maturity the "1-2 years" phrase is grasping for. Apply the counting rules honestly in your favor too: internships count as experience and belong in the experience section; substantial freelance or contract work counts; a year of consistent side-project shipping is legitimately describable as a year of part-time engineering practice, as long as you label it truthfully ("independent projects, 2025-present") and never as employment. Where to spend your applications: postings that say "0-2", "junior", or "new grad" convert best; "1-2 years" postings are worth applying to with a tight, evidence-forward page; "3+ years" and "mid-level" postings are usually real thresholds tied to unsupervised-work expectations, and your cycle is better spent elsewhere. What never works is inflating dates or titles, because engineering references and background checks are routine, and the interview itself calibrates your level within an hour regardless of what the paper claimed.
- How do I list AI tools and AI-assisted projects without looking like a fraud?
- The junior version of this problem is sharper than the senior one, because interviewers now assume juniors used assistants heavily and probe accordingly. Rules that hold up. First, never list an assistant as a skill; "Copilot" in a skills section reads like "Google" would, and at entry level it actively invites the suspicion that the assistant did your projects. Second, your flagship project must be code you can walk through line by line, because junior interviews increasingly include exactly that exercise: explaining a file from your own repo, extending it live, or defending a design choice. If an assistant helped write it, that is fine and normal; the standard is understanding, not authorship purity, and the failure mode interviewers screen for is the candidate who cannot explain their own architecture. Third, AI usage becomes a legitimate bullet only as engineering judgment: an evaluation you ran, tests you added because generated code failed them, a prompt-driven tool you built with a measured outcome. Fourth, keep one honest sentence ready for the inevitable interview question about how you use assistants day to day; naming where you trust them (boilerplate, tests scaffolding, unfamiliar-API exploration) and where you do not (architecture, security, anything you cannot verify) reads as maturity. And do not let a model write this resume unsupervised either: screeners have learned the cadence, and generic AI prose on a junior page confirms the exact doubt you are trying to beat.
- Should I take a support, QA, or IT job while hunting for an engineering role, and how does it read later?
- Take it, with a plan attached: adjacent technical jobs beat both unemployment and long gaps on every axis that matters, provided you keep shipping evidence alive. How each reads to engineering hiring managers: IT support proves troubleshooting discipline and user empathy, and internal transfers from IT to engineering happen constantly at large companies; QA is genuinely undervalued as a route, because QA engineers who automate their own work (Selenium, Playwright, Pytest suites) build a public track record of exactly the testing skill engineering teams lack, and SDET-to-SWE is a worn, respected path; technical support at a software company puts you inside the codebase's blast radius, where reading stack traces, filing precise bugs, and eventually fixing small ones is a documented promotion route. The plan that keeps the door open: negotiate for any code-touching duties in the role, keep one substantial side project moving with visible commits, contribute fixes upstream where your job surfaces bugs, and apply to internal engineering openings early, since transfer bars are lower than external ones. On the resume, frame the adjacent job by its engineering-relevant output (scripts written, automation built, bugs diagnosed) and keep your projects section current, because it remains your primary exhibit. The trap to avoid is passive drift: eighteen months of ticket-closing with no code artifacts genuinely does get read as a plateau. The IT support example shows how to write the adjacent role at full strength.