DEV Community: Anushka Shinde

Companies Are Split on AI and Jobs - And That Split Tells You Everything

Anushka Shinde — Sun, 14 Jun 2026 06:35:55 +0000

This week I read something that stuck with me.

A major tech CEO criticized other executives for publicly celebrating layoffs caused by AI automation.He compared it to celebrating a manifesto that damages long-term innovation and morale.

His company's position? AI should augment human roles not replace them.

Two completely different philosophies.Same industry. Same AI tools. Same year.

And as a fresher about to enter this industry this split matters more than any technical skill I learn.

The Two Camps

Camp 1 "AI replaces, we cut costs"

Some companies are openly using AI to reduce headcount.Fewer developers. Fewer support staff. Fewer analysts.AI does the work. Cost goes down. Profit goes up.

They announce it publicly sometimes almost proudly as a sign of efficiency.

Camp 2 "AI augments, humans still matter"

Other companies are saying the opposite.AI helps employees do more but humans still make decisions, handle judgment calls, and own outcomes.

They're hiring. Training. Investing in people alongside AI tools.

Same technology. Opposite philosophy.

Why This Split Exists

Here's what I think is actually happening.

Companies that compete purely on cost manufacturing, basic support, repetitive operations see AI as a direct replacement for expensive labor.

Companies that compete on judgment, trust, and complex decision making see AI as a tool that makes their best people better.

The difference isn't the technology.It's what the company actually sells.

What This Means For Freshers Like Me

This split is not just a news story.It's a map.

When you're applying for jobs —
the company's philosophy on AI
tells you what kind of role you'll actually have.

Camp 1 companies be cautious.
If they're replacing junior roles with AI now,they'll keep doing it.Your role might be designed to be temporary by definition.

Camp 2 companies look closer.
If they're investing in people alongside AI,they're betting that human judgment still has long-term value.That's where growth happens.

You can often tell which camp a company is injust by how they talk about AI in interviews,
job descriptions, and public statements.

The Skill That Matters Now

Here's what I've started believing.

Technical skills get you in the door.But the skill that keeps you in the room is

Judgment.

The ability to look at AI generated output and know if it's actually right.The ability to ask "should we build this" not just "can we build this."The ability to take responsibility for a decision not just execute one.

AI can write code. AI can analyze data.AI can even make recommendations.

But AI doesn't take responsibility when something goes wrong.

That's still a human thing.And companies in Camp 2 know this is valuable.

What I'm Doing With This Information

I can't control which camp a company belongs to.

But I can control how I position myself.

When I build projects I focus on understanding the problem, not just generating code.

When I write blog posts I explain my reasoning,not just my output.

When I go into interviews I talk about decisions I made and why,
not just technologies I used.

Because the fresher who can explain their thinking is the fresher who looks like
a Camp 2 hire.

The Honest Truth

This AI and jobs debate isn't going away.

Some companies will keep cutting.
Some will keep investing in people.

As a fresher you don't get to choose the industry's direction.

But you do get to choose which companies you apply to,what questions you ask in interviews,
and what kind of professional you become.

Pay attention to which camp a company belongs to.

It might matter more than the salary number. 😊

Have you noticed this split in companies you've researched or interviewed with?

Which camp do you think your dream company falls into?

Drop it below 👇

Student Projects vs Real World Projects - The Honest Difference

Anushka Shinde — Fri, 12 Jun 2026 15:56:51 +0000

You build a project.It works on localhost.You add it to your resume.You feel proud.

And you should.

But somewhere in the back of your mind you wonder.

Would this survive real users?
Would this work if 1000 people used it at once?Would a company actually use this?

Here's the honest difference between what students build and what companies ship and how you can close that gap right now.

The Biggest Difference Nobody Talks About

Student project built to impress.
Real project built to survive.

A student project needs to work once.For a demo. For a viva. For a screenshot.

A real project needs to work always.For real users. Real data. Real consequences.

That's not a small difference.
That's everything.

How Students Build vs How Companies Build

Students think about:

What features should I add?
How should the UI look?
Which tech stack sounds impressive on a resume?

Companies think about:

How many users will hit this at once?
What happens when the server goes down?
How do we deploy without breaking what's already live?
Who is responsible when something breaks at 3am?
How do we scale this without rewriting everything?

Neither is wrong.
But understanding the difference
changes how you build even as a student.

🖥️ Localhost vs Deployed and Live

Student reality:
Project runs on your laptop.
You demo it. Viva done. Laptop closed.

Real world reality:
Project is deployed. Live. Running 24/7.Real users accessing it right now.Emails actually sending. Payments actually processing.APIs handling thousands of requests simultaneously.

How to close this gap:
Deploy your project. Even once.
AWS Free Tier. Render. Railway. Vercel.All free for students.

A deployed project on your resume
is worth ten localhost projects.

👤 Dummy Data vs Real Users

Student reality:
You test with your own account.
Maybe your friend's account.
Data is fake. Stakes are zero.

Real world reality:
Real names. Real emails. Real payment details.Real people who will complain if something breaks.Data protection laws that apply to every user.

How to close this gap:
Think about real users while building.Add proper validation what if someone types nothing?
Add error messages what if the API fails?Add loading states what if it's slow?

These small things separate a student project from something that feels real.

🔐 No Security vs Real Security

Student reality:
Passwords stored as plain text sometimes.No input validation.
SQL queries built by string concatenation.Anyone can access any page.

Real world reality:
Passwords hashed. Always.Every input validated and sanitized.
Parameterized queries everywhere.
Role based access control on every endpoint.HTTPS. Tokens. Session management.

How to close this gap:
Hash passwords with BCrypt.Use parameterized queries never raw SQL.Add authentication to protected routes.These are not advanced topics.They are basics that real projects never skip.

⚡ One User vs Thousands of Users

Student reality:
Project works fine when you test it alone.Nobody thinks about what happens when 500 people use it at the same time.

Real world reality:
APIs designed to handle concurrent requests.Database queries optimized with indexes.
Caching used to reduce repeated database hits.Load balancers distributing traffic.

