DEV Community: Sourav Dey

LeetCode #376: Wiggle Subsequence

Sourav Dey — Tue, 31 Mar 2026 13:59:03 +0000

LeetCode Question - 376. Wiggle Subsequence 🧠

About the Series

Problem-solving is a key skill set for any tech-related stuff you might be working on.

When it comes to developers it's one of the most crucial skills which is needed in almost any day-to-day code you might be writing.

So, this series of blogs is all about practicing Daily LeetCode Challenges & Problem-solving. 🚀

Earlier in this series: LeetCode #1465: Maximum Area of Cake After Cuts.

Problem Statement

Wiggle Subsequence

A wiggle sequence is a sequence where the differences between successive numbers strictly alternate between positive and negative. The first difference (if one exists) may be either positive or negative. A sequence with one element and a sequence with two non-equal elements are trivially wiggle sequences.

For example, [1, 7, 4, 9, 2, 5] is a wiggle sequence because the differences (6, -3, 5, -7, 3) alternate between positive and negative.

In contrast, [1, 4, 7, 2, 5] and [1, 7, 4, 5, 5] are not wiggle sequences. The first is not because its first two differences are positive, and the second is not because its last difference is zero. A subsequence is obtained by deleting some elements (possibly zero) from the original sequence, leaving the remaining elements in their original order.

Given an integer array nums, return the length of the longest wiggle subsequence of nums.

Video Explanation

Watch on YouTube

Solution

Algorithm

First check if the length of the nums array is smaller than two or not. If yes, we will simply return the length of the array ie. 0 for [] and 1 for [x] (where x can be any value)
We check the first difference between the 1st from the 0th value in the nums array and store it in the previousdiff
If the values are not equal we will count both the no. for the wiggle sequence thus our counter will be 2 and if equal we take our counter to be 1
Now, While iterating the nums array we will compare the compare current difference and the previous difference. If one is positive the other should be negative or vice versa. Now, we will increment the count if the conditions are satisfied and update the previous difference with the current difference.
Finally return the count of the wiggle sequence.

Code in JS 🧑‍💻

/**
 * @param {number[]} nums
 * @return {number}
 */
var wiggleMaxLength = function (nums) {
  if (nums.length < 2) {
    return nums.length;
  }
  var previousdiff = nums[1] - nums[0];
  var counter = previousdiff != 0 ? 2 : 1;

  for (var i = 1; i < nums.length; i++) {
    const currentDiff = nums[i] - nums[i - 1];
    if (
      (currentDiff > 0 && previousdiff <= 0) ||
      (currentDiff < 0 && previousdiff >= 0)
    ) {
      counter++;
      previousdiff = currentDiff;
    }
  }
  return counter;
};

Time Complexity : O(n)

Space Complexity: O(1)

You can find me on the web 🌍

Add your solution or approach in the comments below. Also, show your love by Sharing the blog. 🤗

"Dream big. Start small. But most of all, start."

~ Simon Sinek

Originally published on July 3, 2022 at souravdey.space.

LeetCode #1465: Maximum Area of Cake After Cuts

Sourav Dey — Tue, 31 Mar 2026 13:59:01 +0000

LeetCode Question - 1465. Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

About the Series

Problem-solving is a key skill set for any tech-related stuff you might be working on.

When it comes to developers it's one of the most crucial skills which is needed in almost any day-to-day code you might be writing.

So, this series of blogs is all about practicing Daily LeetCode Challenges & Problem-solving. 🚀

Earlier in this series: LeetCode #1710: Maximum Units on a Truck.

Problem Statement

Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

You are given a rectangular cake of size h x w and two arrays of integers horizontalCuts and verticalCuts where:

horizontalCuts[i] is the distance from the top of the rectangular cake to the ith horizontal cut and similarly, and

verticalCuts[j] is the distance from the left of the rectangular cake to the jth vertical cut.

Return the maximum area of a piece of cake after you cut at each horizontal and vertical position provided in the arrays horizontalCuts and verticalCuts. Since the answer can be a large number, return this modulo 109 + 7

