How to Get a Developer Job When Entry-Level Seats Are Shrinking

This article is different from the rest of The Senior Eye. Every other piece is built around something running, a component made by hand with the code beside it, checked against a standard, and this one hands you nothing to build at all. One of the reasons I started the site was to pass on senior judgment early, the part of the craft that normally takes years of sitting in code review to absorb, and the question I actually get asked is how to get in at all.

I also made a video version of this article, with the same chapters, if you’d rather watch than read. Only the text ends with the whole plan as a checklist you can print.

So this one is written to somebody trying to get in, and plenty of you reading it got in a while ago. Stay anyway, because I still do a fair amount of this plan. But the person who needs the whole thing is probably somebody you already know, the intern who asked you for coffee, the bootcamp graduate in your replies, the cousin finishing a degree into a market nobody warned them about. Send it to them.

That question is harder than it used to be, because of the moment we’re in. The classic entry path into this industry, the entry-level seat where you learn on small tickets while a senior checks your work, is narrowing, because AI now produces exactly the kind of code those small tickets used to be made of.

A Stanford Digital Economy Lab team led by Erik Brynjolfsson tracked payroll records from ADP, the largest payroll software provider in the United States, to measure what happened to early-career workers once generative AI arrived. Their latest revision sorts occupations by how much of the work AI can do, and software development sits among the most exposed. For 22 to 25 year olds, employment kept growing in the least exposed occupations and fell behind in the most exposed ones. The gap between the two is 19%, and workers over 25 in those same exposed occupations show nothing like it.

The authors find the adjustment runs through reduced hiring rather than layoffs, with firms opening fewer entry-level seats instead of cutting the people they already have, and they frame all of it as early descriptive indicators rather than causal estimates. Saying the tools closed those seats is my conclusion rather than theirs, and I draw it because it matches the work I watch the tools absorb every week. I’m not the only one drawing it. A paper by Harvard researchers Seyed Mahdi Hosseini Maasoum and Guy Lichtinger, covering nearly 285,000 firms, identified the companies adopting generative AI through the integrator roles a firm advertises when it brings the tools in. At those adopters, junior employment fell afterward while senior employment in the same firms kept growing, and the decline came from hiring fewer juniors rather than letting juniors go, the same pattern the payroll data shows.

Stanford’s lab also publishes a cut of its data for software developers alone, and it shows which ages inside this field lost work and which didn’t.

In the chart below, every line starts at 100, and 100 is that age group’s employment in November 2022. A line above 100 means more people that age are working as software developers than were working that month, and a line below 100 means fewer. All six lines touch 100 at the marker because that’s the month they’re all measured from.

Before that month the six lines rise together, never more than a few points apart. Afterward they split. By June 2026 the 22 to 25 line has fallen to 79.8, about a fifth fewer developers that age than in November 2022, while the 41 to 49 line has climbed to 120.8, about a fifth more. Every group over 25 ends up near or above where it started.

Only one age group is falling, and that’s the difference between a slow hiring market and a narrowing entry door.

A caveat belongs here, because the chart counts ages rather than job titles. Nobody publishes payroll data by seniority, so the 22 to 25 group is standing in for the entry-level seat, and it stands in reasonably well, since most people that age in this field are in their first or second role. The two still aren’t the same thing, and the gap matters if you’re arriving later, changing careers at thirty or finishing a bootcamp at thirty-five. You’d never show up in that group at all while competing for the same seats it counts, so read the number as understating your problem rather than exempting you from it.

Treat that as a map of where the entry-level seats went. The work didn’t disappear, and neither did hiring. The seats that shrank are the ones where a company pays you to learn the basics on the job, and the basics increasingly overlap with what the tools now produce on demand.

No tool produces a person who can look at plausible output and tell whether it’s actually good, and that judgment is something you can start building before anyone hires you. This site exists partly to hand it to you early, and this article is the practical half of that promise.

It’s the plan I give everyone who asks me how to get in. The whole thing is collected as a list at the end, if you’d rather take that and go.

Portfolio

Let the work talk

Nothing here argues against finishing your degree or your course. Fundamentals build on each other, and the study habit is the same one this whole plan runs on. The question is how much weight a credential actually carries. When an entry-level posting collects a few hundred applications, the credential rows read nearly identical, and each one gets seconds of attention. A deployed project is a different thing entirely, because a stranger can click it, use it, and watch it hold up, and going by the applications I’ve seen, almost nobody has one.