How to close this gap:
Add database indexes on columns you search frequently.Learn basic query optimization.Understand what caching means even conceptually.

You don't need to build Netflix.
You need to understand why Netflix needs these things.

🚀 No Deployment vs CI/CD Pipelines

Student reality:
You zip the project and submit it.Or push to GitHub and hope the teacher checks it.

Real world reality:
Every code change goes through automated testing.If tests pass it deploys automatically.If tests fail it never reaches production.
Multiple environments development, staging, production.

How to close this gap:
Set up one GitHub Actions workflow.Make it run your project on every push.Free. Takes 30 minutes to learn.Shows on your GitHub profile as green ticks.

That alone puts you ahead of most freshers.

🧩 Full Project vs One Module

Student reality:
You build the entire project alone.Frontend. Backend. Database. Everything.

Real world reality:
You own one module.One service. One feature.You integrate with what other teams built.You read code you didn't write.You fix bugs in systems you don't fully understand.

How to close this gap:
Work on team projects.Contribute to open source even small fixes.
Read other people's code intentionally.

Being able to work in an existing codebase is a skill companies desperately need and students almost never practice.

🆓 Free Tools That Make Student Projects Feel Real

You don't need to pay for anything.

What You Need	Free Option
Deployment	Render, Railway, Vercel, AWS Free Tier
Database hosting	PlanetScale, Supabase, ElephantSQL
Email sending	EmailJS, Mailtrap
Authentication	Spring Security, Firebase Auth
API testing	Postman
CI/CD	GitHub Actions
Monitoring	UptimeRobot

All free. All used by real companies.All things you can add to your resume honestly.

What Makes a Student Project Actually Stand Out

Not the tech stack.Not the number of features.Not the UI design.

This:

It is deployed and actually live
It handles edge cases and errors gracefully
It has proper authentication and security
The README explains what it does and how to run it
The code is organized and readable
It solves a real problem someone actually has

That combination is rare among freshers.
And rare means memorable.

Final Thought

You don't need to build a startup.You don't need enterprise architecture.You don't need a team of ten.

You need to build something real enough that when someone asks does this actually work?

You can say yes. Here's the link. Try it yourself.

That confidence comes from building with intention.Not for marks. Not for a resume line.
For the person who might actually use it someday. 😊

What's one thing you added to a student project that made it feel more real?

Or what's something you wish you had done differently?

Drop it below 👇

I Learned REST APIs in College - But Nobody Told Me What They Actually Do

Anushka Shinde — Fri, 12 Jun 2026 07:18:33 +0000

You open Instagram.Your feed loads. You like a post. You follow someone.Every single one of those actions is a REST API call happening behind the screen.

College taught me GET, POST, PUT, DELETE, status codes, endpoints, JSON.I memorized it. Answered exam questions about it.

Then I sat down to build a real project and had no idea how any of it actually connected.

Here's where every REST API concept actually lives in the real world.
Real example first, then the concept, then where to use it.

📱 You open Instagram. Your feed loads with posts.

Concept: GET Request

GET is used to fetch data. Nothing changes. Nothing is created.You are just asking give me this data.

When Instagram loads your feed your app sends a GET request to Instagram's server.Server finds your posts. Returns them.
Your screen displays them.

No data was changed. Just fetched.

Use it when: Loading any page, fetching any list, getting any details user profile, product list, order history, search results.

✍️ You post a new photo on Instagram.

Concept: POST Request

POST is used to create something new.You are sending data to the server save this.

When you post a photo your app sends a POST request with the image and caption.Server saves it to the database.It now exists for everyone to see.

Use it when: User registration, placing an order, submitting a form,adding a product, posting a comment anything that creates new data.

✏️ You edit your Instagram bio.

Concept: PUT and PATCH Request

PUT replaces the entire resource.
PATCH updates only specific fields.

When you edit your bio only the bio field changes.Your name, profile picture, followers untouched. That's PATCH - update only what changed.

PUT would replace your entire profile with the new data.

Use it when:
PUT - replacing an entire record like updating a full user profile.
PATCH - updating one specific field like changing a password or email.

🗑️ You delete a comment on Instagram.

Concept: DELETE Request

DELETE removes something from the server.

When you delete a comment your app sends a DELETE request with the comment ID.Server finds it. Removes it. Gone.

Use it when: Removing any data deleting an account,
cancelling an order, removing a product, clearing a notification.

🔗 Instagram has separate addresses for posts, users, stories, and reels.

Concept: Endpoints

An endpoint is the specific address of a resource on the server.

Every type of data has its own address:
/users — for user data
/posts — for post data
/stories — for stories
/reels — for reels

Clean, specific, predictable addresses.
Each endpoint does one thing for one resource.

Use it when: Designing your project's API —every entity gets its own endpoint./donors, /hospitals, /inventory in a blood bank system./products, /orders, /users in an e-commerce system.

✅ You place an order on Swiggy. Something comes back confirming it worked.

Concept: HTTP Status Codes

Every API response comes with a status code telling you what happened.

200 — Success. Here's your data.
201 — Created. Your new resource was saved.
400 — Bad Request. You sent something wrong.
401 — Unauthorized. You're not logged in.
403 — Forbidden. You don't have permission.
404 — Not Found. That resource doesn't exist.
500 — Server Error. Something broke on our end.

When your Swiggy order confirms the server returns 201 Created.
When you search a restaurant that doesn't exist server returns 404 Not Found.

Use it when: Every API response in your project should return the correct status code not just 200 for everything.

📦 Instagram sends your feed data in a structured format your app can read.

Concept: JSON Response

REST APIs communicate using JSON JavaScript Object Notation.

It's just structured data.Key value pairs.Your app reads it and displays it.

Every API response user details, product info, order status comes back as JSON that your frontend parses and renders.

Use it when: Every API response in your project returns JSON.Spring Boot does this automatically.React reads it and updates the UI.

🔐 You can see your own Zomato orders. You cannot see someone else's.

Concept: Authentication and Authorization in APIs

Authentication — who are you?
Authorization — what are you allowed to do?

When you call /orders on Zomato the API checks your token first.
Are you logged in? That's authentication.Are these your orders? That's authorization.