Video Explanation

Watch on YouTube

Solution

Algorithm

Push 0 and h in the horizontalCuts.
Sort the horizontalCuts array in Ascending Order.
Take the maximum difference between the cuts by iterating on the list of horizontalCuts
Push 0 and h in the horizontalCuts.
Sort the horizontalCuts array in Ascending Order.
Take the maximum difference between the cuts by iterating on the list of horizontalCuts
Multiply both the max values and return the modulo 10^9 + 7
Now, we got the largest piece of Cake 🍰

Code in JS 🧑‍💻

/**
 * @param {number} h
 * @param {number} w
 * @param {number[]} horizontalCuts
 * @param {number[]} verticalCuts
 * @return {number}
 */
var maxArea = function (h, w, horizontalCuts, verticalCuts) {
  horizontalCuts.push(0, h);
  horizontalCuts.sort((a, b) => a - b);
  var maxH = 0;
  verticalCuts.push(0, w);
  verticalCuts.sort((a, b) => a - b);
  var maxW = 0;

  for (var i = 1; i < horizontalCuts.length; i++) {
    maxH = Math.max(maxH, horizontalCuts[i] - horizontalCuts[i - 1]);
  }

  for (var j = 1; j < verticalCuts.length; j++) {
    maxW = Math.max(maxW, verticalCuts[j] - verticalCuts[j - 1]);
  }

  return (BigInt(maxH) * BigInt(maxW)) % BigInt(1e9 + 7);
};

Time Complexity : O(nlogn)

Space Complexity: O(1)

You can find me on the web 🌍

Add your solution or approach in the comments below.

Show your love by Sharing the blog. 🤗

“The best way to predict the future is to create it.”

~ Peter Drucker

Originally published on July 2, 2022 at souravdey.space.

Product Engineering: The Only Skill That Survives AI 🏗️

Sourav Dey — Mon, 30 Mar 2026 08:16:54 +0000

I've been building customer-facing products for seven years now. From the Test Creation Experience used across 1.9M+ tests at HackerRank to GPT-4o powered features in production, I've seen what separates products that stick from those that get shelved after three months of development.

Here's what I've learned: the only limitation in the AI era is product thinking.

The AI Acceleration Problem

Everyone's talking about AI making us 10x faster. Write a prompt, get a component. Describe a feature, get working code. The demos are compelling. The productivity gains are real.

But here's what nobody's talking about: speed without direction is just expensive motion.

I see engineers shipping faster than ever and wondering why their features don't land. They can build anything now. The question they can't answer is: what should I build? 🤔

That gap is product engineering.

What Product Engineering Actually Means

Product engineering isn't about choosing React over Vue. It's not about microservices architecture or deployment pipelines.

Product engineering is building with the user's problem as your north star, not the technology.

Back in 2023, I was discussing my promotion with my manager at HackerRank. Around the same time, I stumbled upon Gergely Orosz's The Product-Minded Software Engineer on The Pragmatic Engineer blog. Reading it felt like someone had written down exactly what I do. Every trait he described, from proactive product ideas to end-to-end feature ownership, mapped to how I have been working for years. That article became my pitch for the promotion. I've never been the strongest "pure coder" in the room, but I've always been a solid product engineer. That's what sets me apart 💪 There is another book on this, The Product-Minded Engineer (November 2025) by Drew Hoskins, and it reinforces the same core truth: the engineers who have the most impact are the ones who care deeply about the product, not just the code.

When we built the Test Creation Experience at HackerRank, the engineering challenge wasn't the hardest part. The hard part was understanding that recruiters weren't failing to create tests because our UI was clunky. They were failing because they didn't know what good technical questions looked like in the first place.

The feature that moved the needle wasn't better form validation. It was a question recommendation engine that suggested problems based on the role they were hiring for.

Product engineering is seeing the gap between what users say they want and what they actually need.

For the longer career arc behind that idea, see seven years as a software engineer. For shipping under a brutal clock with a product-shaped goal.

Why AI Makes This More Critical, Not Less

