My blog syndication strategy came from that mistake. 📌

The source of truth lives on souravdey.space. Dev.to and Hashnode help me distribute the same idea further, but they do not become the home of the work. That distinction sounds small until you have been writing long enough to care about URLs, long tails, and the difference between being discoverable and being dependent.

I wrote about this in Portfolio Website Development Part 4, where I said I should have moved canonical hosting to my own domain much sooner. I meant that. The older I get in public writing, the less romantic I am about platforms. A platform is useful. A platform is not ownership.

The workflow at a glance

This is the shape I keep in my head.

Flow: Write the blog, open a PR, merge it into main, then let GitHub Actions fan the post out to Dev.to, Hashnode, Medium, and the GitHub issue checklist.

The process is simple: I write the blog, I open a PR, and once that PR lands in main, GitHub Actions pick up the follow-up work.

At the command line, the ritual is small enough to remember:

yarn build
yarn crosspost -- blog-syndication-strategy

The first command checks whether the post can survive syndication cleanly. The second is the escape hatch I use when I want to inspect or trigger a single post by hand.

What those two commands actually do

This looks tiny. It is not tiny.

yarn build is my rehearsal. In this repo it does not just build the Next.js site. It runs yarn check:syndication first, then the site build. So before I ever merge, the pipeline has already asked a useful question: if this post leaves my website, will it still make sense?

yarn crosspost -- slug is narrower and more practical. It resolves one MDX file, reads the frontmatter, converts the body into platform-friendly Markdown, talks to the Dev.to and Hashnode APIs, and updates the saved crosspost state so the next run knows whether it is creating something new or updating something that already exists.

That division matters. One command protects quality. The other handles distribution.

The mental model in code is even simpler: publish once, then automate the platform copies that are truly repeatable.

const syndicationTargets = ["Dev.to", "Hashnode"] as const;

function publish(post) {
  publishCanonical(post);
  syndicationTargets.forEach((target) => {
    crosspost(post, target);
  });
}

publishCanonical(post) is the whole philosophy in one line. Home first. 🏠

Then the loop fans out only across targets that are predictable enough to automate. That is why the array is short. Dev.to and Hashnode fit that model. Medium does not sit in that loop because the action I care about there is different. I do not want “post some Markdown.” I want “import this canonical URL and preserve the original source.”

Medium stays outside that automated loop on purpose. I handle it manually through link import, because preserving the canonical URL matters more to me than forcing every destination to behave the same way.

There are GitHub Actions around this too. I think of them as guardrails, not magic. The local commands are how I work. The workflows are how I stop that process from depending on my memory.

Canonical first

My site is where the post starts, where it gets updated, and where it stays.

That choice shapes everything else. I write in MDX under src/content/blogs, and the frontmatter decides whether a draft is ready to leave the building. If a post is published, the site treats it as part of the content graph, not as a one-off asset. Search, sitemap entries, RSS, structured data, and the page itself all point back to the same canonical home.

That is the part I care about most.

If someone finds me on Dev.to or Hashnode, I still want the post to know where home is. If search finds the original article, I want that version to be the one search engines remember. If I update the post later, the canonical copy should be the one that carries the truth forward.

Ownership is not just a philosophical preference. It is a maintenance strategy.

What the actual loop looks like

The loop is simpler than it sounds.

I write the post. I open a PR. Review happens there. When that PR lands in main, that is the moment the canonical post becomes live and the follow-up automation starts.

Before any of that merge machinery matters, yarn build runs the syndication checks locally so I get early feedback if a post contains something the crosspost pipeline cannot translate cleanly.

Then GitHub Actions repeat that discipline in CI.

What the GitHub Actions actually do

The first workflow is syndication-check.yml. It runs on pull requests and on pushes to main when blog files or the syndication code changes. I like that detail more than I expected to. It means the check is not some vague “content pipeline” that wakes up for everything. It wakes up only when the parts that matter change. If I change the syndication logic, or I change a blog post that will be published, the workflow reruns the exact question I care about: can this MDX survive outside my site without falling apart?

That workflow is the skeptical friend in the system. 👀 It does not publish anything. It just refuses to let me feel prematurely done.

At the YAML level, it is doing something very plain:

on:
  pull_request:
    paths:
      - "src/content/blogs/**"
  push:
    branches: [main]

That is not glamorous. It is also the reason the workflow feels trustworthy. It runs when blog content changes, and when the code that handles syndication changes. Not on every random edit in the repo.

The second workflow is post-publish-blogs.yml, and this one is the real follow-through. It runs only after content lands on main. That boundary matters to me. Drafting is one phase. Review is another. Distribution starts only when the canonical post is actually live on my domain.

Once that workflow wakes up, it diffs what changed, filters down to published blog slugs, and runs the follow-up work in one place. It can generate OG thumbnails when the image is missing, create audio, crosspost to Dev.to and Hashnode, send social announcements, and open the GitHub distribution checklist issue that reminds me about the manual side of the job. Medium lives there indirectly. Not as an automated API call, but as a deliberate item in the checklist.

The code path is surprisingly readable:

const publishedSlugs = publishedBlogSlugsFromChanged(changed);

