DEV Community: Samaresh Das

I Interviewed 5 Candidates for a Technical Role — Here's What Nobody Tells Freshers

Samaresh Das — Fri, 26 Jun 2026 10:20:24 +0000

Last week I sat across the table from five candidates interviewing for a frontend technical role. Different backgrounds, different colleges, different project stacks. But by the end of day two, I noticed the same patterns repeating — not in their code, but in how they communicated, how they handled pressure, and how they carried themselves in the room.

This isn't a rant. I'm writing this because I genuinely want the next batch of candidates to walk in better prepared. These are fixable problems. Every single one of them.

1. Filler Words Are Quietly Destroying Your Answers

Here's a real example from one of the sessions. I asked a candidate to explain how async/await works under the hood. The answer started like this:

"So like… async await is basically like… when you want to like… wait for something, like an API call or like some data, so like it pauses and um… yeah it like waits and then like continues…"

The candidate actually understood the concept. But by the time they got to the point, I had mentally counted fourteen filler words. The signal was buried under noise.

Every "uh", "um", "like this", "like that" chips away at the confidence you're trying to project. Interviewers don't just evaluate answers — they evaluate how you think. Filler words signal disorganised thinking, even when the underlying knowledge is solid.

The fix is counterintuitive: silence. A three-second pause before answering reads as composure and clarity. A sentence packed with "like" reads as unpreparedness. Choose the pause. Every time.

2. Looping — When Your Brain Gets Stuck on Repeat

One candidate, when asked about the difference between == and === in JavaScript, said roughly the same sentence four times in a row — each time slightly rephrased, never moving forward:

"So double equals checks the value… it checks if the values are equal… like it compares the values… so basically the values are compared…"

This is a nervous system response, not an intelligence problem. When anxiety spikes, the brain defaults to what it already said because forward progress feels risky. But from the interviewer's side of the table, looping signals one thing: the candidate doesn't know where their answer ends.

If you catch yourself looping mid-answer, the best thing you can do is stop. Literally say: "Let me reframe that." Then start fresh with a structure: define the concept, give the difference, offer an example. Three steps. Done.

3. Speaking More Is Not the Same as Saying More

This was the most frustrating pattern I observed across all five sessions.

I asked one candidate: "How does browser rendering work?"

The response started like this:

"So browsers are very important in web development, we use browsers every day to access websites and the internet has changed how we communicate… so when we type a URL the browser goes to the server and browsers are also used on mobiles today and there are many browsers like Chrome, Firefox, Safari…"

Two minutes in. We still hadn't touched the DOM tree, the CSSOM, layout, paint, or compositing — the actual answer to the question.

A technical interview is not a board exam where volume of content earns partial marks. Interviewers are evaluating one thing above everything else: clarity of thought. Can you take a complex topic, identify what's relevant, and explain it precisely?

A tight, structured 45-second answer will always outperform a three-minute monologue that circles the point without landing on it. When you ramble, you don't sound more knowledgeable — you sound less confident in what you actually know.

The formula that works:

Answer the question directly in one sentence.
Explain the mechanism or reasoning.
Give a concrete example if it adds clarity.
Stop.

4. "I Don't Know" Is a Legitimate Technical Answer

I asked a candidate about Web Workers and how they interact with the main thread. They clearly hadn't worked with them. But instead of saying that, they spent four minutes constructing an answer that was a mix of vague generalisations and confidently stated inaccuracies.

Here's what I actually wanted to hear:

"I haven't worked with Web Workers directly, but from what I understand they run scripts in background threads separate from the main thread — so they can handle heavy computation without blocking the UI. I'd want to look deeper at the postMessage API for communication between them."

That answer — which acknowledges a gap but shows reasoning instinct — is worth ten times more than a fabricated answer. It tells me the candidate knows where their knowledge ends, which means I can trust the boundaries of what they claim to know.

Interviewers are not trying to catch you out on every question. We know freshers haven't seen everything. What we're testing is intellectual honesty and the instinct to reason through the unknown — not just recall the known.

5. The Overconfidence Problem — And I'll Say What Others Won't

This one is the hardest to write because it will sting for some readers. But it's the observation I keep coming back to.

One of the candidates had two personal projects on their resume — a portfolio site and a weather app built with a YouTube tutorial. Sharp-looking resume, confident body language, came in with energy. Good signs.

Midway through the session I asked a question about state management — then, fifteen minutes later, asked a variation of the same concept with a different framing to probe depth of understanding. It's a standard technique. The candidate clocked the similarity and said:

"Sir, I already answered this. It's the same question."

It wasn't the same question. And even if it were — that is not how you speak to someone who is evaluating whether to invest in your growth and pay your salary.

But here's my broader, more controversial observation: the current ecosystem of self-learning content is producing a confidence gap in junior developers that is becoming a hiring problem.

When a YouTube tutorial ends with "you're now job ready!" after six hours of content, and a bootcamp graduation certificate gets posted on LinkedIn with forty congratulations comments — it creates a false ceiling. Freshers arrive at interviews having never shipped to production, never debugged a race condition at 2am, never handled a live incident with actual users — and yet they carry the energy of someone who has.

Production experience is a specific kind of education that cannot be replicated by personal projects. When something breaks in production at 11pm and 50,000 users are affected, you learn things about systems, communication, pressure, and your own knowledge gaps that no tutorial teaches. That experience creates a kind of calibrated humility that is immediately visible in how someone answers questions.

The candidates who impressed me most were not the ones who had the most confident answers. They were the ones who said things like "I think it works this way, but I'd want to verify that before I stake anything on it." That self-awareness is rare. And it is worth more than confidence in the interview room.

How to Actually Improve Before Your Next Interview

Work on Your Vocabulary

Technical fluency isn't just about knowing concepts — it's about articulating them precisely. Read engineering blogs from companies like Vercel, Cloudflare, and the React team. Listen to developer podcasts. The language of the industry is absorbed through immersion, not memorisation. The more you consume well-articulated technical content, the more your own speech patterns shift.

Record Yourself Doing Mock Interviews

This is uncomfortable. Do it anyway. Set a timer for 60 seconds, ask yourself a common interview question out loud, and record the answer on your phone. Watch it back. You will immediately hear every "like", every loop, every moment where your answer lost its thread. One session of this is worth ten hours of reading interview prep articles.

Practice the Pause

Before every answer, give yourself three seconds of silence. It feels awkward to you — it reads as composure to the interviewer. Use that time to identify the core of your answer before you open your mouth. Starting with the answer and building outward is far stronger than narrating your way toward it.

