Your First 90 Days at a New Job Determine the Next 3 Years. Here’s the Playbook Nobody Gives You.

Got the job. Celebrated. Started. Then what?

Most career advice focuses on getting hired. Almost none cover what happens after. But I’ve watched people with similar starting points end up in completely different places a couple of years later. The difference often traces back to their first 90 days.

When I started my first engineering role, I made mistakes that I had to work hard to recover from. Stayed quiet in meetings because I didn’t want to seem inexperienced. Waited for tasks instead of finding them. Assumed my code would speak for itself. It took months to rebuild the momentum I lost in those early weeks.

Since then, I’ve paid attention to what separates engineers who get promoted quickly from those who stay at the same level for years. The pattern is consistent: the first 90 days set the trajectory. How you show up early shapes how people perceive you, what opportunities come your way, and how much trust you build.

This week I’m sharing the playbook I wish I’d had.

The 90-Day Playbook

The 90-day playbook has three phases:

Days 1-30: Learn and listen (but not silently)

Your job isn’t to contribute major code yet. It’s to understand the codebase, the team dynamics, and the business context. But “learning mode” doesn’t mean invisible. Ask questions in public channels, not just DMs. Take notes and share them (”Here’s my understanding of X, let me know if I’m off”). This signals engagement without overstepping.

Specific actions: Set up 15-minute 1:1s with every teammate. Ask “What’s one thing you wish you’d known when you started?” Document onboarding gaps and share with your manager.

Days 30-60: Ship something small and visible

Find a low-risk improvement: a documentation fix, a small bug, a test that was missing. The goal isn’t major impact. It’s demonstrating you can move through the entire cycle: identify, propose, implement, review, ship. This builds trust faster than waiting for a big project.

Days 60-90: Identify one area to own

By now, you know where gaps exist. Volunteer to own something specific: a flaky test suite, an outdated wiki section, a monitoring dashboard nobody maintains. Ownership, even of small things, changes how people see you. You become “the person who handles X” instead of “the new hire.”

The meta-lesson: Don’t wait for permission or perfect readiness. Initiative in the first 90 days compounds.

How I NETWORK as a Top 1% Software Engineer

Networking strategies that landed internships at Amazon and Splunk. The LinkedIn DM approach that turned cold outreach into referrals, why reaching out to 30-50 people daily worked, and how building connections early pays off later when those people move into positions where they can hire you.

Watch the full conversation →

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Turn

Starting a new role soon? Save this email and revisit it on day one.

— Sajjaad

Everyone says networking gets you hired. Here’s what I’ve actually seen work for people breaking in.

“It’s all about who you know.” “Referrals are the only way in.” “If you’re applying through the front door, you’ve already lost.”

I’ve heard this advice for years. And it’s not wrong exactly, but it’s incomplete in a way that actually hurts people.

Here’s what I’ve observed from the people in my community who’ve landed roles recently. Referrals help, but they’re not the whole picture. Plenty of people break in through targeted applications, recruiter outreach on LinkedIn, and visibility from building in public. The “networking or nothing” framing makes people feel hopeless if they don’t already have connections.

But here’s the real pattern I keep seeing. It’s not about having a network before you start. It’s about building visibility and relationships during the search. The people who land jobs fastest aren’t the ones with the most existing connections. They’re the ones actively creating touchpoints while they search.

This week I’m breaking down what actually seems to work based on what I’ve observed, not the oversimplified advice that gets repeated everywhere.

Targeted applications through niche channels

Stop mass-applying on LinkedIn Easy Apply. I’ve watched people in my community send 300+ applications with zero responses, then pivot to 15 highly targeted applications and land 3 interviews.

Skip the main job boards. Use company career pages directly, Wellfound for startups, Otta, and industry-specific boards like Climatebase or BuiltIn. These have less competition and often faster response times.

Match your projects to the role. If the job mentions “REST APIs and PostgreSQL,” your resume better show a project with REST APIs and PostgreSQL. Rewrite your bullet points for each application to mirror the job description language.

Apply within 48 hours of posting. Roles that have been up for 2+ weeks are often already in late-stage interviews. Sort by “most recent” and move fast.

Find the hiring manager on LinkedIn. Send a short, specific message after you apply. Something like “Just applied for the SWE role. Saw you’re building [specific thing from job post]. I built something similar at [project]. Would love to contribute.” Keep it under 50 words.

Inbound recruiter outreach

This happens way more than people realize, and you can engineer it. Recruiters live on LinkedIn and GitHub. They’re searching keywords like “React,” “Python,” “new grad,” and scanning for signals that you’re active and hireable.

Your LinkedIn headline needs clear keywords. “CS Student | Python, React, AWS | Open to SWE Roles” beats “Aspiring Developer | Lifelong Learner.” Recruiters search by keywords. Make yourself findable.

Pin GitHub repos with polished READMEs. A recruiter spending 10 seconds on your profile should immediately see a clear project title, what problem it solves, a screenshot or demo link, and the tech stack. Most student repos have zero READMEs. This is low-hanging fruit.

Post what you’re building. Even simple posts work. “Shipped a feature this week that handles [X]. Here’s what I learned about [Y].” Recruiters scroll LinkedIn looking for people who build. Give them something to find.

Turn on “Open to Work.” Yes, some people think it looks desperate. Recruiters filter by it. Your call, but know the tradeoff.

Relationships built during the search

Most referrals I see aren’t from college friends or family connections. They come from people met during the job search itself.

The timeline often looks something like this. Week 1, you join a Discord community for job seekers or a specific tech stack. Week 2, you help someone with a question, share a resource, ask for feedback on your resume. Week 3, someone mentions their company is hiring and you ask if they’d be open to referring you. Week 4, you have a referral from someone you met three weeks ago.

This happens in Blind, Discord servers like Reactiflux and Python Discord and Tech Career Growth, Twitter/X tech communities, local meetups, even LinkedIn comments. The key is being helpful and visible, not just asking for things.

Coffee chats work too, but be strategic. Don’t ask, “Can I pick your brain?” Instead, try “I’m applying to [Company] and saw you worked there. I have two specific questions about the interview process. Would you have 15 minutes this week?” Specific asks get responses.

Stop thinking of networking as something you need to have done already. Think of it as something you do while searching. Every application, every post about your projects, every community you join is building the network that might help you land the next role.

Visibility + Specificity > Volume.

Building something visible and applying strategically to 20 matched roles tends to outperform 200 spray-and-pray applications and waiting for your existing network to save you.

📺 Watch This to Land a Tech Job

This video covers the complete strategy for breaking in, from skills to applications to interviews. The patterns I’m seeing in my community align with the fundamentals here. Impact-driven resumes, leveraging referrals the right way, and preparing for both behavioral and technical interviews.

How did you land your job or your most recent interview? Reply and tell me. I’m curious what’s working right now.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Turn

How did you land your last interview or job offer? Cold application, recruiter outreach, or a referral you built along the way?

Hit reply and let me know. I’m always looking for patterns.

— Sajjaad

Cursor vs Copilot: Breaking Down the Real Differences

Everyone’s talking about Cursor. “It’s Copilot but better.” “It understands your whole codebase.” “Changed everything.”

The hype is loud, but what are the actual differences? I dug into the current state of both tools to give you a clear picture of where each excels and which one makes sense for different types of work.

Here’s what I found: Cursor is better for some things. Copilot is better for others. The gap has narrowed significantly in 2026, but real differences remain. And understanding when to use which can make you noticeably more effective.

This week I’m breaking down the specific technical differences, the workflows where each tool shines, and whether switching is worth it based on how you actually work.

Where Cursor Wins

Codebase-aware context. Cursor indexes your entire project using a custom embedding model and keeps that index updated as you work. When you ask a question about your project, it reasons across all your files by default. Copilot primarily draws from open files and adjacent code. GitHub added repository indexing in January 2026, but DataCamp’s analysis notes that Cursor still has the edge on understanding large codebases because it controls the entire IDE.

Multi-file editing. In agent mode, Cursor edits multiple files simultaneously from a single prompt. It understands cross-file dependencies like imports, shared types, and configuration references. Checkpoints are created for every iteration, so you can roll back any change. Copilot’s agent mode handles multi-file changes too, but the experience is more user-driven, typically requiring you to select files or iterate through changes one at a time.

Deep control over execution. Because Cursor owns the entire editing stack (it’s a fork of VS Code), it has tight control over how AI interacts with your code. Agent mode is the default interaction pattern, and you can run multiple agents simultaneously working on different parts of your project.

Where Copilot Wins

Speed. Every comparison agrees on this: Copilot is faster for inline completions. If you’re writing code line by line and want suggestions that keep up with your typing, Copilot’s autocomplete feels noticeably snappier.