runOgThumbnails(publishedSlugs);
runAudio();
crosspostOk = runCrosspost(publishedSlugs);
socialOk = runSocialAnnounce(publishedSlugs);
runDistributionChecklist(publishedSlugs, crosspostOk, socialOk);

That sequence is the process in miniature. First figure out which published posts actually changed. Then do the repeatable work around them. Then open the checklist for the parts that still deserve a human hand.

That is the real payoff for me. I do not want to remember five slightly different publishing rituals. I want one publishing model. Let the machine handle repetition. Let me handle judgment.

The crosspost layer does the boring work well. Under the hood, it is basically this:

const markdown = mdxToCrosspostMarkdown(body, siteUrl);
const footer = originAttributionFooter("souravdey.space", siteUrl);

What that conversion code is really doing

That little pair of lines carries most of the weight. It turns MDX into platform-friendly Markdown, absolutizes links, strips out components that only make sense on my site, and adds the attribution footer that tells readers where the original lives. In practice, that is the bridge between the thing I enjoy writing and the thing platforms are willing to accept.

mdxToCrosspostMarkdown is the messy realism function in this whole setup. It is where custom site-only components stop being UI elements and start becoming readable plain Markdown. It is where local image paths become absolute URLs. It is where embeds that work beautifully on my site turn into links, summaries, or simplified fallbacks for platforms that do not know anything about my component system.

originAttributionFooter is simpler, but maybe more important. It is the line that keeps ownership visible after the post travels. Without that footer, syndication can quietly become duplication. With it, the copied post still remembers where home is.

There is another small detail here that makes the whole setup feel grown-up to me. The post-publish workflow commits generated assets back with [skip ci], so the automation does not keep waking itself up in a loop. That sounds like a tiny implementation detail. It is also the difference between “automation” and “a bot that eats its own tail.” ♻️

A blog post is not done when I finish writing it. It is done when it survives distribution without losing its shape.

That is a different bar.

The GitHub issue checklist

The automated path is only half the story. I also keep a GitHub issue open for the manual side of distribution, so Medium, social shares, and aggregator submissions do not live in my head. The issue is created from the post metadata and labeled distribution by the same follow-up workflow that handles crossposting.

That part matters more than it sounds. A lot of publishing systems look “automated” right up until the moment they quietly dump the human steps back into your brain. I did not want that. If a step is manual, I still want it in the system. Visible. Attached to the post, not floating around as a half-remembered note.

The Medium row is still a direct link paste, because I want the import tool to preserve the canonical URL:

- [ ] [Medium](https://medium.com/new-story) *(use Import tool to preserve canonical URL: https://souravdey.space/blogs/blog-syndication-strategy)*

That line is intentionally verbose. I do not want future me guessing what “publish to Medium” meant on a sleepy evening.

And if I need to recreate the issue itself by hand, the CLI version is straightforward:

gh issue create --title "📢 Distribution: My Blog Syndication Strategy 📣" --label distribution --body-file checklist.md

That checklist is the human half of the system. It catches the little things automation should not guess.

Why I still syndicate

I do not syndicate because I am unsure where my work belongs.

I syndicate because attention is fragmented, and readers do not all arrive through the same door. Some people discover a post through Dev.to. Some through Hashnode. Some through RSS. Some through search. Some land on my homepage because they already know my name. I want to meet all of them without making every post depend on one channel.

That is the balance I was after: reach without surrendering the original. ✨

If I only published on my own site, I would own everything and reach fewer people. If I only published on platforms, I would get reach and lose some control. Syndication is the middle path I actually believe in. It is not a compromise if the canonical story is strong.

There is also a softer reason. Crossposting makes my writing travel. A good post should be able to sit in different places and still feel like the same thought. That constraint makes me write cleaner, structure better, and keep my MDX honest. If a post depends too heavily on site-specific presentation, I usually need to think harder about whether the core idea stands clearly enough on its own.

The tradeoffs are real

I am not pretending this setup is free.

Every layer of automation adds another place where content can break. Some MDX components do not translate neatly. Some images need better alt text than I would otherwise bother with when I am in a hurry. Some internal links need to become absolute URLs on syndicated copies. That is why I like having check:syndication wired into the build. I would rather learn about a conversion problem before the post is public than after I have shared two broken copies.

There is also a mental tradeoff. Syndication can tempt you into caring too much about platform performance. I try not to let that happen. If Dev.to gets more clicks on one post and Hashnode gets more comments on another, that is interesting, but it is not the point. The point is that the original post stays intact, searchable, and under my control.

I want the platform to amplify the writing, not define it.

That line keeps me honest.

What I would do differently

I would move canonical hosting to my own domain even earlier.

That is the cleanest lesson in the whole thing. For years I cared too much about where a post could travel and not enough about where it should live. In Part 4 I admitted that. The older version of me thought syndication was a distribution decision. The better version of me sees it as an architecture decision.

I would also document my content conventions sooner. Once a site has more than one content type, memory stops being a reliable system. Frontmatter, tags, images, series, and syndication rules all start to interact. A short internal doc saves future me from guessing, and guessing gets expensive when it happens at publish time.

If I were starting again today, I would still syndicate. I would just be much less sentimental about the platform copy and much more protective of the original.

That is the whole strategy, really.

Write once. Keep the canonical copy at home. Let other platforms do the discovery work. Update the source, and let the copies follow.

The original should always know where home is. 🏠

Originally published at souravdey.space.

I was still building. The fuel was not a trophy list. It was ideas: problems I could not drop, small "what ifs," things I wanted to exist whether or not anyone asked. Some turned into code and demos. Some stayed half-born in notes. When something did ship, I parked it on Side Projects so I could point back without turning the build into a performance. The hard part was not a lack of sparks. It was guilt. Every hour on a personal repo felt like an hour I stole from rest, from my day job, from whatever version of adulthood the noise online says you should perform.

If you have ever closed your laptop at 1 AM 🌙 and thought, this does not count, you know the feeling.

Here is the lesson that took me too long to learn: side projects add up over time even when they never become startups. Not because every repo needs a prize. Because they train skills your sprint board rarely optimizes for. ✨

What side projects teach beyond your job 🧾

At work, someone else shapes the problem, writes the ticket, and often picks the hard choices for you. That is not a knock on you. It is how real companies ship.

Side projects push you into the step before that: choosing what is worth building when no one asked, when the scope is yours, when the only deadline is your own pride. That is where you practice decisions when nothing is spelled out, the same habit that later helps when two technical options are both "fine" and someone has to pick.

You also get shipping in public if you publish the work. 📣 A private spike teaches syntax. A public repo teaches taste, communication, and the slow work of explaining your own mess.

Figure from Austin Kleon's Show Your Work!.

That book is where I first saw the learn and teach loop drawn as one circle. You learn, you share what you know, and sharing feeds the next round of learning. Austin Kleon's "show your work" idea is not about showing off. It is about letting your thinking meet real people. I wrote about why that cycle is a career catalyst for builders, and how I use it in mentorship, in this LinkedIn post.

And Guess what? The web is not fair. Polished demos can flop. Rough hacks can take off. You cannot chase likes without turning the whole thing into a second social media job. You can still chase practice reps: ship, write it down, cut scope, finish something. 🎯

What compounding means for side projects 📈

When I say compound, I do not mean every project becomes a clean story for interviews. I mean a set of skills that still help you after you stop opening the repo every week.

Spotting patterns is the big one. After you debug your own auth flow, deploy surprises, and your own "why is this slow" hunts, incidents at work start to look familiar. The details change. The shape of the problem often does not.

Knowing your tools is the quiet kind of compound interest. 🛠️ You learn a framework because a weekend idea needed it. Two years later that is not just a resume line. It is speed when the team needs a prototype, or when you read someone else's system and you actually get the constraints.

Proof you can ship matters more than people say, especially early. ✅ Not proof you are a genius. Proof you can take an idea from zero to something another person can run. That is a different signal than "I finished courses."

There is a follow-on effect too. 🤖 You can ship side projects lightning fast now: AI handles boilerplate, glue code, and first drafts so an idea can become a working thing in hours, not weeks. As that wall gets lower, the hard part moves earlier. The rare skill is not typing UI faster. It is naming the problem, picking limits, and knowing what "good enough" means for a user. Side projects are a low-risk place to grow that product sense without treating a tutorial like owning a real feature.

Product engineering is part of that same stack, and it grows fast when you build for yourself. You are the user, the scope owner, and the engineer in one loop, so tradeoffs land in your head instead of across three roles in a meeting. I wrote about why that mindset is the skill that survives when AI handles more of the code in product engineering in the AI era.

Side projects are not free ⚖️

Growth needs finish lines, not only new ideas. If every spark becomes a new foundation and nothing ships, you get the joke instead of the skills.

Strip: West Side-project story (CommitStrip, 2014).

Side projects still cost something. Sleep. 😴 Relationships. The trap of using "hustle" to skip rest. I will not tell you every engineer needs a perfect GitHub graph. That is not wellness. It is stress with a brand. 😬

The useful idea is smaller: if you already build on the side, stop treating it like a character flaw. Call it practice that stacks over time, then guard your time like a grown person. A side project that ships in six weeks with weekends intact beats a "rewrite everything" dream that eats six months of guilt.

What I would do differently 🧭

I would pick smaller scope and celebrate done more loudly. I would treat docs as part of the product, not an afterthought, because future me is also a user. 📝

I would split real learning from "learning for the feed." Some spikes stay private. Not everything needs a post. The value still lands in your head. 🧠

Most of all, I would stop forcing side projects to prove themselves in the same frame as my job. They are not copies of each other. They are different gyms. One pays your salary. The other builds more choices, speed, and confidence when you see a work problem no one filed yet.

If you are building something odd this weekend and part of you feels guilty for not "optimizing" your career, that build might already be the optimization. Ship the smallest version. Ship it. Then step away.

The compound part was never the repo. It was the person all those reps built. ✨

Originally published at souravdey.space.

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 at souravdey.space.

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 at souravdey.space.

This is the story of HackGPT 2.0, HackerRank's internal 24-hour hackathon during our May P&E Offsite. Our team of 8 engineers reached 2nd runner-up position, but the real win was proving something the product team had been theorizing about for months: AI-powered holistic code review isn't just feasible, it's practical at scale.

Kudos to the entire team: Ankur, Ankush, Hannad, Sudarshan, Satyam, Dinesh, and Dhruv 🙏.

🎯 The Problem: Scoring Developers on a Single Axis

Here's the reality of how most coding assessments work today: a candidate writes code, the platform runs testcases, and the output is a single number. Pass 7 out of 10 testcases? That's your score.

But anyone who's done a real code review knows that the score tells you almost nothing about the developer. Two candidates can both score 70%, but one of them wrote clean, well-structured code with thoughtful edge case handling, while the other brute-forced a solution with global variables everywhere and got lucky on the test cases.

The current model measures two things: correctness and partial performance. Everything else (code style, maintainability, security patterns, debugging skills, how the candidate actually approached the problem) is invisible.

This has real consequences. At enterprise scale, one of our customers was manually reviewing 74,000 candidates per year to compensate for what automated scoring couldn't capture. That's over 12,000 hours of engineering time spent on manual code review, every single year.

We wanted to build something that could see what the score can't.

🗺️ Designing a Holistic Skill Profile

Before writing any code, we spent the first couple of hours whiteboarding what a "complete" developer evaluation would actually look like. We landed on five dimensions:

✅ Solution: Does the code work? Is it performant? This is the baseline that existing systems already cover.

🧹 Code Quality: Is it readable? Is it maintainable? Would you want to inherit this codebase?

🛡️ Reliability: Does the candidate think about security, scalability, exception handling, and technical design? These are the signals that separate a junior developer from a senior one.

♿ User Experience: Does the code consider accessibility? This is especially relevant for frontend assessments.

🧠 Logical Progression: This is the one that got us most excited. Instead of just reviewing the final submission, what if we could understand how the candidate got there? Their debugging patterns, their persistence when stuck, the moments where they pivoted their approach.

That last dimension is what made our project different from "just another AI code reviewer." We weren't just analyzing code. We were analyzing the process of writing code.

🏗️ The Architecture (Plus 12 Cups of Coffee)

Hour 3. Whiteboard phase over. Coffee cup #3. Time to build.

We designed the system as a standalone platform service, intentionally decoupled from any single product UI so it could eventually plug into screening, interviews, and skill assessments across the board.

The data flow looks like this:

⌨️ Keystroke ingestion:

Flow: Assessment Frontend → Attempt Processing Worker → Candidate DB

🔬 Code quality analysis:

Flow: Candidate DB → Code Quality Platform Service → Core API

🤖 AI review engine:

Flow: Code Review Rubric → Next.js App → AI Platform (LLM)

The Code Quality Platform Service is the central piece. It receives attempt data (including raw keystroke streams), runs a combination of static analysis and LLM-powered review against a configurable rubric, and pushes structured results back to the API layer for rendering.

The Next.js app handles the review orchestration, consuming rubric definitions and coordinating with the AI platform to produce categorized, line-level code comments.

And then there was the part I spent most of my 24 hours on.

⏪ My Contribution: Turning Keystrokes into a Time Machine

Here's the thing about keystroke data: it's raw. Really raw. A stream of individual key events with timestamps. Insert character. Delete character. Cursor move. Paste. Undo. Thousands of events per coding session.

My job was to turn that raw stream into something an AI reviewer could actually reason about.

I built a keystroke serialization engine that reconstructs snapshots of the candidate's code at configurable intervals. Instead of just handing the LLM the final submission and saying "review this," the engine generates a sequence of code states, a snapshot every n keystrokes, that captures the candidate's code at different points in their journey.

Think of it like git commits, but automatic and granular 📸. Snapshot at keystroke 50. Snapshot at keystroke 150. Snapshot at keystroke 300. Each one is a frozen moment of the candidate's progress.

This changes what the AI reviewer can see. It's not just what the candidate wrote, it's how they got there 🕵️.

Did they start with a brute-force approach and refactor? Did they handle the happy path first and then circle back for edge cases? Did they get stuck on a syntax error for 10 minutes or catch it in 30 seconds? Did they delete half their code and restart with a better approach, or did they keep patching a broken foundation?

The configurable gap parameter is where the real tradeoff lives: you tune snapshot frequency based on question complexity. For a quick algorithm question, every 30 keystrokes gives enough resolution. For a longer system design problem, every 100.

More granular snapshots = more LLM calls, higher latency, and higher inference cost. The cost-to-resolution curve is a real production problem this approach needs to address before it can scale.

On top of the serialization engine, I built the Next.js frontend that surfaces all of this: the code playback UI, the inline AI review comments, and the attempt timeline that shows the candidate's phases visually.

By hour 18, keystroke-to-snapshot serialization was working end to end. By hour 22, it was integrated with the AI review pipeline and rendering in the UI. The last two hours were pure polish and demo prep (and coffee cups #11 and #12).

📊 What the AI Reviewer Actually Outputs

The review engine produces structured, line-level comments. Not vague "this could be better" feedback, but specific, categorized, severity-tagged observations:

{
  "severity": "High",
  "category": "Code Style",
  "lines": "5-6",
  "comment": "Extensive use of global variables. Leads to unexpected side effects and complicates debugging."
}

These comments overlay directly on the code playback, so a reviewer sees the AI's observations at the exact lines where issues appear.

Beyond line-level feedback, the system generates an Attempt Summary, a natural-language overview designed for non-technical hiring stakeholders. It includes a composite score, a phase timeline (initial setup → debugging → edge-case handling → optimization), and structured highlights and lowlights.

Defined evaluation criteria fed as structured prompts is what makes LLM code review reliable enough to surface to hiring teams. Without the rubric layer, you get opinions. With it, you get a repeatable process.

🌙 24 Hours of In-Office Hackathon Culture

I want to talk about the vibe for a second, because it matters.

There's something different about building alongside your team in a room at 3 AM with empty coffee cups and a deadline. The brainstorming is faster. The decisions are bolder. Nobody's overthinking a PR review. You're just shipping. The energy of an in-office hackathon compresses months of "we should build this someday" into one intense, focused burst.

The first hour was chaos, eight people talking over each other about what to build. Then someone pulled up a whiteboard and it clicked. The next 22 hours were a mix of deep focus sprints, quick syncs standing around someone's laptop, and exactly the right amount of distraction (the poker game was competitive, I'll leave it at that 🃏).

This is the stuff that builds team trust. You learn more about how someone thinks and works in 24 hours of hackathon pressure than in months of regular sprint work.

🚀 From Hackathon to Product

By demo time, we had two things working end to end:

1. A fully operational Code Quality Platform Service: keystroke ingestion, snapshot serialization, AI-powered multi-dimensional review, and structured output via API.
2. A working frontend integration: inline code review comments, skill dimension indicators, attempt timeline, and natural-language summary, all rendered in the assessment UI.

We placed 2nd runner-up 🥉 out of all teams at HackGPT 2.0. More importantly, the prototype demonstrated something the product team had been theorizing about for months: that AI-powered holistic code review is not just feasible, but practical at scale.

Our CEO later called it out publicly 📢:

Post on X

That validation felt great 🙌. But what I keep thinking about is the second-order implication: if keystroke data becomes a first-class evaluation signal, the way assessments get designed changes. Question complexity, time windows, the balance between free-form coding and structured problems, all of it needs rethinking. The technology isn't the hard part. Rethinking the assessment design around it is 🤝.

💡 What I Learned

• ⛏️ Keystroke data is an underrated goldmine. Most platforms throw it away or use it only for proctoring. Treating it as a first-class data source for skill assessment opens up an entirely new evaluation dimension.

• 🤖 LLMs are good at code review, with guardrails. You can't just dump code into an LLM and expect consistent, structured output. The rubric-driven approach, where you define evaluation criteria separately and feed them as structured prompts, is what makes the output reliable enough to surface to hiring teams.

• ⚡ Hackathons compress learning. I went deeper on keystroke event processing, snapshot reconstruction, and LLM orchestration in 24 hours than I would have in weeks of regular work. Constraints breed focus.

Eight people with different expertise areas, 24 hours, one shared vision. That's how real systems get built ✨

Originally published at souravdey.space.

This blog is the 3rd part after Portfolio Website Development - Part 1 and Part 2.

Part 2 ended with a single long page: anchor jumps, Hashnode pulling the latest four posts, and a layout I still liked visually. The problem showed up in day-to-day use. I kept pasting links and then typing “scroll to…” or sending people to Hashnode for the full post. That is fine for a launch story. It is a bad fit when you actually want this domain to be where the writing lives.

So I rebuilt the shape of the site around real routes and MDX in the repo.

⚡ Next.js 13 and the App Router

I am on Next.js 13.4.x with the App Router (experimental.appDir in next.config.js). The src/app/ tree now owns /, /blogs, /blogs/[slug], /mindNuggets, /mindNuggets/[slug], nested /aboutMe/*, /ideas, /mentorship, and the rest. Clicking the menu is navigation, not scrollIntoView on one canvas.

The tradeoff is honest: I lost some of that “one continuous landing page” feel. I gained URLs I can drop in a DM, Open Graph that points at souravdey.space, and room to grow without turning page.tsx into a junk drawer.

📦 Contentlayer + MDX

Blogs and mind nuggets are .mdx files under src/content/. Contentlayer with next-contentlayer is what turns those files into typed documents and generated imports from contentlayer/generated (allBlogs, and the same pattern for other types). My build is yarn contentlayer build && next build.

In contentlayer.config.js I defined Blog, MindNugget, Idea, and Book document types. MDX goes through remark-gfm, rehype-slug, rehype-pretty-code (Shiki, github-dark), and rehype-autolink-headings so code blocks and headings behave the way I expect in long posts.

The homepage still composes intro.mdx and friends via @next/mdx, with experimental.mdxRs where it helps. Two MDX paths sound like extra noise. In practice it let me ship the marketing shell and the article pipeline without blocking one on the other.

🎨 Styling and motion

I did not move to Tailwind for this pass. Most surfaces use CSS Modules (page.module.css, component-level *.module.css) plus tokens in globals.css. prefers-color-scheme: dark drives a simple light or dark flip through CSS variables so I get a baseline theme without a custom toggle yet.

Framer Motion is still doing the heavy lifting for scroll progress and the small transitions that stop long pages from feeling dead. Icons are lucide-react and @icons-pack/react-simple-icons where I need brand marks.

Tooling snapshot

Node 18.x in engines, React 18.2, TypeScript 5.0.x, eslint-config-next. On blog pages dayjs, reading-time, and clsx handle dates, read time, and class names. Nothing here is trying to be clever. It is the stack I could operate while still shipping features after work.

What is next?

• Tighten metadata and sharing cards per route so every blog and nugget looks right when linked on Twitter or LinkedIn.
• Keep pulling more writing off third-party hosts so souravdey.space stays the canonical place.
• Revisit the /aboutMe subtree and side pages so they match the same content model where it makes sense.
• I am sure I will find ten more rough edges once I stop touching the same three files on repeat.

If you are on a similar journey: routes first, content compiler second, polish third. I spent too long in Part 2 pretending scroll targets were URLs. Fixing that unlocked everything else.

✨ Live site: souravdey.space

Originally published at souravdey.space.

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. 🚀

Problem Statement

Fibonacci Number

The Fibonacci numbers, commonly denoted F(n) form a sequence, called the Fibonacci sequence, such that each number is the sum of the two preceding ones, starting from 0 and 1. That is,

• F(0) = 0, F(1) = 1
• F(n) = F(n - 1) + F(n - 2), for n > 1.

Given n, calculate F(n).

Example 1:

Input: n = 2
Output: 1
Explanation: F(2) = F(1) + F(0) = 1 + 0 = 1.

Example 2:

Input: n = 3
Output: 2
Explanation: F(3) = F(2) + F(1) = 1 + 1 = 2.

Example 3:

Input: n = 4
Output: 3
Explanation: F(4) = F(3) + F(2) = 2 + 1 = 3.

Video Explanation

Solution 1: Recursive Approach

Algorithm

1. This is the recursive solution where If n is 0 it will return 0 or if n is 1 it will return 1. This is the base case for recursion
2. Recursively call the f(n-1) and f(n-2) to return the final value of f(n)
3. Finally we get out f(n).

Code in JS 🧑‍💻

/**
 * @param {number} n
 * @return {number}
 */
var fib = function (n) {
  if (n < 2) return n;
  return fib(n - 1) + fib(n - 2);
};

Time Complexity : O(n)

Space Complexity: O(n)

Solution 2: Iterative approach with an array

Algorithm

1. First of all, n = 0 return 0 and for n = 1 return 1
2. Create an array and store the first two values of the Fibonacci sequence in the array
3. Now update the ith value of the array with the i-1 value + the i-2 value of the array.
4. Repeat the same for n iterations and then the array will have the nth value too.
5. Return the nth value from the array

Code in JS 🧑‍💻

/**
 * @param {number} n
 * @return {number}
 */
var fib = function (n) {
  if (n < 2) return n;
  var fibArray = [];
  fibArray[0] = 0;
  fibArray[1] = 1;
  for (var i = 2; i <= n; i++) {
    fibArray[i] = fibArray[i - 1] + fibArray[i - 2];
  }
  return fibArray[n];
};

Time Complexity : O(n)

Space Complexity: O(n)

Solution 3: Iterative approach without an array

Algorithm

The approach is similar to the 2nd solution but it is done without using a new array.

1. First of all, n = 0 return 0 and for n = 1 return 1
2. Store the last two values of the Fibonacci series in f1 and f2.
3. Update f1 with f2
4. Update f2 with the current sum of f1 and f2.
5. Steps 2 and 3 will be repeated till we get the final value after n iterations.
6. Return f2.

Code in JS 🧑‍💻

/**
 * @param {number} n
 * @return {number}
 */
var fib = function (n) {
  if (n < 2) return n;
  var f1 = 0;
  var f2 = 1;
  for (var i = 2; i <=n; i++) {
    var currentSum = f1 + f2;
    f1 = f2;
    f2 = currentSum;
  }
  return f2;
};

Time Complexity : O(n)

Space Complexity: O(1)

Similar Questions for practice

Now it is time to try some similar questions

• Climbing Stairs
• Split Array into Fibonacci Sequence
• Length of Longest Fibonacci Subsequence
• N-th Tribonacci Number

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

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

“Belief creates the actual fact.”

~ William James

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. 🚀

Problem Statement

Longest Consecutive Sequence

Given an unsorted array of integers nums, return the length of the longest consecutive elements sequence.

You must write an algorithm that runs in O(n) time.

Example 1:

Input: nums = [100,4,200,1,3,2]
Output: 4
Explanation: The longest consecutive elements sequence is [1, 2, 3, 4]. Therefore its length is 4.

Example 2:

Input: nums = [0,3,7,2,5,8,4,6,0,1]
Output: 9

Video Explanation

Solution

Algorithm

1. we create a numsMap and store all the values in the map.
2. Now Iterate through the nums array and check if it is the starting point of a consecutive sequence of values or not. ie. num-1 exists or not. If it doesn’t exist that means it can be starting value of the sequence.
3. Now check whether the next consecutive value exists or not in a while loop and increment the value of the current sequence length.
4. Compare the longest sequence length with the current sequence length whichever is maximum will be stored in longest sequence length
5. Finally return the longest sequence length.

Code in JS 🧑‍💻

/**
 * @param {number[]} nums
 * @return {number}
 */
var longestConsecutive = function (nums) {
  var numsMap = new Map();
  for (const num of nums) {
    numsMap.set(num);
  }

  var longestSequence = 0;
  for (const num of nums) {
    if (!numsMap.has(num - 1)) {
      var currentSequence = 1;
      var currentNum = num;
      while (numsMap.has(currentNum + 1)) {
        currentNum++;
        currentSequence++;
      }
      longestSequence = Math.max(longestSequence, currentSequence);
    }
  }
  return longestSequence;
};

Time Complexity : O(n)

Space Complexity: O(1)

Similar Questions for practice

Now it is time to try some similar questions

• Binary Tree Longest Consecutive Sequence
• Find Three Consecutive Integers That Sum to a Given Number
• Maximum Consecutive Floors Without Special Floors

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

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

“Believe you can and you’re halfway there.”

~ Theodore Roosevelt

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. 🚀

Problem Statement

Candy 🍭

There are n children standing in a line. Each child is assigned a rating value given in the integer array ratings.

You are giving candies to these children subjected to the following requirements:

• Each child must have at least one candy.
• Children with a higher rating get more candies than their neighbors.

Return the minimum number of candies you need to have to distribute the candies to the children.

Example 1:

Input: ratings = [1,0,2]
Output: 5
Explanation: You can allocate to the first, second, and third child with 2, 1, 2 candies respectively.

Example 2:

Input: ratings = [1,2,2]
Output: 4
Explanation: You can allocate to the first, second, and third child with 1, 2, 1 candies respectively.
The third child gets 1 candy because it satisfies the above two conditions.

Constraints:

• n == ratings.length
• 1 <= n <= 2 * 10^4
• 0 <= ratings[i] <= 2 * 10^4

Video Explanation

Solution

Algorithm

1. Create a new array of candies with all initial values as at least one candy will be given to all the children.
2. Now, traverse from the left of the array to the right of the array and increase the count of the candies to be given based on the rating of the neighbor child. In this iteration, we are incrementing candies count only based on the left neighbor.
3. Now, repeat the above from right to left and also store the sum.
4. Finally return the total sum of candies. 🍭

Code in JS 🧑‍💻

/**
 * @param {number[]} ratings
 * @return {number}
 */
var candy = function (ratings) {
  var candies = Array(ratings.length).fill(1);
  for (var i = 1; i < ratings.length; i++) {
    if (ratings[i] > ratings[i - 1]) {
      candies[i] = candies[i - 1] + 1;
    }
  }
  var sum = candies[ratings.length - 1];
  for (var i = ratings.length - 2; i >= 0; i--) {
    if (ratings[i] > ratings[i + 1]) {
      candies[i] = Math.max(candies[i], candies[i + 1] + 1);
    }
    sum += candies[i];
  }
  return sum;
};

Time Complexity : O(n)

Space Complexity: O(n)

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

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

“Life is like riding a bicycle. To keep your balance, you must keep moving.”

– Albert Einstein

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. 🚀

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

Solution

Algorithm

1. 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)
2. We check the first difference between the 1st from the 0th value in the nums array and store it in the previousdiff
3. 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
4. Now, While iterating the nums array we will compare the compare current difference and 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.
5. 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)