Structure Every Answer

Adopt a simple framework: Answer → Explain → Example. One sentence that directly addresses the question. Two to three sentences that explain the mechanism or reasoning. One concrete example if it adds clarity. Then stop. Resist the urge to keep going once you've answered the question.

Build Something That Has Real Users

Before your next interview, try to ship something — anything — to real users. A small tool, a side project with actual traffic, an open source contribution that gets merged. The experience of someone else using your work changes how you think about code quality, edge cases, and reliability. It will show in how you answer questions.

Treat Humility as a Technical Skill

In a fast-moving field where the tooling, frameworks, and best practices shift every eighteen months, knowing what you don't know is an operational advantage. Interviewers aren't looking for candidates who know everything. They're looking for candidates who can learn fast, communicate clearly, and operate with intellectual honesty under pressure.

The Line That Stayed With Me

At the end of one session, a candidate who had stumbled through several answers said something I didn't expect: "I realise I didn't answer that well — can I try again with a clearer structure?"

That self-awareness, in the middle of a stressful interview, told me more about their potential than any technically correct answer could have.

The tech industry is patient with skill gaps. It is not patient with attitude gaps. Come in knowing what you know, honest about what you don't, and hungry to close the distance between the two. That combination is rarer than any specific technical skill — and it gets noticed every time.

Claude Fable 5 Is Here: Anthropic's Most Powerful Model Just Went Public

Samaresh Das — Tue, 09 Jun 2026 19:22:15 +0000

On June 9, 2026, Anthropic did something many developers didn't expect so soon — it released Claude Fable 5, the public version of its previously restricted Mythos model, to the general market. If you've been tracking the AI frontier over the past few months, you'll know this is a big deal. Mythos was initially deemed too powerful — and too risky — for broad access. Two months later, it's on your API dashboard.

This article breaks down what Claude Fable 5 actually is, how it differs from prior Claude models, what the benchmark numbers say, and what Anthropic's own words tell us about where this is all heading.

From Project Glasswing to General Availability

Claude Mythos Preview launched in April 2026 through Project Glasswing — a tightly controlled program that included partners like AWS, Microsoft, Apple, and CrowdStrike. Access was limited to defensive cybersecurity professionals and managers of critical infrastructure. The reason? Mythos demonstrated an exceptional ability to autonomously discover and chain zero-day exploits across operating systems and browsers. Anthropic wasn't ready to hand that to the open market.

But frontier AI moves fast. By late May, Anthropic expanded Glasswing access to hundreds of organizations across 15 countries. Then on June 9, Claude Fable 5 — the public build of Mythos — became available to anyone via the Claude API and consumption-based Enterprise plans.

The key difference between the Glasswing Mythos and public Fable 5: guardrails. Sensitive requests across cybersecurity, biology, chemistry, and model distillation trigger an automatic fallback to Claude Opus 4.8. Anthropic says these safeguards activate in fewer than 5% of sessions — meaning most use cases are completely unaffected.

What's New: Capabilities That Set Fable Apart

Claude Fable 5 is officially positioned as Anthropic's first model tier above Opus. Here's what makes it meaningfully different from its predecessors:

Agentic task performance: Fable 5 is built for long-running, multi-step autonomous workflows. Where earlier Opus models would lose coherence or context across extended tasks, Fable maintains reasoning depth across complex chains.
Software engineering: Benchmark results show a dramatic coding advantage over competing frontier models (details below).
Knowledge work and vision: Anthropic says Fable 5 excels at cross-domain knowledge synthesis and visual reasoning — making it a genuine research-grade assistant.
Scientific reasoning: The model was validated by external scientific partners prior to release for use in research contexts, with expanded capability in structured scientific analysis.

Benchmark Scores: How Fable 5 Compares

Numbers speak louder than marketing. Here's how Fable 5 stacks up on the benchmarks that actually matter for developers:

SWE-Bench Pro (Agentic Coding)

This is the benchmark that measures how well a model can resolve real GitHub issues autonomously — the closest thing we have to a real-world coding test.

Model	SWE-Bench Pro Score
Claude Fable 5	80.3%
GPT-5.5	58.6%
Gemini 3.1 Pro	54.2%

That's a 21.7 percentage point lead over GPT-5.5. Reviewers at Fast Company who tested the model noted it showed "strong judgment and attention to nuance" — particularly on issues that required understanding intent rather than just pattern matching against existing code.

Hex Core Benchmark (Complex Analytical Tasks)

Analytics company Hex reported that Fable 5 is the first model to break 90% on their internal benchmark for complex, long-running analytical tasks — a 10-point jump over Claude Opus 4.x models. This benchmark is particularly relevant for data engineering, business intelligence, and multi-step reasoning workflows.

GPQA Diamond (Graduate-Level STEM Reasoning)

Anthropic did not publish official Fable 5 GPQA scores at launch. For reference, GPT-5.5 sits at 93.6% on this benchmark, with Opus 4.7 at 94.2% and Gemini 3.1 Pro at 94.3% — all within noise at the near-saturated frontier. Expect Fable 5 to be competitive here when Anthropic publishes the full benchmark table.

What Anthropic Actually Said

Anthropic's messaging around this launch is notably candid — and slightly paradoxical. The same week they launched Fable 5, they publicly called on major AI labs to establish a coordinated brake pedal on frontier AI development, warning that systems may soon achieve recursive self-improvement (RSI) — the ability to autonomously improve themselves without human intervention.

Yet they shipped anyway. Their reasoning: responsible access with guardrails is better than ceding the frontier to less safety-focused labs. On the security side, Anthropic was direct:

"Internally, we ran an external bug bounty that produced no universal jailbreaks in over 1,000 hours of testing." — Anthropic, June 9, 2026

Business users on Mythos-class models will also face mandatory 30-day data retention for safety monitoring — a notable policy addition that signals Anthropic is treating this tier of model with a different level of oversight than its consumer products.

Pricing and Availability

Claude Fable 5 is priced at roughly double the current Claude Opus pricing. For context, the original Mythos Preview was priced at five times Opus — so this is a significant reduction for general availability. It's currently included on Pro, Max, Team, and Enterprise plans until June 22, 2026. After that, usage credits may be required as Anthropic scales capacity.

For most teams building serious agentic workflows or code-heavy pipelines, the premium needs to justify itself against GPT-5.5, which costs roughly half as much. On raw coding benchmarks, the Fable 5 gap is large enough to make that case — especially for long, complex, multi-step tasks where precision compounds across steps.