Editor flexibility. Copilot works in VS Code, JetBrains IDEs, Neovim, Visual Studio, Xcode, and Eclipse. Cursor is a standalone editor. If your team uses diverse environments, Copilot is the only option that works everywhere.

GitHub integration. Copilot connects directly to your issues, pull requests, and Actions workflows. The Coding Agent can spin up a VM, implement changes, and open a draft PR for you to review. Code review is built in with CodeQL support. If your team lives on GitHub, that integration is hard to replicate.

Pricing Comparison

Plan Cursor GitHub Copilot Free Limited agent requests + completions 50 chat/agent requests + 2,000 completions/month Paid $20/month (Pro) $10/month (Pro) Premium $60/month (Pro+) $39/month (Pro+)

Copilot’s free tier gives you concrete monthly limits. Cursor’s free tier is described as “limited” without specific numbers published.

Action Steps

• If you’re working on large, complex codebases: Cursor’s deep indexing and multi-file editing give it a real advantage. Worth trying for a couple weeks to see if it fits your workflow.

• If you’re doing quick prototypes or learning: Copilot’s speed and generous free tier make it the practical choice. Less friction to get started.

• If your team uses multiple editors: Copilot is your only option unless everyone standardizes on Cursor.

• If budget matters: Copilot Pro at $10/month is half the price of Cursor Pro at $20/month.

Both tools are better than no AI assistance. The tool matters less than building the habit of using AI effectively in your workflow.

Microsoft VP: Here’s How to Beat 99% of Software Engineers

AI tools are just one piece of standing out. My conversation with Brendan Burns, Corporate VP at Microsoft and co-creator of Kubernetes, covers the bigger picture. His take: “10 years ago, maybe you could just be a really good coder. Now, you’re going to have to be a product manager and a good user of these AI tools. We’ve leveled out the playing field, and now it’s more about whether what you’re producing is good.”

Watch the full interview →

What’s your current AI coding setup? Reply with your stack. I’ll share what I hear.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Turn

What’s a question you’ve been stuck on?

Hit reply with it. I might feature the best reframes in a future issue.

— Sajjaad

I’ve Answered This Question Hundreds of Times. Here’s What I’ve Learned.

“What programming language should I learn first?”

It’s the most common DM I get. And every time, I want to say the same thing: you’re asking the wrong question.

Not because it doesn’t matter. But because the answer (Python or JavaScript, depending on your goals) takes seconds to Google. The question reveals confusion about what actually matters.

Something I’ve learned from reviewing resumes and talking to hiring managers: most people aren’t stuck on information. They’re stuck on direction. They ask surface-level questions because they haven’t figured out what they’re actually trying to do.

The right question isn’t “what language.” It’s “what do I want to build, and what’s the fastest path to building it?”

Languages are tools. You pick them based on the job, not the other way around.

Here are the questions I keep getting, why they’re misdirected, and the reframes that actually unlock progress.

“What language should I learn first?”

Ask instead: What do I want to build, and what do those jobs require?

Web development, data science, and mobile apps all have different stacks. Pick the goal first. The language follows.

Here’s something I learned early: doing a calculator in Java is a cool beginner project, but it’s not going to get you into big tech. A project that analyzes real data to solve a real problem? That stands out. The language matters less than the impact.

“How many LeetCode problems do I need to solve?”

Ask instead: What level of companies am I targeting, and what do their interviews actually test?

FAANG interviews are different from startup interviews. Many companies don’t do LeetCode at all. Research before grinding.

The best candidates I’ve seen don’t just grind problems randomly. They master paradigms: all the dynamic programming problems, then all the graph problems, then all the stack problems. You don’t know what the interview will contain, so you build depth in each area rather than surface-level exposure to everything.

“Do I need a CS degree?”

Ask instead: What evidence do I need to show that I can do this job?

The degree is one form of evidence. Projects, contributions, and experience are others. Focus on building proof.

A VP I talked to said something that stuck with me: “I’d rather hire someone with one impressive project than someone with a bunch of tutorial clones.” The degree signals baseline competence. The work you can point to signals everything else.

“Is the job market too bad to break in?”

Ask instead: What are people who are getting hired right now doing differently?

People are still getting hired. The market is harder, not closed. Study the successful cases.

Here’s the thing most people miss: smart people don’t get paid. Likeable people get paid. In tech, we get sucked into the technicals. What languages should I know? What projects should I do? We forget the basics: forming warm connections with people.

The engineers, founders, and executives I’ve interviewed all share two things. First, they’re talented and methodical in their craft. Second, they’re genuinely likable. They build rapport. They connect. Those skills are rare, and they matter more than most people realize.

“Should I learn AI/ML?”

Ask instead: How is AI changing the specific role I want, and what skills does that require?

“AI/ML” is broad. The relevant question is how AI tools integrate into your target job.

Every role is being reshaped. The question isn’t whether to learn AI. It’s understanding which AI skills matter for where you’re headed. A front-end developer using Copilot effectively is different from a data scientist building ML pipelines. Get specific about the intersection.

The Pattern

Most people ask questions that feel productive but keep them in research mode forever.

The reframe that matters: stop asking “what should I learn” and start asking “what should I build for who?”

Build something one real person needs. Not a hypothetical user. An actual human you can name. Get them to use it. Watch them use it. Fix what breaks. Document the impact.

That evidence is worth more than any certification or course completion.

The Strategic Thinking That Separates Those Who Break In

This conversation with Philip Su, former distinguished engineer at Meta who worked directly with Zuckerberg, gets into the mindset that separates people who break in from people who stay stuck.

His take on standing out: “If you cannot be trusted with small things, no one’s going to trust you with big things. Be the best bug fixer there is. You got to earn that before people give it to you.”

It’s about asking better questions and thinking like an owner, not a hired hand.

Watch the full conversation →

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Turn

What’s a question you’ve been stuck on?

Hit reply with it. I might feature the best reframes in a future issue.

— Sajjaad

I bombed my first several technical interviews. Here’s the debrief system that fixed everything.

My first technical interview, I froze on a basic array problem. Not a hard one. The kind you’d see in week two of a data structures course. My mind went blank. I stared at the screen. The interviewer waited. I mumbled something about iterating through the array. Time ran out.

Second interview, I talked too much and coded too little. I was so nervous about the silence from round one that I overcorrected. Spent too long explaining my approach. By the time I started typing, I barely had time left. Didn’t finish.

Third, I solved the problem but couldn’t explain my approach. The code worked. The interviewer asked why I chose that solution over alternatives. I had no answer. I’d pattern-matched from LeetCode without understanding the trade-offs.

Fourth, I ran out of time on a system design question I actually knew. I’d studied this exact scenario. But I went too deep on database choices and never got to caching or load balancing. The interviewer cut me off mid-sentence.

Multiple interviews. Multiple rejections. Different failure modes each time.

Here’s what frustrated me. I was practicing. Hours every week. Grinding problems. Watching mock interviews. Reading system design blogs. Still failing.

The problem wasn’t preparation. It was learning from failure.

I was treating each rejection as a closed chapter. Move on. Try again. Hope the next one goes better. But I kept making variations of the same mistakes because I never systematically analyzed what went wrong.

So I started a debrief system after those early bombs. Simple document. Filled it out within a couple hours of every interview while details were fresh. Tracked what went wrong, what went right, and specific adjustments for next time.

After implementing this system, my results improved dramatically. Same person. Same skills. Different feedback loop.

Most people treat interviews as pass/fail. Binary outcomes. But every interview is a source of data. The debrief system turns rejection into iteration.

Here’s exactly how it works.

The Debrief Template

Fill this out within a couple hours of every interview. Not the next day. Not when you feel like it. While it’s fresh.

This timing matters. The longer you wait, the more your brain smooths over the uncomfortable details. You’ll remember the general feeling but lose the specifics. Capture them before that happens.

Section 1. What was asked?

Write down every question, problem, and topic as accurately as you can. Don’t rely on memory later.

Include the exact wording if possible. “Design a URL shortener” is different from “Design a URL shortener that handles 100 million daily users.” The constraints matter. Write down follow-up questions the interviewer asked. These reveal what they were actually testing.

Over time, you’ll build a personal database of questions you’ve seen. Patterns will emerge. Certain topics come up constantly. Others rarely. This shapes how you prioritize study time.

Section 2. Where did I struggle?

Be specific. “I struggled with recursion” isn’t useful. “I couldn’t figure out the base case for the tree traversal until late in the problem” is useful.

Vague self-criticism feels productive but changes nothing. You need precision to improve.

Think about what type of struggle it was. Was it a knowledge gap where you didn’t know the concept? Was it application where you knew the concept but couldn’t see how to use it? Was it communication where you solved it but failed to explain your thinking? Was it time management where you spent too long on one part?

