Forem: Sunil Chaudhary

The Art of Parallelization: Why Your Features Take 13 Weeks Instead of 4

Sunil Chaudhary — Thu, 04 Dec 2025 13:00:00 +0000

What to expect in this article: This article tackles a pervasive frustration in software delivery: the "Sequential Trap." It argues that one of the biggest bottleneck isn't code execution speed but the organizational friction of handing work off between siloed teams (QA, Security, SRE) in a strictly linear fashion. After reading this article, you should be able to shifts the focus from efficiency (writing code faster) to efficacy (shipping value faster).

As developers, we're obsessed with optimizing our code. We'll spend hours refactoring a function to make it run 50ms faster. Yet, we often ignore the single biggest bottleneck in our process: The Sequential Handoff compounded by sprint planning. I've seen it countless times. A developer finishes a feature, tosses the ticket over to the QA column, and moves on. They've feel they have done their job. But the feature is nowhere near "done." It has just entered a void. It's sitting in a queue, waiting for QA's next sprint planning meeting. The feature languishes in a series of queues, slowly moving from team to team.

This isn't a process; it's a relay race where each runner decides to start the race two weeks after the baton is handed to them. This is the Sequential Trap, and it's how simple features take an entire quarter to ship.

What if that "simple" feature could get to production 100% faster, not by coding faster, but by thinking differently?

This isn't a fantasy. It's a skill I call strategic parallelization.

The "Sequential Trap": A 13-Week Tragedy

Let's look at a common, and painfully slow, delivery process for a single feature. We'll be generous and assume each team's actual work only takes one week. But, we'll add the realistic constraint that each team runs a 2-week sprint and won't pick up unplanned work.

Week	Type	Item
1	Development	The feature is coded. At the end of the week, the ticket is handed to QA.
2, 3	QA "Planning Gap"	The QA team's current sprint is already full. The ticket sits in their backlog, "Ready for Planning."
4	QA Sprint	The ticket is finally planned and executed. At the end of the week, it's handed to AppSec.
5, 6	AppSec "Planning Gap"	The AppSec team is in the middle of their sprint. The ticket sits in their backlog.
7	AppSec Sprint	The ticket is planned and reviewed. At the end of the week, it's handed to InfoSec.
8, 9	InfoSec "Planning Gap"	... (you see the pattern) ...
10	InfoSec Sprint	...
11, 12	SRE "Planning Gap"	...
13	SRE Sprint	Infrastructure changes are made.

Live! (Finally)

Total Time: 13 weeks (~ 1 Quarter).

The problem isn't just the 13 weeks. It's the waste. While the feature sits in the AppSec queue, the QA team has moved on. By the time SRE gets it, the original developer is deep in another project and has lost all context.

This is a 13-week process for what was probably 4 weeks of actual work. We've spent almost two months (9 weeks) just waiting in queues. This is invisible, soul-crushing waste.

This model is lazy, expensive, and slow.

The Parallel Mindset: A 4-Week Reality

Now, let's re-run that same feature, but this time, the tech lead acts as an orchestrator, not just a coder. The lead's first step is dependency mapping. "What truly blocks what?"

Development:

This is the root dependency. Nothing can be fully tested or reviewed until the code exists.

The Review Block:

QA, AppSec, and InfoSec can all maybe review the same final code parallely. They are not dependent on each other.

Does AppSec, InfoSec need to wait for QA? Maybe / Maybe Not.
Does AppSec need to wait for InfoSec? No.
Does SRE need to wait for InfoSec or AppSec? No.

The Release Block:

SRE needs the approvals from all three review teams.

By identifying this, we can re-plan the entire flow.

New Optimized Plan

Week 1: Development & Proactive Planning

The dev team codes the feature.

Parallel Action (The Magic Step): On Day 1 of this week, the tech lead contacts the leads for QA, AppSec, InfoSec, and SRE.

The Message: "We are starting work on Feature X today. The code will be ready for review by the end of this week. Please reserve capacity in your next sprint (which starts Week 2) for this."

Week 2: The QA testing Sprint

The code is merged to a staging/test environment. Because QA teams knows in advance, they can pull the feature into their current sprint and work on it at the same time.

Week 3: The parallelization track

Because AppSec and InfoSec teams knows in advance, they can pull the feature into their current sprint and work on it at the same time.

Workstream 1: AppSec begins its security review (code scans, logic review).
Workstream 2: InfoSec begins its compliance review.

Week 4: Integration & Release Sprint

Feedback from all the teams comes in (e.g., end of Week 2 / start of Week 3). The dev team makes any required fixes if needed (e.g., a bug from QA, a vulnerability from AppSec). If not, feature can be handed over to SRE. The SRE team (who was also informed in Week 1) has the "Release Feature X" task in their Week 4 sprint. Once the approvals are all green, they execute the release.

Total Time: 4 weeks.

We didn't just save 9 weeks. We eliminated the "Planning Gaps" and converted a linear long review process (QA + AppSec + InfoSec) into a parallel process.

The Playbook: How to Do It

This shift doesn't just "happen." It requires a different kind of mindset focused on project flow.

Deconstruct at the Start:

Before writing a single line of code, break the feature down. Identify all the "non-dev" tasks: documentation, QA test plans, security reviews, infrastructure needs.

Map the Critical Path:

Ask the hard questions.

"Can we write the QA test plan while the code is being written?" (Yes).
"Can the security team review the design before the code is finished?" (Yes).
"Can SRE provision the new database before the code is merged?" (Yes).

Identify the longest unbreakable chain of tasks—that's your critical path. Everything else should be moved off it.

Communicate Proactively (and Beat the Sprint Cycle):