Similar Questions for practice

Now it is time to try more similar questions

• Rearrange Array Elements by Sign

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

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

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. 🚀

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

Solution

Algorithm

1. Push 0 and h in the horizontalCuts.
2. Sort the horizontalCuts array in Ascending Order.
3. Take the maximum difference between the cuts by iterating on the list of horizontalCuts
4. Push 0 and h in the horizontalCuts.
5. Sort the horizontalCuts array in Ascending Order.
6. Take the maximum difference between the cuts by iterating on the list of horizontalCuts
7. Multiply both the max values and return the modulo 10^9 + 7
8. 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 🌍

• Github
• LinkedIn
• Twitter

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

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

1. 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)
2. We check the first difference between the 1st from the 0th value in the nums array and store it in the previousdiff
3. 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
4. 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.
5. 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)

Similar Questions for practice

Now it is time to try more similar questions

• Rearrange Array Elements by Sign

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

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 at souravdey.space.

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. 🚀

Problem Statement

Maximum Units on a Truck 🚛

You are assigned to put some amount of boxes onto one truck. You are given a 2D array boxTypes, where boxTypes[i] = [numberOfBoxesi, numberOfUnitsPerBoxi]:

• numberOfBoxes is the number of boxes of type i.
• numberOfUnitsPerBox is the number of units in each box of type i. You are also given an integer truckSize, which is the maximum number of boxes that can be put on the truck. You can choose any boxes to put on the truck as long as the number of boxes does not exceed truckSize.