Each diagnosis leads to a different fix. Knowledge gaps need study. Application problems need more practice. Communication issues need mock interviews with feedback. Time management needs deliberate pacing drills.

Section 3. Where did I do well?

Don’t skip this. Knowing your strengths matters.

Most people only analyze failures. But understanding what works lets you double down on it. If you explain your thought process clearly, keep doing that. If you stay calm under pressure, that’s an asset. If you ask good clarifying questions, build on it.

Write it down even when it feels small. “Caught my own bug before the interviewer pointed it out.” “Asked about edge cases before coding.” “Recovered well after going down a wrong path.”

After several debriefs, you’ll have a profile of your interview strengths. This builds confidence. You’re not going in hoping for the best. You know what you do well.

Section 4. What would I do differently?

Concrete adjustments only. Nothing vague.

“Be more confident” is not actionable.

“Practice explaining trade-offs out loud while coding. Record myself solving a problem and review the recording.” That’s a specific drill you can do tomorrow.

“Study harder” tells you nothing.

“Review tree traversal patterns before any interview with this company, since they asked tree questions in the first round.” Targeted and practical.

These adjustments go directly into your preparation routine for the next interview.

Section 5. What should I study?

Topics or problem types that need work. Add them to your practice queue.

Be specific about the gap. Not “arrays” but “sliding window problems on arrays” or “in-place array manipulation without extra space.”

Rank by frequency. Topics that come up across multiple debriefs get priority. If several different interviews exposed the same weakness, that moves to the top of your study stack.

[VISUAL: Screenshot of actual debrief template with sections labeled]

Why This System Works

Pattern recognition.

After enough debriefs, you’ll see your recurring failure modes. Not the surface-level stuff. The deep patterns.

Mine was rushing to code before fully understanding the problem. I’d hear the question, get excited that I recognized the pattern, and start typing. Then I’d hit an edge case I hadn’t considered. Or realize midway that my approach wouldn’t work for the actual constraints. Backtracking. Panic. Time pressure.

Took several debriefs before I noticed it. Once I saw it, I fixed it. Now I force myself to spend the first few minutes asking questions and thinking through my approach before I write any code.

You won’t see your patterns after one interview. You need the data. The debrief system builds that data set.

Emotional processing.

Rejection hits hard. Especially when you’ve prepared. The instinct is to suppress it, move on, try not to think about it.

The debrief gives that energy somewhere to go. Writing “I failed because I didn’t clarify the requirements before coding” feels different than sitting with a vague sense of “I’m just bad at interviews.”

One is actionable. The other spirals.

The debrief separates your identity from your performance. You’re not a person who fails interviews. You’re a person who made specific, fixable mistakes in a specific situation. That reframe matters for your headspace going into the next one.

Compound improvement.

Most people do zero structured reflection. They practice. They interview. They get rejected. They practice more. Same mistakes. Same rejections.

The debrief creates a feedback loop. Each interview makes the next one better. Improvement compounds.

This alone puts you ahead of almost everyone else interviewing for the same roles.

Google Coding Interview With a Google Software Engineer

Debriefs work best when you know what good performance looks like.

This video shows an actual technical interview in real time. Watch how problems get approached. Notice when the candidate pauses to clarify versus when they dive in. See where they struggle and how they recover.

Study it like game film. Then apply what you observe to your own debrief process.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Turn

If this helped, forward it to someone mid-interview grind right now. They’ll thank you later.

See you next week.

— Sajjaad

Claude, GPT, Gemini: Which AI Coding Assistant Should You Actually Use?

Every week, someone asks me which AI coding assistant to use. “Is GPT better than Claude?” “Should I switch to Gemini?” “What about Copilot vs Cursor?”

I’ve been using all of them on real projects and paying attention to where each helps and where each falls short.

The answer isn’t “one is best.” The answer is that each excels at different things, and knowing when to reach for which can make a real difference in your workflow.

Here’s what I’ve noticed: Claude’s models serve different purposes depending on whether you’re planning or executing. GPT handles boilerplate and well-documented APIs well. Gemini sometimes offers a fresh perspective when you’re stuck on the same error message.

Your mileage may vary. But thinking about these tools as a toolkit rather than picking a single winner is worth considering.

What I’ve Noticed From Each

Claude Opus 4.7 vs Sonnet 4.6

This is something I wish I knew earlier: choosing the right model matters because each is optimized for different things.

Opus 4.7 is Claude’s smartest model, best for planning and handling ambiguous tasks. Think of Opus as your senior engineer who thinks through hard problems. When you’re starting a new project or tackling something complex, Opus takes its time to lay out a thoughtful plan for how things should be structured.

Sonnet 4.6 is the engineer who ships tasks quickly. Once Opus gives you a plan you’re happy with, switch to Sonnet for execution. It moves much faster in terms of writing code and generating files.

My workflow: Start with Opus for planning, switch to Sonnet for building.

GPT-5.5

Fast and broad. Good at generating CRUD operations, writing tests, scaffolding projects. Knows most libraries. OpenAI calls it their “smartest and most intuitive” model, with particular strength at writing and debugging code, doing research online, and working across different tools. The tradeoff: it will confidently suggest API methods that don’t exist. Always verify.

Reach for it when: Writing boilerplate, working with popular frameworks, generating test cases.

Gemini

Sometimes approaches problems differently than the others. When I’ve been stuck on the same bug, Gemini occasionally offers an angle I hadn’t considered. The tradeoff: less consistent. Sometimes helpful, sometimes not.

Reach for it when: You need a different perspective after hitting a wall.

Try this: Use all three on your next project. Notice which helps most for which tasks. Build your own mental model based on your experience.

Based on my experience, not rigorous testing.

Watch: How To Get Ahead of 99% Of Software Engineers (WITH AI)

Knowing which AI tool to use is becoming a skill itself. This video covers the broader picture: how to use AI to accelerate your career without becoming dependent on it.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Which AI coding tool do you find yourself reaching for most? Reply with your pick, and I’ll share what I hear next week.

— Sajjaad

I Asked My Followers What’s Holding Them Back. One Answer Dominated.

When I ask my followers what’s stopping them from applying to software engineering jobs, I expect answers about skills gaps. Lack of experience. The tough market.

But one answer comes up more than anything else: “I don’t feel ready yet.”

Not “I don’t have the skills.” Not “I can’t pass the interview.” Just... not ready.

That’s a confidence problem disguised as a preparation problem.

Here’s what I’ve learned from reviewing resumes and talking to hiring managers: The people who feel “ready” often aren’t any more qualified than the people who don’t. They just applied anyway. The gap between you and the person who got the job isn’t always skill. Sometimes it’s just tolerance for discomfort.

This week I’m breaking down why “not ready” is usually a trap, and the specific mindset shifts that helped me apply before I felt qualified.

The Readiness Trap (And How to Break It)

The trap works like this: You set an internal bar for when you’ll apply. Learn one more thing. Finish one more project. Get a little more comfortable. But the bar keeps moving because there’s always more to learn.

Three reframes that broke the cycle for me:

“Ready” is a feeling, not a state. I applied to my first internship knowing maybe half of what the job posting listed. Got interviews. Got offers. The posting is a wish list, not a checklist.

Rejection is data, not judgment. Every “no” teaches you something about your resume, your interview skills, or the market. You can’t collect that data without applying. The people who land jobs faster aren’t smarter. They’re just collecting more data.

The market doesn’t wait for you. The job you’re “getting ready for” might get filled next week. Roles open and close. Hiring freezes happen. Waiting for perfect readiness means missing opportunities that won’t return.

Practical action: Apply to a few jobs this week that feel slightly out of reach. Roles where you meet most but not all requirements. Track what happens. You’ll either get interviews (proving you were ready) or get silence (giving you feedback on your materials). Both outcomes beat waiting.

The person who got the offer you wanted probably felt “not ready” too. They just clicked submit anyway.

The Brutal Truth About Software Engineering

I made this video for everyone who needs an honest perspective on what this career actually requires. It covers the realities nobody tells you, and why waiting for perfect readiness keeps most people stuck.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

This Week’s Action Step

What’s one thing you’re waiting to feel “ready” for? Reply and tell me. Sometimes just naming it breaks the spell.

See you next week.

— Sajjaad

The networking mistake that’s costing you opportunities. Here’s what actually works.

Everyone says LinkedIn is for networking. I disagree.

Hitting the blue connect button is not networking. Liking, commenting, and reposting are not networking. These activities feel productive, but they rarely lead to real opportunities.

True networking happens outside of LinkedIn. The platform is just a stepping stone.

Most people refresh job boards, hoping something will appear. But the best opportunities come through relationships, not applications. When your outreach strategy is just collecting connections, you’re missing the introductions, referrals, and insider knowledge that come from building a real network.

Here’s the approach that actually leads to internships, jobs, and career-changing conversations.