Final Take

Claude Fable 5 isn't just an incremental upgrade. It represents a new tier in the public frontier — one that was restricted to government-adjacent partners just weeks ago. The SWE-Bench Pro numbers are the most striking signal: a 21-point lead over GPT-5.5 in agentic coding isn't statistical noise. It's a real capability gap at the hard end of software engineering work.

The guardrails are real, the safety story is credible, and the pricing — while premium — is far more accessible than expected. For developers building at the frontier of what's possible with LLMs in 2026, Fable 5 is the most important model release since GPT-4 landed in 2023.

Test it on your hardest, most multi-step problem first. That's where the difference shows.

Using AI to build a consistent learning structure

Samaresh Das — Thu, 04 Jun 2026 09:01:08 +0000

Forget drowning in tutorials; AI can actually forge a learning path that sticks.

We're all perpetually trying to learn new tech, right? But the endless rabbit hole of Udemy courses and YouTube playlists can leave you more confused than when you started. What if we could use AI to build a learning structure so solid, even your imposter syndrome would pack its bags?

Here's how you can leverage AI to ditch the scattered notes and create a focused learning framework. Think of it as building your own personalized curriculum, powered by a digital brain.

First, identify your goal. Are you diving into React, mastering serverless, or maybe brushing up on your CSS game? Once you have a clear target, it's time to use AI to break it down. I usually feed a prompt like this into a helpful AI:

"Break down the core concepts for learning [Your Target Skill, e.g., React Hooks] into a logical learning path, from beginner to intermediate. Include key related technologies and foundational knowledge required. Suggest practical exercises or mini-projects for each stage."

The AI will spit out a structured outline, often categorizing topics into foundational knowledge, core concepts, and advanced features. It's like having a senior dev draft your study guide overnight.

Next, refine and prioritize. The AI's output is a great starting point, but you know yourself best. Some topics might click faster for you, while others might require more time. Use your AI-generated list as a roadmap, but be flexible.

// Example of a refined task list
const learningTasks = [
  { topic: "JavaScript Fundamentals (Variables, Scope, Functions)", status: "To Do" },
  { topic: "DOM Manipulation Basics", status: "To Do" },
  { topic: "React Component Lifecycle", status: "To Do" },
  { topic: "useState Hook", status: "In Progress" },
  { topic: "useEffect Hook", status: "To Do" },
  { topic: "Building a Simple To-Do App (useEffect practice)", status: "To Do" },
];

This structured approach helps you see progress, which is a massive motivator. Instead of feeling like you're just watching videos, you're actively completing actionable steps.

The real magic happens when you use AI to generate specific practice problems or small project ideas for each module. This hands-on application solidifies the theoretical knowledge and helps you identify gaps you might have missed.

The key takeaway? AI isn't here to replace your learning; it's here to optimize it. It can handle the tedious task of structuring, leaving you free to focus on the actual learning and building. As a freelancer building websites, staying current is non-negotiable, and this method has been a game-changer for me. If you're looking for someone to help bring your web projects to life, you can find me at https://hire-sam.vercel.app/.

Save this if you're tired of learning in circles.

ai #learning #developers #freelancer

Why developers quit silently and how to not be one of them

Samaresh Das — Wed, 03 Jun 2026 09:01:12 +0000

Most developers don't quit with a bang; they just fade away, and it starts long before they submit their resignation. It’s a silent, slow disengagement that eventually hollows out their passion for coding. You might even be feeling it creep in right now.

This isn't about the dramatic "I quit!" moments, but the quiet erosion of enthusiasm that leads to uninspired code, missed growth opportunities, and eventually, a career dead end. Let's dig into why this happens in web development and, more importantly, how to yank yourself out of that spiral.

Often, the silent exit begins with feeling stuck. Repetitive tasks, a stagnant tech stack, or a project that's more about maintenance than innovation can quickly drain your energy. Suddenly, that cool feature you built last week feels like a chore, and you're just pushing pixels without purpose.

Another huge culprit is burnout, disguised as "just being busy." When every day is an endless stream of tickets, urgent bugs, and unrealistic deadlines, your brain stops seeing the bigger picture. You stop learning, stop exploring, and start doing the bare minimum. Your commit messages start looking like this:

git commit -m "fix"

Not exactly inspiring, right? Compare that to when you’re fully engaged:

git commit -m "feat(auth): Implement password reset flow with secure token validation ✨"

The difference in energy is palpable. To avoid this silent slump, you need to take control.

Here’s how to fight back:

Automate the Annoying: Identify those soul-crushing repetitive tasks. Is it manually deploying a static site? Wrangling build scripts? Write a script! It’s like giving your future self a high-five.
```
// package.json snippet
"scripts": {
  "build:prod": "vite build --mode production",
  "deploy:surge": "npm run build:prod && surge ./dist my-awesome-app.surge.sh"
}
```
This not only saves time but also injects a bit of problem-solving fun back into your day.
Set Boundaries: Learn to say "no" or "not right now." Your mental health is more important than that urgent-but-not-really-urgent request at 6 PM.
Keep Learning (Your Way): Don't wait for your job to offer training. Tinker with a new framework, build a silly side project, or contribute to open source. As someone who builds websites and does a lot of freelance work for clients, I've found that constantly exploring new tech keeps things exciting. If you ever need a hand with a project, you can always check out what I do at https://hire-sam.vercel.app/.
Communicate: Talk to your manager, your teammates, or a mentor. Express your desire for new challenges, or voice your concerns about workload. Often, people don't know there's a problem until you speak up.

The one clear thing to remember is this: your career isn't a passive ride. You have agency. Don't let your passion for development slowly fade into the background. Take proactive steps to steer your ship, find your joy, and build a career you genuinely love.

Save this if useful!

webdev #career #developer #freelance #productivity

Start before you feel ready — seriously

Samaresh Das — Tue, 02 Jun 2026 09:01:03 +0000

The perfect time to start is never.

Seriously, that urge to wait until you're "ready," have learned "everything," or feel "confident enough"? It's a trap. As developers, and especially as freelancers building websites, we're constantly in a state of learning. The good news is, you don't need to have it all figured out before you begin.

Think about that first coding project you tackled. Were you a Linus Torvalds in the making? Probably not. You likely fumbled, Googled like crazy, and maybe even questioned your life choices at 3 AM. But you did it. That feeling of accomplishment? It came after starting, not before.