Return the maximum total number of units that can be put on the truck.

Video Explanation

Solution

Algorithm

1. Sorting the array in descending order based on the no. of units in each box. 📦
2. Iterate through the sorted array elements and check the remaining truckSize.
   • If not enough size for all boxes take as many boxes as you can and calculate the total units
   • Else take all the boxes and calculate the total units.
3. Return the total units

Code 🧑‍💻

var maximumUnits = function (boxTypes, truckSize) {
  boxTypes.sort((a, b) => b[1] - a[1]);

  var maxTotal = 0;
  var i = 0;

  while (truckSize > 0 && i < boxTypes.length) {
    const numOfBoxes = boxTypes[i][0];
    const numOfUnits = boxTypes[i][1];

    if (truckSize <= numOfBoxes) {
      maxTotal += truckSize * numOfUnits;
      truckSize = 0;
    } else {
      maxTotal += numOfBoxes * numOfUnits;
      truckSize -= numOfBoxes;
    }

    i++;
  }
  return maxTotal;
};

Time Complexity : O(nlogn)+O(n) = O(nlogn)

Space Complexity: O(1)

Similar Questions for practice

Now it is time to try more similar questions

• Maximum Bags With Full Capacity of Rocks

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

Add your solutions or approaches to the comments.

Show your love by Sharing the blog. 🤗