The Framework That Actually Works

Here’s something that took me years to learn: smart people don’t get paid. Likeable people get paid.

In tech, we get sucked into the technicals. What coding languages should I know? What projects should I do? We forget the basics: forming warm connections with people. When I’ve interviewed highly accomplished engineers, founders, and executives, they all share two things. First, they’re talented and methodical in their craft. Second, they’re genuinely likable. They have a great rapport and human-to-human connection skills. These are rare qualities.

50% of what you do is your work. The other 50% is how you present yourself and connect with people.

That’s why networking matters more than most people realize. And here’s how to actually do it:

Step 1: Show up where the right people are

Go to meetups, university events, Luma, and local panels. Most people looking for jobs are refreshing job boards. Be where opportunities start, not where they get posted. The best roles often get filled before they’re ever listed publicly. Hiring managers ask their network, “Who do you know?” before they post a job ad.

Step 2: Use the 3-10-2 rule for every conversation

Structure your conversations intentionally:

• 3 minutes: casual pleasantries

• 10 minutes: ask about their story, their path, what they’d do differently

• 2 minutes: ask to stay in touch or hop on a follow-up call

This keeps it natural and makes you memorable. You’re not pitching yourself. You’re learning from their experience. People remember the ones who show up, stay curious, and build real connections long before they need something.

Step 3: Follow up. Always.

Give it a few days, then reach out. Remind them of the conversation, thank them, and make the ask. Whether that’s a coffee chat, a referral, or advice, most people won’t help unless you actually ask. This is where most people drop the ball. They have a great conversation and then never follow through. The follow-up is what turns a conversation into a relationship.

The LinkedIn-to-call pipeline:

Here’s exactly what works for landing internships and jobs:

1. Search “Software Engineer” plus your target company name on LinkedIn

2. Connect with 30-50 people

3. When you connect, introduce yourself and share your value: a project you built, a specific insight, an impressive achievement

4. Request a 15-minute call

5. During the call, establish rapport and ask for a referral

Hitting the blue connect button is not networking. Liking and commenting are not networking. True networking happens outside of LinkedIn. The platform is just a stepping stone to real conversations.

This is what real networking looks like. Not passive scrolling. Not collecting connections. Actual conversations that lead somewhere.

How I Beat 99% of Software Engineers (Networking HACK)

This video breaks down the full networking system, how to build relationships that create opportunities without feeling sleazy or transactional.

Start one real networking conversation this week. Use the 3-10-2 rule. Follow up within a few days.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

This Week’s Action Step

Who’s one person you’ve been meaning to reach out to but haven’t? Send that message today. Keep it short. Ask one question. See what happens.

See you next week.

— Sajjaad

Most portfolio projects get ignored. Here’s what makes recruiters actually click.

I’ve reviewed a lot of resumes. Talked to a lot of hiring managers. Seen what gets callbacks and what gets skipped.

Here’s the pattern: most portfolio projects are perfectly fine, with solid tech stacks, clean code, and functional demos. But they all blend together, and nothing makes a recruiter stop scrolling.

The projects that stand out don’t win on complexity or fancy frameworks. They tell a story recruiters actually care about.

The filter is simple: Does this show problem-solving? Does it demonstrate real impact? Would I actually click the demo link? And most importantly, did someone other than the creator ever use this thing?

Here are three types of projects that pass that filter and how you can apply the same principles to your next build.

Three Project Types That Stand Out

Type 1: The Local Problem Solver

Think: a campus event finder that aggregates events from multiple university sources into one feed. Simple concept. Nothing revolutionary about the tech.

Why it works: It solves a real problem for a real user base. The README doesn’t just explain what it does. It shows adoption. Screenshots of active users. Testimonials from classmates. Evidence that this thing lives in the world and people actually use it.

The lesson: Impact metrics matter more than technical complexity. Recruiters don’t care that you used GraphQL. They care that real humans found your work useful.

Type 2: The Open Source Contribution

Think: an API rate limiter library. Not flashy. Not a full-stack app with a pretty UI. Just a well-documented tool that does one thing well.

Why it works: Clear documentation. GitHub stars from strangers. Evidence it’s actually being used in other projects. This isn’t just code sitting in a repo. It’s code that other developers trusted enough to depend on.

The lesson: Open source contributions with real adoption signal collaboration skills. You’re not just building for yourself. You’re building for a community. Recruiters notice that.

Type 3: The Meta Build

Think: an interview prep tool that generates custom coding challenges based on job descriptions. You paste in a job posting, it analyzes the requirements, and creates practice problems tailored to that role.

Why it works: It’s meta. You built a tool to help people get jobs, which demonstrates you deeply understand the job-search process itself. That’s the kind of product thinking that makes you memorable.

The lesson: Building for your target audience shows you understand their problems. If you’re trying to get hired as a developer, building tools that help developers is a cheat code.

The Common Thread

All three types share the same DNA.

Clear READMEs. Not just installation instructions. Context. Why does this exist? What problem does it solve? Who is it for? Screenshots. Demo links. The README sells the project before anyone touches the code.

Live demos. A GitHub repo is not enough. Recruiters aren’t going to clone your project and run it locally. Give them a URL they can click. Vercel, Netlify, Railway, whatever. Make it effortless to see your work in action.

Evidence of real usage. This is the hardest part and the most important. Did anyone besides you ever use this? Can you prove it? Screenshots, testimonials, download counts, GitHub stars from strangers. Anything that shows your project exists beyond your localhost.

Your Next Build

Here’s the framework: Build something one real person needs. Not a hypothetical user. An actual human you can name.

Get them to use it. Watch them use it. Fix what breaks. Document that in your README.

That’s it. That’s the whole strategy. One real user who isn’t you transforms a portfolio project into proof of impact.

Go Deeper

If you’re a CS major figuring out how to stand out, this video covers the core advice I’d give anyone building their tech career right now.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

This Week’s Action Step

Look at your best portfolio project. Does it have a clear README, a live demo, and evidence of real usage?

If not, fix that before you apply anywhere else.

See you next week.

— Sajjaad

How to Ship a Full-Stack App in a Weekend

Most people never finish projects.

They spend weeks researching the “perfect” framework. Months perfecting features nobody asked for. Years with half-built apps sitting in local environments that will never see the light of day.

Here’s the thing: you can ship something real in a weekend. Something deployed. Something with a URL you can send to a recruiter or drop in your LinkedIn bio.

This newsletter breaks down exactly how to do it. The stack, the timeline, and the shortcuts that save hours.

The Weekend Stack (And Why It Works)

These tools handle the boring infrastructure work so you can focus on features that actually matter.

Frontend: Next.js + TypeScript

Next.js gives you routing, server-side rendering, and API routes out of the box. No configuring webpack. No setting up a separate backend server. TypeScript catches bugs before they happen and makes your code look more professional in interviews. The combo is industry-standard at this point, which means recruiters recognize it immediately.

Backend: Vercel Serverless Functions

No server management. No scaling configuration. No paying for compute you’re not using. You write a function, deploy it, and Vercel handles everything else. For a weekend project, this is non-negotiable. You don’t have time to babysit infrastructure.

Database: Supabase

Think of it as Firebase but built on Postgres. You get a real relational database with an instant REST API, built-in authentication, and a generous free tier that covers most side projects indefinitely. You can have your database schema set up and connected in under 30 minutes.

Deployment: Vercel

Connect your GitHub repo. Push to main. It’s live. That’s it.

Why this specific combination? Every tool here has a free tier that actually works. Every tool removes decisions so you can focus on building. And every tool is something you can legitimately put on a resume because real companies use them.

The Timeline That Works

Here’s how to structure your weekend.

Hours 0-4: Foundation

Set up the repo, initialize Next.js, connect Supabase, sketch the database schema on paper. Resist the urge to add features. Define the absolute minimum: what does this thing need to do to be useful?

Hours 4-12: Core Features

Build the main functionality. Authentication with Supabase takes about an hour. The core feature set takes the rest. This is where AI coding tools earn their keep. Cursor handles repetitive boilerplate, component scaffolding, and database queries in minutes. Focus on logic and user experience.

Hours 12-20: Polish and Edge Cases

This is where most people quit. The app “works” but feels broken. Spend these hours on loading states, error handling, mobile responsiveness, and the small details that make something feel finished. Deploy repeatedly. Test on your phone. Send the link to friends to break it.

Hours 20-24: Ship It

Final bug fixes. Write a README. Clean up the UI. Post about it. Done.

What Separates People Who Ship From People Who Don’t

Cut features ruthlessly. Ship with 30% of your original vision. The 30% that ships is more valuable than the 100% that sits on your laptop forever. You can always add features later. You can’t get back the months you spent not shipping.