The same applies to freelancing. You might be staring at a blank canvas, wondering if you can handle that client request. Maybe the tech stack is new, or you're unsure about pricing. Here’s a secret: most experienced freelancers felt the same way at some point. You learn by doing.

Consider a simple JavaScript problem. Let's say you need to fetch data from an API. You might think, "I need to understand Promises, async/await, error handling, different HTTP methods..." while true, you can start with a basic fetch and add complexity as needed.

async function fetchData(url) {
  try {
    const response = await fetch(url);
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    const data = await response.json();
    console.log(data);
    return data;
  } catch (error) {
    console.error("Error fetching data:", error);
  }
}

fetchData('https://api.example.com/data');

This basic structure gets the job done. You can then layer in more robust error handling, request bodies, or different headers. The key is to start building.

Waiting for perfect is paralysis. It’s better to launch an imperfect product or service and iterate than to never launch at all. This is a lesson I learned building websites and working as a freelancer. If you're curious about how I approach projects, you can peek at my work here: https://hire-sam.vercel.app/

So, take that first step. Write that first line of code, send that first proposal, or launch that first feature. You'll be surprised at how much you learn when you're actually in motion.

Follow for more dev content

javascript #webdev #freelancing

How to turn your random ideas into actual apps

Samaresh Das — Mon, 01 Jun 2026 09:00:57 +0000

That brilliant app idea you had at 3 AM? It's probably still just a figment of your caffeine-fueled imagination.

We all get them – those flashes of inspiration that promise to change the world (or at least make our lives a little easier). But how do you go from a scribbled note on a napkin to a working piece of software? It's less magic, more messy, but totally doable.

The first step is brutal honesty: is this idea really worth pursuing? Instead of jumping straight into coding, grab a notebook (or a digital equivalent) and sketch it out. What problem does it actually solve? Who is this for? Don't get bogged down in technical details yet; focus on the core value proposition. Think about the absolute minimum features needed to prove the concept. This is your Minimum Viable Product (MVP) thinking kicking in.

Once you have a clearer picture, it's time to pick your tools. For web apps, this often means a frontend framework like React or Vue, and a backend to handle data. Don't overthink it! If you're comfortable with JavaScript, a Node.js backend with Express is a solid, well-trodden path.

// A super simple Express route example
const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Your app is live!');
});

app.listen(port, () => {
  console.log(`App listening at http://localhost:${port}`);
});

Don't aim for perfection right away. Your first version will likely be clunky. Embrace the "ugly first draft." Focus on getting something working that users can interact with. This is where quick prototyping tools or even simple static HTML and CSS can help visualize the user flow before you write a single line of backend code.

The key is iteration. Build a little, test it, get feedback (even if it's just from yourself or a patient friend), and then build a little more. This iterative process is what separates a dormant idea from a tangible product. You'll learn what works, what doesn't, and what your users actually need, not just what you think they need.

It's a journey, and sometimes the most challenging part is just starting. For me, building websites and helping clients bring their ideas to life is a huge part of my freelance work. If you're looking to turn your own concept into a reality, you can check out how I can help at https://hire-sam.vercel.app/.

So, stop dreaming and start building. Your next great app is just a few cycles of "build, test, iterate" away.

Save this if useful.

webdev #javascript #entrepreneurship #mvp

Projects beat certificates every single time

Samaresh Das — Sun, 31 May 2026 09:00:58 +0000

That shiny certificate might impress your aunt, but it won't land you the gig.

Let's be real: in the dev world, what you've built trumps what you've studied every single time. While certifications might tick a HR box, projects are the real currency, speaking volumes about your actual skills and problem-solving abilities.

Think about it from an employer's or client's perspective. A certificate says you passed an exam. A project, however, tells a whole story:

You can initiate: You started something from scratch.
You can problem-solve: You hit roadblocks and figured them out.
You can deliver: You actually finished it.
You write real code: Not just theoretical examples. For instance, building a simple utility like this for a project:

// A debounce function, super useful in many web projects
function debounce(func, delay) {
  let timeout;
  return function(...args) {
    const context = this;
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(context, args), delay);
  };
}

// Usage in a project:
// const handleSearch = debounce(() => console.log('Searching...'), 500);
// <input type="text" onkeyup={handleSearch} />

Certificates are static; they capture a moment in time. Projects are dynamic. They show your growth, your tech stack choices, your Git commit history – basically, your journey. They demonstrate not just what you know, but how you apply it and why you made certain decisions. That's invaluable.

What kind of projects? Anything!

A personal portfolio website (a must for any web developer).
A small utility app that solves a personal pain point.
Contributing to open-source (even tiny bug fixes count!).
Recreating a popular website feature.
A simple CRUD app with a database.

The takeaway is simple: stop collecting badges and start building. That’s where the real learning happens and where you generate tangible proof of your abilities.

As someone who builds websites and does a fair bit of freelance work, I can tell you clients don't ask for my certs. They want to see my portfolio, the live sites I've built, and hear about the challenges I overcame. If you’re curious about my work, check out my services here: https://hire-sam.vercel.app/

Share this with your dev friends who are stuck in tutorial purgatory!

webdev #career #coding #freelancing

AI Is Doing the Work of Junior Developers — And Nobody Is Talking About What Happens in 7 Years

Samaresh Das — Sat, 30 May 2026 13:54:26 +0000

Fresh graduates are sending out 300, 400, sometimes 500 job applications and hearing nothing back.

Not because they're unqualified. Not because they built bad projects. Not because they failed their interviews. But because somewhere between 2024 and 2026, the entry-level job market in tech quietly collapsed — and the industry is pretending it's a temporary blip rather than a structural shift with serious long-term consequences.

This article isn't about doom. It's about a specific, underappreciated problem that the developer community needs to start talking about loudly: the pipeline crisis that AI is creating without anyone planning for it.

What Actually Happened to Entry-Level Jobs

The timeline is important to understand. In 2022 and early 2023, the narrative was "AI will assist developers." Tools like GitHub Copilot were framed as autocomplete on steroids — helpful, but not replacing anyone. Developers nodded along and kept hiring.

By 2025, something shifted. Tools like Cursor, Claude Code, Windsurf, and Antigravity weren't just completing lines — they were completing features. Writing unit tests. Drafting documentation. Building CRUD APIs from a natural language description. Setting up authentication flows. Scaffolding entire modules.

That was the work freshers used to get hired to do.