This is the most critical step. Do not use tickets as your primary communication. The moment a developer throws a "done" ticket over the wall is the moment you've already lost 1-2 weeks. Sending a "heads-up" email or Slack message two weeks before you file the ticket is the magic trick. It allows other teams to manage their backlogs and "book" time for you. Your goal is to get your feature into the next sprint of all dependent teams. You transform from an interruption into a predictable partner.

The Pros and Cons of Parallelism

This approach is powerful, but it's not "free." It trades one kind of work for another.

Pros

Massive Reduction in Lead Time: This is the obvious win (13 weeks vs. 4). Features get to customers faster, which is the ultimate business goal.
Increased Team Throughput: You can ship more features per quarter.
Earlier Risk Discovery: If AppSec finds a fundamental design flaw, you find out in Week 3, not Week 7. This saves enormous amounts of rework.
Higher Engagement: Other teams are treated as partners, not as gates. They are involved early, feel respected, and can plan their own work effectively.
"Fail Fast" for Architecture: In the sequential model, if InfoSec rejects a fundamental architectural decision in Week 10, you have wasted 10 weeks of Dev and QA effort. In the parallel model, InfoSec reviews the design/code in Week 3. If there is a show-stopping compliance issue, you catch it immediately, preventing weeks of wasted effort on a feature that was never going to be approved.
Context Retention (The Efficiency Multiplier): When a developer fixes a bug 9 weeks after writing the code, they spend 50% of their time just re-reading their own code to remember how it works. By compressing the feedback loop into 3 weeks, the code remains fresh in the developer's mind, making fixes significantly faster and higher quality.
Improved Stakeholder Trust: Strategic parallelization turns delivery into a predictable, scheduled event. Being able to say, "We have booked the Security and SRE slots for Week 3 and 4," sounds far more professional and reliable than "We will send it to Security when we are done."

Cons

Higher Communication Overhead: You (or the tech lead) must spend more time planning, coordinating, and communicating. You can't just put your head down and code.
Increased Management Complexity: You're a circus ringleader juggling multiple acts. If the QA stream finds a blocker, you have to communicate that to the other parallel streams ("Pause your review, a new build is coming").
Risk of Wasted "Pre-Work": If SRE provisions a new server and the feature is then canceled or fails its AppSec review, that work was wasted. (This is a small, manageable risk that is usually outweighed by the time savings).
The "Context Switching" Tax: For the downstream teams (like AppSec), being booked "tentatively" can be annoying if the Dev team slips their deadline. If Dev is late by 3 days, they miss the reservation window in the AppSec sprint, potentially causing similar chaos like sequential model.

Conclusion: The Code is Only 20% of the Delivery

The "Art of Parallelization" ultimately teaches us one harsh truth: Writing the code is often the fastest part of software development. The real challenge—and the real time-sink—lies in the spaces between the code.

If we treat development as a linear assembly line, we are destined for the "Sequential Trap." We surrender our timelines to the mercy of other teams' backlogs and sprint cycles, watching helplessly as a 5-day coding task turns into a 9-week waiting game.

True parallelization isn't about working harder; it's about working wider. It requires:

Visualizing the hidden queues before they happen.
Respecting the planning cycles of your partner teams (QA, Sec, SRE) by alerting them early.
Orchestrating concurrency so that while one team is working, no one else is waiting.

The next time you are assigned a feature, look beyond your IDE. Don't just plan your code; plan your dependencies. By mastering this art, you stop being a developer who just "finishes tickets" and become a developer who delivers value.

(Off course there is some exaggeration in the post, but you get the gist and understood the art of strategic parallelization which many devs fail to understand)

(co-author: Google Gemini Pro)

The CSS Casing Wars: A Survivor's Tale.

Sunil Chaudhary — Mon, 06 Oct 2025 12:38:51 +0000

The CSS Casing Chaos: My Beef with CSS Casing

Confession time: I'm a developer with a bad case of Code-OCD. For the past decade, I've found a strange sort of peace in the predictable, orderly worlds of different programming languages. I love that Python developers collectively decided snake_case_is_the_way, and the JavaScript community embraced camelCaseLikeThis. It’s clean. It’s uniform. It’s consistent.

And then there's CSS.

Oh, CSS. The Wild West of the web. It's the one place where every project feels like a new frontier, and the local naming convention is "anything goes." In my travels, I’ve seen them all:

kebab-case: the-good-stuff
camelCase: theWeirdStuff
PascalCase: TheTitleStuff
snake_case: the_confusing_stuff
And my personal nightmare: an unholy mix of all four in the same file.

😱

Just peek into the developer tools of a few major websites. It’s often a tangled mess that makes my eye twitch.

Examples

Below are statistics from various sites on different percentages of css being used by them in their homepage. Key observations:

Facebook and Instagram seem to be most consistent in classname naming convention.
Amazon seems to be following good old kebab-case.
LinkedIn seems to be using mix-up of classes.

snippet used to gather this data

Gmail

Facebook

Instagram

Amazon

Flipkart

How did we, an industry obsessed with standards, let this happen?

The short answer is that CSS wasn't designed for the complex world it now lives in, and the community built solutions in fragmented ways before any single standard could emerge.

Here are the key reasons why we, an industry obsessed with standards, ended up in this naming mess:

1. Humble Beginnings: It Was for Documents, Not Apps 🌱

When CSS was created in the mid-90s, the web was a collection of static documents. Its primary job was simple: separate content (HTML) from presentation (CSS). No one imagined we'd be building massive, interactive applications with it. The problem of large-scale, maintainable CSS with dozens of developers simply wasn't on the radar. We started with a garden shovel and are now trying to build a skyscraper with it.

2. The Browser's Forgiving Nature 🧐

Programming languages like JavaScript or Python have strict rules and linters (like ESLint or PEP 8) that yell at you for inconsistent syntax. Browsers, on the other hand, are incredibly lenient with CSS. A browser’s main goal is to render a webpage, not to enforce stylistic purity. As long as a class name doesn't break basic syntax rules, the browser will accept my-class, MyClass, or my_ClAsS without complaint. There's no built-in "gatekeeper" to enforce a single convention.