So build a portfolio out of real, finished things a stranger could use. You’re welcome to use this site as your backlog. Every build on this site is meant to be made by hand and checked against a standard, which makes each one portfolio material. One component sitting alone in a repository still reads like finished homework, though, so don’t stop there.

Grow each build into a small library instead. For example, you could take the accessible modal dialog and shape it into a dialog library any framework can drop in. The tooltip system could become a package that owns positioning and dismissal, and the adaptive card that honors user preferences could become a set of components that respect those preferences out of the box. Any other build here works the same way, and so does anything of your own you’ve had to solve more than once.

Open source doesn’t have to be huge to be valuable, and a small, focused library that solves one real problem shows the half of senior work you can practice alone, things like the API design and the documentation. Publish it properly, with the package on npm, a README, and a deployed demo page. Firebase Hosting, GitHub Pages, Netlify, Vercel and Cloudflare Pages all host one free, and all of it links from your profile.

It’s fine if the repository never gets popular, because it’s there to show a stranger how you build. And you don’t need to know everything to start one, since the gaps you hit along the way are exactly the writing material the next section asks for.

Then add one project nobody assigned you. Pick a problem from your own week, scope it yourself, and ship it, because a guided rebuild proves you can execute, and choosing the problem yourself proves the judgment I said no tool produces.

Finish it off with one contribution to a codebase you didn’t start. A merged pull request into a library you actually use, even a modest one, proves what no solo repository can, that you can read unfamiliar code, work inside someone else’s constraints, and take review from a stranger. That’s the other half of senior work, the collaborative half, and you’ll be hired into an existing system far more often than to invent a new one.

Grade each portfolio project against three checks.

• A deployed URL. Someone with your link and thirty seconds can use the thing without cloning, installing, or trusting you. If it only runs on your machine, it doesn’t count yet.
• A README that explains two decisions. Two choices you actually made, a short paragraph each. Maybe why you wrote the date picker yourself instead of installing one, or why the form checks the email when you submit rather than on every keystroke. A feature list shows what you assembled, a decision shows what you understood, and the interview will be about the second one.
• One thing you’d redo. Name it in the README, honestly. It reads as self-review, and self-review is the most senior signal an early project can carry.

For programmers, all of this goes on a public GitHub profile, pinned repositories with those READMEs on top. For designers, it goes on Dribbble and Behance, where the deployed URL becomes the shipped case study and the two decisions become the before and after with the reasoning in between. Either way you’re aiming at the same thing, proof a stranger can inspect without your help.

Write down what you figured out

The second thing that proves you can do this is writing, and most people skip it, because putting yourself forward as someone worth reading feels weird.

Write about what you just learned. It doesn’t need to be a tutorial or a guide aimed at people ahead of you. You’re telling somebody what confused you and what it turned out to be. The reader you’re writing for is the person who hits the same wall next month and types the same words into the same search box you did.

It works even if nobody reads it. Writing an explanation is the fastest way to discover you don’t have one, so the post you can’t finish is pointing at the part you don’t understand yet. A post is a link you can send somebody, just like a project is, except a project shows what you built and a post shows how you got there. It’s also the same skill as the README that explains two decisions, the pitch at the demo table, and the answer you give when an interviewer asks why, which means the hour you spend writing is never only about the post.

Put it wherever you already are, your own site if you have one, medium.com or dev.to if you don’t, and link it from the same place as the rest of your work. Be honest about what you didn’t know. You don’t have to sound like an expert.

Study

Follow a curriculum somebody maintains

You search for how to learn anything and get ten tutorials, and nothing tells you which one comes first, or which ones are already out of date. There’s plenty of material. What’s missing is the order. So work through a curriculum somebody keeps current, and treat the tutorials and blog posts as things you look up when you need them, rather than a path you follow.

Start with Google’s web.dev courses, free and in a sensible order. Each one is written by an industry expert with help from the Chrome team, which is about as close to the source as studying gets. HTML, CSS and JavaScript are the core of it, and the rest of the catalog covers the things almost nobody teaches. Accessibility, performance, forms, images, responsive design, testing and privacy each get a course of their own.

