DEV Community: Akash Gupta

How to Actually Prepare for a Backend Developer Interview in 2026

Akash Gupta — Sun, 20 Sep 2026 11:33:08 +0000

Most backend interview prep advice is either "grind 500 LeetCode problems" or "just build projects." Neither alone gets you hired. After mentoring freshers into backend roles, here's the actual breakdown of what interviewers test — and how to prepare for each part efficiently.

1. Language + runtime fundamentals (the fastest points to lose)

For Node.js roles, interviewers almost always probe:

The event loop — phases, the microtask queue, and why process.nextTick runs before Promises. If you can't explain how Node handles thousands of concurrent connections on a single thread, that's an instant red flag.
Async patterns — callbacks → Promises → async/await, and when to use Promise.all vs sequential await.
module.exports vs exports, require vs import, and module caching.
Streams and when to use them instead of buffering.

Don't just memorize definitions — be ready to explain the why. I keep a growing set of these Q&As here, open-source:
👉 Backend Developer Interview Questions (GitHub) — Node, Express, MongoDB, MySQL, Redis, System Design & DSA, with clear answers.

2. Databases — the part freshers underprepare

You'll get questions on:

Indexing (and why a missing index kills performance at scale)
SQL joins, normalization, transactions & ACID
MongoDB schema design (embed vs reference) and the aggregation pipeline
Redis for caching, sessions, and rate limiting

Know when to reach for SQL vs NoSQL vs a cache — that decision-making impresses more than syntax.

3. APIs, auth & HTTP

Be crisp on REST design, and know your status codes cold — 401 vs 403, 400 vs 422, 502 vs 504 come up constantly, both in interviews and real debugging. I put together a full reference with causes + fixes here:
👉 HTTP Status Codes — meaning, causes & how to fix

Also nail JWT auth: how the token is signed, why it's stateless, and access vs refresh tokens.

4. DSA — enough, not endless

You don't need 500 problems. You need the patterns: hashing, two pointers, sliding window, recursion, trees, and basic graphs — plus always stating time/space complexity out loud.

A focused, curated sheet beats random grinding. This free one is organized by topic + a 12-week plan with progress tracking:
👉 Backend-focused DSA Sheet

5. System design basics (yes, even for freshers)

At minimum: horizontal vs vertical scaling, load balancers, caching strategy, and moving heavy work to a queue (BullMQ/RabbitMQ/Kafka). You won't design Twitter, but you should reason about "how would this handle 10x traffic?"

6. Mock interviews > re-reading notes

The single highest-ROI step. Practicing out loud exposes the gaps that silent revision hides. Do mock interviews with a peer, a mentor, or even AI — then iterate.

A simple 6-week plan

Weeks	Focus
1–2	Node.js + JS fundamentals + async
3	Databases (SQL + Mongo + Redis)
4	APIs, auth, HTTP, system design basics
5	DSA patterns
6	Mock interviews + revise weak spots

If you want a structured path from basics to job-ready (in English + Hindi), the full backend developer roadmap is free too.

TL;DR: Interviewers test fundamentals → databases → APIs/HTTP → DSA patterns → system design → communication. Prepare each deliberately, practice out loud, and use curated resources instead of grinding blindly.

What's the toughest backend interview question you've faced? Drop it in the comments 👇

7 Node.js Mistakes That Are Quietly Killing Your Backend

Akash Gupta — Fri, 11 Sep 2026 14:39:48 +0000

7 Node.js Mistakes That Are Quietly Killing Your Backend

Your API works. It passes the demo. Then it hits real traffic — and everything slows to a crawl, memory balloons, and one bad request takes the whole thing down.

Most of the time it's not a hard bug. It's one of these seven quiet mistakes almost every backend developer makes early on. Fix them and your Node.js backend gets faster, safer, and far harder to knock over.

1. Blocking the event loop

Node is single-threaded for your code. One synchronous, heavy operation freezes every request, not just the current one.

// ❌ blocks everyone while it runs
const hash = crypto.pbkdf2Sync(password, salt, 100000, 64, 'sha512')

// ✅ async version keeps the loop free
crypto.pbkdf2(password, salt, 100000, 64, 'sha512', (err, hash) => { /* ... */ })

Rule of thumb: if a function ends in Sync, ask what it's blocking. JSON.parse on a huge payload, big loops, synchronous file reads — same danger.

2. Not handling promise rejections

An unhandled rejection can crash the whole process in modern Node.

// ❌ if this throws, nothing catches it
app.get('/user', async (req, res) => {
  const user = await db.findUser(req.query.id)
  res.json(user)
})

// ✅ wrap async handlers so errors reach your error middleware
const wrap = fn => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next)
app.get('/user', wrap(async (req, res) => {
  const user = await db.findUser(req.query.id)
  res.json(user)
}))

3. No database indexes

Your query is fast on 100 rows and dies on 100,000. Without an index, the database scans every single document.

If a query filters or sorts on a field, that field almost always needs an index. One line often turns a 900ms query into a 3ms one. Check your slow queries before users find them for you.

4. Trusting user input

Every value from the client is hostile until proven otherwise. Unvalidated input is how you get injection, crashes, and garbage in your database.

Validate the shape and type of every request body and query param at the edge (a schema validator makes this one line per route). Never build a database query by string-concatenating user input.

5. Leaking secrets and stack traces

Two classics: committing a .env file, and sending raw error objects to the client.

// ❌ hands attackers your stack trace, file paths, and query internals
res.status(500).json({ error: err })

// ✅ log the detail, return something safe
console.error(err)          // or your error tracker
res.status(500).json({ message: 'Something went wrong' })

Keep secrets in environment variables, never in the repo. Add .env to .gitignore before your first commit.

6. No timeouts on outbound calls

Calling another API or service with no timeout means one slow dependency can hang your requests forever and pile up until you run out of connections.