In 2019, if you wanted to build a feature, you needed to:

Design the database schema
Write the API endpoints
Build the frontend components
Handle edge cases and error states
Deploy and monitor

That took weeks. The friction forced you to think: is this worth building?

In 2026, I can describe a feature to Claude and have working code in 20 minutes. The friction is gone. The forcing function for good judgment disappeared. 🫠

Now anyone can build anything. The engineers who survive aren't the ones who can prompt better. They're the ones who know what's worth building.

The Obsession With "Great Engineering"

I've worked with brilliant engineers who could optimize a database query from 200ms to 15ms, architect systems that handle millions of requests, and debug race conditions in distributed systems.

Some of them built features nobody used. 😅

The ones who had impact? They started every conversation with: "What problem are we solving, and for whom?"

They asked questions like:

Who specifically has this problem?
How do they solve it today?
What would make them change their workflow?
How do we know if we fixed it?

Those questions matter more than knowing the latest JavaScript framework.

My Product Engineering Principles

After seven years and dozens of shipped features, here's what I've learned:

1. Fall in love with the problem, not your solution.
I've killed features I spent months building because user research showed we were solving the wrong problem. It hurt. But shipping the wrong thing perfectly is worse than not shipping at all.

2. Build for one person first.
Every successful feature I've shipped started with understanding one specific user's workflow in detail. Generic "user personas" don't build products. Real humans with real problems do.

3. The best code is code you don't write.
Before building anything, ask: what's the simplest thing that could work? Half the features I thought I needed to build turned out to be configuration changes.

4. Measure behavior, not opinions.
Users will tell you they want feature X. Then you build feature X and nobody uses it. Watch what they do, not what they say they'll do.

The AI Era Divide

I predict a split in our industry:

AI-Assisted Code Writers: Fast at implementation, focused on technical craft. They can build anything you spec out.

Product Engineers: Focused on what to build and why. They use AI as a tool to ship faster, but they're solving the right problems.

Both roles matter. But if you're building customer-facing products, you need to be in the second category.

The companies that win in the AI era won't be the ones with the best AI engineers. They'll be the ones with the best product engineers who happen to use AI. 🚀

What I'd Do Differently

If I were starting my career today, I wouldn't spend time learning every new framework or AI tool that comes out.

I'd spend time with users. I'd sit in customer support calls. I'd read every piece of feedback. I'd understand how people actually work, not how I think they should work.

The frameworks change every two years. Understanding humans compounds forever.

Product engineering isn't a nice-to-have anymore. In the AI era, it's how you stay relevant.

The future belongs to engineers who can think like builders, not just coders. AI will handle the coding part. The building part still needs humans. ✨

Originally published on March 30, 2026 at souravdey.space.

7 Years as a Software Engineer: What Actually Changed 💼

Sourav Dey — Wed, 25 Mar 2026 14:10:14 +0000

Green build. Staging fine. I still walked away feeling off 💻

The code did what we agreed on. The agreement was the broken part. That week stuck with me more than any refactor I have shipped since.

Seven years in, I still write code. I also still Google things I have looked up a hundred times, and I am fine admitting that. The job stopped being mostly syntax ages ago. It moved into requirements nobody wrote down, roadmaps that pretend six things are one thing, and the gap between what product imagines and what the system can honestly do. You feel that gap in your calendar before you feel it in the compiler.

I am not going to give you a promotion timeline or a framework bingo card.

Here is what moved in how I work, and what I would say to the version of me who was scared of sounding dumb in standup 🙈

🧭 The first shift: when “it runs” is not the win

Early on I treated success like a checklist. Tests pass ✅ PR merged. Done. That bar matters. You cannot skip it.

The first time it failed me was ordinary. Everything behaved in staging, users were still unhappy, and the bug was the assumption behind the feature, not a null pointer.

These days I slow down before I type. Who is this actually for? What happens at 10x traffic? What is the cheapest way to prove we are wrong? I used to think those questions were someone else’s job.

They are the job 🎯

