this is my guide to navigating the new grad software engineering recruiting process, from applying to landing an offer. it’s based on my real experiences with various companies from startups to faang.
this guide is for people who feel like they’re not the best. you don’t need to be a usaco platinum or a leetcode god. i hope this helps anyone feeling overwhelmed or unprepared. you’re more capable than you think.
inspired by my friend bradley tian (berkeley'25, incoming at openai) and his detailed early-career swe guide. i highly recommend checking his guide out. it’s a great resource for planning your college cs path. he covers which extracurriculars and projects to focus on, how to build experience, and offers a comprehensive overview of the recruiting process with actionable tips while mine is focused on the actual interview process, specific interviews i had with different companies and what i learned from them.
i’m not a cracked, top-tier bay area cs student. i just grew up building pcs and playing games, and one day my aunt said:
“you’re always on the computer. why not make it your job?”
that stuck. i picked up cs in high school as a low-income, first-generation student with limited resources and not much initial motivation. my school was more focused on athletics than academics, especially cs, so i didn’t have much of a foundation and i was pretty addicted to video games. in college i realized how little i knew about how computers really worked. the deeper i went, the more fascinated i became with creating software and understanding systems under the hood.
i’ve been extremely lucky to have interned at google multiple times, worked part-time at amd, and a part of plextech @ uc berkeley that gave me hands-on experience and a great support system.
i also want to acknowledge how hard recruiting is, especially for:
i still haven’t finished leetcode 75. i noticed i learn best under pressure, so i started using interviews as way of preparation, which is a strategy i want people to try out.
just keep learning and showing up. use each experience as a building block.
recruiting is tough.
as my friend dylan huynh (berkeley ‘24, databricks) once told me (paraphrased):
“recruiting is just a numbers game and all you can do is just increase your odds. there are too many variables that come with it, and there’s no clear-cut path to getting an offer.”
this guide will be broken up into the following stages of the interview process:
do the best you can to get as much experience as possible. if one path doesn’t work out, pivot to another. there are so many ways to gain experience. the important thing is to just start somewhere.
as you work through projects, document the obstacles you hit and how you solved them. write them down immediately. over time, this will become your bank of stories for behavioral interviews. follow the star method (situation, task, action, result), and reflect on tradeoffs and what you’d do differently if you had more time.
side projects are probably the best way to build technical depth, explore what you’re interested in, and show initiative. just be mindful of the decisions you make.
one mistake i made was choosing tools first just because they were trendy (e.g. golang, docker) to solve some problem, rather than choosing the right tools for the job. in interviews, people would ask me, “what was the most technically difficult part?” and i’d end up talking about things like setting up docker containers and learning golang, which isn’t really compelling. instead, pick a project that solves a real problem, ideally one you care about. that way, you’ll be more motivated, and you’ll run into meaningful design and implementation challenges, the kind you can talk about later in interviews.
clubs can be a great way to get team experience, especially if they build products, run workshops, or compete in technical challenges. that said, clubs can be very competitive, so don’t worry if you don’t get in right away.
try again next semester or use side projects to build experience in the meantime.
internships are valuable not just for the resume, but for understanding how software gets built in the real world.
i know they can be hard to get, especially early on or if you’re coming from a non-target school.
if that’s the case, double down on your personal projects, attend career fairs, work in startups and other forms of experience to help you break in.
if you’re newer to cs or still in school, course projects are a great starting point.
try to go beyond the minimum requirements: add features, refactor the design, or optimize performance. then put those versions on github with clean documentation.
just avoid using super generic course projects that everyone in your program does unless you’ve done something notably different.
teaching (ta-ing, mentoring, or tutoring) shows mastery, leadership, and communication, which are all super valuable. even informal teaching counts. if you’ve ever helped someone debug a project or understand a concept, that’s already a good story to share in your behavioral interviews.
consider ta-ing for cs classes, hosting workshops, or tutoring/mentoring for societies and programs within your campus or online programs.
hackathons are a fun way to build something quickly and meet people. even though i haven’t done too many myself, i’ve heard great things because you can win prizes, meet new people, work with sponsored tech, and potentially build some great projects.
just make sure the projects you walk away with are well-scoped and documented. that way, you can reuse them in interviews or on your resume.
contributing to open source is one of the best ways to gain experience working with a real codebase. i haven’t done much of it myself yet, but i wish i had. it teaches you how to navigate unfamiliar code, follow coding standards, and work with other contributors.
i don’t have personal experience with research, but it’s a strong path if you’re interested in depth, theory, or working closely with faculty. it can help you explore topics like systems, ai, hci, etc., and it often opens doors to grad school or specialized roles. if you’re still in school, try reaching out to professors/grad students whose work you find interesting.
freelancing can give you hands-on experience building for real people. personally, i like the idea of solving a concrete problem for a client and seeing the direct impact. if you enjoy that too, freelancing can be really fulfilling and you’ll learn to manage scope, communication, and deadlines, which are all key professional skills.
i think this is the most difficult to get in since you have to do lots of self-advertising to get clients.
in the end, it doesn’t matter which combination of these you pursue. what matters is that you’re gaining experience, building confidence, and learning how to work through real problems.
if you’re just starting out, side projects, course work, and freelance gigs are great early bets. if you’re closer to graduating, double down on projects, hackathons, freelancing and open-source contributions.
whatever you do: reflect on what you learned, document your growth, and tell your story well. experience is less about the medium and more about how you make meaning from it.
my friend matthew nguyen (meta intern, berkeley ‘26) gave me this great mindset:
“gaslight yourself into loving the topic you’re studying.”