Always set a timeout on outbound HTTP calls and database operations. Fail fast, return a clear error, and your backend stays responsive even when something downstream is having a bad day.

7. Console.log as your only observability

console.log is fine for local dev. In production it tells you nothing when a real user hits a bug at 2 AM and you're asleep.

Use structured logging and an error tracker that alerts you the moment something breaks — with the stack trace and the request that caused it. The goal: you find the bug before your users report it.

The pattern behind all seven

Every one of these is the same lesson: code that works in a demo is not code that survives production. The gap between "it runs" and "it holds up under real load, real users, and real attackers" is exactly what separates a hobby project from a hireable backend developer.

None of this is advanced. It's just rarely taught in order — which is why so many devs learn it the painful way, in production.

I run AS Backend Institute, where we teach backend and full-stack development the way it actually works in production — not just tutorials that stop at "hello world." If you want a structured path, start here.

If this saved you one 2 AM incident, share it with a developer who's still doing console.log in production. 🙂

Nobody Gets Hired for Knowing Node.js. Here's What Actually Does.

Akash Gupta — Mon, 07 Sep 2026 20:17:38 +0000

Every week I talk to developers who can build a REST API in their sleep, have "MERN stack" on their résumé, and still can't get past the first interview round.

And every week I watch someone with worse raw coding skills get the offer.

After years of mentoring backend developers and watching who gets hired vs. who gets ghosted, I've stopped believing the thing everyone repeats online: "just learn Node.js and build projects."

That advice is not wrong. It's just not enough — and nobody tells you the rest. Here's the rest.

1. Companies don't hire "Node.js developers." They hire problem-removers.

Your framework is a detail. What a team actually pays for is: "when something breaks at 2 AM, can this person find it and fix it without panicking?"

Knowing Express routing is table stakes. Knowing why a request is slow, where a memory leak hides, and how to read a stack trace under pressure — that's the skill that survives interviews. Learn to debug, not just to build.

2. Your project folder is not a portfolio. Your decisions are.

"I built a food-delivery clone" means nothing. Everyone built the clone.

What makes an interviewer lean in: "I chose a queue here because the emails were blocking the request. I added an index after the query took 900ms. I cached this because it was hit 10,000 times an hour."

Same project. The difference is you can explain the trade-offs. Interviewers hire the person who made choices, not the person who followed a tutorial.

3. You will be rejected for how you talk about code, not how you write it.

Most rejections after a decent coding round are communication rejections. The candidate solved it — but couldn't say why, froze when asked "what if the input is 10x bigger," or went silent instead of thinking out loud.

Practice narrating your thinking. Out loud. To a wall if you have to. The job is 30% typing and 70% explaining what you typed to other humans.

4. Fundamentals beat frameworks. Every single time.

Frameworks change. Fundamentals compound.

If you understand how HTTP actually works, what an event loop is doing, why databases use indexes, and what happens between "user clicks button" and "row saved in DB" — you can pick up any framework in a weekend. The reverse is not true. A dev who only knows the framework is one version bump away from being lost.

Spend 70% of your energy on the things that don't have a version number.

5. "Full-stack" without depth is a red flag, not a feature.

Listing React, Node, Mongo, Docker, Kafka, AWS, and GraphQL on your résumé as a fresher doesn't signal range. It signals that you touched each for a weekend.

Pick one thing you can go three questions deep on. Real interviewers don't ask "do you know X." They ask "okay, and then what happens under the hood?" — three times. Depth in one area beats a buzzword salad in ten.

6. Consistency quietly beats talent.

The developers who make it aren't the smartest ones I've met. They're the ones who showed up daily for six months while the "talented" ones did a burst for two weeks and quit.

A small amount of focused practice every day — reading real code, solving one real problem, shipping something tiny — compounds into a level that looks like genius from the outside. It's not genius. It's just attendance.

7. Aim at a job, not at "learning to code."

"Learning backend development" is infinite. "Being ready for a backend interview in six months" is a plan.

Reverse-engineer it: look at 20 real job descriptions for the role you want. List every skill that appears more than five times. That is your syllabus — not a random 40-hour YouTube playlist. Learn what the market is actually paying for, in the order it pays for it.

The uncomfortable summary

You don't get hired for knowing Node.js. You get hired for:

being able to debug under pressure,
being able to explain your decisions,
having depth in fundamentals,
and showing up consistently long enough to get good.

None of that is on a certificate. All of it is learnable — but only if someone tells you it's what actually matters. Now someone has.

I run AS Backend Institute, where we train developers on exactly this — job-ready backend and full-stack skills built around what companies actually hire for, not a random tutorial list. If you want a structured path instead of guessing, the 6-month roadmap is here.

Found this useful? Share it with the one friend who keeps saying "I know how to code, why am I not getting hired." They need it.

How to Structure a Production-Grade Node.js + Express Backend (2026)

Akash Gupta — Wed, 02 Sep 2026 19:55:27 +0000

How to Structure a Production-Grade Node.js + Express Backend (2026)

Most Node.js tutorials stop at app.get('/', ...). Then you land a real project, the codebase hits 40 files, and everything lives in one 800-line index.js. Been there.

After building and reviewing dozens of backends, here's the structure and the handful of decisions that actually keep a Node + Express project maintainable — explained so a beginner can follow, but detailed enough to use at work today.

1. Layer your app: route → controller → service

The single biggest upgrade you can make is to stop putting logic inside routes.

Route — only wiring. Which URL maps to which handler.
Controller — reads the request, calls a service, sends the response.
Service — the actual business logic (talks to the DB, other APIs).

// routes/user.routes.js
import { Router } from 'express'
import * as userController from '../controllers/user.controller.js'
const router = Router()
router.get('/:id', userController.getUser)
export default router