Without a valid token — 401 Unauthorized.Trying to access someone else's orders — 403 Forbidden.

Use it when: Any API that returns personal or sensitive data needs authentication user profiles, order history, payment info.

📊 The Honest Summary

Real World Scenario	REST API Concept
Feed loads on Instagram	GET Request
You post a new photo	POST Request
You edit your bio	PATCH Request
You delete a comment	DELETE Request
/users /posts /orders addresses	Endpoints
Order confirmed — 201 Created	Status Codes
Data returned in structured format	JSON Response
Only you can see your orders	Authentication and Authorization

Final Thought

Every app you use daily is a collection of API calls.

Open Instagram — GET.
Post a photo — POST.
Edit profile — PATCH.
Delete comment — DELETE.

REST APIs are not a backend concept.They are the language your frontend and backend
use to talk to each other.

Once you see every user action as an API call building full stack applications starts to make complete sense. 😊

Which REST API concept finally clicked for you when you used it in a real project?

Drop it below 👇

I Learned Spring Boot in College - But Nobody Told Me What Each Part Actually Does

Anushka Shinde — Thu, 11 Jun 2026 11:58:47 +0000

You open Zomato. You search "pizza near me."Results appear in milliseconds.

Behind that screen Spring Boot is running.Handling your request. Talking to the database.Sending back the response.All in one smooth flow.

College taught me controllers, services, repositories, beans, autowiring, JPA.I wrote the code. It somehow worked.I had no idea why.

Here's where every Spring Boot concept actually lives in the real world.
Real example first, then the concept, then where to use it.

🛵 You open Zomato. You type "pizza". The app sends a request. Something receives it.

Concept: Controller

The Controller is the entry point of your application.It receives incoming requests and decides what to do with them.

When you search pizza on Zomato a request hits the Controller.The Controller says okay, someone wants pizza results.Let me ask the Service to handle this.

That's it. Controller just receives and delegates.It never does the actual work itself.

Use it when: Every API endpoint in your project lives in a Controller login, register, search, add to cart, place order.

🍕 Zomato checks if the restaurant is open, calculates delivery time, applies discounts.

Concept: Service Layer

The Service is where the actual business logic lives.

Controller received the pizza request.Now Service does the real work is this restaurant open right now?what's the estimated delivery time?does the user have any active coupons?

All the rules and decisions happen here.Service is the brain of your application.

Use it when: Every business rule, calculation, validation, and decision belongs in the Service layer never in the Controller, never in the Repository.

🗄️ Zomato needs to fetch all pizza restaurants from its database.

Concept: Repository

The Repository talks to the database.Nothing else. Just database communication.

Service says I need all pizza restaurants within 5km.Repository goes to the database, fetches them, and returns.

Service doesn't know how the database works.Repository doesn't know why the data is needed.
Each layer does exactly one job.

Use it when: Every database operation save, find, delete, update lives in the Repository. In Spring Boot, JpaRepository gives you all basic operations for free.

📦 Every time a request comes in, Spring Boot already has everything ready. You never create objects manually.

Concept: Beans and Dependency Injection

In Spring Boot you don't create objects with new keyword manually.Spring creates them for you and injects them wherever needed.

These managed objects are called Beans.

Your Controller needs a Service Spring injects it.Your Service needs a Repository Spring injects it.You just declare what you need with @Autowired.Spring handles the rest.

This is Dependency Injection objects are given to you, not created by you.

Use it when: Always. Every Service, Repository, and Controller in Spring Boot is a Bean managed and injected automatically.

🔄 Zomato's order goes through place order, deduct payment, update inventory. All must succeed or all must fail.

Concept: Transaction Management

A transaction is a group of operations that must all succeed together.

If payment is deducted but inventory update fails the system is in a broken state.

Spring Boot's @Transactional annotation handles this automatically.If anything fails midway everything rolls back.
No partial updates. No broken data.

Use it when: Any operation that involves multiple database changes that must succeed or fail together placing orders, transferring money, booking appointments.

🔐 You try to access your Zomato order history. The app checks if you're logged in first.

Concept: Spring Security and Filters

Every request in Spring Boot can pass through filters before reaching the Controller.

Spring Security acts as a gatekeeper.Before your request touches any Controller Security checks is this user authenticated?do they have permission for this endpoint?

If yes ,request goes through.If no , blocked immediately.

Use it when: Any application with login, roles, or protected endpoints needs Spring Security admin panels, user dashboards, payment pages.

⚠️ Something goes wrong in Zomato. Instead of a blank screen you get a proper error message.

Concept: Exception Handling with @ControllerAdvice

When something breaks in Spring Boot @ControllerAdvice catches the error globallyand returns a clean, meaningful response instead of a crash.

Restaurant not found return 404 with a message.Payment failed return 400 with a reason.Server error return 500 with a safe message.

One central place handles all errors across the entire application.

Use it when: Every production application needs global exception handling never let raw errors reach the user.

📊 The Honest Summary

Real World Scenario	Spring Boot Concept
Request comes in from the app	Controller
Business rules and decisions	Service Layer
Fetch or save data to database	Repository
Objects created and managed automatically	Beans and Dependency Injection
All database operations succeed or all fail	Transaction Management
Check if user is logged in before proceeding	Spring Security
Return clean error instead of crash	Exception Handling

Final Thought

Spring Boot feels like magic when you start.Annotations everywhere. Things just work.You have no idea why.

But once you understand each layer's job Controller receives.
Service decides.Repository fetches.Spring manages everything else.

It stops feeling like magic
and starts feeling like a very well designed system.

And well designed systems are the ones you actually enjoy building. 😊

Which Spring Boot concept confused you the most
when you first started?

Drop it below 👇

I Learned OOP in College - But Nobody Showed Me Where It Actually Lives

Anushka Shinde — Thu, 11 Jun 2026 11:52:34 +0000

You order food on Swiggy.Behind that screen there's a User object, an Order object, a Restaurant object.All talking to each other. All built using OOP.

College taught me classes, objects, inheritance, polymorphism, encapsulation, abstraction.I memorized definitions. Drew diagrams. Passed the exam.