Hackathons taught me scope is the real villain 🏃 Side projects taught me demos follow their own physics. HackerRank taught me the expensive problems sit between intent and reality. Same muscle, different costumes.

🌫️ Ambiguity stopped feeling like a personal failure

Junior me assumed if I asked enough questions in one Slack thread, uncertainty would pack up and leave.

It does not work that way. Some fog only lifts after there is a real thing to poke at.

I stopped pretending I had it all figured out on day one. I try to pick a step we can undo, say the tradeoff out loud, and invite correction early. A rough prototype still beats a three-day thread. A written assumption beats a silent guess every time ✍️

I mentored at a hackathon once (notes from CentuRITon), on the other side of the table. The struggling teams were rarely lazy. They were drowning in parallel goals 🌊 Helping them kill features felt like coaching courage, not debugging. I still use that instinct when a roadmap tries to ship six epics like they are one.

⚖️ Speed, quality, and the lie of having both for free

You have heard both sermons.

Move fast and break things. Quality is non-negotiable. Real teams live in the middle and rarely say the quiet part out loud.

What helped me was naming the tradeoff in a room full of people. If we optimize for learning speed, we accept rough edges and we instrument them. If we optimize for reliability, we skip shortcuts and we staff for that choice. The painful failure mode is when leadership says one priority and the calendar and incentives say another. Then you get slow and brittle together.

No prize 💥

I still misread that alignment sometimes. I just catch it faster.

Sounds tiny. It cost a lot of Tuesday evenings to get there 🩹

💬 Communication is not fluff. It is part of the ship.

I am not the person who “only wants to code.” Not because I love calendars 📅 Because when alignment drifts, it shows up as reverts, sharp tickets, and that quiet distrust nobody puts in writing.

A decent PR description. A diagram someone can find next month. A short note on why we picked this shape. Those things feel soft until you pay for not having them.

When I built this portfolio in public, I realized people read the thinking, not only the pixels. Same thing shows up in code review and design feedback. They are judging whether they can trust your judgment.

🧠 Competence and confidence refuse to stay in sync

Call it imposter syndrome or call it a brain that loves your mistakes more than your wins.

Same glitch.

I stopped waiting for the doubt to vanish. I keep boring receipts now. What shipped. What broke. What I fixed. What someone else shipped because I unblocked them.

Loud moments under pressure helped once. They do not cure anything. They just remind you that you have done hard things before. Without the small receipts, one bad deploy on a random Tuesday eats the whole story 📉

🧰 What actually aged well

Syntax turns over. Tools churn 🔄

The skills that kept paying were unglamorous. Reading a stack trace without ego. Tracing a bug across services and saying which layer lied 🐛 Knowing when a library saves time and when it hides the learning you still need.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

— Martin Fowler

I still enjoy a gnarly bug.

I enjoy it less when the gnarl exists because nobody wrote how the system is supposed to behave. Docs are not admin homework. They are kindness to whoever is on call at 11 PM 🌙 Future you counts.

🤝 Leadership without the title

Influence is not a level on a ladder.

It shows up in a clearer ticket, a safer rollback plan, a review comment that teaches instead of scores points. Sometimes it is saying I do not know when everyone else is improvising confidence 🤷

I have spent five years at HackerRank now 🌱 Sustained product engineering, for me, is not heroics. It is ownership. It is the quiet work of keeping a platform understandable while it grows.

✉️ What I would tell past me

Ask earlier. Ship smaller. Write down why you chose something, not only what you built.

Guard your attention the way you guard uptime, because it is the same finite resource.

Busy is not the same as useful. I am still learning that last one ⏳

🪨 What still feels hard

Saying no without becoming the villain in someone else’s story. Estimating when the information is incomplete, without faking precision. Staying curious when the backlog is shouting. Remembering the win is not owning the thread. It is leaving the system less confusing than you found it.

Seven years is not mastery 🎓

It is enough repetitions to spot the same traps: fake urgency, complexity sold as intelligence, teams confusing motion for progress. Enough time, too, to feel grateful for people who raised the bar 🙏 and a little gentler with myself when I was the bottleneck.