// controllers/user.controller.js
import * as userService from '../services/user.service.js'
export const getUser = async (req, res, next) => {
  try {
    const user = await userService.findById(req.params.id)
    if (!user) return res.status(404).json({ message: 'User not found' })
    res.json(user)
  } catch (err) { next(err) }
}

// services/user.service.js
import User from '../models/User.js'
export const findById = (id) => User.findById(id).lean()

Why it matters: your business logic becomes testable without HTTP, and swapping Express for Fastify later touches only the route/controller layer.

2. A folder structure that scales

src/
  config/        # env, db connection, third-party clients
  models/        # schemas
  routes/        # URL wiring only
  controllers/   # request/response glue
  services/      # business logic
  middleware/    # auth, validation, error handler
  utils/         # pure helpers
  app.js         # express app (no listen)
  server.js      # starts the server

Keep app.js (build the app) separate from server.js (start it). Your tests can import app without opening a port.

3. Centralize config — never read `process.env` everywhere

// config/env.js
import 'dotenv/config'
export const env = {
  port: process.env.PORT || 3000,
  mongoUri: process.env.MONGO_URI,
  jwtSecret: process.env.JWT_SECRET,
  nodeEnv: process.env.NODE_ENV || 'development',
}
if (!env.mongoUri) throw new Error('MONGO_URI is required')

Reading env in one place means a missing variable fails loudly at startup, not silently at 2 AM in production.

4. One error handler to rule them all

Stop writing try/catch that just res.status(500). Funnel everything to a single error middleware.

// middleware/error.js
export const errorHandler = (err, req, res, next) => {
  const status = err.status || 500
  if (status === 500) console.error(err) // log real bugs
  res.status(status).json({ message: err.message || 'Something went wrong' })
}

// app.js (must be registered LAST)
app.use(errorHandler)

Controllers just next(err) and move on. Clean and consistent.

5. Validate input at the edge

Never trust the request body. Validate before it reaches your service (Zod is great):

import { z } from 'zod'
const signupSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8),
})
export const validate = (schema) => (req, res, next) => {
  const result = schema.safeParse(req.body)
  if (!result.success) return res.status(400).json({ errors: result.error.issues })
  req.body = result.data
  next()
}

6. The security basics you can't skip

helmet() for sane HTTP headers
express-rate-limit on auth routes
Hash passwords with bcrypt (never store plaintext)
Keep secrets in env, never in the repo (add .env to .gitignore)
Validate + sanitize every input (point 5)

import helmet from 'helmet'
import rateLimit from 'express-rate-limit'
app.use(helmet())
app.use('/api/auth', rateLimit({ windowMs: 15 * 60 * 1000, max: 20 }))

7. Graceful shutdown (the detail nobody teaches)

When your host restarts the app, finish in-flight requests and close the DB cleanly:

const server = app.listen(env.port)
process.on('SIGTERM', () => {
  server.close(() => { mongoose.connection.close(false, () => process.exit(0)) })
})

Putting it together

A good backend isn't about knowing every library — it's about separation of concerns, failing loudly, and never trusting input. Master these seven and you're already ahead of most juniors.

If you want a structured path from "first API" to "deployed, production-ready backend" — with Node.js, Express, MongoDB, MySQL and Redis — that's exactly what we teach at AS Backend Institute.

What does your Express folder structure look like? Drop it in the comments 👇

Written by the team at AS Backend Institute — a placement-focused backend development course for aspiring developers in India.

A stranger's comment rewrote my retention strategy — so I shipped it the same day

Akash Gupta — Mon, 31 Aug 2026 18:13:30 +0000

I'm building a backend-development learning platform solo — the whole thing: Node/Express API, MongoDB, Socket, SQL, live classes, a roadmap, assignments, certificates. Real students, real fees, one developer.

Last week I posted about it here. The most valuable thing that came out of it wasn't traffic — it was one comment.

The comment that changed my roadmap

A developer in the comments pushed back on how I was thinking about retention. My instinct was streaks (the Duolingo flame). Their point, paraphrased:

Streaks are fragile. One missed day and streak-based motivation collapses. Track the % of active days vs total days as your internal health metric — and show the user an all-time tally instead. "You've practiced X times" survives a broken streak in a way "streak: 0" never does.

That reframed the whole thing for me. A streak is a motivator, not a measure. The moment it breaks, it demotivates the exact person who needed one more nudge.

So I shipped it — the same day

I added a lifetime "days practiced" count next to the streak. It counts the distinct days a student actually did the work, and it never resets — even after a missed day.

Streak = the visible nudge. "You've shown up 24 times" = the thing that keeps you going after you miss a day.

Then I realized the bigger lesson

That one comment was worth more than a week of my own planning. So I asked: how do I get more of this from actual users, not just from Dev.to?

I built an in-app "Report a bug / feedback" button. On the platform, once you're logged in: click your avatar (top-right) → Report a bug, type what broke, and hit send — and it lands in a dashboard I triage every day.

Try it here: https://asbackendinstitute.com

The bet: your users' bugs and comments are your real roadmap. Make it stupidly easy for them to hand it to you.

The takeaway

Building solo doesn't mean building alone. The best product decisions this month didn't come from me — they came from a comment, and (now) from a feedback button. My job is mostly to listen fast and ship faster.

If you've built something people use: what's the one piece of user feedback that changed your product the most?

— Akash, solo dev, AS Backend Institute

15 Git Commands That Quietly Separate Juniors from Seniors

Akash Gupta — Fri, 28 Aug 2026 08:00:53 +0000

Everyone knows add, commit, push. That's the entry fee, not the game.

The developers who move fast — the ones who never lose work, never ship an ugly history, and never panic when a rebase goes sideways — all quietly share the same toolbox. It's not senior "Git magic." It's about 15 commands you can learn in an afternoon and lean on for the rest of your career.

