December 15, 2017. 1:29 AM. I'm doing a master's at Berkeley, about to send a cold LinkedIn message to an engineering leader at Pinterest.
The message is generic. I tell him I'd like to work at Pinterest. I attach my resume and cover letter. I ask for a referral.
He replies with nine words: "Passed your resume to the right folks. Good luck!"
I get the interview. I get the offer. I take Palantir instead.
I don't remember how many other cold messages I sent that month. But I sent a few. Being at Berkeley likely helped. The message itself wasn't clever. It still worked.
That was the 2018 playbook for landing your first dev job: master DSA, find a referral, apply, get hired.
That playbook is dead.
I know this because I came back from maternity leave a few months ago and watched Claude Code eat 1/4 of my job in real time.
First week back, I had to ship a change across the frontend and the backend. Previously that kind of cross-stack work would have cost me half a day just understanding the backend code I didn't write. With Claude I understood it in five minutes. Ready in a day instead of three.
I sat with that for a while.
If a senior dev at Palantir is having that experience, the junior market is something else. Not doomed. Just harder than it's been in years. The kind of work I would have handed a junior to ramp up on can now be done by an AI in under 10 minutes.
So if I was looking for a junior frontend role in 2026, here's what I'd actually do.
What's in this issue
Get serious about communication from day one
Use a coding agent until you can feel when it's lying
Learn the things Claude gets subtly wrong
Build real things and ship them to real people
Get one foot in the door, anywhere
Network the way I networked that Pinterest exec
Pick up something beyond frontend
Contribute to open source, slowly, with thought
Let people watch you figure things out
If you can only do two this month, do the first two. The rest compound once those are in motion.
1. Get serious about communication. On day one.
This is item nine on every "how to get a job as a junior dev" list. I'm putting it first because it's the part of the job Claude can't touch.
Public speaking.
Influencing a decision in a meeting.
Reading a room and noticing the manager is annoyed before anyone says it out loud.
Writing a doc that someone actually finishes.
These are the things I now spend more of my time on, because the rest has shrunk.
When I was a junior I assumed the best coder wins. The best coder no longer wins on code alone, because Claude writes a lot of the code. The dev who ships the code AND explains why AND gets the other humans to agree wins.
So I would invest in this from week one, not from year five.
2. Use a coding agent until you can feel when it's lying
Not optional anymore.
Pick a coding agent. Use it every day. Learn what it's good at and where it lies. Stay close to the news so you notice when something better drops.
If you can't afford a paid plan: free models, opencode, Gemini CLI, student credits from OpenAI and Anthropic. If you can build well with cheap models, the better ones will feel like cheating.
The advantage you have over me is that you don't have years of habits to unlearn. You can build the AI-native instincts from scratch.
3. Learn the things Claude gets subtly wrong
I keep telling people this. I'll keep telling people this.
HTML, CSS, JavaScript.
Data structures.
Browser dev tools.
Being able to build a small project without React or Tailwind.
Why this still matters in 2026: Claude will write the code. Without strong fundamentals, you won't catch the subtle bugs in what it writes. You'll ship something that compiles, passes the tests, and is silently wrong, and you won't know why for two days.
4. Build real things and ship them to real people
The basic portfolio is dead. Anyone with Claude can produce a basic portfolio in an afternoon, including the recruiter screening you.
What works instead: build something that solves a real problem you have.
Job hunting? Build a resume tool.
Studying? Build something for your study group.
Then use it. Get other people to use it. Now you have a story for the recruiter, and you'll have hit the actual hard part of being a dev, which is not writing the code. It's getting the code into someone's hands and dealing with what they say back.
5. Get one foot in the door, anywhere
A nonprofit with an ugly website. Your school's admin. A researcher whose data analysis lives in a 2009 spreadsheet. Anyone with a real problem who'd let you solve it for free.
Experience is the unfair differentiator. The people doing the hiring know that what you learn at a job is different from what you learn in class. A semester of fixing a real organisation's broken signup flow beats six months of LeetCode.
6. Network the way I networked that Pinterest exec
Most jobs are not won through the portal.
Engage with people from companies you want to work at. Regularly, not once. Do cold outreach. Join the dev communities where devs hang out.
Look back at the top of this post. The cold message was generic. The reply was nine words. The offer came anyway. The probability of any one message landing is low. The probability of zero messages landing if you send one hundred is also low.
Thanks to AI, you can now send more customised messages at scale. A spreadsheet of 100 people you want to work with, and a prompt that generates a unique message for each of them. You can do this in an afternoon. Do it.
7. Pick up something beyond frontend
Design taste.
A bit of backend.
Product sense.
Something that makes you a person who can think about a whole feature, not just the part with the buttons. The "just a frontend dev" job is the most exposed one in this market.
8. Contribute to open source. Slowly. With actual thought.
Find a project you already use. Pick a beginner-friendly issue. Understand every line of what you're about to submit. Then open the PR.
Don't be the person flooding maintainers with agent-generated PRs. They're already drowning in those. The signal you want to send is the opposite: I'm a person who took the time to understand this codebase.
9. Let people watch you figure things out
Devs have gotten jobs from this. When people watch you learn, two things happen. They see you actually doing the work. And they get a real sense of what you're capable of, which is more than your resume can ever tell them.
It also makes friends, which loops back to the networking point.
I'm writing this from inside a job AI is reshaping under my feet. I have not figured out the new rules. I'm partly writing this to figure them out.
But here's what I keep coming back to. I can write two or three lines of code now and watch them get shipped to people using the software in a hospital, or a factory, somewhere I'll never visit. Their day gets a little easier because of those two or three lines.
If that's still what you want, here's where I'd start this week: open a doc, write down one real problem a real person around you has, and see if you can build the first ugly version of a fix by Sunday. That's the whole job. Everything else in this post is in service of that.

🍔 FOOD FOR THOUGHT
[Twitter Link]