"I didn't fail 1000 times. The light bulb was an invention with 1000 steps."

~Thomas A. Edison

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

1. Push 0 and h in the horizontalCuts.
2. Sort the horizontalCuts array in Ascending Order.
3. Take the maximum difference between the cuts by iterating on the list of horizontalCuts
4. Push 0 and h in the horizontalCuts.
5. Sort the horizontalCuts array in Ascending Order.
6. Take the maximum difference between the cuts by iterating on the list of horizontalCuts
7. Multiply both the max values and return the modulo 10^9 + 7
8. 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 🌍

• Github
• LinkedIn
• Twitter

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 at souravdey.space.

Complete page background animation with CSS moving gradient

The above Codepen example shows a moving gradient animation on the whole body of the website.

Code snippet for the animation effect.

HTML 👇

<body>
  <h1>
     Animation effect on "body"
  </h1>
</body>

CSS 👇

body {
  background: -webkit-linear-gradient(
    -70deg,
    #a2facf,
    #64acff
  );
  background-size: 400% 400%;
  animation: gradient 5s ease infinite;
}

@keyframes gradient {
  0% {
    background-position: 0% 50%;
  }
  50% {
    background-position: 100% 50%;
  }
  100% {
    background-position: 0% 50%;
  }
}

So, What is happening ??