Use AI coding tools aggressively. Cursor, Copilot, whatever works for you. Let them write boilerplate, suggest fixes, and handle the tedious parts so you can focus on decisions that matter. If you’re not using AI tools to accelerate your builds, you’re leaving speed on the table.

Deploy early and often. Push to production on day one with barely anything working. Bugs behave differently in production. Localhost lies to you. A real URL forces you to confront real problems. Plus, every deploy is a psychological win that keeps momentum going.

Constraints create momentum. A weekend deadline forces decisions. No time to debate frameworks. No time to build features “just in case.” Ship or fail. That pressure is clarifying.

Your move: Pick this stack for your next portfolio project. Give yourself a weekend. See what you can ship. I promise it’s more than you think.

Go Deeper

The same principles that help you learn to code fast help you build fast: focus on fundamentals, use the right resources, ship constantly.

I broke down my entire learning routine and the free resources I actually used in this video. If you want to accelerate both your learning and your building, start here.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

This Week’s Challenge

Ship a weekend project this month.

Doesn’t have to be perfect. Doesn’t have to be original.

Has to be deployed. Has to have a URL.

Tag me when it’s live. I want to see what you build.

See you next week,

Sajjaad

System Design Interviews Terrified Me. Here’s the Framework That Changed That.

The first time I got a system design interview, I froze.

Drew some boxes and arrows that meant nothing. Bombed it completely.

Here’s what nobody tells you: these interviews aren’t testing whether you’ve memorized architectures. They’re testing whether you can think through ambiguous problems out loud.

And nobody teaches you how to do that. You’re just expected to know.

So I built a practice framework. Used it consistently. Next system design interview, I got the offer.

This isn’t about memorization. It’s about having a process when you don’t know the answer.

The Practice Framework

I broke every session into four phases. Set a timer and move through them.

Phase 1: Understand the Problem

Read it. List your constraints. State your assumptions out loud. How many users are we designing for? Read-heavy or write-heavy? This is where most people rush, and it’s where most people fail.

Phase 2: High-Level Architecture

Draw your system. But speak your trade-offs as you go: “I’m adding a load balancer here because we’re expecting high traffic.”

Phase 3: Deep Dive

Pick one component. Go deep. Database choice, caching strategy, and data partitioning. Show you can zoom in when it matters.

Phase 4: Review

What did you miss? What would you research further? Saying “I’d want to explore message queues here” shows self-awareness, not weakness.

Interviewers don’t expect perfect answers. They expect structured thinking and honest communication about your limits.

Three resources I used:

1. System Design Primer (GitHub) - Common patterns, real examples, free.

2. Daily random app design - Pick Uber, Netflix, Twitter. Design it on a timer. No looking anything up.

3. Record yourself - Awkward at first. Biggest unlock. You can’t improve what you can’t observe.

Real example: When I practiced designing Instagram, I realized I had no idea how CDNs actually work. Spent that evening studying them.

That exact topic came up in my next interview. Not luck. Targeted practice reveals gaps.

Go Deeper

System design isn’t just an interview skill. It’s becoming the core competency that separates engineers who get replaced from engineers who lead.

In my conversation with Microsoft CEO Satya Nadella, he talked about the new era of software engineering, where understanding architecture and system design is what will define the next generation of developers.

AI can write code. But it can’t architect systems that scale, make trade-off decisions under constraints, or communicate technical reasoning to stakeholders. That’s your job.

Watch: My Interview with Satya Nadella on the Future of Software Engineering

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Move

Try the framework today.

Pick any popular app. Design it. Time yourself. Record it if you’re willing to be uncomfortable.

Consistent practice with this framework changed everything for me.

Talk soon,

Sajjaad

I’ve spent time scraping and manually reviewing hundreds of software engineering job postings.

Not just scanning requirements. I tracked patterns in language, emphasis, and red flags. What words kept appearing? What was buried in the “nice to have” section? What companies are actually prioritizing versus what they say they want?

The biggest pattern is that AI/ML skills appeared in the majority of postings, even for roles that aren’t explicitly machine learning engineering. Companies want engineers who can work alongside AI tools, not just engineers who can build AI systems.

What continues to surprise me is how often “scrappy” and “comfortable with ambiguity” show up now compared to before. Companies want people who can build without perfect specs. The era of highly specialized roles with clear boundaries is fading.

What follows is what’s actually in demand right now, what’s become table stakes, and what’s quietly disappearing from requirements.

The Data Breakdown

What’s rising fast:

AI tooling familiarity is no longer a bonus. Copilot, Cursor, ChatGPT for coding. Companies expect you to use these tools, not debate whether they’re useful. If you’re not already integrating AI into your workflow, you’re behind candidates who are.

Full-stack flexibility is dominating. Fewer postings are hiring pure frontend or pure backend engineers. Companies want engineers who can move across the stack as needed. Specialization still matters, but rigid boundaries are a liability.

Specific frameworks kept appearing: Next.js, TypeScript, and PostgreSQL dominated the listings I reviewed. React is assumed. TypeScript is expected. Next.js signals you can ship production applications, not just components.

New roles are emerging at the intersection of these skills. Forward Deployed Engineers are showing up more frequently, especially at AI and data platform companies. These are hybrid roles: part software engineer, part solutions architect, part consultant. You work directly with customers to deploy and customize complex systems into their workflows. If you’re someone who’s technically strong but also enjoys the people side of the work, this is a path worth watching. It combines everything companies are asking for: AI fluency, full-stack ability, and comfort operating without perfect specs.

What’s now table stakes:

Git and GitHub appeared in nearly every posting. This isn’t a skill anymore. It’s literacy. If you’re not comfortable with version control, branching strategies, and pull request workflows, fix that immediately.

Cloud basics are expected even for junior roles. AWS, GCP, or Azure awareness. You don’t need to be a DevOps engineer, but you need to understand how applications get deployed and run in production environments.

API design and integration is everywhere. Building APIs. Consuming APIs. Understanding REST and increasingly GraphQL. This is fundamental to how modern software works.

What’s quietly fading:

“5 years experience required” is becoming “2 years plus demonstrated ability.” Companies are realizing years don’t equal competence. Your portfolio and what you can prove you’ve built matters more than tenure.

Degree requirements are softening. I’m seeing them mentioned noticeably less than a couple years ago. The shift isn’t complete, but it’s real. Bootcamp grads and self-taught engineers have more pathways than ever.

Red flags to watch for:

Postings that list 15+ “required” skills for entry-level roles. No salary range posted. Vague descriptions that could describe any company doing anything. These signal disorganization, unrealistic expectations, or both. Apply strategically, not desperately.

The actionable takeaway:

If you’re learning right now, prioritize TypeScript, Next.js, and one AI coding tool. That combination appeared constantly in postings from high-growth companies. Learn those three things well, build projects that demonstrate them, and you’re positioned for what companies are actually hiring for.

This data tells you what to learn.

The video below tells you how to learn it.

My complete roadmap for breaking into tech with today’s market realities. Skills to prioritize. Projects that actually matter. Mistakes I see people make constantly.

If you’re building your skills right now, make sure your learning path includes what companies are actually hiring for.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

Your Move

Building something new? Make sure it includes the skills companies want right now.

TypeScript. Next.js. AI tooling. Full-stack flexibility. These aren’t trends. They’re the new baseline.

Talk soon,

Sajjaad

From 1,000 to 1,000,000: The Unfiltered Timeline

Three years ago, I had 1,000 Instagram followers and no clear strategy. I was posting inconsistently, jumping between topics, and wondering why nothing was working. Today it’s 1M+ across platforms and over 100M views.

This isn’t a “how to go viral” guide. It’s what I actually learned about building audience trust in one of the most saturated spaces online: tech content.

Here’s the thing nobody tells you: growing an audience and landing a job require the exact same skill. You have to make people care about your work in 10 seconds or less. Whether it’s a recruiter scanning your resume or someone scrolling past your video, the challenge is identical. Capture attention. Deliver value. Be memorable.

Three decisions changed everything for me. One nearly killed my channel.

What Worked, What Failed, and the Parallels to Your Job Search

Decision 1: I picked one platform to master first.

Instead of spreading myself thin across YouTube, TikTok, Instagram, and LinkedIn simultaneously, I went all-in on Instagram. I learned the algorithm, studied what it performed, and built a system before expanding.

The job hunting parallel: Go deep on one company or role type instead of spray-and-pray applications. Knowing everything about 5 target companies beats knowing nothing about 50.

Decision 2: I made complex topics visceral.

My Oreo videos explaining algorithms and data structures have over 4 million views combined. Not because the information was new, but because the format made it stick.

The job hunting parallel: Make your projects understandable to non-technical recruiters. If you can’t explain your work simply, they can’t advocate for you internally.

Decision 3: I showed my face and personality, not just code.