The hiring math changed overnight. A mid-level developer with Claude Code or Cursor now ships what two junior developers shipped before. The senior developer mentors less because the AI handles the boilerplate the junior would have cut their teeth on. The team moves faster with fewer people. From a purely business standpoint — why hire two juniors when one AI-augmented mid-level does more?

Companies aren't being cruel. They're being rational. But rationality at the individual company level is creating an irrational outcome at the industry level.

The Numbers Are Already Bad

Entry-level software engineering job postings dropped significantly across major markets between 2024 and 2026. Companies that used to run graduate programs with 20–30 intake positions have cut to single digits or eliminated them entirely. The "we're not hiring juniors right now" email has become so common it barely registers.

Meanwhile the number of computer science graduates, bootcamp completers, and self-taught developers entering the market hasn't decreased — if anything it's increased, partly driven by the promise of AI making development more accessible.

More people entering. Fewer doors opening. The rejection numbers are staggering.

A 2025 survey found that recent CS graduates were applying to an average of 400+ positions before landing their first role — compared to under 50 applications in 2021. The timeline from graduation to first job has stretched from weeks to over a year for a significant portion of new graduates. Some never make it at all and pivot out of tech entirely.

The anxiety this produces is not abstract. These are real people who did everything the system told them to do — studied hard, built projects, contributed to open source, got internships — and are now sitting at home wondering what they did wrong. They didn't do anything wrong. The ground shifted under them.

What Junior Roles Actually Were

To understand why this matters beyond individual hardship, you need to understand what junior roles actually were — not just for the junior developer, but for the organisation and the industry.

Junior roles were not charity. They were a mechanism for knowledge transfer.

A junior developer writing their first production feature under the guidance of a senior engineer isn't just completing a ticket. They're learning:

How to read an unfamiliar codebase and find your way around it
How to ask the right questions when you're stuck
How to understand business context — why this feature matters, who uses it, what breaks if you get it wrong
How to handle production incidents — the 3am adrenaline of something being down and needing to fix it fast
How to communicate uncertainty to non-technical stakeholders
How to make architectural tradeoffs when there isn't a right answer
How to navigate disagreement in a code review without burning bridges
How to know when the AI is confidently wrong

None of these things are in any tutorial. None of these things can be learned by building solo projects. All of them require real production environments, real stakes, and crucially — a more experienced developer who has made all these mistakes before and can accelerate your growth through them.

Junior roles were how the industry reproduced itself. They were the mechanism by which a graduate became a senior engineer over five to eight years of compounding experience.

That mechanism is being switched off.

The Chicken and Egg Problem Nobody Is Modelling

Here's the scenario that should be keeping CTOs and engineering leaders up at night, and apparently isn't:

If companies stop hiring juniors in 2025 and 2026 — those juniors don't get the production experience that turns them into mid-level developers in 2028. They don't become senior engineers in 2030 and 2031. They either leave tech, stagnate in permanent junior limbo, or never develop the deep system-level understanding that comes only from years of real-world engineering work.

Now project forward. It's 2031. The senior engineers who currently exist are five years older. Some have retired. Some have burned out. The cohort of developers who would have been mid-level by now — the 2025 and 2026 graduates — either don't exist in tech or never developed past the skills they had at graduation, because they never got the mentored production experience that compounds over years.

Who is maintaining the systems? Who is reviewing the AI output? Who is making the architectural decisions? Who is handling the incidents?

Because here is what is absolutely certain: AI cannot do this alone. Not in 2031. Probably not in 2041.

Current frontier models — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Ultra — are extraordinary at what they do. They can write correct code for well-specified problems faster than any human. They are genuinely useful in production workflows today.

They do not understand your organisation. They do not know why your payment service has a 200ms artificial delay introduced in 2021 to prevent a race condition that's never been fully fixed. They do not know that your largest enterprise client has a custom integration that breaks if you change the response format of that one legacy endpoint. They do not understand the political history of why your authentication is split across two systems. They do not feel the weight of a production incident at 2am and make judgment calls under pressure.

Senior engineers know these things. Because they were junior engineers who learned them, slowly, over years, in production environments, mentored by people who knew them before.

Cut the supply of juniors today. Get no seniors in seven years. It really is that simple.

You cannot train AI on institutional knowledge that was never created.

The Compounding Problem With AI-Generated Code

There's a second layer to this that's worth examining carefully.

As AI-generated code makes up an increasing proportion of production codebases, understanding that code — really understanding it, not just being able to read it — requires a different and deeper kind of experience than understanding code you wrote yourself.

When you write code, you know why you made every decision. When you inherit AI-generated code, you're reading the output of a system that made thousands of micro-decisions without explaining any of them. Debugging it, extending it, and refactoring it safely requires the kind of deep systems intuition that only comes from years of writing and debugging code yourself.

A developer who never wrote production code from scratch — who went straight from graduation to "supervise the AI" without the intervening years of building things the hard way — will not have that intuition. They will be a supervisor without the context to supervise effectively.

The irony is almost perfect: the more AI-generated code dominates production systems, the more you need deeply experienced engineers to manage it safely. And the more companies replace junior roles with AI, the fewer deeply experienced engineers get created.

What Freshers Are Actually Dealing With Right Now

It's easy to discuss this as an abstract industry problem. It's worth spending a moment on what it actually feels like to be on the receiving end of it.

You spent four years getting a computer science degree. You built projects. You did competitive programming. You got a mediocre internship because the good ones were competitive beyond reason. You graduated with a GPA you're proud of and a GitHub that shows real effort.

Then you start applying. You send 50 applications. Then 100. The rejections are mostly automated — you never even reach a human. You start thinking it's your resume. You redo your resume. You start thinking it's your portfolio. You redo your portfolio. You do a DSA course to refresh for technical interviews. You do a system design course because you've heard companies want that now.

Six months in, you've spent money you don't have on courses, you've had maybe five actual interviews, and you're starting to genuinely wonder whether you should have studied something else. Your friends outside tech are employed. You are not.

The cruelest part is that nothing you did was wrong. The system changed while you were inside it.

What Needs to Change — And Who Needs to Change It

For Companies

Treat junior hiring as infrastructure investment, not overhead. The short-term efficiency gains from replacing junior roles with AI are real. The long-term cost of losing your talent pipeline is also real — it just arrives on a quarterly report in 2031 rather than 2026, which makes it easy to ignore today.

A sustainable model: hire one junior per senior engineer on your team. Not as charity. As an investment in institutional knowledge transfer and future senior capacity. The companies that maintain junior pipelines through this transition period will have a significant talent advantage in five years over those that don't.