3. Community Solutions Created Competing Standards

As web applications grew more complex, developers felt the pain of messy CSS. Instead of a single, top-down standard being created, brilliant developers from the community came up with their own solutions to manage the chaos. This gave us:

BEM (Block, Element, Modifier): nav__item--active
SMACSS (Scalable and Modular Architecture for CSS)
OOCSS (Object-Oriented CSS)

These are fantastic methodologies, but they are competing philosophies, not a universal standard. It's like if different groups invented their own traffic rules for the same city—all are trying to solve the problem, but the result is still fragmentation.

4. The Tooling Revolution Added Another Layer 🤖

Then came the modern tooling era with SASS, LESS, CSS Modules, and CSS-in-JS. These tools were game-changers, solving major problems like variable management and scope leakage. However, they also introduced their own unique ways of working:

SASS/LESS allowed nesting, which created its own naming patterns.
CSS Modules and CSS-in-JS often generate unique, hashed class names (.header_title__a34Bf) to guarantee styles are scoped. This makes the human-written naming convention less critical for preventing conflicts, so the focus shifted away from standardizing it.

In summary, it wasn't a single decision that led us here. It was a slow, organic evolution where the problem grew faster than the language's core ability to manage it, and the community patched the gaps with a diverse and brilliant—but ultimately fragmented—set of tools and ideas.

So, that explains the chaos, but it doesn't excuse it. We're standing in a mess created by historical accidents and competing ideas. While we can't rewrite the past, we can choose a clearer path forward. For me, that path starts with a simple, foundational choice

Given this complex history of competing methodologies and powerful tools, it’s easy to feel like the problem is too big to solve. But what if the first step toward sanity is much simpler than adopting another framework? What if it begins with looking at the native language itself for guidance?

My Hero: The Humble Kebab

If I had to plant my flag on one hill, it would be for kebab-case (main-navigation-link). It just feels native. CSS properties themselves are written in kebab-case (font-size, background-color, align-items), and so are HTML attributes (data-user-id, aria-label). Using kebab-case for class names creates a beautiful, harmonious flow between your HTML structure and your CSS rules. Everything looks like it belongs together.

Now, I know what you’re thinking. "But what about BEM!?"

Sure, methodologies like BEM (block__element--modifier) are a fantastic effort to bring structure to our stylesheets. They are a godsend for organizing complex components. But here's the catch: BEM tells you how to structure the relationship between classes, not the fundamental way to write the words themselves. You can still end up with MainMenu__Nav-Item--isActive, which is a stylistic Frankenstein.

Two Pleas for a Tidier Future

So, where does that leave us in this beautiful, chaotic mess? I believe the path to CSS sanity lies in maybe a two-pronged approach.

1. The Grassroots Pact: What We Can Do Today

My first plea is to you, my fellow developers, fighting in the trenches of daily code. Let's make a pact. Pick a convention and stick to it with fierce loyalty. My vote is for the humble kebab-case, as it aligns perfectly with CSS's native syntax. But honestly, even if your team chooses camelCase or snake_case, the win is in the consistency. Agree on a style, document it, and enforce it. Future you will be grateful.

2. The Big Picture Plea: A Call to Framework Architects

My second plea goes out to the brilliant minds building the frameworks and tools we love. In the JavaScript world, frameworks like React, Vue, and Svelte don't reinvent the language's syntax; they embrace its standards (camelCase variables, PascalCase components).

Why can't we have that for CSS?

I understand that many modern tools auto-generate hashed class names (.cz13b8) to prevent conflicts, making human-readable names less critical in production. However, the source code—the component files and style sheets we actually write—is where the chaos lives. A plea to the framework architects: Promote and adopt a single, consistent naming style for the code we write. Let's build that consistency right into the tools we use every day.

Until that glorious day arrives, you’ll find me in my projects, acting as the lone sheriff wrangling every stray camelCase and outlaw snake_case I can find. A little consistency, after all, is all a developer with a twitchy eye for clean code can ask for.

Is that really too much to ask?

(co-author: Google Gemini Pro)

Web Development: We're Back Where We Started, and It's a Good Thing!

Sunil Chaudhary — Mon, 22 Sep 2025 06:33:02 +0000

Have you ever looked at the latest trends in web development and thought, "Wait, haven't we been here before?" It feels like we're on the verge of completing a full cycle, returning right back to where we started.

But what if it isn't a circle? What if it's a spiral? We're revisiting old ideas, but with all the knowledge and power we gained along the way. Let's look at the journey.

Stage 1: The Age of the Server (Traditional SSR)

In the beginning, the server was king. Technologies like PHP, Ruby on Rails, and Django would build the entire HTML page on the server for every single request.

How it worked: You click a link, your browser sends a request, the server thinks, builds a brand new page, and sends the finished product back.

The Good: The first page load was fast, and since the content was all in the initial HTML, Search Engine Optimization (SEO) was simple and effective.

The Bad: The user experience could feel clunky. Every significant interaction, even clicking a 'like' button, often required a full page reload. It wasn't smooth.

Stage 2: The Client-Side Revolution (The SPA Era)

To solve the clunky user experience, we flipped the model entirely. Frameworks like React, Angular, and Vue gave birth to the Single-Page Application (SPA).

How it worked: The server sends a nearly blank HTML file and a giant bundle of JavaScript. The browser then runs this code to build the page and handle all future interactions.

The Good: The user experience became incredibly fluid and fast, feeling more like a native desktop app than a website. No more full page reloads!

The Bad: This created new problems. The initial load could be very slow (the dreaded "white screen of death" while JavaScript downloads), and SEO became a major challenge because the initial HTML was empty.