Mozilla’s MDN curriculum is the other one I’d work straight through. It’s free, it was made for front-end beginners, and split into getting started, core and extensions, so the order is decided for you, and every lesson links straight to the reference pages.

The Odin Project is the project-heavy option, free and open source, and it finishes with deployed projects rather than a video you watched.

Those three cover what you need, and for anything else you come across, two questions answer whether it’s worth your time. The first is when it was last updated, because the web keeps changing and a tutorial written four years ago will hand you workarounds for problems that no longer exist. The second is what you’re left holding at the end, because a course that finishes with a video finishes with nothing a stranger can click, and your portfolio needs things people can click.

Use the tools without letting them do the learning

The other question I get is how to use AI while you’re still learning.

When you accept a suggestion that works, the feature ships and you learn nothing, because the reasoning that produced it happened somewhere you weren’t looking. Six months of that leaves you with a portfolio you can’t explain, which is the worst place to be in an interview, where every question is about the reasoning.

The rule I’d hand you is to let the tool write what you could have written yourself, and to read closely whatever you couldn’t. When an AI like Gemini gives you something you don’t follow, that’s the signal to stop and take it apart, not the signal to move on. Ask why, then ask what would break, then check the answer against a source that isn’t a model, because what these tools get wrong most often is an explanation that sounds right and isn’t, and that’s the hardest kind to catch until you’ve been fooled by one before. That checking builds the judgment this whole site is about, and the tools turn out to be one of the faster ways to build it, as long as you’re the one doing the checking.

Some ways of using them are just good for you. Paste in your own code and ask what’s wrong with it. Ask for three approaches you didn’t consider and why someone would choose each one. Have it interview you about the project you just finished, which is free practice for the interviewing chapter later in this article. None of those three hands over the work, and each of them has you judging output instead of producing it, which is increasingly the job.

Two books that train the eye

Building projects teaches you how to make something work. Telling whether it’s any good is a separate skill. Two short books will start you on it, Don’t Make Me Think by Steve Krug and The Design of Everyday Things by Don Norman. You can finish both in a couple of weekends.

I hand them to every developer, backend included, because an API, a command line flag, an error message and a config file are all interfaces with a person on the other side of them. Norman’s examples are doors and stoves rather than screens, and that’s why the book works for everyone.

Krug trains you to see an interface the way a first-time user does, which is the core skill of usability. His test is right in the title, whether your interface made someone stop and think. Every moment spent puzzling over your navigation comes out of a budget the Nielsen Norman Group calls interaction cost. That’s the total mental and physical effort it takes somebody to reach their goal. Once you’ve read it, you start noticing the cost of every extra tap and every clever label, in your own projects first.

Norman, the cognitive scientist who later co-founded the Nielsen Norman Group with Jakob Nielsen, hands you the vocabulary underneath all of it. An affordance is what an object lets you do, a signifier is how it tells you, feedback is how it confirms you did it, and when a person gets those wrong, Norman’s argument is that the design failed. In a demo, “We cut the flow from five taps to one” and “the button’s signifier was too weak, so we made it look pressable” are sentences a junior can say that land like something a senior said, because they name the user experience concept instead of gesturing at it.

Certifications

Everything so far is work you scope yourself, which makes a certification the one item on this list somebody else grades.

A certification means you passed a timed exam on a platform, with somebody watching you take it. That’s different from a personal project, because of who sets the bar. On your own work you set it yourself, but with a certification the platform owner sets it, so even a hiring manager who never opens your repository knows exactly what you were tested on and how hard it was.

Google’s Associate Cloud Engineer is the entry level one on the cloud side, and most of the others look roughly like it. The exam takes two hours and costs $125 plus tax, and you get fifty to sixty questions, some multiple choice and some multiple select. You do it either online with a proctor watching through your webcam, or in person at a testing center, and it’s good for three years, after which you renew it with a shorter exam or a set of designated courses.

Look at the order Google puts its own preparation steps in. Step one is get real world experience, and it recommends six or more months of hands-on time with the platform before you take the exam at all. Reading the exam guide, working the learning path, and reviewing the sample questions are steps two through four, and scheduling the exam is step five. That order tells you plainly what the credential is for. It certifies that you’ve spent real time on the platform, and that’s why it holds its value.