Structured graduate programs with intentional mentorship pairing are not a luxury in this environment. They are the mechanism by which your 2031 senior engineering team gets created.

For Freshers and New Graduates

The hard truth: competing with AI on its own turf — writing boilerplate, building CRUD features, completing well-specified tickets — is a losing game. AI is faster and cheaper at that category of work. That fight is over.

The opportunity is in the skills AI genuinely doesn't have: judgment, context, communication, and the ability to direct AI effectively. The developer who deeply understands how to use Claude Code or Cursor to accomplish goals that take other developers hours — and can explain the output, extend it, and debug it when it goes wrong — is genuinely valuable in ways an AI isn't.

Learn the tools at a depth that most mid-level developers haven't reached yet. Build things in public that demonstrate judgment, not just technical competence. Write about what you're learning. The barrier to demonstrating genuine technical thinking has never been lower — use that.

For Senior Engineers and Engineering Leaders

If you have any hiring influence — push for junior intake. One per senior is a reasonable ratio. Volunteer to mentor. The institutional knowledge in your head doesn't transfer to the next generation by osmosis — it requires the deliberate, time-expensive process of mentoring someone through real production work.

The pipeline problem is partially your problem to solve, not just an HR or executive decision.

For the Industry

Start modelling the talent pipeline problem explicitly. Track not just current hiring efficiency but projected senior engineer supply five and seven years out under different junior hiring scenarios. The numbers are not complicated to run. The conclusions they point to are uncomfortable, which is probably why nobody is running them publicly.

The Longer View

AI is not going away. The efficiency gains from AI-augmented development are real and are not going to be reversed. This article is not arguing for slowing down AI adoption in engineering.

It's arguing for maintaining the human pipeline alongside it.

The endgame of an industry that fully optimises for short-term output efficiency at the expense of talent development is an industry that becomes brittle, dependent on a shrinking pool of senior engineers who are aging out, and unable to maintain or evolve the increasingly complex AI-generated systems it has built.

The freshers who cannot get hired today are not a social problem to be managed. They are the senior engineers, architects, and engineering leaders of 2031 and 2035 — if the industry gives them the chance to become those things.

The pipeline doesn't fix itself. Someone has to decide it's worth fixing.

Are you a fresher dealing with this right now? A hiring manager who's changed your junior intake because of AI? A senior engineer watching this happen? Drop your perspective in the comments — this conversation needs all sides.

Follow for more on AI, developer careers, and building products that make AI work for people rather than against them.

How AI can simulate real production problems for you

Samaresh Das — Sat, 30 May 2026 09:01:04 +0000

What if you could "break" your production environment without actually breaking production? Sounds like a developer's fever dream, right? Well, AI is starting to make that dream a low-risk, high-reward reality.

We're talking about using AI to simulate the kind of real-world, panic-inducing problems that usually only crop up when your CEO is trying to demo the site to investors. Instead of waiting for a meltdown, we can proactively create chaos in a safe sandbox, all guided by our AI buddy.

AI isn't just about generating boilerplate code anymore; it can be prompted to think like a system under immense stress, a slow network, or even a third-party service having an existential crisis. It's like having your own dedicated chaos engineer, but one that’s also really good at writing mock code. 🤯

Here’s how you can tap into this superpower:

Define the Scenario: Instead of vaguely thinking "what if the API breaks?", you can ask your AI: "Simulate a scenario where my GET /products endpoint takes 5 seconds to respond, then intermittently fails with a 500 error for 10% of requests."
Generate Simulation Code: AI can then generate a mock server or specific test data that mirrors this exact problem. You can point your development environment or testing suite to this mock, rather than your actual API.

// AI-generated mock server snippet (e.g., using Express)
const express = require('express');
const app = express();
const port = 3001;

app.get('/api/products', (req, res) => {
  console.log('Simulating slow and sometimes failing API for /products...');
  const shouldFail = Math.random() < 0.1; // 10% chance to fail
  const delay = 5000; // 5-second delay

  setTimeout(() => {
    if (shouldFail) {
      res.status(500).json({ message: 'Internal Server Error: Database Unavailable' });
    } else {
      res.status(200).json([
        { id: 1, name: 'AI Widget', price: 29.99 },
        { id: 2, name: 'Chaos Controller', price: 99.99 }
      ]);
    }
  }, delay);
});

app.listen(port, () => {
  console.log(`Mock API server running on http://localhost:${port}`);
});

This simple mock allows you to:

Observe UI behavior: How does your frontend handle a 5-second wait? Does it show a loader? Does it just sit there blankly?
Test error states: Does your application gracefully display an error message when the API fails, or does it crash?
Improve user experience: Identify pain points users might experience and build more robust, resilient interfaces.

AI can help you simulate a variety of headaches, not just slow APIs:

Network latency and timeouts: Imagine a user on a slow mobile connection.
Database connection issues: What if your DB gets overloaded?
Third-party service outages: Your payment gateway or analytics provider suddenly goes offline.
Edge-case user input: AI can suggest malicious or unexpected input to test your sanitization.

The core takeaway here is that AI transforms problem prediction from guesswork into a structured, executable exercise. It lets you proactively discover vulnerabilities and build more robust systems before they hit actual users. 🛠️

As a freelance web developer, building websites that are resilient to real-world problems is critical for client success. Using AI to simulate these scenarios helps me deliver more robust solutions. If you need help building something equally sturdy, you can find me at https://hire-sam.vercel.app/.

Follow for more dev content!

ai #webdev #testing #devops #freelance

Anthropic just dropped Claude Opus 4.8 yesterday — 41 days after 4.7. The AI race is no longer measured in quarters. It's measured in weeks.

Samaresh Das — Fri, 29 May 2026 10:30:44 +0000

Claude Opus 4.8 Just Dropped — Dynamic Workflows, Effort Controls, and a 4× Reliability Jump

Anthropic shipped Claude Opus 4.8 on May 28, 2026 — just 41 days after Opus 4.7. That release cadence alone tells you something important: the feedback on 4.7 was not great, and Anthropic moved fast to fix it.

This isn't a minor patch. Opus 4.8 brings meaningful changes to agentic capabilities, introduces two significant companion features, cuts the cost of fast mode dramatically, and posts benchmark numbers that put it ahead of GPT-5.5 and Gemini 3.1 Pro on almost everything except terminal-based agent loops.