Stage 3: The Hybrid Era (The Best of Both Worlds)

This is where we are now, with frameworks like Next.js, Nuxt.js, and SvelteKit. It looks like a return to Stage 1, but it's far more intelligent. This isn't just server rendering; it's a hybrid model.

How it worked: For the initial request, the server pre-renders the page (like Stage 1), sending fully-formed HTML. This gives us a super-fast first load and perfect SEO.

The Magic Part: This HTML also includes the necessary JavaScript to "hydrate" the page in the browser, turning it into a full-fledged SPA (like Stage 2).

The Result: We get the benefits of the server (fast initial load, great SEO) and the benefits of the client (rich interactivity, no page reloads). This is the "upward turn" in our spiral. We've solved the problems from both previous eras.

Stage 4: Where Do We Go From Here?

So, will we just repeat Stage 2 and go back to pure client-side rendering?

Highly unlikely. That would mean giving up all the incredible performance and SEO benefits we've just regained. The future isn't about going backward, but continuing up the spiral.

The next stage is already taking shape with concepts like React Server Components (RSC) and Edge Computing. These aim to blur the line between client and server even further, allowing us to build incredibly complex applications that remain lightning-fast by intelligently deciding where each piece of the application should run.

So, are monoliths coming back? In a way, yes. But they're not the slow, clunky monoliths of the past. They're smarter, faster, and have learned all the lessons from the client-side revolution.

Lazy Loading: Do you really know what it is?

Sunil Chaudhary — Sat, 06 Sep 2025 11:52:30 +0000

Introduction: Not Your Usual Lazy Loading Blog

If the title intrigued you and you’re expecting a straight answer; this isn’t that blog. But... if you’re here to think, explore, and maybe chuckle a bit, you’re in the right place. 😝

If you ask a developer (or check MDN), you’ll get something like this:

Lazy loading is a strategy to identify resources as non-blocking (non-critical) and load these only when needed. It's a way to shorten the length of the critical rendering path, which translates into reduced page load times.

Here is my tongue-in-cheek definition 😝:

Lazy loading is a strategy developed by SPA libraries owners to clean the mess created by SPA libraries owners when they thought moving from simple server rendered single pages to heavy client side bundled pages is a good idea.

A Short History of Web Rendering

Decade(s) ago, a lot of pages and content were server rendered with only the css, js etc related to that page getting downloaded ('MPA' or 'Multi Page Application').