The same model runs well past cloud, so know the options before you spend anything. Google’s certification catalog runs from foundational exams up through the professional specialties, and nearly all of them are about platform work. NVIDIA’s program starts at an associate tier that covers AI infrastructure, accelerated data science and generative AI. Each of those takes about an hour and costs $125, and above them there are professional exams in agentic AI and AI networking. Anthropic’s Academy runs free courses on Claude Code, the API and the Model Context Protocol that issue a certificate when you finish. Its proctored exams run $99 to $175, but you need a company email at a partner organization to take one, so the free courses are the part of it open to you today. If the work you want is anywhere near AI or infrastructure, a hiring manager on a platform team will recognise those names the way they recognise a cloud certification.

There is no web-specific exam anymore, since the Mobile Web Specialist was retired years ago and the catalogs have followed cloud and AI work since. So if you write frontend code and you want a certification, the nearest fit is a cloud or AI exam. That used to be a stretch, but frontend work now touches deployment, APIs and models, so it’s closer to what you actually do than it would have been a few years ago.

A certification counts most when somebody has written it into the requirements. Public-sector postings and regulated employers sometimes name a specific certification as a hard requirement. Consultancies are the other clear case, because partner status depends on keeping certified people on staff, which makes the certificate something a company will pay for, and sometimes count towards a promotion.

Take the studying either way, because most of it costs nothing. Google publishes the exam guide as a PDF and the sample questions come as a form you can work through in an afternoon. The Cloud Engineer learning path on Google Skills is built from hands-on labs rather than videos. The labs run on credits, and you get a small number free each month through Google’s developer program, after which you pay. That’s a maintained curriculum with an order somebody thought about. Self-teaching almost always lacks exactly that.

So work the labs, build something with what they taught you, and deploy that. Then take the exam once the credential means something concrete to you, like a posting that names it, a team that runs on that platform, or a subject you want proof that you know. The project and the certificate answer different questions about you, and holding both puts you in a better position than either alone.

Networking

Now the part I push hardest, and it’s the one thing on this list you can’t do alone at your desk.

Hiring has always had a shortcut, and it runs through a person vouching for a name they know. Ashby, the recruiting platform, measured it in its own hiring data, 38 million applications to 93,000 jobs between 2021 and 2024. If somebody inside the company put your name forward, you reached an interview 40% of the time, against 3% if you just applied through the form. Only about 1% of the applications in that sample came through a referral, so hardly anyone arrives that way.

Those are observational numbers rather than a controlled experiment, since whoever referred those candidates had already filtered them once. The gap tells you how differently employers treat a name when somebody’s word is behind it. Most referrals trace back to someone who has seen you or your work, a classmate, a former colleague, a maintainer who merged your pull request, an engineer from a meetup. That turns the job search into a simpler question. Where do you go to be seen? A local meetup gets you seen once a month, and a hackathon gets you seen by a whole building in one weekend.

Most cities have a local developer community that meets monthly, and Google Developer Groups are the easiest to find, since Google puts the count at more than two thousand community groups in one directory. Every big city you’d think of is in there, GDG NYC and GDG San Francisco, GDG London, GDG Tokyo, GDG Sao Paulo and GDG Bogota, next to a few hundred places nobody would call a tech hub. Each chapter is run by local organizers in the local language, so the Bogota one is in Spanish and the Sao Paulo one is in Portuguese, and they run monthly talks, hands-on workshops, and a full conference once or twice a year.

There are student chapters under GDG on Campus too, if you’re still enrolled somewhere. Their own line about who belongs says, whether you’re a beginner or a pro, all interested in technology are welcome.

Across Latin America, Crafter Station runs the same kind of room, calling itself the LatAm network of shippers, alongside hackathons and workshops in cities around the region. Its meetups are called Code Brews, small rooms where people show a demo of something they shipped and tell the honest story of how it went.

North America and Europe have their own versions of it. AI Tinkerers runs demo nights in more than 200 cities, New York, San Francisco, Toronto, London, Berlin and Amsterdam among them, built around four to eight five-minute demos of running code with no slides. Organizers screen for people who are actually building, so bring something that works.

codebar is for people who are still learning. It’s a charity that runs free workshops across Europe and in New York, and every session pairs you with a volunteer mentor for the evening. Its student places are held for people from groups underrepresented in tech, and mentoring is open to anyone, so there’s a way in from either side of the table.

Two hours on a weeknight gets you into a room where people can put a face to your name, and it repeats every month.