I teach backend developers over at AS Backend Institute, and if I had to name one skill that predicts seniority without touching a single line of application code, it's Git fluency. So here are the 15 I actually reach for every week — with the gotchas nobody warns you about.

1. `git switch` and `git restore` — stop using `checkout` for everything

For years checkout did two unrelated jobs: switching branches and throwing away file changes. That overloading caused real accidents. Modern Git split it:

git switch main            # change branch
git switch -c feature/pay  # create + switch
git restore src/app.js     # discard changes in a file
git restore --staged x.js  # unstage, keep the edits

Gotcha: git restore <file> permanently discards uncommitted changes. There's no undo. Reach for it deliberately.

2. `git add -p` — commit like a surgeon

Changed five unrelated things in one file? Don't dump them into one commit. Stage hunks:

git add -p

Git walks you through each change: y (stage), n (skip), s (split further), e (edit the hunk by hand). This one habit is the difference between a readable history and a "misc fixes" graveyard.

3. `git commit --amend` — fix the last commit, not your dignity

Forgot a file? Typo in the message? Don't add a fix typo commit:

git add forgotten.js
git commit --amend --no-edit   # fold it in, keep the message
git commit --amend             # ...or edit the message too

Gotcha: amend rewrites the commit (new hash). Fine locally. If it's already pushed, you'll need a force push — see #13.

4. `git commit --fixup` + `--autosquash` — amend an old commit

--amend only fixes the last commit. To fix one buried three commits back:

git commit --fixup=<hash>              # a marked "fixup!" commit
git rebase -i --autosquash main        # Git auto-orders it next to its target

This is the professional move most people never learn. Your fix lands exactly where it belongs, automatically.

5. `git rebase -i` — the history editor

Interactive rebase lets you reshape recent commits: reword, squash, fixup, drop, edit, and reorder — just by editing a list.

git rebase -i HEAD~5

Turn add validation → fix validation → actually fix it into one clean Add form validation. Rule: only rewrite commits nobody else has pulled.

6. `git stash` — park work without committing junk

Production's on fire and your feature half-builds? Stash it:

git stash push -u -m "wip: checkout flow"   # -u also stashes untracked files
git stash -p                                # stash only selected hunks
git stash list
git stash show -p stash@{0}
git stash pop                               # apply + remove
git stash apply stash@{0}                   # apply, keep in list

Gotcha: without -u, brand-new untracked files stay behind. Always name your stashes — "future you" won't remember what stash@{3} was.

7. `git cherry-pick` — grab one commit, not the whole branch

You need one commit from another branch — a config fix, a hotfix — nothing else:

git cherry-pick <hash>
git cherry-pick -x <hash>   # records "cherry picked from…" in the message
git cherry-pick -n <hash>   # apply but don't commit (batch several, then commit)

Perfect for porting a single fix onto a release branch.

8. `git bisect` — binary-search the commit that broke it

Bug appeared "sometime in the last 200 commits"? Don't guess. Let Git find it in ~8 steps:

git bisect start
git bisect bad                 # current commit is broken
git bisect good v1.4.0         # this old one worked
# Git checks out the midpoint — you test and mark:
git bisect good   # or: git bisect bad
# ...repeat until Git names the exact culprit
git bisect reset

Even better, automate it:

git bisect run npm test

Git runs your test on each midpoint and finds the breaking commit on its own. The first time you see this work, it feels illegal.

9. `git worktree` — two branches, two folders, one repo

The best-kept secret for context switching. Instead of stashing your feature to fix a prod bug, check the other branch out into a separate folder:

git worktree add ../hotfix main
# fix, commit, push from ../hotfix — your feature work stays untouched
git worktree remove ../hotfix

No stashing, no rebuild churn, no lost train of thought.

10. `git log -S` and `git log -L` — detective mode

"When did this line appear? Who deleted this function?"

git log -S "calculateTax" --oneline    # commits that added/removed that string
git log -p -L :calculateTax:tax.js     # full history of one function

The "pickaxe" (-S) has ended more "who wrote this and why" arguments than any meeting ever will.

11. `git blame -w -C` — line-by-line history, done right

git blame -w -C src/auth.js

-w ignores whitespace-only changes; -C follows code that was moved or copied — so you blame the real author, not whoever ran the formatter. Then read the commit for the why, not to assign blame. 🙂

12. `git reflog` — the undo button for "undo"

Nuked a branch with a bad reset? Git logs almost every move of HEAD:

git reflog
# 821cd77 HEAD@{1}: commit: Add authentication   ← there it is
git branch rescue 821cd77   # recover it safely into a new branch

Limit: reflog only resurrects things Git already stored (commits, stashes). Work you never committed is gone. Translation: commit early, commit often.

13. `git reset --soft / --mixed / --hard` (+ safe force push)

One command, three levels of "go back," each answering "what happens to my changes?"

git reset --soft  HEAD~1   # undo commit, keep changes STAGED
git reset --mixed HEAD~1   # undo commit, keep changes UNSTAGED (default)
git reset --hard  HEAD~1   # undo commit, DISCARD changes (danger)

After any history rewrite, push safely:

git push --force-with-lease   # refuses to clobber if someone else pushed

--force-with-lease over --force, always. It's the difference between "oops" and "I just deleted my teammate's afternoon."

14. `git revert` — undo on shared branches without rewriting history

A bad commit is already on main/develop. Do not reset + force-push a shared branch. Create an inverse commit instead:

git revert <hash>

History stays honest: the change happened, it broke things, it was reverted — everyone can see the trail. Rule of thumb: shared branch → revert; private branch → reset.

15. `git rerere` — Git remembers how you fixed a conflict

Reuse Recorded Resolution. Enable it once:

git config --global rerere.enabled true

Now when you resolve a conflict, Git records it. Hit the same conflict again (super common during long rebases) and it replays your resolution automatically. Obscure, underused, borderline magical.