Then I sat down to build a real project and stared at a blank file not knowing where to start.

Here's where every OOP concept actually lives in the real world.
Real example first, then the concept, then where to use it.

🧑‍💻 Swiggy has Users, Restaurants, and Delivery Partners. All different. All stored separately.

Concept: Class and Object

A class is a blueprint. An object is the real thing built from that blueprint.

On Swiggy User is a blueprint.
Every person who signs up becomes a new User object with their own name, address, and order history.

Restaurant is another blueprint.
Every restaurant on the platform is a Restaurant object with its own menu, ratings, and location.

Same blueprint. Thousands of different objects.

Use it when: Every entity in your project User, Product, Order, Doctor, Donor becomes a class.

🏥 A hospital system has Doctors, Nurses, and Receptionists. All are Staff. But all do different things.

Concept: Inheritance

When one class inherits properties and behavior from another.

Doctor, Nurse, and Receptionist are all Staff.All have a name, staff ID, and can clock in and out.

Instead of writing those details three times Doctor, Nurse, and Receptionist all inherit from Staff.Each one only adds what makes them unique.

Doctor adds diagnose().
Nurse adds assistSurgery().
Receptionist adds scheduleAppointment().

Use it when: Multiple entities share common properties. Don't repeat yourself inherit instead.

💳 You pay on Swiggy. Sometimes UPI. Sometimes card. Sometimes cash. Same button. Different behavior.

Concept: Polymorphism

Same method name. Different behavior depending on the object.

processPayment() works for UPI, Card, and Cash.You press the same Pay Now button every time. But what happens inside is completely different for each payment type.

That's polymorphism one interface, many forms.

Use it when: Multiple classes do the same thing differently payment methods, notification types, login types, shipping methods.

🔒 You use a banking app. You see your balance. You cannot directly change it from outside.

Concept: Encapsulation

Hide the internal data. Expose only what's needed through controlled methods.

Your bank balance is private.
You cannot just type a number and change it directly.
You have to go through deposit() or withdraw() where rules and validations are enforced.

That protection is encapsulation.

If balance were public anyone could set it to any number.
Making it private and controlled keeps the system honest and secure.

Use it when: Any sensitive data passwords, balances, medical records should be hidden and only accessible through controlled methods.

🚗 You use Uber. You press "Book Ride." You have no idea how the algorithm finds your driver.

Concept: Abstraction

Show only what the user needs. Hide the complex implementation.

You just press Book Ride.You don't see the driver matching algorithm.You don't see the surge pricing calculation.You don't see the route optimization logic.

That's abstraction defining WHAT something does without exposing HOW it does it.

Use it when: You want a clean simple interface hiding complex logic underneath. The user interacts with the surface. The complexity lives inside.

📱 Every Netflix account has a profile. Every profile remembers your watch history separately.

Concept: Constructor

A constructor initializes an object the moment it is created.

When you create a Netflix profile a Profile object is instantly created with your name, preferences, and an empty watch history.

The constructor makes sure no Profile object can exist without the essential information already set.

Use it when: Every entity needs to be created with initial values already set users, profiles, orders, accounts.

📧 Gmail sends millions of emails. It doesn't create a new mail server for each one.

Concept: Static Methods

Static belongs to the class itself not to any individual object.
One copy. Shared by everything.

Utility operations like sending emails, generating unique IDs, formatting dates these don't need a new object created every time.
They live as static methods and are called directly.

Use it when: Helper functions, utility operations, and shared counters that don't depend on individual object state.

📊 The Honest Summary

Real World Scenario	OOP Concept
User, Restaurant, Order on Swiggy	Class and Object
Doctor and Nurse are both Staff	Inheritance
UPI, Card, Cash all process payment	Polymorphism
Bank balance hidden from direct access	Encapsulation
Book Uber without seeing the algorithm	Abstraction
Netflix profile created with instant details	Constructor
Gmail sends emails without new server each time	Static

Final Thought

OOP is not about memorizing definitions.

It's about looking at the real world and asking what are the entities here?what do they share?what makes each one unique?what should be hidden?what should be exposed?

Every app you use daily is already answering those questions.
Swiggy. Uber. Netflix. Gmail. Instagram.

Once you see OOP in the apps around you it stops being exam theory
and starts being how you think. 😊

Which OOP concept finally clicked for you
when you saw it in a real app?

Drop it below 👇

I Learned SQL in College - But Nobody Told Me Where to Actually Use It

Anushka Shinde — Wed, 03 Jun 2026 19:51:33 +0000

You open Swiggy. Your past orders appear, newest first.
That's SQL working silently behind that screen.
College taught me DDL, DML, GROUP BY, HAVING, triggers, cursors, functions, PL/SQL.
I learned all of it. Wrote queries in practicals. Passed the exams.
Then I sat down to build a real project — and had no idea where any of it actually went.
Here's where every concept lives in real projects. Real example first, then the concept, then where to use it.
🛵 You open Swiggy. Your past orders load, newest first.
Concept: ORDER BY
Every sorted list in every app uses ORDER BY behind the scenes.

Use it when: Displaying any list, feed, table, or history in your project.
📝 You register on any app. Your account gets created.
Concept: DML — INSERT, UPDATE, DELETE, SELECT
Every user action triggers DML behind the scenes.

User registers → INSERT
User edits profile → UPDATE
Admin removes record → DELETE
Page loads data → SELECT
Use it when: Literally every user action in your entire application.
📱 Instagram shows how many posts each hashtag has.
Concept: GROUP BY with COUNT

In my LifeFlow project I used this exact pattern — total blood units grouped by blood type, displayed as a Chart.js bar chart for admins.
Use it when: Showing statistics, summaries, reports, or any grouped data.
🔍 You filter — show only categories with more than 10 products.
Concept: HAVING
GROUP BY groups the data. HAVING filters the groups.

Simple rule:
WHERE filters rows before grouping
HAVING filters groups after grouping
Use it when: Filtering based on COUNT, SUM, or AVG results.
🗄️ You set up your database before writing a single line of backend code.
Concept: DDL — CREATE, ALTER, DROP, TRUNCATE