The tech content space is crowded with faceless tutorials. I made the bet that people connect with people, not just information.

The job hunting parallel: Let your resume show who you are, not just what you know. Personality is a differentiator.

The mistake that almost ended everything:

I wasted months copying other creators. I saw what was trending and chased it. Reaction videos. Hot takes on topics I didn’t care about. Growth flatlined completely. The moment I went back to my angle, explaining complex concepts simply and sharing real career insights, growth resumed.

Your differentiation is your leverage. In content and in job searches.

Watch: 7 Years of Lessons in 10 Minutes

Everything I learned building my career and my platform, condensed into one video. The lessons apply whether you’re building code or building an audience. If you only watch one of my videos this month, make it this one.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

That’s it for this week.

What’s one thing you do differently from other candidates? Hit reply and tell me. I read every response.

Talk soon,

Sajjaad

I Talked to Hiring Managers This Month. The “Skills Gap” Isn’t What You Think.

I spent the last year asking hiring managers at tech companies the same question: “What skills should a student aspiring for a career look into?”

Not one said “technical skills.”

Every single one talked about communication. Ownership. Knowing how to work on a team. Scott Strazik, CEO of GE Vernova, put it clearly: “Regardless of AI, I think you’ve got to be able to ask good questions. You need to be able to listen. And then ultimately, life is about problem solving.”

Here’s the contrarian take: You’re optimizing for the wrong thing. You’re grinding LeetCode until 2 am while hiring managers are evaluating whether you can write a clear Slack message or raise your hand when you’re stuck.

The skills gap everyone talks about isn’t technical. It’s human. And that’s actually great news if you know how to demonstrate it.

The Three Gaps That Actually Cost You the Job

Every hiring manager mentioned some version of these three problems:

1. Can’t explain technical decisions to non-technical people. If you can’t tell a product manager why you chose one approach over another, you’re going to struggle in every cross-functional meeting.

2. Don’t ask clarifying questions. Junior engineers who just start coding without grasping the problem cause more rework than engineers who ask “dumb” questions upfront.

3. No evidence of working through ambiguity. Real projects don’t come with spec documents and test cases. Hiring managers want proof you can figure things out.

Technical skills are table stakes. Everyone applying has built projects and passed a coding screen. These soft skills are tie-breakers when hiring managers are choosing between qualified candidates who all know how to code.

Here’s how to demonstrate them when you have zero professional experience:

Document your projects with decision logs. Write down why you chose certain technologies, what tradeoffs you considered, and what you’d do differently. This shows your thinking, not just your output.

Contribute to open source with professional communication. Your PR descriptions and issue comments are proof of how you communicate. Make them clear, specific, and respectful.

Build something for a real user and show the feedback loop. Even if it’s a tool for your roommate, document how you gathered requirements, iterated on feedback, and handled ambiguity.

How I Built My Network (and You Can Too)

Networking is just professional communication at scale. This video breaks down how to build relationships that get you noticed by the right people, from cold LinkedIn outreach to turning connections into referrals that actually land interviews. If you’re serious about getting your foot in the door, this is the playbook.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

That’s it for this week.

Reply to this email with the hardest “soft skill” you’re working on. I’ll share what worked for me.

Talk soon,

Sajjaad

I interviewed a software engineer who got laid off from Meta. He struggled to land interviews. Then suddenly landed offers at Google, TikTok, and Snapchat.

His Snapchat offer? $363,000. Nearly double what he made at Meta.

His name is Omayow, and when I asked him what changed between struggling with interviews and suddenly having three offers from top tech companies, he gave me one answer.

Pramp.

Not LeetCode. Not Blind 75. Not another system design course. A free platform where you practice real interviews with other engineers who are also trying to land jobs.

Here’s what he told me. “Yes, people know data structures. Yes, they know system design. But can you actually do the interview and impress the interviewer? That’s what stops most people.”

He did LeetCode. He studied data structures and algorithms. But the thing that actually changed everything? Mock interviews on Pramp every single day. Real interviews under real pressure with real feedback.

That’s what got him the offers. And that’s what most people preparing for technical interviews completely miss.

Why Mock Interviews Matter More Than LeetCode

Pramp is a peer-to-peer mock interview platform. You schedule sessions with other software engineers. One person interviews, one person gets interviewed. Then you switch. Both people get practice, both people get feedback.

It’s completely free. No premium tier. No upsells. Just engineers helping engineers get better at the one skill that actually matters in job searches: performing under interview pressure.

Here’s the problem LeetCode solves. It teaches you algorithms. It builds problem-solving skills. It gives you pattern recognition for common coding questions.

Here’s the problem LeetCode doesn’t solve. It doesn’t teach you how to explain your thought process while coding. It doesn’t simulate the pressure of someone watching you debug in real time. It doesn’t prepare you for ambiguous requirements or follow-up questions that test whether you actually understand what you just wrote.

Omayow wasn’t failing interviews because he couldn’t solve the problems. He was failing because he couldn’t perform the interview itself. The moment he started practicing that specific skill, everything changed.

How to actually use Pramp:

Sign up at pramp.com. Pick your interview type. They offer coding interviews, system design, behavioral, and more. Schedule your first session. You’ll be matched with another engineer at your chosen time.

Treat it exactly like a real interview. No pausing. No looking up answers mid-session. If you don’t know something, practice saying “I don’t know, but here’s how I’d figure it out.” That’s a real interview skill.

After the session, you get immediate feedback. Your partner rates your communication, problem-solving approach, and code quality. You do the same for them. This is the part LeetCode can never give you.

Do this every day for two weeks, and you’ll notice the difference immediately. You’ll get comfortable thinking out loud. You’ll stop freezing when someone asks a clarifying question. You’ll learn how to debug while explaining what you’re doing.

Two things Omayow specifically practiced:

He used Pramp to get comfortable with system design trade-offs. When he didn’t know the perfect answer, he practiced explaining his reasoning and how he’d research the decision. That’s what interviewers actually want to hear.

He used it to debug code live while talking through his process. Most real tech interviews include pair programming or live debugging. If you’ve never done that under pressure, you’ll stumble. He practiced until it felt natural.

The combination of LeetCode for algorithms and Pramp for interview performance is what works. LeetCode builds the technical foundation. Pramp builds the performance skills. You need both.

Watch the Full Story

I interviewed Omayow about his entire journey from getting laid off at Meta to landing a $363K offer at Snapchat. He breaks down his interview prep strategy, how he negotiated a $60K raise, and what he’d do differently if he had to start over.

Watch here: From Meta Layoff to $363K at Snapchat

If you’re prepping for technical interviews right now, this is worth your time.

Start Building

If you’re still working on coding fundamentals, check out Coddy. Bite-sized projects with an AI bot that answers your questions while you build. Start with their Python module, then move to Java and JavaScript.

It’s free to use. If you want premium features, use code SAJ20 for 20% off.

That’s it for this week.

Hit reply and tell me where you’re struggling most in technical interviews. Is it algorithms, system design, or just the pressure of performing live? I’ll point you to the exact resource that’ll help.

See you next Thursday.

-Sajjaad

P.S. If you know someone grinding LeetCode but still bombing interviews, forward this to them. Pramp is free, and it’s the missing piece they need.

Spotify just told investors their best developers haven’t written a single line of code since December.

Their engineers use an internal system called Honk with Claude Code to ship features and fix bugs without touching their keyboard. An engineer on their morning commute can tell Claude to add a feature to the iOS app, get the updated version pushed to their phone on Slack, and merge it to production before they walk into the office.

When I first read this, I thought the same thing you probably did. This is wild. The future is here.

Then I saw research from Anthropic that tested 52 software engineers learning a new library. Half used AI assistance, half coded manually. The AI group scored 50% on comprehension tests. The manual group scored 67%. Nearly two letter grades lower.

The AI group only finished 2 minutes faster. 23 minutes instead of 25.

Spotify’s approach works because those developers already have years of experience. They know how to architect systems, debug edge cases, and evaluate whether AI-generated code is solid or garbage. They built that expertise by writing thousands of lines of code the hard way.

If you’re trying to break into tech right now, you don’t have that foundation yet. And if you use AI the wrong way while you’re building it, you won’t just learn slower. You’ll become someone who can ship code fast but can’t explain what it does, fix it when it breaks, or improve it when requirements change.

That’s not the person who gets hired. That’s the person who gets replaced.

What the Research Actually Found

The Anthropic research broke down exactly how different developers used AI and what happened to their skills. The pattern that emerged is something every aspiring engineer needs to understand.

The control group encountered an average of 3 errors per person while building their projects. The AI group encountered just 1 error on average. Sounds like AI made things smoother. But the control group averaged 67% on comprehension tests while the AI group scored 50%. The developers who avoided errors never learned how to fix them.