Then came SPA.
Why? Some people thought it will make applications and subsequent page loads faster, interactions will be better (which are). But no one thought about the initial load time? or the increasing TTI with large bundle sizes? Here comes Lazy loading to the rescue. (Create a problem, then fix it yourself and get kudos from the community on problem which shouldn't have existed in the first place 🤣🤣)

Then comes Code splitting; then comes Lazy Loading; then comes SSR frameworks like NextJs, RedwoodJS; and now we are going back again to MPA style Frameworks from where we started in the first place. With shinier tooling.

Moore’s Law question

What do you think? Are apps genuinely faster today because of these strategies, or is Moore’s Law doing most of the heavy lifting?

Of course there are improvements! People will argue that things are faster. But Are applications really faster due to this? I will probably write another blog on this. Try running the current application in a system that’s decades old. And one will realize that improved hardware, RAM, CPU, GPU etc might be playing a more important reason for better performance than these.

The Cycle Comes Full Circle

Isn't it funny, the entire cycle is completed!
It is also funny that in grand scheme of life, almost every time "History Repeats Itself" or each generation tries to improve a situation only to land back in same situation and never to realize it. In this case:
- We started with server-rendered MPAs.
- We moved to client-rendered SPAs.
- We added lazy loading to fix SPA problems.
- SSR and SSGs coming into place.
- Now frameworks are pulling us back to MPA-style rendering. And here we are, celebrating the “new” solution that looks suspiciously like the old one. Almost like... history repeating itself.

Maybe lazy loading is brilliant. Maybe it’s a band-aid.
Or maybe it’s just proof that in tech, as in life:

We love solving problems we created ourselves.

Thoughts?

(Truly speaking, this is just a thought process right now; will dig much deeper into it;)

Developing our own cowin slot notifier in 30 mins

Sunil Chaudhary — Sun, 16 May 2021 09:04:58 +0000

Since the vaccination slots have opened all over the country; getting a slot has become as difficult as booking tatkal ticket on IRCTC. There are many apps now available who notifies when slots are available; I had an idea - Can I code my own cowin slot notifier? Will it be as effective as other apps? Turns out, the answer is yes. Without further waiting, let's jump into the code.

We will develop a very minimalistic NodeJs application which will notify us when the slots are available.

Pre-Requisites

Cowin Public APIs - https://apisetu.gov.in/public/api/cowin
Some knowledge of a NodeJs.

Part 1: Fetching the data

The API which we need to target are Appointment Availability APIs. Following APIs are exposed by Cowin:

We will use /v2/appointment/sessions/public/findByDistrict but one can use other API as well and the logic will be same. This API takes in 2 query parameters:

district_id - To get the district_id, we need to hit the meta APIs from the swagger. Open the swagger link and hit get states API under Meta APIs - /v2/admin/location/states. Pick the state_id for your state. Then using this state_id hit, get list of districts under Meta APIs - /v2/admin/location/districts/{state_id}. Pick the district_id for your state. We will hardcode this value for out main API. For sample reference, we will use state as Delhi and district as South Delhi. The relevant state_id is 9 and district_id is 149.
date - The date in DD-MM-YYYY format for which we want slots.

We won't send any header value (I think the APIs are not consuming this header properly and giving incorrect response if you use them).

Now we have all data to get the slots. Using the https node module we will make a GET call to https://cdn-api.co-vin.in/api/v2/appointment/sessions/public/calendarByDistrict?district_id={district_id}&date={date}

Sample Code for the same is:

https.get('https://cdn-api.co-vin.in/api/v2/appointment/sessions/public/calendarByDistrict?district_id=149&date=16-05-2021', (resp) => {
  let data = '';

  resp.on('data', (chunk) => {
    data += chunk;
  });

  resp.on('end', () => {
    processData(JSON.parse(data))
  });

}).on("error", (err) => {
  console.log("Error: " + err.message);
});

This will give us the API response in data variable which we will pass to another function for processing.

Note: We need to call the api regularly at frequent intervals so as to get the slots as soon as they are available. The Cowin doc says API have limit of 100 calls per 5 minutes = One call per 3 second. We will use setInterval function for the same and clearInterval as soon as the slots are found.

Part 2: Processing the data

The response we have got is for all the centres of the district. Here is one sample response:

{
  "centers": [
    {
      "center_id":701523,
      "name":"P. SKV School Fatehpurberi S-4",
      "address":"4 Church Wali Gali Fatehpur Beri New Delhi Delhi",
      "state_name":"Delhi",
      "district_name":"South Delhi",
      "block_name":"Not Applicable",
      "pincode":110074,
      "lat":28,
      "long":77,
      "from":"09:00:00",
      "to":"17:00:00",
      "fee_type":"Free",
      "sessions": [
        {
          "session_id":"23e393ea-a06e-42d7-860f-83ecd45edb5f",
          "date":"16-05-2021",
          "available_capacity":0,
          "min_age_limit":18,
          "vaccine":"COVISHIELD",
          "slots": [
            "09:00AM-11:00AM",
            "11:00AM-01:00PM",
            "01:00PM-03:00PM",
            "03:00PM-05:00PM"
          ],
          "available_capacity_dose1":0,
          "available_capacity_dose2":0
        }
      ]
    }
  ]
}

The response contains a lot of info and we will write few conditions to filter the data. Note that each object under sessions array, contains available_capacity key which tells the availability of the slots and min_age_limit key tells the age limit for which slots are open. Based on these 2 keys and other factors such as pincode, let's filter out the results

const pincodes = [110030, 110062]
const centers = data.centers
for (let i = 0; i < centers.length; ++i) {
  if (pincodes.indexOf(centers[i].pincode) >= 0) {
    const sessions = centers[i].sessions
    for (let j = 0; j < sessions.length; ++j) {
      if (sessions[j].available_capacity > 0) {
        slotFound = true
        console.log(`Slots Found:
            Pincode: ${centers[i].pincode}
            Centre Name: ${centers[i].name}
            Centre Address: ${centers[i].address}
            Capacity Remaining: ${sessions[j].available_capacity}
        `)
        notify()
      }
    }
  }
}

Once we have filtered out the results, we need a mechanism to notify us.

Part 3: The Notification

Since, I will be running this application locally in my laptop, I thought of using my Mac's audio player afplay to notify me (Ubuntu equivalent for afplay is ffplay). We just need one audio file in our system and exec from child_process. Using exec, we can run bash commands in node. As soon as any slot is found, we can run the following command. It will start to play the music in our system thus alerting us (:D).

exec('afplay ./audio.mp3')

Stitching everything together, here is the full code:

Go ahead, save this file and run it in your system.

Next Steps

This is a working POC done in 30 mins and can be improved a lot. There are a lot of improvements that can be:

Remove the hardcoding at various places and make the application generic for all states and districts
Support to search for slots by different APIs
Create UI and deploy the same on a website (and change the notification mechanism) to make it suitable for all users

Please comment for any valuable feedback, comment or criticism.

Thanks!

Amazon Virtual Interview Experience - Frontend Engineer II

Sunil Chaudhary — Mon, 28 Dec 2020 10:02:17 +0000

About a few months ago I was looking out for a job when I got the opportunity to be interviewed at Amazon. As I started my research online (or googling as others would say), I found less articles for frontend interviews and that too for virtual processes were close to none. So, after the interview process was over, I thought of writing down an article of my own experience at Amazon.

Hoping that a lot of people will be benefitted by this!

Even if you are not a frontend/UI developer, do have a look as a lot of processes are common for both frontend and backend engineers.

This will be a detailed article going in depth of the entire process from start to end. I will be covering the entire virtual process, online tools, interview rounds (including questions summary) and their timelines as well as will be attaching the relevant docs provided by Amazon. So without further waiting, let's start.

Brief Summary about me

(at the time of interview process)

Total Experience: 4 years
Relevant frontend experience: 3 years
Core Expertise: Javascript (ReactJs + Redux and other relevant libraries in React ecosystem), HTML, CSS, NodeJs
Companies worked till now: Practo and Goomo

Role - Frontend Engineer II (FE2)

The Role I interviewed for was for a Frontend Engineer II (FE2) role (JD attached at bottom). Now, Amazon do have multiple categories of roles even in frontend development. There is one Web Development Engineer (WDE) role and other type is Frontend Engineer (FE) role. As per the interviewers, FE role is more senior in terms of responsibilities and work compared to WDE. So even for same level (e.g. FE2, WDE2); FE2 will have more responsibilities and salary than WDE2.

Process

Do note that Amazon is a very big firm and sometimes, it takes a lot of time to get the process done. Process was relatively longer for me. From applying till the final selection/rejection it took about 3 months.

Shortlisting

My profile went through third party recruitment firm CareerNet Technologies. Kiran from Careernet and their team helped a lot in the overall process. I used to get constant and timely updates from them. All the info related to interviews, shortlisting was conveyed properly. My resume was submitted in early week of March 2020 and took a few weeks to get shortlisted for next rounds.

Number of rounds:

There were 6 rounds in total (including one screening round). All the rounds were done virtually. Most of the rounds were scheduled 1 hour rounds (but few got extended to 2 hours in my case).

Arrangements/Logistics for Virtual Interview

So, the way interviews are happening now will be very different from how they used to happen onsite (pre-covid era). The rounds happened over video call (except for screening which was over chat). I used to get mails few days before the interview. It contained the link for the chat, the online editor as well as white board tool. The mail also contained various other links for me to read and get to know about the company, interview tips and preparation docs etc. The links for documents have been added at bottom.

For white boards, there was invision link shared where both interviewer and interviewee can draw the diagrams etc (Do get used to it as it might slow you down). Though the tool is intuitive to use, it needs a lot of practice to draw things. (Excalidraw is also another similar tool which you can use to practice)
Then there was a tool where you can write code as the interview proceeds. The link was something like: https://livecode.amazon.jobs/session/xxxx-xxxx-xxxxxxxxx-xxxx. Note: There is no functionality to run the code. It was some sort of plain text editor. So, you just have to go with the gut feeling of code being correct/incorrect.
For video calling, the tool was Chime (similar to Google meet or Hangouts).

Timelines

I started to look for a job in mid February 2020 and had started to apply for Amazon via referral as well as third party recruitment firms.

Here is also a timeline of the various rounds. As far as I know, this can vary for individuals depending upon the requirements. The interviews happened as per my convenience and even some interviews happened on Saturdays as my week days were occupied with my work. So, amazon was very much flexible with it.

	Date
Resume submitted	1st week of March 2020
Screening Round	17th April 2020
Round 1	12th June 2020
Round 2	12th June 2020*
Round 3	13th June 2020
Round 4	15th June 2020
Round 5	18th June 2020
Round 6	18th June 2020
Result	23rd June 2020

*This round was interrupted and postponed due to internet issues. So it wasn’t evaluated.

I wasn’t expecting the process to take so long. So, somewhere around screening, I had already joined another firm. But, when the interview call came, I just thought of giving interviews so as to get an experience which will help me in future.

Interview Rounds

There were about 6 interview rounds (including screening round). The pattern was very standard with the only exception being that this was more related to frontend perspective. The questions were mostly restricted to html/css/javascript and the basic principles. No framework specific questions were asked.

Briefly summing up the interview rounds:

Screening: Was asked to write code (html/css/javascript) for a navigation menu bar following all good practices and conventions. Then a lot of counter questions on the solution I presented. This round was a chat only round. There was an online editor where I can write code and a chat window where we can type and interact with the interviewer. No audio/video feedback was there.
Round 1: This round was a mix of DS/Algorithm and UI. Was asked to design a search bar (using trie like data structure) with good caching mechanism (browser side caching). And then there were some other questions related to arrays in Javascript.
Round 2: It was pure Data Structure and Algorithm round. A question to find the lowest common ancestor for 2 nodes in a tree was asked (read more here). Discussed multiple approaches with the interviewer. And then was asked to present a working solution with best time and space complexity covering edge cases. However, this round was interrupted in the middle due to some internet issues and a new round was scheduled for the same.
Round 3: It was more of a culture fit/leadership principles round. A lot of questions of the pattern “Tell me about a time when you did this/that” were asked.
Round 4: I was asked to design the Amazon search page. Users should be able to search and see results. Mostly targeted how will UI components be designed, what will be the API design, What kind of data structure to be used. How optimization/caching etc can be done and a lot more grilling around this. This round went to about 2 hours. This round involved a lot of white board drawing (and due to time constraint, interviewer asked me to submit a flowchart diagram of my solution post interview).
Round 5: Was asked to write optimized solution for problems such as:
1. Given an array, find all pairs of numbers which sum to n with best time and space complexity.
2. Write javascript code to deeply clone an object.
3. Create a circle of radius 200px with some text in the center.
Round 6: This was a mixed questions round. It involved 2-3 questions like “Tell me about time when conflict between you and your team mates arose and how you resolved”. Then there was a algorithm related question on finding the correct order of execution for a set of libraries where some libraries have dependency on other libraries and I was supposed to write the code for the same.

In almost all rounds, the solution expected was to be perfect covering all the edge cases and with best practices. A lot of discussion happened on why certain approaches were better or why this has been done or how can you improve this. This is why it sometimes becomes difficult to crack the interview.

Result

My profile wasn’t shortlisted. This was the mail sent by their HR team.

Post this mail, it took about 10 days for HR to get me the detailed feedback. It was mainly the Data Structure and Algorithms implementation where they felt I need to work a bit more and HR asked me to reapply after some months (the usual stuff 😀).

Also, an interesting point to note here is that during the course of interview Amazon also tries to move the profile between various other job profiles they have if the candidate is not suitable for current applied position which is a pretty good thing on their part. So, they themselves will recommend other positions and will change the course of interviews.

Some useful links:

Summary

Overall it was a nice interview experience. Got to learn a lot of things.

Note: I haven’t included a very detailed description of all the interview questions as the article was getting really long. But do let me know in the comments and I will write a separate article on that. Additionally, I have dumped all the interview questions (even from other companies as well) in this Github Repository. Do check that out as well and contribute by practising and submitting your solutions :-).