Use it when: Setting up your project database for the first time, or modifying structure as requirements change.
🩸 A donor registers. Blood inventory updates automatically. Nobody wrote extra backend code for it.
Concept: Trigger
A trigger fires automatically when something happens in the database.

Use it when: One table change should automatically update another, or you need audit logs of every change.
🔢 You need donor age calculated in 10 different queries across your project.
Concept: Function
Write it once. Use it everywhere.

Use it when: Same logic repeats across multiple queries and you want clean, reusable SQL.
✅ Your UPDATE ran. But did it actually change anything?
Concept: Implicit Cursor
SQL creates an implicit cursor automatically for every DML statement. SQL%ROWCOUNT tells you how many rows were affected.

Use it when: Checking if your INSERT, UPDATE, or DELETE actually did anything.
📨 You need to send reminders to 500 donors individually.
Concept: Explicit Cursor
When SELECT returns multiple rows and you need to handle each one individually.

Simple rule:
Single row → Implicit cursor
Multiple rows, one by one → Explicit cursor
Use it when: Batch processing, generating reports row by row, or sending bulk notifications.
📊 The Honest Summary
Real World Scenario
SQL Concept
Sorted list loads on screen
ORDER BY
User registers or submits form
DML — INSERT
Analytics dashboard with counts
GROUP BY
Filter groups by count or sum
HAVING
Setting up database tables
DDL
Auto update when data changes
Trigger
Reusable calculation
Function
Check if UPDATE worked
Implicit Cursor
Process rows one by one
Explicit Cursor
Final Thought
Every app you use daily — Swiggy, Instagram, your college portal — is running these exact queries right now.
Once you connect each concept to a real scenario you've seen — it stops being theory and starts being a tool you actually reach for. 😊
Which SQL concept finally clicked when you used it in a real project? Drop it below 👇

Zero Trust Security - Why Companies Trust Nobody, Not Even You

Anushka Shinde — Mon, 01 Jun 2026 10:18:33 +0000

It Started With My Brother's Laptop

During lockdown corona time my brother worked from home on his company laptop.

Sometimes my laptop would die and I'd borrow his.Just to watch YouTube. Nothing serious.

One day I accidentally clicked an ad.A normal Adidas ad.Just a regular advertisement.

Within minutes someone from his company video called him.

"What were you doing?
What were you accessing?"

The company's security system had flagged an unusual link being accessed
outside the normal work pattern.

A normal ad. Caught immediately.

That's when I understood company security is not a joke. And Zero Trust is why.

What Is Zero Trust Security?

Old security thinking was simple:

Build a wall around your network. Everyone inside the wall trusted. Everyone outside blocked.

Like an office building where once you badge in you can walk anywhere freely.

But then the world changed.

Employees started working from home. Apps moved to cloud. People accessed company data from cafes, homes, phones.

The "wall" stopped making sense.

Zero Trust said forget the wall.

Trust nobody automatically. Verify everyone. Every time. For every resource. Every access.

Even if you're inside the network prove who you are.Even if you're on the company laptop verify again. Even if you accessed this yesterday verify again today.

Zero Trust. Means exactly that.Nobody gets automatic trust.

You've Already Experienced This

Every time you:

Login and still need an OTP
Use VPN to access company resources
Get asked to verify again even on a trusted device
See "suspicious activity" warnings

That's Zero Trust in action.

Your company's Wi-Fi tracks every site you visit. Your VPN monitors every connection. Your company laptop flags unusual behavior.

Not because they don't trust you personally.Because the system trusts nobody and that's what keeps everyone safe.

The Fired Employee Problem

Here's something that happens more than companies admit.

When an employee gets fired they sometimes share their access credentials with someone outside.

In service companies especially where contractors access sensitive
client systems this is a massive security risk.

Zero Trust minimizes this damage.

Because even if someone has stolen credentials they still can't access everything. Each resource requires separate verification. Access is limited to only what's needed. Unusual behavior gets flagged immediately.

One stolen password can't unlock everything. That's the point.

The Hacking Story That Stayed With Me

An alumni came to my college once. He worked at a well-known firm.

He told us one of their systems got hacked. The hacker had the data.
Was demanding money. A ransom.

But the company had something a blockchain based backup system. Same data stored across multiple locations worldwide. Decentralized. Redundant. Tamper resistant.

The company accessed their own data through the blockchain system.
Changed the security credentials. And told the hacker

"Do whatever you want with what you have. We won't pay."

The hacker had nothing left to threaten with. The company had already secured themselves.

Days later the hackers were caught. The data was never leaked.

Security awareness saved that company. Not luck. Preparation.

My Mock Interview Answer

In a mock HR interview at my college I was asked a scenario based question:
"As a software developer what can you do for society that makes a real difference?"

My answer was immediate:

As a developer my core responsibility is to build robust, secure applications that are not just hard to hack but genuinely protected.

When I deliver a product to a client I should be able to confirm:
This is secured. This is robust. This will protect your data.

Because when developers cut corners on security real people pay the price. Real data gets leaked. Real companies get ransomed. Real lives get affected.

Security is not a feature.It's a responsibility.

What Zero Trust Means for Developers

As developers we build the systems people depend on.

Zero Trust principles we should build into every application:

Verify explicitly
Always authenticate and authorize. Never assume someone is who they say they are just because they logged in once.

Least privilege access
Give users only the access they need. Nothing more. A customer shouldn't access admin panels. An intern shouldn't access production databases.

Assume breach
Design your system assuming someone will get in someday. Limit the damage they can do when that happens.

Monitor everything
Log every access. Every unusual pattern. Like my brother's company caught an accidental ad click good systems catch real threats the same way.

Final Thoughts

Security used to be about building walls.

Zero Trust says walls are not enough anymore.

The threats are inside and outside. Former employees. Accidental clicks.
Stolen credentials. Ransomware.

The only answer is trust nobody automatically. Verify everything continuously. Limit access ruthlessly. Monitor constantly.

As a developer entering this industry understanding security is not optional.

The most brilliant application means nothing if it can be compromised in minutes.