If you are earlier in the curve, the takeaway is smaller than everyone makes it sound.

Show up. Say the risky true thing. Make the next step obvious. Keep building.

The code is only one part of the craft ✨

Originally published on March 25, 2026 at souravdey.space.

⚡ Flexbox-Guide 🚀 Flexbox layout made simple with an Interactive tool

Sourav Dey — Wed, 14 Apr 2021 08:49:49 +0000

TLDR

An Interactive Tool for the concept of Flexbox and Responsive Design. Simply set the attributes as needed and copy the CSS code. 🎉

Website Link - http://flexbox-guide.vercel.app/

Github Repo - https://github.com/Souravdey777/flexbox-guide

Docs Link - https://souravdey777.github.io/flexbox-guide/

About `Flexbox-Guide`

Flexbox-Guide is a website developed for web developers and Coding newbies learning CSS Flexbox Layout. This website can be used for both learnings or generating the code. Simply arrange the flex items as you need and copy the CSS to your code.

Before the Flexbox Layout module, there were four layout modes:

Block, for sections in a webpage
Inline, for text
Table, for two-dimensional table data
Positioned, for the explicit position of an element

The Flexible Box Layout Module makes it easier to design a flexible responsive layout structure without using float or positioning.

For a detailed explanation please check A Complete Guide to Flexbox by Chris Coyier

Why wait? Straightaway go to the website and join the Awesomeness 😎
https://flexbox-guide.souravdey777.vercel.app

Inspiration 💡

I got the Idea while I was explaining flexbox to a few of the interns in my office. I was explaining to them with three sample cards that how to make responsive cards with flexbox. And I have seen a lot of web developers using static paddings and margins and handling it with a lot of media queries. But, why go for such a mess when we have the CSS flexbox layout.

This tool was also created with the same thought process. So that all the budding software developers can learn flexbox layout with an interactive tool, where you can set the attributes and check the layout as well as It will generate the CSS code for it.

Technologies 🔨

Built with Reactjs and Love ❤️

Hosted in Vercel Cloud.

Accomplishment 🚀

I have integrated 📈 analytics with plausible with the website recently on the 29th of Jan and here are the stats https://plausible.io/flexbox-guide.vercel.app.

It also got published in a Weekly Magzine for Designers 🎉
https://speckyboy.com/weekly-news-for-designers-577/

The greatest of all is that It will help the community.

License

📝 Distributed under the MIT License. See LICENSE for more information.

Contribution and Support

Upvote Flexbox-Guide in 🚀 Product Hunt.

Open a Pull Request or Raise an Issue.

👨‍🚀 Contributions are what make the open-source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

Hope you Loved it! Do let me know in the comments.

Want to learn more about flexbox?? Check the below link
https://souravdey777.github.io/flexbox-guide/#learn-more-about-flexbox

Contact me

Creating your own npm package

Sourav Dey — Sun, 11 Apr 2021 12:18:17 +0000

First of all, What is npm?

npm is two things: first and foremost, it is an online repository for the publishing of open-source Node.js projects; second, it is a command-line utility for interacting with a said repository that aids in package installation, version management, and dependency management. A plethora of Node.js libraries and applications are published on npm, and many more are added every day.

☝ This is not out of my brain. 🧠

Reference to the definition
https://nodejs.org/en/knowledge/getting-started/npm/what-is-npm/

Setting the things up

What you need to start is with simple Node.js installation and yes, that is it.
Refer to the below links 👇

How to install Node.js

Download link for Node.js

Let us break this down into simple steps

1. Creating the package.json file

For publishing an npm package you don't need anything apart from package.json. But, yeah it will not be having any functionalities.

There are two ways to create the package.json file. You can simply open any code editor and go for the good old-fashioned way of editing it yourself. I will suggest trying it once. You will get to know how to and what to add as key-value pair in the JSON file.

{
    "name": "your-amazing-package",
    "version": "1.0.0",
}

This is the minimum key-value pair that is required to publish a package

But, again if you want things to be done efficiently. Create the package.json with the below command

npm init