Please share it amongst your colleagues, friends and others who might get benefitted from it.

Thanks!

Choose a CMS (Content Management System)

Sunil Chaudhary — Tue, 22 Dec 2020 09:13:43 +0000

Hey folks,

Need some recommendation around good CMS options.

Context

One of my clients (based in India) is looking out for a full-fledged CMS Solution similar to AEM or DotCMS. They already have django-cms as their CMS solution but it is not as good as it seems. It has very basic CMS capabilites but to incorporate anything new requires a lot of coding and python expertise. Anything new means integrate a new plugin and a lot of plugins are outdated.

For example, they needed headless support (which many CMS support) but in django-cms; the plugin for the same is not maintained. I also asked a question for the same on stackoverflow but got no positive response (link to question).

Now, my client is re-thinking the options and here is I need help from you all.

Requirements

Looking out for CMS which supports feature like:

Multi-tenant/Multi-site support
Granular Permissions for sections/pages/documents
Article Versioning
Backup and Restore
Google SSO Integration
Multi language support
Multi environment support (testing/production)
Analytics, etc.

And can be quickly used to onboard multiple tenants/sites with zero or limited developer support.

They are fine with both Paid or Open source versions. We are exploring AEM, dotcms, sitefinity, wagtail etc but recommendation from you folks will really help us finalizing one. We also looked at wordpress, joomla but felt they have more security concerns and hence dropped off those.