Build secure. Always. 😊

Have you ever experienced a security incident even a small one? Or built something where security was a real concern?

Drop it in the comments 👇And if you're a developer who has worked with Zero Trust principles share how you implemented it!

WebAssembly - Why Your Browser Can Finally Do What Desktop Apps Could

Anushka Shinde — Sun, 31 May 2026 14:44:08 +0000

We've All Been There

You open a government portal.
Urgent form to fill.The page loads. Slowly.You click. It freezes.You refresh. You wait.
Still doesn't work.

Every student knows this feeling.

Then I discovered WebAssembly.
And suddenly everything made sense.

What Is WebAssembly?

Browsers only understand JavaScript.Always have.

WebAssembly lets browsers run code written in OTHER languages
C++, Rust, Java at near native speed.

Near native means as fast as apps running directly on your computer.

Not slowed down by browser limits.
Just fast.

Where You've Already Seen It

Figma -runs entirely in browser. Fast.
Google Earth -3D globe in a tab.
Games and video editors- in browser.

All previously impossible for browsers.WebAssembly made them real.

How It Works -Simply

You write code in C++ or Rust.
Compile it to WebAssembly format.
Browser runs it alongside JavaScript.

JavaScript handles UI.WebAssembly handles heavy work.Both together powerful.

Is JavaScript Dead?

Not at all.

JavaScript = everyday web tasks.
WebAssembly = heavy, performance critical work.

They're teammates. Not competitors.

Why You Should Care

WebAssembly is expanding beyond browsers into cloud computing and edge computing too.

Understanding it now puts you ahead of developers who still think browsers are only for JavaScript.

The gap between websites and desktop apps is closing fast.

WebAssembly is why. 😊

Ever used something surprisingly fast
in a browser?
Or struggled with a painfully slow portal?

Drop it below 👇

Edge Computing - Why the Cloud Is Moving Closer to You

Anushka Shinde — Sat, 30 May 2026 12:43:31 +0000

I First Heard About This in My AWS Course

When I was going through AWS Cloud Practitioner Essentials one concept caught my attention.

Edge Computing.

It sounded simple at first. "Processing happens closer to the user."

But the more I understood what that meant the more I realized how fundamentally it changes everything we know about how the internet works.

First-What Is Cloud Computing?

Before edge computing makes sense let's quickly understand regular cloud.

Traditional cloud computing means:Your device sends a request →Request travels to a data center
somewhere far away →Data center processes it →Response travels back to you.

This works great for most things.
But it has one problem.

Distance takes time.And time to in technology is everything.

What Is Edge Computing?

Edge computing moves the processing closer to where the data is created.

Instead of sending everything to
a far away data center some processing happens right there.At the "edge" of the network.

On the device itself.On a local server nearby.On a router. A gateway. A base station.

The edge is wherever the data originates.And processing at the edge meansfaster response, less data traveling,less load on the central cloud.

Why Distance Actually Matters

Let me give you a real example.

Self driving cars.

A self driving car generates
massive amounts of data every second.Camera feeds. Sensor readings. GPS data. Traffic detection.

If that car had to send all that data to a cloud server and wait for instructions even a 100 millisecond delay could mean the difference between stopping safely and an accident.

100 milliseconds.Less than the blink of an eye.But enough to be catastrophic.

Edge computing processes that data instantly right there in the car.No waiting for a distant server.No network dependency.Just immediate decisions.

More Real World Examples

Smart hospitals
Patient monitoring devices that detect emergencies instantly without waiting for data to reach a cloud server.Milliseconds matter in medical emergencies.

Manufacturing plants
Machines that detect defects in real timeon the production line.
Stopping a faulty product immediately not after the data travels to a server and comes back.

Smart cities
Traffic lights that respond to
real time traffic flow.Cameras that detect incidents instantly.
Systems that don't depend on
internet connectivity to function.

Gaming
Cloud gaming requires ultra low latency.Edge servers placed closer to players reduce lag and make real time gaming possible.

Retail stores
Smart shelves that detect when
products run low instantly.No waiting for central server processing.

Cloud vs Edge Not Enemies

Here's something important to understand.

Edge computing is not replacing cloud.They work together.

Think of it like this:

Cloud the brain far away.
Handles heavy processing, storage,analytics, machine learning, long term data management.

Edge the nervous system nearby.Handles immediate reactions,real time processing,
time sensitive decisions.

Your phone is actually an edge device.When Face ID recognizes your face that processing happens on your phone.Not on Apple's servers.That's edge computing.

Why AWS Talks About This

In my AWS Cloud Practitioner course AWS introduced services like:

AWS Wavelength
Brings AWS compute and storage
to the edge of 5G networks.Ultra low latency applications for mobile and connected devices.

AWS Outposts
Brings AWS infrastructure to your own data center or location.Run AWS services on premise at the edge of your own network.

Amazon CloudFront
Content delivery network that
caches content at edge locations worldwide.When you load a website fast from anywhere in the world CloudFront is often why.

Why This Matters for Freshers

Edge computing is not a future concept.It's happening right now.

5G networks are expanding globally.IoT devices are everywhere.AI is moving to edge devices.Every industry is generating more real time data than ever before.

Companies need developers who understand:

When to process at the edge vs cloud
How to build applications for low latency environments
How edge and cloud work together
Security implications of distributed processing

This is a growing skill gap.
And freshers who understand it early have a real advantage.

Research Paper Topics

For Cloud Computing:

Latency comparison between edge and cloud processing for IoT applications
Security challenges in edge computing environments

For Networks:

Edge computing in 5G network architecture
Bandwidth optimization using edge processing

For AI/ML:

Federated learning at the edge training AI models without sending data to central servers

For Healthcare:

Edge computing for real time patient monitoring systems

Final Thoughts

The cloud moved computing
from your desk to a distant server.

Edge computing is bringing it back not all the way to your desk but close enough to matter.

Close enough to save lives in hospitals.Close enough to make self driving cars safe.Close enough to make your gaming
experience seamless.

The future of computing is not just in giant data centers far away.

It's distributed. It's local.It's fast.It's at the edge. 😊