please checkit out this also: a-strangers-comment-rewrote-my-retention-strategy-so-i-shipped-it-the-same-day

The pattern underneath all of these

Notice the theme: most of these exist so you can keep a clean, honest history and never lose work. That's really what Git seniority is — not memorizing flags, but having the reflexes to move fast without breaking things.

If you're leveling up your backend skills and want more hands-on workflow stuff like this, we publish free guides over at AS Backend Institute.

Which command surprised you? And what's the one intermediate command I left out that you'd fight to keep? Drop it in the comments — I always end up learning something. 👇

The Node.js Event Loop, Explained Simply (with Examples)

Akash Gupta — Wed, 26 Aug 2026 17:52:09 +0000

"Node.js is single-threaded" — you've heard it a hundred times. So how does it handle thousands of requests at once without freezing?

The answer is the event loop. Once it clicks, a lot of Node "magic" suddenly makes sense. Let's break it down.

The one-line mental model

Node runs your JavaScript on one main thread, but hands off slow work (file reads, network calls, timers) to the system, and picks up the results later via the event loop. So one thread juggles thousands of connections — it just never sits around waiting.

Blocking vs non-blocking

// ❌ Blocking — nothing else runs until this file is read
const data = fs.readFileSync('big.txt')

// ✅ Non-blocking — Node starts the read and moves on
fs.readFile('big.txt', (err, data) => {
  console.log('done reading')
})
console.log('this prints FIRST')

Output:

this prints FIRST
done reading

The second version doesn't wait — that's the whole point.

The phases (simplified)

Each loop iteration goes through phases, in order:

Timers — setTimeout / setInterval callbacks
Poll — I/O callbacks (file, network)
Check — setImmediate callbacks
Close — cleanup callbacks

And between every phase, Node drains the microtask queue first.

Microtasks jump the line

process.nextTick() and resolved Promises are microtasks — they run before the loop moves to the next phase.

console.log('1')
setTimeout(() => console.log('2'), 0)
Promise.resolve().then(() => console.log('3'))
console.log('4')

Output:

1
4
3   ← Promise (microtask) runs before setTimeout
2

Most people guess 1 2 4 3. If you understand why it's 1 4 3 2, you understand the event loop.

setTimeout vs setImmediate

Inside an I/O callback, setImmediate always fires before setTimeout(fn, 0):

fs.readFile('f.txt', () => {
  setTimeout(() => console.log('timeout'), 0)
  setImmediate(() => console.log('immediate'))
})
// → immediate, then timeout

The one rule that keeps Node fast

Never block the event loop. A heavy CPU task (huge loop, sync crypto, giant JSON parse) freezes everything, because it hogs the single thread. Offload it:

worker_threads for CPU-heavy work
the cluster module to use all cores
a queue/microservice for big jobs

TL;DR

One JS thread + the event loop = non-blocking I/O
Microtasks (nextTick, Promises) run before the next phase
setImmediate beats setTimeout(0) inside I/O
Don't block the loop with heavy CPU work

The event loop is one of the most common interview questions too — if you want the full set, I put together a 64-question Node.js interview guide here: https://asbackendinstitute.com/blog/nodejs-interview-questions/top-60-nodejs-interview-questions

I teach hands-on backend development (Node.js, Express, MongoDB, Redis) at AS Backend Institute. More practical guides like this if you're learning backend. 🚀

15 Node.js Interview Questions You Should Be Able to Answer (2026)

Akash Gupta — Mon, 24 Aug 2026 19:35:15 +0000

Prepping for a Node.js interview? Here are 15 questions that come up again and again — with short, to-the-point answers. If you can explain these clearly, you're in good shape.

Basics

1. What is Node.js?
A runtime to run JavaScript outside the browser (built on V8). It's event-driven and non-blocking — great for I/O-heavy apps like APIs and real-time servers.

2. Is Node.js single-threaded?
Your JS runs on one main thread, but Node offloads heavy I/O to libuv's background thread pool. So it feels single-threaded but uses multiple threads under the hood.

3. CommonJS vs ES Modules?
CommonJS uses require/module.exports (synchronous, classic). ES Modules use import/export (modern standard, async, tree-shakeable). Enable ESM via "type":"module" or .mjs.

Event loop & async

4. What is the event loop?
The mechanism that lets single-threaded Node handle many operations at once — it runs callbacks for completed async tasks (timers, I/O) when the call stack is empty.

5. setTimeout vs setImmediate?
setImmediate runs in the "check" phase; setTimeout(fn,0) in the timers phase. Inside an I/O callback, setImmediate always fires first.

6. What is async/await?
Syntactic sugar over Promises so async code reads like sync code. An async function returns a Promise; await pauses until it settles. Handle errors with try/catch.

7. Promise.all vs allSettled vs race vs any?
all: rejects on first failure. allSettled: waits for all, reports each. race: first to settle wins. any: first success wins, rejects only if all fail.

8. How do you handle CPU-intensive tasks?
Offload them — worker_threads for parallel CPU work, child processes, or the cluster module to use all cores. Never block the single JS thread.

Modules & core

9. What are streams?
They process data in chunks instead of loading it all into memory — ideal for large files/network. Types: Readable, Writable, Duplex, Transform.

10. How does require() caching work?
The first require() runs the module and caches its exports. Later requires return the cache — so top-level module code runs only once.

Express & REST

11. What is middleware?
A function with (req, res, next) that runs during the request-response cycle. It can read/modify req/res, end the response, or call next() to pass control on.

12. What are the key REST principles?
Resources identified by URLs (nouns), standard HTTP methods (verbs), stateless requests, and meaningful status codes.

Auth & security

13. How does JWT auth work?
On login the server signs a token (header.payload.signature). The client sends it on each request; the server verifies the signature. The payload is only Base64-encoded — never put secrets in it.

14. How should you store passwords?
Never plain text. Hash with a slow, salted algorithm like bcrypt, and compare with bcrypt.compare on login — you never decrypt the stored hash.