The person who forwards your CV is rarely someone who met you once, so this only works if you keep turning up. Three months in, you’ve spent six hours, and after that you just keep going. A referral starts with being known, and being known mostly comes down to how often people see you.

Once you’ve been to a few, the next step is speaking at one. Most chapters run lightning talks and have trouble filling the slots, five or ten minutes on something you built, and nobody expects a keynote. It’s the cheapest practice you’ll get at explaining your own work out loud, and a talk listed on a chapter’s page is something public you can link the way you link a deployed project.

If it never feels awkward, you aren’t doing enough of it

Most people network up to the edge of their comfort and stop, which is roughly the point where it starts working. Walking up to a stranger whose talk you liked feels like you’re bothering them, and it feels that way the first ten times. Sending the follow-up message two days later feels worse.

Do both anyway, because you pay that awkwardness to stop being a document someone has open and start being a person they can picture. A recruiter reading your application sees a file that looks like forty others. Someone who spent fifteen minutes hearing you explain the thing you built remembers your name, and that’s the person who forwards a role when one opens.

You don’t need to be charming and you don’t need a rehearsed line. Ask what someone is working on, say what you’re building, and follow up once.

Hackathons

A hackathon is the same thing as the last chapter, compressed into one weekend, with hundreds of future colleagues in one building, and you don’t need a job to get in. That only works in person, so go in person when your time and your city allow it.

At the big sponsored events the tables are staffed by engineers whose whole weekend job is meeting participants, and the judges often include seniors and hiring managers watching you present under pressure. Most events keep mentors on the floor too, working engineers who unstick whoever waves them over, which is senior review before anyone has hired you. Your teammates, by Sunday night, are people who’ve seen you work and will say so, and some of them will be employed somewhere with a referral form six months from now. Every offer chain I’ve watched up close started earlier than the application, usually with someone saying I met this person, and they’re good.

Plan the weekend in three moves

Talk to the sponsor engineers during the slow hours, ask what their team is building and what they look for, and let them see your project while it’s still ugly. Demo to everyone who pauses at your table, because practice at explaining your own work is free there, and you need a lot of it. Before you leave, turn the weekend into contacts, the teammates, the judge who gave you a real note, the engineer who said send me your portfolio, because the event is over on Sunday night and the contacts aren’t.

Where to find one

You don’t have to go hunting for one. Major League Hacking keeps one page with the current season’s hackathons around the world, with dates, cities, and whether each is in person or digital. That page stays current as seasons roll over, which any list written into an article, mine below included, won’t. If you’re in Latin America, hack0.dev does that job for the region, a free public index of events, communities, labs, and grants across twenty countries, with the most listings by far in Peru, then Colombia.

If you’re anywhere near Europe, I’d go to Junction. 2,000 builders in Espoo, Finland, over November 13 to 15, 2026. Its travel grants closed on September 6, more than two months before the event, like most big hackathons, so look up the deadlines for anything you’re considering, not just the event dates.

If you can’t go in person, go online

I’ve never watched the demo reps and the contacts transfer over a video call at the same rate, so in person comes first and the online editions are the fallback. But sometimes there’s genuinely nothing within reach, and these five are a real second door, every one with an online way in. Dates move, so click through before you plan a weekend around one.

Table Five beginner-friendly build events with an online way in.

Event	Registration status	Event dates	Rules and notes
NASA Space Apps Challenge	Opened August 26, stays open	November 14 to 15, 2026	Free, open to all ages and skill levels. You join a local event, in person or virtual, teams cap at six, and you can register alone and form one there.
MLH Global Hack Week	No deadline, signups stay open	A themed week roughly every month, Data Week September 11 to 17, open source October 9 to 15	Free, fully online, every level, and solo is normal. A week you miss costs you a month.
Hacktoberfest	A mailing list at the mid-August check, and last year signups opened September 15	Every October, with more than 300 events announced for 2026	Historically the gentlest way in, a month of small open source pull requests, though the 2026 edition swaps counting them for guided open source AI work, so check the new format first. Everyone welcome, in person and online.
Microsoft Imagine Cup	Next season’s timing still to be posted	Online rounds across the school year, with the 2026 champion crowned in June at Microsoft Build	Students only, 18 and up, teams of 1 to 4, beginners encouraged, with online semifinals, mentorship, and Azure credits.
Global Game Jam	Jammer registration opens December 1, 2026	January 25 to 31, 2027	Experience is not necessary by GGJ’s own page, and fees are set by the local site, many free, some not. Online and hybrid sites run alongside physical ones, though some only take jammers from their own region, so check the one you pick. You sign up at a site and build your team there.