Have you worked with any edge computing concepts in your projects or studies?

Or have you used any AWS edge services?Drop your experience below 👇

Would love to know how students
are connecting with this topic!

How I Built a Resume That Actually Gets Shortlisted - The Honest Messy Journey

Anushka Shinde — Fri, 29 May 2026 18:05:20 +0000

My First Resume Was Embarrassing

I'll be honest.

My first resume was someone else's resume with my name on it.

I found a template on Overleaf.
Replaced the person's name with mine.Added my basic education details.Added some skills I barely knew.No projects. No certifications. No experience. Nothing real.

That was it.That was my first resume.

And I sent it out thinking it was fine.

How It Started Getting Better

I made a LinkedIn account.

And suddenly I was seeing resumes
that made mine look like a rough draft.

People were talking about ATS scores. About what Google prefers .What Microsoft looks for.
What gets shortlisted vs what gets ignored.

I started paying attention.

And slowly one project at a time,
one certificate at a time,one skill at a time my resume started filling up with real things.

Not borrowed things.
Mine.

The Fake Instagram Account Nobody Knows About

Okay. Here's something I've never told anyone.

I made a fake Instagram account.

Not for anything weird.To follow tech people without mixing it
with my personal life.

Recruiters who had hired people.
Developers who worked at big companies.Career coaches who guided freshers for free.

I used to comment on their posts.
Ask questions. Take notes.Learn from people who had actually
been on the other side of hiring.

One day a woman caught me.She noticed my Instagram ID and my resume didn't match at all.

I was honest with her.She was completely fine with it.

And she guided me more than
any YouTube tutorial ever did.

Here's what I learned from that experience

Tech people who have established careers genuinely want freshers to succeed.They are not trying to pull you down.They share knowledge freely because someone once helped them too.

Don't be afraid to reach out.
Even with a fake account. 😅

What I Actually Did to Build My Resume

Step 1 - I built things first
You cannot have a good resume
with nothing to put in it.

I built 8 to 9 projects over time.Then I selected the best 4 to showcase.Not all of them. The ones that told the strongest story.

Step 2- I was ruthless with certifications
I had 10 to 15 certifications.
I asked Claude and ChatGPT "Out of these, which ones actually
matter to recruiters right now?"

Both gave similar answers.I kept only those.The rest dropped.

No point cluttering your resume
with certifications nobody recognizes.

Step 3 — I only added skills I could answer for
This was the most important rule.

I took ChatGPT's suggestions to Claude.Took Claude's suggestions back to ChatGPT.Cross referenced both.

And then added only the skills
I could genuinely answer questions about in an interview.

Because a skill on your resume
is an invitation for the interviewer to ask you about it.

Don't invite questions you can't answer.

Step 4 — I humanized everything
AI suggestions are a starting point.Not the final version.

Everything AI helped me write I rewrote in my own words.My own tone. My own voice.Something that sounded like me not like a template.

Step 5 — I showed it to real people
My brother. LinkedIn connections.
Instagram recruiters. College workshops.

Every set of eyes caught something the previous ones missed.

The Moment I Knew I Was on the Right Track

My college had a CV writing workshop.

I saw BTech students' resumes.
Computer engineering students' resumes.

And I realized my resume was actually better.

Not because I'm smarter.Because I had been learning from the updated world not waiting for someone to make a YouTube video about it.

I talked to real recruiters.Real developers. Real people.And I kept updating. Keep improving.

What Your Resume Actually Is

Your resume is not a document.

It is evidence.

Evidence that you built real things.Evidence that you learned real skills.Evidence that you are worth 30 minutes of someone's time.

A weak resume doesn't mean you're a weak developer.It means your evidence isn't showing yet.

Start building the evidence.
Then let your resume tell that story.

What I'd Tell My Past Self

Start with any template. Just start.
Build projects even when nobody asks you to.
Add only what you can defend in an interview.
Ask real people not just AI, not just YouTube.
Update it every single semester.
Compare it to others not to feel bad but to know where to improve.
Your resume will never be perfect .But it can always be better than yesterday.

Final Thought

I went from copying someone else's name off an Overleaf template to having a resume that got shortlisted when better coders didn't.

Not because I'm the most talented person in the room.

Because I treated my resume like a project.I iterated. I improved. I asked for help.I kept building the evidence.

That's all it takes. 😊

What's the biggest resume mistake
you made as a fresher?

Drop it below 👇
Let's help each other avoid the same ones!

Impostor Syndrome in Tech - The Honest Version Nobody Posts About

Anushka Shinde — Thu, 28 May 2026 16:57:21 +0000

Let Me Tell You Something Embarrassing

I got selected for a placement opportunity at my college.

Out of everyone including people who code better than me, people with better grades,people who I genuinely thought deserved it more

I got selected.

And my first thought wasn't excitement.

It was "why me?"

What Impostor Syndrome Actually Feels Like

Not the LinkedIn version where someone says"I still feel like I'm learning every day!"

The real version.

The version where you see someone's resume and feel your stomach drop.Where you pass an interview and think "they made a mistake."Where you build a project and feel guilty because AI helped you write the code. Where you have certifications but know that lakhs of other students have the same ones.Where nothing feels unique enough.Where nothing feels like enough.

That version.

The Placement That Confused Me

A company came to my college.
They wanted resumes.They shortlisted fifteen to twenty people.

Some of the best coders in my batch didn't get shortlisted.
Maybe their resume structure wasn't right.Maybe it was luck.
Maybe the system is just that unpredictable.

But I got selected.

And then I got the internship opportunity.

When I went the experienced people there were genuinely impressed.Not by my grades. Not by my CGPA.By my curiosity.

The fact that I touched different technologies not because my syllabus demanded it but because I wanted to know what they felt like.

That meant something to them.

And in that moment I realized a lot of people don't know what I know.Just like I don't know what a lot of people know.

Nobody is complete.
Not even the seniors.

The AI Guilt Nobody Admits

Here's something I've never seen
anyone write about honestly.

Most of my projects I choose the idea.I design the system. But the development phase?AI writes a significant portion of the code.