Here's a complete technical breakdown of everything that shipped — what it means, how to use it, and where the competition still holds an edge.

What's New in Opus 4.8

1. Dynamic Workflows — Parallel Subagents at Scale

This is the headline feature and it's genuinely impressive in scope. Dynamic Workflows is a research preview shipping inside Claude Code — available in the CLI, Desktop app, and VS Code extension — for Max, Team, and Enterprise plans.

The capability: Opus 4.8 can plan a large-scale task, spawn hundreds of parallel subagents to execute it across different parts of the codebase simultaneously, and then verify their outputs against your test suite before returning a result. The whole pipeline runs autonomously.

In practical terms — you describe a feature or a refactor, and Claude coordinates its own parallel workforce to get it done. You're not managing individual agents. You're setting intent and reviewing a verified result.

Anthropic describes the architecture as a planner-executor split: Opus 4.8 acts as the orchestrator, spawning cheaper/faster subagents for execution tasks, then verifying output quality at the end. This mirrors a common 2026 pattern developers have been building manually — using a frontier model as planner and a cheaper model like DeepSeek V4-Pro as executor. Anthropic has now baked that pattern directly into the product.

Dynamic Workflows tasks can run for extended periods — hours or days — in the background. You set the task, close your laptop, and come back to a verified result.

2. Effort Controls

Launching simultaneously on claude.ai for all plans. Users can now explicitly control how much reasoning effort Claude applies to a task — from a quick answer to deep extended thinking.

This matters more than it sounds. Previously, Claude decided effort level based on prompt complexity heuristics. Now you control it directly. For developers building on the API, this translates to more predictable latency and cost characteristics — you can request a lightweight response for simple queries and full reasoning depth only when needed.

The API surface for effort control is available immediately. Expect this to become a standard parameter in production Claude integrations going forward.

3. Fast Mode is Now 3× Cheaper

Fast mode — where Opus 4.8 operates at 2.5× standard speed — is now three times cheaper than it was on Opus 4.7. Standard pricing remains unchanged at $5 input / $25 output per million tokens. Fast mode pricing has dropped significantly without any reduction in speed.

For teams running high-volume agentic tasks — think CI pipelines, automated code review, or content generation at scale — this is a material cost reduction. The economics of running Opus-class intelligence on production workloads just got substantially better.

4. Honesty, Reliability, and Alignment Improvements

This is the section most benchmark comparisons skip, but it matters for production use.

Opus 4.8 is roughly four times less likely than Opus 4.7 to output faulty code without flagging the issue. In real terms: when Claude writes code that has a bug or an edge case it's unsure about, it now surfaces that uncertainty rather than silently shipping flawed output.

For agentic code review workflows, this is a production reliability change — not a benchmark footnote. Silent failures in autonomous pipelines are the hardest class of bugs to catch.

Additional alignment improvements include:

Less prone to making unsupported or hallucinated claims
Better at detecting and flagging misuse attempts
Improved support for user autonomy — the model is less likely to override user intent with its own judgment
Better honesty under adversarial prompting conditions

Anthropic also notes improvements in long-context retrieval — the model is more reliable at pulling accurate information from large context windows, which matters for the 1M-token use cases it's increasingly being deployed for.

Benchmark Breakdown — vs 4.7, GPT-5.5, and Gemini 3.1 Pro

Benchmark	Opus 4.8	Opus 4.7	GPT-5.5	Gemini 3.1 Pro
SWE-bench Verified	88.6%	—	—	—
SWE-bench Pro	69.2%	64.3%	58.6%	~60%
OSWorld (Computer Use)	83.4%	—	78.7%	—
GDPval-AA Elo	1890	—	1769	—
Terminal-Bench 2.1	74.6%	65.8%	78.2%	—
USAMO 2026 (Math)	96.7%	69.3%	—	—

The USAMO 2026 jump is the most striking number here — 96.7% versus 69.3% on 4.7 is a 27-point improvement on advanced mathematics in a single point release. That's not incremental. Something meaningful changed in the reasoning pipeline.

The GDPval-AA Elo score of 1890 implies roughly a 67% head-to-head win rate against GPT-5.5 on general reasoning tasks.

The one area GPT-5.5 still wins: Terminal-Bench 2.1 at 78.2% vs Opus 4.8's 74.6%. If your workload is pure command-line agent loops — shell scripting, terminal automation, CLI-heavy pipelines — GPT-5.5 retains an edge there.

Availability and Pricing

Opus 4.8 is available immediately across:

Anthropic API — model ID claude-opus-4-8
Amazon Bedrock
Google Cloud Vertex AI
Microsoft Azure AI Foundry — capped at 200,000 tokens at launch
GitHub Copilot — available to Pro+, Business, and Enterprise users

Pricing is unchanged from Opus 4.7:

Input: $5 per million tokens
Output: $25 per million tokens
Context window: 1 million tokens
Max output: 128,000 tokens

Fast mode (2.5× speed) is now 3× cheaper than it was on Opus 4.7 — previously $10/$50 per million tokens, now significantly reduced.

How Opus 4.8 Compares to DeepSeek V4-Pro

The benchmark comparison above covers frontier proprietary models. But the cost comparison with DeepSeek V4-Pro is worth a separate section because it changes the architecture decisions teams are making.

DeepSeek V4-Pro is approximately 12× cheaper on input ($0.435 vs $5) and 29× cheaper on output ($0.87 vs $25). That's not a marginal difference — it's a fundamentally different cost tier.

Opus 4.8 wins on agentic coding (SWE-bench Pro: 69.2% vs ~60%), reasoning with tools, and computer use. V4-Pro wins on cost for high-volume routine generation tasks.

The architecture pattern that's becoming standard in 2026: use Opus 4.8 as the planner and orchestrator, use V4-Pro (or similar) as the executor for repetitive subtasks. Anthropic's Dynamic Workflows feature is essentially a managed version of this pattern baked into Claude Code.

Using Opus 4.8 on the API — Quick Start


import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

// Standard request
const message = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 1024,
  messages: [
    {
      role: "user",
      content: "Refactor this authentication module for better error handling."
    }
  ]
});

console.log(message.content);

With Extended Thinking (Effort Control)


const message = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 16000,
  thinking: {
    type: "enabled",
    budget_tokens: 10000  // controls reasoning depth
  },
  messages: [
    {
      role: "user",
      content: "Design a distributed rate limiting system for a multi-region API."
    }
  ]
});