When these pass, Devpost’s hackathon listing is the running one, filterable by online, beginner friendly, and open for registration right now.

You already qualify

The worry is usually that you have to be good enough first. The rules pages in that table say otherwise. Space Apps takes all ages and skill levels, MLH Global Hack Week takes every level, and Global Game Jam states on its own page that experience is not necessary.

Teams are small on purpose, the caps sit in the table above, and MLH’s standard rules set none at all. In practice teams run three to five, small enough that a motivated beginner who owns the README, the deck, or the CSS matters to the result. So register alone, since every event listed either works solo or lets you build a team once you’re there. Arriving with friends is the one reliable way to spend a whole weekend in that room and leave knowing exactly the people you already knew.

Judging is a few minutes of demo, so the team that explains itself best often beats the team that built the most. That looks unfair the first time you watch it happen. It isn’t, because the people who decide about your work are almost never the people who watched you do it, and that stays true long after the weekend.

So a hackathon trains the skills tutorials skip. You explain what you made to someone who wasn’t there, cut everything that doesn’t serve that, and fit all of it into the few minutes you get.

The clearest pitches all have the same four parts. You name the problem, then the person who actually has it, because a fix for nobody in particular is hard to care about. Then you stop talking and you run the thing, because they need to see it work. You finish on what you’d build next, which tells the judges you know exactly what you didn’t get to.

Why I still go

I’d hand you this advice even if I’d retired from it, but I haven’t. I still go, because at a comfortable job you slowly lose the ability to take a messy problem, cut it down to something you can demo, and get it done before a deadline. Earlier this year I joined a hackathon that Colsubsidio ran with 30X, four days to turn a messy housing challenge into a working prototype, and we walked out with the prototype and a set of people I’m still talking to.

This August I went to Platanus Hack 26 in Bogota, turning up without a team and joining three people I’d never met who had already formed a group. The four of us worked well together from the first day, and by the third day I knew how each of them handles a deadline. They were talented and genuinely good people, the kind of professionals any company would want on its team. I left wanting to keep building with them past the project, and I’d vouch for any of the three.

We built Moirai, an app that estimates your biological age from nine biomarkers in an ordinary blood test and then simulates ten thousand possible futures over the following ten years. Each future assumes one lifestyle change and a level of consistency you hold it to, so the app can come back with a clear recommendation about which change is actually worth the effort.

We didn’t win, and we knew that we had things to improve, so we went to the judges to ask why. They said the demo left them with questions about what Moirai would actually change for someone, so we still have room for improvement in how we sell the work.

Past my own team, I met dozens of skilled people over those three days, and I’m proud that the winning team came out of Crafter Station, the same community I wrote about earlier. Their project, Woki, lets people call for help after an earthquake has knocked out the cell towers.

A small radio node broadcasts a WiFi network your phone can join, and you ask for help from a plain web page with nothing to install. A long range radio carries that request to a command post that works with no internet at all, and when the network comes back the whole record syncs to the web.

This year I also went as a mentor and volunteer instead of a competitor, to Go Build by Google Cloud, the hackathon house inside GoFest 2026, the Bogota Chamber of Commerce’s entrepreneurship festival. GDG Bogota helped organize the hackathon, and the challenge was to use data, AI and Google technologies to speed up the economic and social recovery of the communities in Colombia that were hit by the August 10 earthquake.

We received 15 submissions, and each team had three minutes to present in front of a jury. I met Google Developer Experts and GDG members I have a lot to learn from, and I hope to see them again at DevFest in a few months.

The two winning teams, Pantalones y Camisetas and Modus, won US$4,000 in Gemini API credits, Platzi Expert subscriptions and tickets to Platzi Conf between them. Every team, and not only the top two, will get the chance to present its project to business leaders in construction, healthcare and logistics. You can read more about all of it at the site we created for the event.

Interviewing