Performance

15. How do you scale a Node app?
Use the cluster module (or PM2) to use all CPU cores, cache with Redis, add DB indexes, avoid blocking the event loop, and paginate large responses.

Want the full set? I wrote a complete 64-question guide (beginner → advanced, with English/Hinglish) here:
👉 https://asbackendinstitute.com/blog/nodejs-interview-questions/top-60-nodejs-interview-questions

What question do you always get asked in Node interviews? Drop it below 👇

JWT Authentication in Node.js: A Practical Guide (with Express)

Akash Gupta — Mon, 24 Aug 2026 12:42:21 +0000

Ever logged into an app, closed the tab, come back, and you're still logged in — no password needed? That's almost always JWT doing its job behind the scenes.

JWT (JSON Web Token) is one of the most common ways to handle authentication in modern backends. But a lot of developers use it without really understanding what's happening — and that's exactly where security bugs sneak in.

Let's fix that. By the end of this post you'll know what a JWT actually is, how to use it in a Node.js + Express app, and the mistakes that quietly break real apps.

What is a JWT, really?

A JWT is just a string with three parts, separated by dots:

xxxxx.yyyyy.zzzzz
   │      │      │
 header payload signature

Header — says which algorithm signed the token (e.g. HS256).
Payload — the actual data (like userId, role, and an expiry time). This is not encrypted — it's just Base64-encoded. Anyone can read it.
Signature — a cryptographic stamp created using a secret only your server knows. This is what stops people from faking tokens.

Want to see this for yourself? Paste any token into a free JWT decoder and you'll instantly see the header and payload. Notice you can read everything without the secret — that's the key lesson: never put passwords or sensitive data in a JWT payload.

Creating a token (login)

Install the library:

npm install jsonwebtoken

When a user logs in successfully, sign a token:

import jwt from 'jsonwebtoken'

// On successful login:
const token = jwt.sign(
  { userId: user._id, role: user.role },   // payload
  process.env.JWT_SECRET,                    // secret (keep it in .env!)
  { expiresIn: '7d' }                        // auto-expiry
)

res.json({ token })

Three things to notice:

Keep the payload small — just an id and role, not the whole user object.
The secret lives in an environment variable, never hardcoded.
Always set expiresIn. A token that never expires is a token that can be stolen forever.

Verifying a token (protecting routes)

Now create a middleware that checks the token on every protected request:

export function auth(req, res, next) {
  const header = req.headers.authorization || ''
  const token = header.startsWith('Bearer ') ? header.slice(7) : null

  if (!token) return res.status(401).json({ message: 'No token provided' })

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET)
    req.user = decoded          // { userId, role, iat, exp }
    next()
  } catch (err) {
    return res.status(401).json({ message: 'Invalid or expired token' })
  }
}

Use it on any route you want to protect:

app.get('/api/profile', auth, (req, res) => {
  res.json({ userId: req.user.userId })
})

That's the whole core loop: sign on login, verify on every request.

The mistakes that break real apps

These are the ones I see again and again:

Trusting the payload without verifying. Decoding a token (reading it) is not the same as verifying it. Always use jwt.verify(), never just decode.
A weak or leaked secret. If your secret is secret123 or committed to GitHub, anyone can forge valid tokens. Use a long random string.
No expiry. Always set expiresIn. Pair short-lived access tokens with a longer refresh token for a better experience.
Storing the token in localStorage carelessly. It's vulnerable to XSS. For sensitive apps, an httpOnly cookie is safer.
Putting secrets in the payload. Remember — the payload is readable by anyone. No passwords, no card numbers.

Debugging tip

When something "just doesn't work," the fastest fix is to actually look at the token. Drop it into a JWT decoder and check:

Is the exp (expiry) in the past? → token expired.
Is the payload what you expect? → maybe you signed the wrong data.
Wrong alg in the header? → algorithm mismatch.

90% of JWT bugs become obvious the moment you see the decoded token.

Wrapping up

JWT isn't magic — it's a signed string that says "this user is who they claim to be, and here's proof my server made it." Get the basics right (small payload, strong secret, always expire, always verify) and you've covered most of what breaks in production.

I teach hands-on backend development (Node.js, Express, MongoDB, Redis) at AS Backend Institute. If you're learning backend and want more practical guides like this, come say hi. 🚀

I built a full backend-learning platform solo — here's what I shipped (and what broke along the way)

Akash Gupta — Sat, 08 Aug 2026 22:15:45 +0000

A few months ago I got tired of the same problem: you finish a "backend course," feel great for a day, then realize you still can't build anything real or pass an interview.

So I started building the thing I wish I'd had when I began. Today it's finally live: https://asbackendinstitute.com

Posting it here because dev.to is where I learned a ton — I'd genuinely love your feedback.

Why I built it

Most resources hand you videos and call it a day. The gap between "I watched a tutorial" and "I can actually build and get hired" is where people give up. I wanted the whole thing to be hands-on and job-focused.

What's inside

Instead of just videos, I tried to make everything practical:

Node.js & Socket.io courses — from scratch, with an English/Hinglish toggle (India-first audience)
A 24-topic roadmap with progress tracking, so you always know what's next
AI mock interviews — two interviewer personas that actually grill you and score you
DSA practice with a "select any line → AI explains it" helper
Live classes with recordings + AI-generated notes
In-browser dev stack — run MongoDB and code without any local setup
A "Backend Ready" certificate you can only earn by proving skills (no participation trophies)
Resume + portfolio builder
Installable as a PWA

The tech (for the curious)

Frontend: React + Vite → Netlify
Backend: Node.js + Express (ESM), MongoDB + Mongoose → Render
Realtime: Socket.io for live classes/chat, WebRTC (mesh) for video rooms & 1:1 calls
PWA: service worker for install + web push notifications
AI: Anthropic / Gemini / Groq for the interview, explainers and notes