// Response includes thinking blocks + final answer
message.content.forEach(block => {
  if (block.type === "thinking") {
    console.log("Reasoning:", block.thinking);
  } else if (block.type === "text") {
    console.log("Answer:", block.text);
  }
});

The budget_tokens parameter is the API-level implementation of effort control — higher values allow deeper reasoning at the cost of more tokens and latency.

What's Coming Next

The 41-day release cycle and the mention of "Mythos 1 and Sonnet 4.8 could be next" in Anthropic's communications suggests the company has shifted to a much more aggressive shipping cadence. Mythos 1 is widely understood to be Anthropic's next-generation architecture — not a point release, but a ground-up rebuild.

Dynamic Workflows is currently in research preview. General availability across all Claude Code tiers is expected in the coming weeks based on Anthropic's typical preview-to-GA timeline.

The effort control UI on claude.ai is live now. The API parameter for effort control is available immediately for developers.

Should You Upgrade?

If you're on Opus 4.7 — yes, immediately. Same price, meaningfully better on every benchmark that matters, and the 4× reliability improvement on code quality alone is worth the migration. The model ID change is the only work required.

If you're on Sonnet 4.6 for cost reasons — Fast mode pricing changes make Opus 4.8 worth re-evaluating for production workloads that previously couldn't justify Opus-tier pricing.

If you're on GPT-5.5 — test your specific workload. Opus 4.8 leads on agentic coding, computer use, and reasoning. GPT-5.5 leads on terminal-heavy CLI agent loops. Run both on your actual production tasks before committing.

The model is live. The pricing is unchanged. The benchmarks are better. There's no reason not to test it today.

Follow for breakdowns on AI model releases, agentic systems, and what they mean for developers building production systems in 2026.

Struggle is part of mastery — stop skipping it

Samaresh Das — Thu, 28 May 2026 09:01:03 +0000

What if the secret to becoming a great developer isn't about innate talent, but about embracing the suck?

We're often fed this narrative of overnight success, of brilliant minds just "getting it." But the reality of building anything worthwhile, especially in tech, is a messy, drawn-out process. It's about banging your head against the keyboard until something clicks. And that, my friends, is where the magic happens.

Think about learning a new JavaScript concept. You read the docs, watch a tutorial, and then try to implement it. Often, it’s a glorious train wreck. You stare at red error messages like they're hieroglyphics from an alien civilization.

function delayedGreeting(name) {
  setTimeout(() => {
    console.log(`Hello, ${name}! You waited.`);
  }, 2000);
}

delayedGreeting("Dev"); // Works fine, right?
// Now, what if we try to use it synchronously?
// const message = delayedGreeting("Dev"); // This won't give you "Hello, Dev!"

This initial confusion, the moments where you question your entire career choice – that's the struggle. It's not a sign you're bad at coding; it's a sign you're actually learning. You're pushing the boundaries of what you know.

When I first started freelancing, building complex UIs felt like navigating a minefield blindfolded. Debugging was less about logic and more about fervent prayer. But each frustrating TypeError and unexpected infinite loop was a lesson etched into my brain.

The temptation is always there to find the "easy way out." Copy-paste from Stack Overflow without understanding. Use a boilerplate that abstracts away all the "hard parts." But skipping the struggle means you're skipping the deep understanding. You're building a facade, not a foundation.

Consider CSS. You might know display: flex; or display: grid; by heart. But truly mastering layout involves understanding specificity, the box model nuances, and how different browsers interpret your styles. That often comes from wrestling with a particularly stubborn layout for hours.

So, next time you hit a wall, don't see it as a failure. See it as a feature. It's an opportunity to grow, to understand why things work the way they do, not just that they work. This is the bedrock of true mastery, whether you're building your own projects or crafting custom websites for clients through my freelance services at https://hire-sam.vercel.app/.

The goal isn't to avoid challenges, but to learn to navigate them with increasing skill. Embrace the debugging sessions. Cherish the "aha!" moments after hours of confusion. That’s where the real developer superpowers are forged.

Follow for more dev content

Why you should always rewrite the code you copy

Samaresh Das — Wed, 27 May 2026 09:00:55 +0000

Copying code is the ultimate developer cheat code, right? Wrong.

We've all been there. Staring at a problem, the clock ticking, and a quick Stack Overflow search yields a perfect-looking snippet. It’s tempting to just paste it in and call it a day. But trust me, that seemingly innocent copy-paste can be a breeding ground for subtle bugs and future headaches.

Think of code like spoken language. You wouldn't just parrot someone's sentences without understanding their meaning, would you? The same applies here. When you copy code, you're inheriting someone else's thought process, their context, and potentially their assumptions. Without that understanding, you're building on shaky ground.

Let’s say you find a nifty JavaScript function for handling dates:

function formatDate(date) {
  var d = new Date(date),
      month = '' + (d.getMonth() + 1),
      day = '' + d.getDate(),
      year = d.getFullYear();

  if (month.length < 2) month = '0' + month;
  if (day.length < 2) day = '0' + day;

  return [year, month, day].join('-');
}

This looks great! But what if your project requires a different format, like MM/DD/YYYY? Or maybe it needs to handle timezones differently? By rewriting it, you're forced to consider these nuances. You might end up with something like this, which is more aligned with your project's specific needs:

function formatLocalDate(dateString) {
  const date = new Date(dateString);
  const options = { year: 'numeric', month: '2-digit', day: '2-digit' };
  return date.toLocaleDateString('en-US', options);
}

Beyond just getting the syntax right, rewriting forces you to:

Understand the Logic: You grasp how it works, not just that it works. This is crucial for debugging when things inevitably go wrong.
Adapt to Your Context: Your project might have different variable names, scope requirements, or dependencies. Rewriting allows you to seamlessly integrate the functionality.
Improve Performance and Readability: You can often optimize copied code or make it more idiomatic for your existing codebase, making it easier for others (and your future self!) to read.
Learn and Grow: Every line you rewrite is a learning opportunity, reinforcing best practices and expanding your own coding toolkit.

Ultimately, the time spent rewriting code you copy is an investment. It saves you hours of debugging down the line and leads to more robust, maintainable applications. As someone who builds websites and works as a freelancer, I can attest that clean, well-understood code is the bedrock of a successful project. If you're ever looking for someone to help bring your ideas to life with solid code, feel free to check out my work at https://hire-sam.vercel.app/.

So, the next time you find that perfect snippet, resist the urge to hit paste. Take a few extra minutes, rewrite it in your own way, and build something truly your own.

Save this if useful