Interviewing is its own skill, separate from building, and it pays better per hour of practice than anything else you’ll rehearse this year. Two people with the same ability get different offers all the time, and the difference is usually that one of them has said these answers out loud before while the other is assembling them live under stress. So practice out loud, on your feet, with someone listening, because the version you rehearse silently is not the version that comes out of your mouth. Record yourself explaining one project for two minutes and watch it back once. It feels weird, but it teaches you more than an hour of reading about interviews.

The most useful thing you can say in an interview is some version of “I don’t know, but I know how to find out.” It’s tempting to treat a question you can’t answer as a failed test, so you freeze or you guess, and a confident guess is the worst answer in the room. The people across the table are mostly checking whether you can work a problem you’ve never seen before. A calm “I don’t know”, followed by where you’d look, what you’d try first, and what would tell you you’re wrong, is the exact thing they’re hiring for. Say it, mean it, then go find out and come back with what you learned.

The coding round is the other half wherever your targets use one. Handling a question you can’t answer is a habit you build over many conversations, while the coding round is a known format with a syllabus, so this is the part you can actually study for. Plenty of teams screen with practical debugging, a pair programming session or a take-home instead, so find out what each company actually runs before you spend months on algorithm problems. Cracking the Coding Interview by Gayle Laakmann McDowell, who sat on Google’s hiring committee, is the book that defined this genre, and it still works through the data structures and big O reasoning those rounds keep returning to. Its official sequel, Beyond Cracking the Coding Interview, is the one I’d hand you first now, written with Mike Mroczka, Aline Lerner, and Nil Mamano for a harder hiring market than the original was published into.

Read either for the patterns rather than the answers, because the interviewer is watching how you get there more than whether you arrive. The sequel also spends real pages on behavioral rounds, on running a job search, and on asking for referrals, which the Ashby numbers above measured, and almost nobody asks for one.

Reading about it is the easy part, and you only practice by rehearsing against something that answers back. Google’s own interview preparation advice now points at Gemini Live, which will hold a conversational interview with you and hand back structured feedback on the answers.

When you want a real person on the other side, interviewing.io runs anonymous mock interviews with engineers from Google, Meta, OpenAI and Amazon, audio and chat with no video so there’s nothing to dress up for. Those sessions start at $179, and you pay more to pick an interviewer from a specific company. Its AI interviewer is free and works through more than two hundred problems from the sequel above. Start with the free one, because your first mock is going to go badly and you want that out of the way before you’re in a real interview, where the same performance costs you the job. Then pay for a session with a real person once you can afford it and real interviews are close.

Applying

Everything above builds the evidence, and none of it decides where the applications go, so the search itself deserves the same structure as the portfolio.

Pick one kind of role and hold the choice for a few months. A few months spent applying as a frontend developer, a QA engineer and a data analyst at once teaches you a little of three tracks and none of one, while a single track teaches you what they keep asking you, and every project you finish adds to the same pile of evidence. Write down the companies you’d actually take, so you’ve got a list with an end to it, instead of scrolling forever.

Then rework what gets seen first. Whoever reads your resume spends seconds on it, mostly the top third and whatever projects sit pinned, so shape those two things to each posting and let the rest stand. Read the requirements the way the reviewer will, line by line, and put a piece of visible evidence, a deployed project, a post, a merged pull request, one click away from every line you can cover.

This is also where you ask for the referral. After someone has seen your work, at a meetup, in a repository, across a hackathon table, name the specific role and ask whether they’d refer you or introduce you to whoever owns it, with the link already attached so saying yes costs them a minute.

Then track the whole thing, one row per application, with columns for the first call, the technical round and the offer. The spreadsheet is there to tell you which stage is failing. When dozens of applications bring no calls, the fix is the resume or the targeting. When those calls never become technical rounds, change how you talk about the work. When technical rounds never become offers, the fix is rehearsing both halves of the interview. Repair the failing stage before adding volume, because a hundred more applications through the same broken stage produce a hundred more silences.

Where this plan needs adjusting

Two situations change how you should run it.

The first is a credential gate you can’t route around. Some employers filter on the degree before a human reads anything, and for plenty of public-sector employers the degree requirement is written into the rules. A protected professional title, or an immigration route that scores the diploma you hold, works the same way. If that’s the door you’re aiming at, get the paper on its own timeline, and let the portfolio do its work at the interview, where it still decides plenty.