The background size here is 400% 400% and the background is moving. Thus, the animation is happening.

A lot of cool stuff can be coded with this type of animation.

1. 🌈 Rainbow Effect

The above Codepen example shows a 🌈 rainbow effect.

This is similar to the animation that we saw in the previous example but with 7 colors.

2. Loader for cards and simple components.

The above Codepen example shows a loader 🐌 with the same gradient animation.

3. Implementing the same effect on a button or cards

The above Codepen example shows 🌈 the rainbow effect on a button.

4. On Hover the same animation effect

Animation on hovering on the card

Configurable parameters

• Changing the background-size
• Changing the time-duration
• Changing the degree of the linear gradient.

Now, put on your creative 🤠 hats and make an interesting animation effect with moving gradients.

Drop the website link in the comments for which you would be doing it or have done it.

Show your love by Sharing the blog. 🤗

You can find me on the web 🌍

• Github
• LinkedIn
• Twitter

Let us create a page fade-in animation with CSS.

The above Codepen shows animation with opacity: from 0 to 1. Because of infinite, it is animating continuously.

Check the whole code in Codepen or, Check the code below for the animation

HTML snippet.

<body>
  <h1>
    This is the fade-in animation moving in the y-axis
  </h1>
  <!-- Your code -->
</body>

Now, add the below code to your 🎨 CSS.

body{
  animation: fadeIn 2s infinite;
}

@keyframes fadeIn {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}

If you remove the infinite from the CSS you will get the animation effect on the first render only. With infinite it is animating continuously.

There can be many more possibilities.

Check this out,

The above codepen shows animation with transform: from translateY(50px) to translateY(0) and opacity: from 0 to 1. Because of infinite it is animating continuously.

Link for Codepen

The HTML code snippet will be the same as for the 🎨 CSS. check the code below 👇

body{
  animation: fadeIn 2s infinite;
}

@keyframes fadeIn {
  from {
    opacity: 0;
    transform: translateY(50px);
  }
  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Just remove the infinite from the CSS code for getting the animation once on the load of the page only.

Now, put on your creative hats and make an animation effect for your whole website on the initial load.

You can check something similar I did for my portfolio website. Souravdey.Space ✌

Drop the website link in the comments for which you would be doing it or have done it.

Show your love by Sharing the blog. 🤗

Contact me 🌍

• Github
• LinkedIn
• Twitter