The research identified six different ways developers interacted with AI. Three patterns led to quiz scores below 40%. These developers either fully delegated code writing to AI, progressively relied on it more and more, or used it iteratively for debugging without understanding the solutions. They finished tasks but learned almost nothing.

Three other patterns preserved learning. Developers who asked only conceptual questions scored 68%. Those who requested explanations alongside code generation averaged 65%. The highest scorers generated code first, then asked follow-up questions to build comprehension. They scored 86%.

The difference between those two groups tells you everything about how to use AI without destroying your career before it starts.

Here’s what you need to do differently

Stop asking AI to write complete functions and pasting them into your project. Start asking AI to explain concepts, then write the code yourself. When you do use AI-generated code, retype it manually instead of copying it. The research showed this preserves the learning that happens when you engage with every line.

When you hit an error, spend 10 minutes trying to debug it yourself before asking AI for help. The developers in the study who encountered more errors during learning became better at debugging afterward. The ones who let AI smooth over every problem never developed that skill. Those frustrating moments where you’re stuck staring at an error message are building the pattern recognition you need to supervise AI later.

After AI helps you solve something, close the chat and explain the solution out loud like you’re teaching it to another person. If you can’t walk through why the code works and what trade-offs it makes, you don’t actually understand it. You just copied something that happens to run.

The Spotify announcement works because their senior engineers already spent years building the mental models that let them evaluate AI output. They can look at AI-generated code and immediately spot architectural problems, security issues, or performance bottlenecks. They earned the right to delegate by first proving they could do it themselves.

You haven’t earned that yet. And if you try to skip straight to the delegation phase, you’ll become someone who can ship features quickly but can’t answer basic questions in technical interviews about how those features actually work.

The Tools Worth Using (And How to Use Them Right)

If you’re going to use AI coding tools, these are the ones worth your time. But remember the framework above. Use these to learn faster, not to skip learning entirely.

GitHub Copilot - Best for learning new syntax and patterns

Free for students. Use it to see how experienced developers structure code, then retype the suggestions manually instead of tab-completing. When it suggests something unfamiliar, ask yourself why it works before moving on. Perfect for exploring new libraries or languages where you need examples.

Cursor - Best for debugging and understanding existing code

Point it at a confusing codebase and ask conceptual questions. “Why is this function structured this way?” or “What design pattern is this using?” Use it as a reading comprehension tool, not a code generator. When you hit a bug, describe the problem and ask for explanations, not just fixes.

Claude Code / ChatGPT - Best for explaining concepts before you write

Before you start coding a new feature, describe what you’re trying to build and ask for a high-level approach. Get the architecture and trade-offs explained first. Then close the chat and implement it yourself. Come back after with questions about your implementation, not to generate the implementation itself.

v0 by Vercel - Best for frontend prototyping and design iteration

Generates full React components from descriptions. Dangerous if you just copy-paste without understanding. Powerful if you use it to see patterns, then rebuild simpler versions yourself. Good for learning modern component structures and seeing how professionals organize frontend code.

The pattern across all of these: use AI to explain, explore, and understand. Not to replace the act of writing code while you’re still building foundational skills.

Future-Proof Your Skills

I talk about this in my How to Stay Ahead of AI in Tech Jobs video. The core message is simple. You won’t get replaced by AI. You’ll get replaced by someone who knows how to use AI better than you do.

The research I shared today shows exactly what that means in practice. Learning to use AI tools like GitHub Copilot is essential. But using them in a way that degrades your debugging skills and comprehension will make you worse at the job, not better at it.

GitHub offers free Copilot access to students. Use it. Just use it strategically. The goal is to build skills, not bypass them.

Watch the full breakdown: How to Stay Ahead of AI in Tech Jobs

That’s it for this week.

Hit reply and tell me which AI coding tool you’re using right now and how. I’ll tell you if you’re building skills or accidentally destroying them.

See you next Thursday.

- Sajjaad

P.S. If you know a CS student or junior developer using AI to code, forward this email to them. The difference between the 50% comprehension group and the 86% group could define their entire career.

You sent me your resumes. I reviewed 47 of them. 39 had the same two fatal flaws.

The mistakes? Generic objective statements at the top. And skills-only bullet points (in both experience and projects) that say nothing about impact.

Here’s why it matters: recruiters spend 7 seconds on your resume in an F-shaped scan pattern. The top-left corner gets 80% of their attention. If those first few lines don’t answer “why should I keep reading,” you’re out.

When I fixed these exact problems on my resume, my response rate jumped significantly. Same experience. Same skills. Different first impression.

The difference wasn’t what I knew. It was how I showed it.

Most resumes I reviewed started with a generic objective like:

“Seeking a software engineering role to leverage my skills in a dynamic environment.”

That’s the first problem. It wastes the top of your resume, saying nothing.

The second problem shows up in your experience and project sections. Bullets that just list technologies with no impact:

“Built web app using Python, React, Node.js, MongoDB, Git”

“Worked on team project with React and Express.”

Every CS major knows those technologies. Every applicant wants a “dynamic environment.” You’re not standing out. You’re blending in with 1,000 other resumes in the pile.

Recruiters don’t have time to guess if you’re good. You have to prove it immediately.

The Two Mistakes Killing Your Chances

Mistake #1: Generic Objective Statements

The problem: Starting with what you want instead of what you offer.

“Seeking a software engineering role with growth opportunities.”

This tells recruiters nothing about why they should hire you. It wastes the hottest real estate on your resume (the top-left corner where eyes land first), saying something that applies to literally every applicant.

The fix: A strategic summary statement

Replace generic objectives with 1-2 sentences that immediately qualify you for the role. Make it easy to digest. Tell them exactly why you’re a fit.

This comes from Steve Wynn, a former Amazon principal engineer and bar raiser who conducted 850+ interviews and helped set hiring standards at Amazon. He explains that recruiters scan resumes in an F-shape, spending most time on the top-left. That space is “super expensive real estate.”

Before: “Seeking software engineering role with growth opportunities.”

After: “Computer Science student with 3 deployed full-stack applications serving 10K+ users. Strong foundation in React, Node.js, and scalable system design.”

Before: “Aspiring software engineer looking to apply skills in a fast-paced environment.”

After: “Built and shipped 4 web applications with focus on performance optimization. Reduced load times by 40%+ across projects using React and lazy loading.”

See the difference? The “after” versions immediately tell recruiters what you’ve done and why it matters.

Mistake #2: Skills-Only Bullets (Experience & Projects)

The problem: Describing what you used instead of what you achieved.

Most experience and project sections look like this:

“Software Engineering Intern Worked on backend development using Node.js, Express, and MongoDB.”

“E-commerce Website Built using React, Node.js, Express, MongoDB, and CSS.”

This tells recruiters you know some frameworks. So does everyone else. It doesn’t show impact. It doesn’t prove you can ship real solutions. It’s just a list.

The fix: Impact-driven bullets

Every bullet in your experience and projects should answer: What did you build? What got better because of it?

Lead with verbs. Add outcomes. Use numbers.

Experience examples:

Before: “Worked on database optimization using SQL and MySQL.”

After: “Optimized SQL queries, reducing average response time from 2.1s to 340ms for the inventory system.”

Before: “Developed features for e-commerce platform.”

After: “Redesigned checkout flow, increasing conversion rate by 18% across 2,500+ monthly transactions.”

Project examples:

Before: “Weather app using Python and OpenWeather API.”

After: “Built weather dashboard serving 800+ daily users with real-time forecasts and 7-day predictions.”

Before: “E-commerce site built with React, Node.js, Express, MongoDB.”

After: “Developed full-stack marketplace with secure payments, serving 500+ users in first month.”

Notice: every “after” version shows what improved. Numbers matter. Even small ones. 340ms sounds more impressive than “made queries faster.” 800+ users sounds more impressive than “built an app.”

The Three-Step Resume Fix

Step 1: Replace Your Objective with a Strategic Summary

Put 1-2 sentences at the very top that immediately qualify you. Focus on what you offer, not what you want.

Template: “[Your background] with [X projects/experience] in [relevant technologies]. [Key strength or achievement].”

Examples:

“CS graduate with 5 full-stack projects deployed to production. Specialized in React performance optimization and scalable backend architecture.”

“Software engineering intern with experience building mobile apps for 10K+ users. Strong foundation in Swift, iOS development, and API integration.”

“Self-taught developer with 4 shipped web applications. Reduced load times by 35%+ through code optimization and modern frontend practices.”

This goes at the top. Right where recruiters look first. Make it count.

Step 2: Rewrite Every Experience and Project Bullet with Impact

Don’t just list technologies. Show what you built and why it mattered.

This applies to both your experience section (internships, jobs) and your projects section. Write them in the same impact-driven format.

Formula: [Action verb] + [what you built] + [outcome/metric]