Any secure, reliable CMS recommendations will really help. Or if any of your companies is currently using CMS Solution, feedback on the same will be highly appreciated.

Thanks!

Using request/success/failure pattern in Redux to handle async actions

Sunil Chaudhary — Sun, 20 Dec 2020 10:39:50 +0000

Request/Success/Failure Pattern in Redux (2 Part series)
Part 1: Using request/success/failure pattern in Redux to handle async actions
Part 2: Simplifying request/success/failure model for async action in Redux for large applications

A lot of times while making the API calls, we face the challenge; where based on different points of time of API call, we need to show different UI or handle other scenarios in a project. There are a lot of approaches to do the same. However, there is one which is the best and is widely used in many organizations. We will discuss about the same in this article.

This is a 2 part article where we will see what is this pattern and how by using capabilities of javascript we can modify this pattern to scale our project easily and keep the code clean in the longer run.

The pattern!

When any async action or API call is made, there are mainly 3 states:

Request State - The async action or API call is in process
Success State - The async action or API call is successful and gets some data
Failure State - The async action or API call is errored/failed due to some reasons

Based on these 3 states, we create functions and follow certain conventions etc to achieve the desired result.

Things needed here:

action functions
type strings
reducer function(s)

We pick the main action verb here and append request/success/failure at the end to follow consistent naming convention.

Let's take an example where we will be making an API call to get a list of users. For each of above listed cases, we will create an action and a type each. Corresponding to cases in above list for get list of users, we have now the following actions and types now:

And the corresponding reducer and the initial state will look something like this

How it works

When we need to make an api call we will dispatch the request action. It will make isLoading to true and we can use it to show an appropriate message/loader in the screen. As soon as the api call is finished; it will either be in successful or failure state. For each of these, we will dispatch either success or failure which will update the data in the reducer (in data or error variables respectively) as well as make isLoading to false and loaded to true.

The various variables such as isLoading, loaded etc can be now be used in our component for the desired interactions or functionalities.

Why to stick to this pattern

There are several advantages for this pattern and it closely follows all the good practices recommended in any software development. Few of them are:

Readability and Maintainability: Since we are following a fixed pattern for naming, code becomes a lot more readable. request/success/failure model communicates properly the state in which API is and reduces mental overhead.
Code Scalability: This structure is highly scalable. We will see how in our next article where we will reuse this structured format to extend this pattern for multiple API calls and avoid a lot of code repetition.
Control and Precise Hooks: This pattern also gives us more control. Once implemented, we have hooks at various point in API call to update the UI. Variables like isLoading and loaded give us control over UI whereas actions give control over how to save data in reducer.

Integrating the pattern with middlewares

The pattern also fits in very nicely which libraries such as redux-thunk or redux-saga.

An example here will demonstrate on how to use the same with redux-saga

and the same can be done easily with thunk as well.

Adding additional actions/types (if needed)

There could be some scenarios where devs might need to reset the data to initial state. In that case, we can add additional action accordingly.

That's it about the pattern. So simple and sleek and yet so powerful!!

Extending the pattern for multiple API calls

The same approach can be extended now for multiple API calls. The only issue is that if one have a lot of api calls, there will be 3 actions, 3 types and 1 reducer per API call. It means that there will be a lot of repetitive code involved and there will be multiple reducers and logic to merge them.

Well, not to worry about; we can simplify this by using the functional nature of javascript.

For now, Part 1 of the article ends here. Keep following this space and I will update the link for Part 2 in here shortly!

Edit: Part 2 of the article is published here.

Simplifying request/success/failure model for async action in Redux for large applications

Sunil Chaudhary — Fri, 18 Dec 2020 18:14:00 +0000

Request/Success/Failure Pattern in Redux (2 Part series)
Part 1: Using request/success/failure pattern in Redux to handle async actions
Part 2: Simplifying request/success/failure model for async action in Redux for large applications

Now that we have learnt the pattern to skillfully handle the async actions in redux, let's dive deeper into how to simplify the same to make code more cleaner and scalable. For those who missed the Part 1, please read here.

Why to simplify?

Notice that, we have written a lot of boilerplate code just to handle one API call. Also, code will become repetitive in nature for multiple calls which contradicts with DRY and other software writing methodologies.

Process of simplification

We will pick each of our actions, types, reducer(s) and simplify them one by one.

Actions and Types

This is how we write our actions and types in this approach

Observe here that there are 3 actions and 3 types. And the same pattern will be repeated for each API call. Imagine if there are 10 API calls. It means there will be 30 actions and 30 types to be manually written. To avoid this, we will write a helper function that will take one input string and return all the these. The function will look something like this:

If we use the above function then the entire logic for actions and types will be reduced to just one single line

const getUsersList = actionCreator('GET_USERS_LIST')

This will give all the required actions and types.
Next question is how to use all these. The answer is pretty simple. getUsersList is an object, so the relevant actions and types will be following:

getUsersList.request instead of getUsersListRequest
getUsersList.success instead of getUsersListSuccess
getUsersList.failure instead of getUsersListFailure
getUsersList.REQUEST instead of GET_USERS_LIST_REQUEST
getUsersList.SUCCESS instead of GET_USERS_LIST_SUCCESS
getUsersList.FAILURE instead of GET_USERS_LIST_FAILURE