Follow the instructions and enter the details one after another and after that just select enter after confirming the details.

This is how your Package.json is going to look after that 👇

{
  "name": "awesome-npm",
  "version": "1.0.0",
  "description": "the awesome package",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/YOUR_Git_USERNAME/awesome-npm.git"
  },
  "keywords": [
    "awesome"
  ],
  "author": "Sourav Dey",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/YOUR_Git_USERNAME/awesome-npm/issues"
  },
  "homepage": "https://github.com/YOUR_Git_USERNAME/awesome-npm#readme"
}

We have the package.json ready. Now, index.js comes to the picture that is defined in pacakge.json as "main": "index.js"

2. Creating the index.js file.

Let's create a simple function in the index.js file. 👇

function awesomeEmojiLog(message) {
    if (message === undefined) throw new Error("No Message Found");
    console.log("😎", message)
};

module.exports = awesomeEmojiLog

It is any day better to test your function before publishing it.
It can be easily called inside index.js as

awesomeEmojiLog("This is awesome emoji")

Test it with a simple command

node index.js

The output will be

😎 This is awesome emoji

Once done. It is now time to publish it.

3. Publish the npm package

To publish an npm package you first need to create an account in the npm registry with this link 👉 Signup for npm.

Done. Cool.

npm login

npm adduser

Enter the username, password, and email ID as asked.

After that, you are one command away from your npm package. Just type this

npm publish

Note- If your package name starts with "@Your-username/packageName"

use the below command.

npm publish --access=public

🎉🥳 The npm package is Published. You will get a mail for the same and You can check your list of packages in the npm registry if you are logged in.

4. Create the Github Repo for your package.

Create your repo awesome-npm and push the code.

Follow the command to push the code.

echo "# awesome-npm" >> README.md
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/Souravdey777/awesome-npm.git
git push -u origin main

Add the Licence for your package. I have used MIT.

Write the package's basic details in the Readme file like how to use it and what it does. Now, you can Create a new release for the npm package with proper versioning.

you can check the repo for reference 👉
https://github.com/Souravdey777/awesome-npm

and the npm package 👉
https://www.npmjs.com/package/awesome-npm

😎

Your awesome npm package is ready. 🎉🎉

Hope you Loved it! Do let me know in the comments.

DEV Community: Sourav Dey

LeetCode #376: Wiggle Subsequence

LeetCode Question - 376. Wiggle Subsequence 🧠

About the Series

Problem Statement

Video Explanation

Solution

Similar Questions for practice

You can find me on the web 🌍

LeetCode #1465: Maximum Area of Cake After Cuts

LeetCode Question - 1465. Maximum Area of a Piece of Cake After Horizontal and Vertical Cuts 🍰

About the Series

Problem Statement

Video Explanation

Solution

You can find me on the web 🌍

Product Engineering: The Only Skill That Survives AI 🏗️

The AI Acceleration Problem

What Product Engineering Actually Means

Why AI Makes This More Critical, Not Less

The Obsession With "Great Engineering"

My Product Engineering Principles

The AI Era Divide

What I'd Do Differently

7 Years as a Software Engineer: What Actually Changed 💼

🧭 The first shift: when “it runs” is not the win

🌫️ Ambiguity stopped feeling like a personal failure

⚖️ Speed, quality, and the lie of having both for free

💬 Communication is not fluff. It is part of the ship.

🧠 Competence and confidence refuse to stay in sync

🧰 What actually aged well

🤝 Leadership without the title

✉️ What I would tell past me

🪨 What still feels hard

⚡ Flexbox-Guide 🚀 Flexbox layout made simple with an Interactive tool

TLDR

About Flexbox-Guide

Inspiration 💡

Technologies 🔨

Accomplishment 🚀

License

Contribution and Support

Contact me

Creating your own npm package

First of all, What is npm?

Setting the things up

Let us break this down into simple steps

1. Creating the package.json file

2. Creating the index.js file.

3. Publish the npm package

4. Create the Github Repo for your package.

😎

Contact me

About `Flexbox-Guide`