Experience examples:

Before: “Worked on backend API using Node.js and Express.”

After: “Architected REST API handling 50K+ requests/day with 99.8% uptime.”

Before: “Responsible for frontend development on team project.”

After: “Built a responsive React dashboard, reducing page load time from 4.2s to 1.1s.”

Project examples:

Before: “Created mobile app using React Native and Firebase.”

After: “Shipped iOS app to 3,200 users for campus event discovery with 4.6★ rating.”

Before: “Weather dashboard using Python and OpenWeather API.”

After: “Built weather dashboard serving 800+ daily users with real-time forecasts and 7-day predictions.”

Every bullet in both sections should prove you can deliver real solutions. Not just that you know syntax.

Step 3: Keep Your Skills Section (But Move It Down)

Here’s what NOT to do: don’t remove your skills section entirely.

A dedicated skills section listing your technologies (Python, JavaScript, React, SQL, Git, etc.) is standard and expected. Recruiters look for it.

But it shouldn’t be at the top. And it definitely shouldn’t replace your project descriptions.

Structure your resume like this:

1. Summary (strategic, impact-focused)

2. Education

3. Experience (with impact-driven bullets)

4. Projects (with impact-driven bullets)

5. Skills (clean list of technologies)

The skills section is fine. Just don’t let it be the first or most prominent thing recruiters see. And don’t let “I used React” be your only bullet in experience or projects.

Why This Works

You’re not competing to be qualified. You’re competing to not be eliminated in the first 7 seconds.

Recruiters scan in an F-shape. Top-left gets the most attention. If you waste that space on generic statements or technology lists, you’ve already lost.

What are they looking for in those 7 seconds? Proof you’ve built something real. Numbers that show impact. Clear evidence you can deliver.

Your resume isn’t a list of things you learned. It’s a case for why someone should interrupt their day to interview you instead of the other 199 people in the pile.

Two simple changes:

1. Replace generic objectives with strategic summaries

2. Replace skills-only bullets with impact-driven outcomes

Lead with proof. Make it impossible to ignore.

The Resume That Got Me Into Amazon

I break down my entire resume strategy in this video: The Exact Resume That Got Me Into Amazon as a Freshman

This is the resume that landed me a software engineering internship at Amazon as a first-semester freshman. I walk through every section, every formatting choice, every psychological trick I used to get recruiters to notice me when I had almost no experience.

Get the Free Resume Template

Download my free resume template that got me interviews at top companies without cold applying.

This is the exact format I used. Same structure. Same section order. Same impact-first approach.

Download the template here.

Open it. Rewrite your top 3 lines using the formulas above. Save the new version. Send it to the next 5 jobs you apply for.

Watch what happens.

That’s it for this week.

Hit reply and send me your resume’s first three lines. I’ll tell you if it’s working or what to fix.

See you next Thursday.

- Sajjaad

P.S. If you know someone applying for software engineering roles, forward this email to them. This one fix could change their entire job search.

I’ve had thousands of subscribers on this list for months. And I’ve sent exactly zero emails.

That’s embarrassing. But it’s also a perfect example of the trap I built for myself: I’ve spent years building an audience on Instagram, TikTok, YouTube, and LinkedIn. One million followers across platforms I don’t own, don’t control, and that could change the algorithm tomorrow and cut my reach in half.

Meanwhile, this email list (the one asset I actually own, the one place I can reach you directly without begging an algorithm for permission) has been sitting here collecting dust.

So here’s the deal. Every week, you’ll get one email from me. Just the most useful thing I learned, built, or figured out that week about breaking into tech, leveling up as a developer, or working in this industry as AI reshapes everything.

If you’ve been following me on social, this is the same Sajjaad. Just deeper, more focused, and in your inbox instead of competing with 47 other videos for your attention.

Let’s get into it!

How to Become a Software Engineer in the AI Era (The A-B-C-D Framework)

If you’re trying to break into software engineering right now, you’re probably hearing two contradictory things:

1. “AI is going to replace all the junior developer jobs.”

2. “Software engineers have never been more in demand.”

Both are true. And the reason comes down to what software engineers actually do.

Most people think software engineering is just coding. It’s not. Coding is one piece. Here’s the full picture: what I call the A-B-C-D Framework:

A is for Architect. Before you write a single line of code, you have to design the system. What features does it need? How do users interact with it? What’s the tech stack? This is the planning phase. It requires creativity, business sense, and user empathy. AI can’t do this for you because AI doesn’t know what problem you’re solving or who you’re solving it for.

Example: When Amazon launched in 1995, someone had to architect a system that could handle search, shopping cart, checkout, and recommendations. That wasn’t a coding problem. That was a design problem.

B is for Build. This is the part everyone thinks of: writing code. Python, Java, JavaScript, whatever. You implement the design. And yes, this is where AI helps. GitHub Copilot can autocomplete functions. ChatGPT can generate boilerplate. You’re not typing every character yourself anymore.

But here’s the key: AI is a tool, not a replacement. It’s like saying a chef doesn’t need to know how to cook because they have a food processor. The food processor helps. But the chef still needs to know what they’re making.

Think of it like butter chicken. You don’t need to hand-grind every spice. But you'd better know which spices go in, when to add them, and how to taste-test along the way.

C is for Collaborate. Software engineering is a team sport. You’re working with product managers who define features, QA engineers who test your code, UX designers who create interfaces, and other engineers who depend on your work. You’re in meetings. You’re reviewing code. You’re explaining trade-offs.

AI can’t go to standup for you. It can’t negotiate with a PM about whether a feature is feasible. It can’t explain to a designer why their mockup won’t work on mobile.

This is the part people underestimate. And it’s the part that makes great engineers invaluable.

D is for Debug. Everything breaks. Your code has bugs. The production server crashes at 3 AM. A user reports a button that’s 2 pixels off-center. You have to find the problem, figure out why it happened, and fix it without breaking something else.

Debugging requires intuition, pattern recognition, and deep system knowledge. AI can suggest fixes, but it can’t diagnose a race condition or figure out why your API calls are timing out intermittently.

Here’s the big shift happening right now:

Software engineers are becoming software managers. Instead of writing every line of code yourself, you’re orchestrating teams of AI agents. You’re the architect, the reviewer, the debugger, and the collaborator. AI is your junior developer.

What does that mean practically?

A team of 10 engineers used to ship 10 features. Now they can ship 100 features. The bottleneck isn’t coding anymore. It’s designing the right features, making sure they work together, and ensuring they solve real problems.

If you’re breaking into software engineering in 2025, this is your advantage. Learn the full A-B-C-D cycle. Don’t just learn to code. Learn to architect, collaborate, and debug. That’s what makes you irreplaceable.

I broke this down in more detail here: Watch: How I’d Start a Career in Software Engineering in 2026

You Don’t Need to Be Great to Start. But You Have to Start to Be Great.

Here’s the truth no one wants to hear: your first project will be terrible. Your first line of code will be embarrassing. Your first portfolio will look like it was built in 2003.

And that’s exactly the point.

Every software engineer you admire started with garbage code. Every YouTuber you watch made unwatchable first videos. Every writer you read published terrible first drafts.

The difference between people who make it and people who stay stuck is one thing: they started anyway.

I call this paying down your ignorance debt. You don’t know what you don’t know until you try to build something and it breaks. Every bug you fix, every feature you ship, every stupid mistake you make. That’s you getting smarter.

So if you’re waiting to feel ready, stop. You’ll never feel ready. Build something bad. Ship it. Then build something slightly less bad. Repeat.

That’s the entire game.

If you’re new here, start with this video.

This is the foundation of everything I believe about breaking into tech and leveling up as a software engineer.

I break down three things:

1. How to talk tech: Knowing the jargon that actually matters (APIs, frameworks, databases) so you can hold your own in interviews and on teams.

2. How to build real projects: Not to-do apps. Not calculator apps. Real projects that solve real problems and give you stories to tell in interviews.

3. Why being loud about your work is non-negotiable: Posting on LinkedIn, sharing your projects, talking about what you’re learning. This is how you get interviews without applying. This is how you get into rooms with people at GitHub, Meta, and Google.

This mindset and strategy got me interviews without cold-applying. It got me in conversations with GitHub executives. It built this entire platform.

If you’re serious about breaking into software engineering, this is where you start.

Watch here: How to Get Ahead of 99% of Computer Science Majors

That’s it for this week.

Every Thursday, you’ll get one email like this: one useful insight, one framework or lesson, and links to videos that go deeper.

Just the most valuable thing I figured out that week.

Hit reply and tell me: What’s the biggest thing holding you back from breaking into software engineering right now? I read every response.

See you next Thursday.

- Sajjaad

P.S. If you know someone trying to break into tech or level up as a developer, forward this email to them.

Subscribe now