And I feel guilty about it every single time.

Like I didn't really build it.
Like if someone looked closely enough they'd see the seams.
Like I'm presenting something as mine that isn't fully mine.

But here's what I've slowly started understanding —

I chose what to build.I understood the problem.I designed the solution.I knew when something was wrong.I explained it to experienced people
and they were impressed.

The tool doesn't define the builder.A carpenter who uses a power drill didn't build less than one who used a hand saw.

The guilt is real.But so is the work.

The Certification Trap

I look at my certifications and think thousands of people have these exact same ones.

IBM. AWS. HackerRank.Every student is collecting them.
Every resume looks the same.

What makes mine different?

And then I remember certifications are not the proof.
What you do with the knowledge is.

The person who completed AWS certification and then wrote a blog post explaining cloud cost optimization to other students that person stands out.

Not because of the certificate.
Because of what they did after.

The JavaScript Confession

I don't like JavaScript.

I said it.

It doesn't feel logical to me.
The syntax feels inconsistent.
PHP feels similar rules that don't always make sense.

In one interview they asked me JavaScript questions.I told them honestly "I learned it in bachelor's but I'm not
comfortable with it right now."

They said "That's fine. We work with JavaScript a lot here.It's actually the language behind React, TypeScript, Angular."

And I felt small for a second.
Because I use React.And I don't like the language it's built on.

But they weren't bothered.
They valued the honesty more than the knowledge.

The Jealousy That Actually Helps

Someone in my batch built something I wish I had built.

I won't call it pure jealousy.
It was jealousy mixed with curiosity mixed with a fire that said I want to build something better than that.

And that feeling uncomfortable as it is is the most productive feeling I've ever had as a developer.

When someone is better than me I don't want to bring them down.I want to reach their level.And then go further.

That jealousy became projects.
Those projects became my portfolio.That portfolio got me selected.

What I Know Now

Someone will always be better than you.Always. In every room. At every level.

Even when I join a company I'll look at seniors and think "they know so much more than me."

And that will light a fire.And I'll learn everything they know. And then I'll want to know more.

That's not impostor syndrome winning.That's impostor syndrome becoming fuel.

The difference between developers
who grow and developers who freeze is what they do with that feeling.

Freeze and you stay stuck.Move anyway and the feeling slowly starts to feel less like fear
and more like direction.

Final Thought

You are not a fraud.

You are someone who hasn't learned everything yet.
Nobody has.
Nobody ever will.

The impostor feeling means you care.It means you have standards.
It means you know there's more to learn.

That's not a weakness.
That's exactly the kind of person
a good company wants to hire. 😊

When did you last feel like an impostor?
And what did you do with that feeling?

Drop it honestly below 👇
Not the polished version.
The real one.

Why Every Developer Needs a Digital Presence in 2026 - Even If It Feels Like Showing Off

Anushka Shinde — Tue, 26 May 2026 09:45:32 +0000

I Used to Find LinkedIn Annoying

When I first joined LinkedIn in 2024 I was frustrated.

Everyone was posting about:What they learned.What they achieved.
What certifications they got.
What companies they interviewed at.

It felt like showing off.It felt performative.It felt like nobody was being real.

And then I realized something
that changed how I see everything.

Companies Are Watching

When a company looks for an employee they don't just look at your resume.

They look at your LinkedIn.
Your GitHub.Your blog.Your online presence.

And what they're looking for is not just your skills they're looking for a social animal.

Someone who communicates.
Someone who shares knowledge.
Someone who shows up consistently.Someone who is active, engaged, and present in their field.

Because here's the truth when that employee represents the companyin front of a foreign team,a foreign client,an international stakeholder

They need someone with:
Good communication.Good values.
Good understanding of their field.And proof that they can present themselves well.

Your digital presence is that proof.

The Shift That Changed Everything for Me

Once I understood WHY people post the frustration disappeared.

They're not showing off.They're building evidence.

Evidence that they know things.
Evidence that they're growing.
Evidence that they're worth hiring,worth collaborating with,
worth trusting with real work.

And when I started building my own GitHub with real projects,
DEV.to with honest blogs,
LinkedIn with actual achievements
I stopped feeling invisible.

What Digital Presence Actually Means

It doesn't mean posting every day.It doesn't mean fake achievements.It doesn't mean pretending to be someone you're not.

It means showing what's real.

GitHub shows you actually build things.Not just talk about building them.

DEV.to or any blog shows you can explain what you know. Explaining something well proves
you understand it deeply.

LinkedIn shows your professional journey.Where you've been. What you've learned.Who you've worked with.

Together they tell a story
no resume ever could.

The Developer Who Gets Hired

Two freshers. Same skills. Same college.Same tech stack. Same CGPA.

One has:

GitHub with 3 real projects
10 blog posts about what they built
Active LinkedIn with certifications posted
A digital trail that proves their journey

One has:

A resume
Nothing else

Who gets the callback?

You already know the answer.

The Uncomfortable Truth About Staying Silent

Staying quiet about your achievements doesn't make you humble.

It makes you invisible.

In a world where hundreds of freshers are applying for the same role the ones who are visible online have already won half the battle before the interview even starts.

Your skills are real.Your projects are real.Your journey is real.

But if nobody can see them they might as well not exist.

What to Start With — Today

You don't need to do everything at once.

Start with one thing:

If you have projects push them to GitHub.If you have certifications add them to LinkedIn.If you have experiences write one honest blog post.

That's it.One thing.Build from there.

The goal is not to become a LinkedIn influencer.The goal is to make sure that when a recruiter searches for someone like you they find you.

And when they find you they see someone real,someone consistent,
someone worth reaching out to.

Final Thought

I used to think digital presence was for people who loved attention.

Now I understand it's for people who want opportunities.

In 2026 your skills get you in the room.Your digital presence gets you the invite.

Start building yours. Even if it feels uncomfortable.Even if it feels like showing off.

Because somewhere right now a recruiter is searching for someone with exactly your skills.

Make sure they can find you. 😊

When did you realize digital presence matters?
Or are you still on the fence about it?

Drop your honest take below 👇