A few things I learned (the hard way)

WebRTC across mobile networks is brutal. STUN alone isn't enough — symmetric NATs (hello, mobile data) need a TURN server. I spent way too long debugging "why won't the remote video show up."
Cache invalidation is genuinely one of the hard problems. A stale server cache + client cache had me chasing "why isn't my new logo showing" far longer than I'd like to admit.
Shipping beats perfect. It's not finished — but it's real, and it's out there.

It's live — feedback welcome 🙏

👉 https://asbackendinstitute.com

If you're learning backend (or teaching it), I'd love to hear what you'd want added. I'm actively building on it.

dotenv-audit v1.1.0 — now with .env.example auto-sync

Akash Gupta — Tue, 07 Apr 2026 19:09:09 +0000

This is a follow-up to my previous article: I built a CLI tool that auto-detects missing environment variables — no schema needed

Quick update on dotenv-audit — the CLI tool that scans your code and finds missing environment variables.

What's new in v1.1.0

1. `sync` command — keep .env.example in sync with your code

The most common problem with .env.example files? They go outdated. Someone adds a new process.env.STRIPE_KEY in code but forgets to update .env.example. New developers clone the repo, miss the variable, and waste time debugging.

Now just run:

npx dotenv-audit sync

It will:

Scan your code for every process.env usage
Compare with your existing .env.example
Add missing variables with smart placeholder values
Warn about unused variables that should be removed

# .env.example
PORT=3000
DATABASE_URL=
JWT_SECRET=
OLD_UNUSED_VAR=something

After running npx dotenv-audit sync:

  dotenv-audit sync
  Scanned 12 files

  + 2 variable(s) missing from .env.example:
    + API_KEY        app.js:3
    + STRIPE_KEY     payments.ts:22

  - 1 variable(s) in .env.example but not used in code:
    - OLD_UNUSED_VAR

  ✓ Added 2 variable(s) to .env.example
  ! 1 unused variable(s) found — review and remove manually

Your .env.example now has:

PORT=3000
DATABASE_URL=
JWT_SECRET=
OLD_UNUSED_VAR=something

# ── Added by dotenv-audit sync ──────────────
# Other
API_KEY=your_api_key_here

# Stripe
STRIPE_KEY=sk_test_your_stripe_secret_key_here

Local .env file reading (bug fix in v1.0.3) Previously the tool only checked process.env at runtime — so if you had variables in your .env file, they were still showing as "missing". Fixed. Now it reads .env and .env.local before validating.

All commands

npx dotenv-audit              # Scan and show missing vars
npx dotenv-audit --ask        # Interactive mode (generate .env + ENV_SETUP.md)
npx dotenv-audit sync         # Sync .env.example with code
npx dotenv-audit audit        # List all detected variables
npx dotenv-audit gen          # Generate .env.example from scratch
npx dotenv-audit --json --ci  # CI mode with JSON output

Try it
npx dotenv-audit sync
npm: https://www.npmjs.com/package/dotenv-audit

400+ downloads in the first 2 days. Would love your feedback — what would you want next?

Thanks for reading! If you missed the first article, check it out here: How I built dotenv-audit

If you find it useful, drop a ❤️ and share it with your team!

I built a CLI tool that auto-detects missing environment variables — no schema needed

Akash Gupta — Sun, 05 Apr 2026 19:35:26 +0000

Every Node.js developer has faced this at least once:

App crashes in production.
"Cannot read property of undefined."
2 hours of debugging later — someone forgot to set DATABASE_URL.

I got tired of this. So I built dotenv-audit — a CLI tool that scans your actual code, finds every process.env usage, and tells you exactly what's missing.

The Problem with Existing Tools

dotenv → loads .env file. Doesn't validate anything.

envalid → validates, but you have to write a schema manually:

// With envalid - you write this for EVERY variable
const env = cleanEnv(process.env, {
  DATABASE_URL: str(),
  JWT_SECRET: str(),
  PORT: port({ default: 3000 }),
  REDIS_HOST: str(),
  // ... 20 more lines
})

The problem? You already wrote process .env.DATABASE_URL in your code. Why write it again in a schema?

The Solution

npx dotenv-audit --ask

That's it. One command. It:

Scans your .js, .ts, .jsx, .tsx, .vue, .svelte files
Finds every process.env.XXXX automatically
Shows what's missing with exact file locations
Generates a .env file with smart placeholder values
Output

  dotenv-audit  v1.0.2
  ──────────────────────────────────────────
  Scanned 47 files · Found 12 env variables

  ✗ MISSING (3)

    ✗ DATABASE_URL
      → src/db/connect.ts:14

    ✗ JWT_SECRET
      → src/auth/middleware.js:7

    ✗ STRIPE_KEY
      → src/payments/stripe.ts:22

  ⚠ 2 warning(s) — use --verbose to see details

  ✓ SET (9)

  ──────────────────────────────────────────
  3 missing · 9 set

Smart .env Generation
When you run --ask mode, it asks:


? Generate ENV_SETUP.md with all missing variables? (yes/no): yes
? Create new .env file with missing variables? (yes/no): yes
And generates a .env with context-aware placeholder values:


# ── Database ────────────────────────────────
DATABASE_URL=mongodb://localhost:27017/your_database_name
REDIS_HOST=localhost
REDIS_PORT=6379

# ── Authentication ──────────────────────────
JWT_SECRET=your_jwt_secret_key_min_32_chars_long

# ── Stripe ──────────────────────────────────
STRIPE_KEY=sk_test_your_stripe_secret_key_here

# ── AI / LLM ────────────────────────────────
OPENAI_API_KEY=sk-your_openai_api_key_here

It even reads your package.json — if you use mongoose, it gives mongodb:// URLs. If you use pg, it gives postgresql:// URLs.