The second is time. If you’re caregiving, working full time, or living a schedule where a free weekend is fiction, the hackathon advice can sound like a joke. Run the same order at whatever speed your life allows, one small deployed project, then a monthly meetup or an online week you can dip into for an hour after everyone’s asleep, then an in-person weekend when there’s room for one. Six months of that beats a plan you abandoned in week two.

The only comparison that helps

One last thing, about the feeling that piles up while you do all of this. You’ll deploy your first project the same week someone your age demos at a conference, and your feed will make sure you know. I’d treat managing that feeling as part of the job. Left alone it shows up as the worry that everybody found something you missed, as a low anxiety sitting underneath a day that was actually productive, as the sense that you started too late to catch up. All three start with the same habit, checking how you’re doing against what other people posted.

A social feed shows you the best week of a few hundred people at once, ranked so the most impressive one reaches you first. So you end up measuring one person’s month, yours, against the accumulated wins of hundreds, most of whom spent years getting to the thing you just scrolled past.

A post carries the finished part and nothing else. People celebrate joining a big company, and the months of rejections that came before it stay private. They post the demo, and the video leaves out the weeks of not understanding the problem, the version that got deleted, the help somebody gave them quietly. You’re comparing your whole process to other people’s results, so of course you come out behind.

Point the comparison backward instead. Measure yourself against yourself, six months ago, and against nobody else. Six months is long enough for the plan in this article to move you visibly, a first deployed URL, a README a stranger complimented, a first hackathon survived, a pitch that didn’t shake.

The whole plan on one screen

Save this part. It’s the same plan ordered by when each piece starts, and the first list is small on purpose.

This week

• Deploy one project a stranger can click, however small.
• Put the next local developer group meetup in your calendar.
• Register for a hackathon within reach, alone, expecting a team of three to five, and don’t wait until you feel qualified.
• Pick the one kind of role you’re applying for and write down the companies you’d actually take.

This month

• Keep studying, and let a deployed portfolio carry the weight a credential can’t.
• Work through a maintained curriculum rather than loose tutorials, starting with Google’s web.dev courses, then MDN’s front-end curriculum or The Odin Project.
• Grade every project against three checks, a URL a stranger can click, a README that explains two decisions, and one thing you’d redo.
• Put the work where your field looks, pinned public repositories on GitHub, or case studies on Dribbble and Behance.
• Write up whatever confused you and publish it, because the post you struggle to finish is pointing at the part you don’t understand yet.
• Let the tools write what you could have written yourself, and take apart anything you couldn’t, checking it against a source that isn’t a model.
• Read Don’t Make Me Think and/or The Design of Everyday Things.
• Match the top third of the resume and your pinned projects to each posting, with visible evidence one click from every requirement you can cover.
• Get your first mock interview out of the way on a free AI interviewer like Gemini Live, and pay for a real person once real interviews are close.

The next six months

• Go to developer meetups and hackathons in person before you fall back on the online editions, because the strongest referrals come from someone who has seen you or your work.
• Grow the builds from this site into small, focused libraries, published with a deployed demo, and link them from your profile.
• Let the repository showcase how you build instead of chasing stars, and start it before you feel ready.
• Add one project nobody assigned you, scoped and shipped on your own judgment.
• Get one pull request merged into a project you didn’t start.
• Work a certification’s learning path for the free curriculum, and take the exam once it names a platform you’re committing to or a posting you want.
• Hold the monthly meetup rhythm, and give a lightning talk once you’ve been to a few.
• Keep introducing yourself past the point where it stops feeling comfortable, since that’s about where it starts to work.
• When nothing in person is within reach, take an online event instead, like MLH Global Hack Week roughly every month, or whatever Devpost lists as online and beginner friendly.
• Practice the pitch, because the clearest story beats the deepest codebase in front of judges and hiring managers alike.
• Practice interviewing deliberately, out loud and on your feet, as the highest-paid skill on this list, and drill the coding round with Beyond Cracking the Coding Interview when your targets use one.
• Answer what you don’t know with “I don’t know, but I know how to find out”, and then go find out.
• Track every application through the first call, the technical round and the offer, and fix the stage that’s failing instead of adding volume.
• Measure yourself against yourself six months ago, and let the rest of the feed go.

The first list fits in a week on purpose. Six months from now, compare yourself to the person who just finished reading this, and enjoy the difference. And if a step of this plan leaves you with a question, send it to me on LinkedIn, because answering developers is part of why this site exists.