Reducer

This is how current reducer looks like and it is only usable for one api call.

The reducer will now be modified to this

Note we have done 2 things here:

We have clubbed the relevant switch cases together and transferred the logic to update store to a new reducerHandler function.
We have added a key usersList which will contain entire state for that particular API. This will make sure that same reducer can be used for multiple API calls.

Let see the definition of reducerHandler function (helper function to be written only once) now:

Though we have added few functions which might seem that code is increased but observe that the task of creating multiple actions, types and reducers is reduced to few lines. Now if we have to do a new API call, just one line is added to create actions & types and few lines added in reducers instead of writing about 50 lines and adding a new reducer. This simplifies the code a lot.

Integrating with middlewares

The other part of calling from sagas and dispatching actions will remain same. Let's see an example:

This will help to keep code clean and help developers to increase productivity and focus on other areas.

Exhaustive example

Just to show, how this approach works here is an example with just 3 API calls:

Old approach (read more here)

Simplified new approach

If you see, effort is almost reduced to 1/3rd with same desired effect.

Are we done? Yes! At this point, a lot of repetitive logic is reduced and code is simplified. Can we simplify this further? Maybe, but I won't advice it. We can even write a wrapper to avoid writing actions and reducers at all but it has chances of doing more harm than good.

Are there any libraries which can provide these utilities?

Yes, there are a few libraries which can do this for you but one should always think before adding extra libraries. Libraries increase the bundle size and then one has to maintain dependencies etc. That's why for simpler parts like this, writing our own logic seems preferable.

Hope, you like this article. Please like, share and comment to discuss anything which can make this approach better.

Determining real data types in Javascript using Object.prototype.toString

Sunil Chaudhary — Mon, 07 Dec 2020 08:57:57 +0000

Is there an alternative (and maybe better way) to determine data type of variables in javascript other than typeof? Turns out there is one.

Recently, I was looking at some code and found a different way some developers were using to determine the data types using Object.prototype.toString instead of typeof. On further exploration, I found that Object.prototype.toString gives much better results as compared to typeof and can be useful at a lot of places.

Let’s look at some of the results it gives:

Application

Though typeof works fine for most of the cases, toString will come in handy covering cases such as

we need to differentiate between various types in objects (such as arrays, null, object, date)
we need to get correct data type for primitive variables created using their respective object wrappers (e.g. new Number(10) is a number but typeof will give object)

Syntax

One can also write a wrapper around it or even modify the function prototype to remove the unnecessary characters in the output and get only datatypes

Pros vs Cons

It seems typeof is more compact than toString in its usage as well as the result it returns but toString is more accurate.
- toString gives more accurate data types which are useful when differentiating between various types of objects (arrays, null, objects, date)
- toString gives more accurate results in cases if someone has used object wrapper for primitive data types such as new Number/String.
toString function can be overriden but typeof can’t which seems the only major drawback.

You can read more about the mechanism and working of the function over here.

Overall, Object.prototype.toString is a pretty good method to determine the datatypes correctly in lot of cases.

Forem: Sunil Chaudhary

The Art of Parallelization: Why Your Features Take 13 Weeks Instead of 4

The "Sequential Trap": A 13-Week Tragedy

The Parallel Mindset: A 4-Week Reality

Development:

The Review Block:

The Release Block:

New Optimized Plan

Week 1: Development & Proactive Planning

Week 2: The QA testing Sprint

Week 3: The parallelization track

Week 4: Integration & Release Sprint

The Playbook: How to Do It

Deconstruct at the Start:

Map the Critical Path:

Communicate Proactively (and Beat the Sprint Cycle):

The Pros and Cons of Parallelism

Pros

Cons

Conclusion: The Code is Only 20% of the Delivery

The CSS Casing Wars: A Survivor's Tale.

Table of contents:

The CSS Casing Chaos: My Beef with CSS Casing

Examples

Gmail

Facebook

Instagram

LinkedIn

Amazon

Flipkart

How did we, an industry obsessed with standards, let this happen?

1. Humble Beginnings: It Was for Documents, Not Apps 🌱

2. The Browser's Forgiving Nature 🧐

3. Community Solutions Created Competing Standards

4. The Tooling Revolution Added Another Layer 🤖

My Hero: The Humble Kebab

Two Pleas for a Tidier Future

1. The Grassroots Pact: What We Can Do Today

2. The Big Picture Plea: A Call to Framework Architects

Web Development: We're Back Where We Started, and It's a Good Thing!

Stage 1: The Age of the Server (Traditional SSR)

Stage 2: The Client-Side Revolution (The SPA Era)

Stage 3: The Hybrid Era (The Best of Both Worlds)

Stage 4: Where Do We Go From Here?

Lazy Loading: Do you really know what it is?

Introduction: Not Your Usual Lazy Loading Blog

A Short History of Web Rendering

Moore’s Law question

The Cycle Comes Full Circle

Developing our own cowin slot notifier in 30 mins

Pre-Requisites

Part 1: Fetching the data

Part 2: Processing the data

Part 3: The Notification

Next Steps

Amazon Virtual Interview Experience - Frontend Engineer II

Brief Summary about me

Role - Frontend Engineer II (FE2)

Process

Shortlisting

Number of rounds:

Arrangements/Logistics for Virtual Interview

Timelines

Interview Rounds

Result

Some useful links:

Summary

Choose a CMS (Content Management System)

Context

Requirements

Using request/success/failure pattern in Redux to handle async actions

The pattern!

How it works

Why to stick to this pattern

Integrating the pattern with middlewares

Adding additional actions/types (if needed)

Extending the pattern for multiple API calls

Simplifying request/success/failure model for async action in Redux for large applications

Why to simplify?

Process of simplification