Detection Patterns
It catches all the ways developers access env variables:

// All detected:
process.env.DATABASE_URL              // dot access
process.env["API_KEY"]                // bracket access
const { PORT, HOST } = process.env    // destructuring
process.env.PORT || 3000              // defaults (shown as warning)
import.meta.env.VITE_API_URL         // Vite

// Smart filtering:
import.meta.env.DEV                   // SKIPPED (Vite built-in)
import.meta.env.MODE                  // SKIPPED (Vite built-in)
// process.env.COMMENTED              // SKIPPED (in comments)

Monorepo Support

If you have a monorepo (pnpm workspaces, lerna, turbo), it auto-detects services and creates separate .env files:

? Create .env inside each service folder? (yes/no): yes

  ✓ api/.env          — created with 18 variables
  ✓ client/.env       — created with 8 variables
  ✓ services/auth/.env — created with 5 variables

  ✓ Done! 3 service .env files processed

No more dumping all variables into one file.

Use in CI/CD
Add this to your GitHub Actions:

- name: Validate env vars
  run: npx dotenv-audit --ci --json

If any required variable is missing, the pipeline fails — before your app does.

Quick Comparison

Feature	dotenv	envalid	dotenv-audit
Auto-detect from code	No	No	Yes
Zero schema needed	-	No	Yes
Generate `.env` file	No	No	Yes
Database auto-detect	No	No	Yes
Monorepo support	No	No	Yes
Zero dependencies	Yes	No	Yes

Try It

npx dotenv-audit --ask

npm: https://www.npmjs.com/package/dotenv-audit

This is my first npm package. I'd genuinely love feedback — what features would make this more useful for your workflow?

Update: v1.1.0 released with .env.example auto-sync →

DEV Community: Akash Gupta

How to Actually Prepare for a Backend Developer Interview in 2026

1. Language + runtime fundamentals (the fastest points to lose)

2. Databases — the part freshers underprepare

3. APIs, auth & HTTP

4. DSA — enough, not endless

5. System design basics (yes, even for freshers)

6. Mock interviews > re-reading notes

A simple 6-week plan

7 Node.js Mistakes That Are Quietly Killing Your Backend

7 Node.js Mistakes That Are Quietly Killing Your Backend

1. Blocking the event loop

2. Not handling promise rejections

3. No database indexes

4. Trusting user input

5. Leaking secrets and stack traces

6. No timeouts on outbound calls

7. Console.log as your only observability

The pattern behind all seven

Nobody Gets Hired for Knowing Node.js. Here's What Actually Does.

1. Companies don't hire "Node.js developers." They hire problem-removers.

2. Your project folder is not a portfolio. Your decisions are.

3. You will be rejected for how you talk about code, not how you write it.

4. Fundamentals beat frameworks. Every single time.

5. "Full-stack" without depth is a red flag, not a feature.

6. Consistency quietly beats talent.

7. Aim at a job, not at "learning to code."

The uncomfortable summary

How to Structure a Production-Grade Node.js + Express Backend (2026)

How to Structure a Production-Grade Node.js + Express Backend (2026)

1. Layer your app: route → controller → service

2. A folder structure that scales

3. Centralize config — never read process.env everywhere

4. One error handler to rule them all

5. Validate input at the edge

6. The security basics you can't skip

7. Graceful shutdown (the detail nobody teaches)

Putting it together

A stranger's comment rewrote my retention strategy — so I shipped it the same day

The comment that changed my roadmap

So I shipped it — the same day

Then I realized the bigger lesson

The takeaway

15 Git Commands That Quietly Separate Juniors from Seniors

1. git switch and git restore — stop using checkout for everything

2. git add -p — commit like a surgeon

3. git commit --amend — fix the last commit, not your dignity

4. git commit --fixup + --autosquash — amend an old commit

5. git rebase -i — the history editor

6. git stash — park work without committing junk

7. git cherry-pick — grab one commit, not the whole branch

8. git bisect — binary-search the commit that broke it

9. git worktree — two branches, two folders, one repo

10. git log -S and git log -L — detective mode

11. git blame -w -C — line-by-line history, done right

12. git reflog — the undo button for "undo"

13. git reset --soft / --mixed / --hard (+ safe force push)

14. git revert — undo on shared branches without rewriting history

15. git rerere — Git remembers how you fixed a conflict

The pattern underneath all of these

The Node.js Event Loop, Explained Simply (with Examples)

The one-line mental model

Blocking vs non-blocking

The phases (simplified)

Microtasks jump the line

setTimeout vs setImmediate

The one rule that keeps Node fast

TL;DR

15 Node.js Interview Questions You Should Be Able to Answer (2026)

Basics

Event loop & async

Modules & core

Express & REST

Auth & security

Performance

JWT Authentication in Node.js: A Practical Guide (with Express)

What is a JWT, really?

Creating a token (login)

Verifying a token (protecting routes)

The mistakes that break real apps

3. Centralize config — never read `process.env` everywhere

1. `git switch` and `git restore` — stop using `checkout` for everything

2. `git add -p` — commit like a surgeon

3. `git commit --amend` — fix the last commit, not your dignity

4. `git commit --fixup` + `--autosquash` — amend an old commit

5. `git rebase -i` — the history editor

6. `git stash` — park work without committing junk

7. `git cherry-pick` — grab one commit, not the whole branch

8. `git bisect` — binary-search the commit that broke it

9. `git worktree` — two branches, two folders, one repo

10. `git log -S` and `git log -L` — detective mode

11. `git blame -w -C` — line-by-line history, done right

12. `git reflog` — the undo button for "undo"

13. `git reset --soft / --mixed / --hard` (+ safe force push)

14. `git revert` — undo on shared branches without rewriting history

15. `git rerere` — Git remembers how you fixed a conflict

1. `sync` command — keep .env.example in sync with your code