DEV Community: Chirag Goel

Master These 30+ JavaScript Questions to Level Up Your Interview Game

Chirag Goel — Wed, 26 Feb 2025 15:01:16 +0000

JavaScript is one of the most important programming languages for technical interviews, especially for front-end and full-stack roles. Mastering JavaScript interview questions helps you:

✅ Demonstrate problem-solving skills and algorithmic thinking
✅ Showcase deep knowledge of JavaScript fundamentals and advanced concepts
✅ Improve your ability to write clean, optimized, and efficient code
✅ Boost confidence in handling real-world coding challenges

Below are 30+ JavaScript questions that frequently appear in interviews. Understanding and solving them will enhance your coding skills and improve your chances of landing your dream job.

JavaScript Interview Questions You Must Master

Core JavaScript Concepts

💡 Create a Curried Multiplication Function
💡 Group Elements by Callback
💡 Merge Identical API Calls
💡 Custom Polyfill for document.getElementById
💡 Store and Return Message
💡 Memoization for Expensive Calculations
💡 Last Card Loser
💡 Create a Count Function
💡 Two-Way Data Binding with Model
💡 Flatten Array of Objects

Advanced JavaScript Techniques

💡 Distribute Task Units
💡 Throttle API Requests with Promises
💡 Implement _.chunk()
💡 Convert Hours to Minutes
💡 Bind state.value to an HTMLInputElement
💡 Polyfill for Promise.all
💡 Implement LocalStorage with Expiry
💡 Auto-Retry Promise on Rejection
💡 Counting Layers in a Grid

Data Structures & Algorithms

💡 Implement Array.prototype.reduce()
💡 Count Number of Parameters
💡 Intersection of Two Sorted Arrays
💡 Create an Incrementing Score Tracker
💡 Multiply Using Anonymous Functions

Take Your Coding Skills to the Next Level with KodeKarma

Looking to sharpen your coding skills and get interview-ready? KodeKarma is your ultimate platform for practicing frontend coding challenges. With carefully curated problems, real-world scenarios, and personalized guidance, KodeKarma helps you:

🔥 Improve problem-solving efficiency with hands-on coding challenges🔥 Learn from real-world scenarios tailored for frontend development🔥 Get insights and tips from experienced developers
🔥 Track your progress and stay motivated
🔥 Prepare smarter and faster for coding interviews

Looking to take your coding skills to the next level? kodekarma.dev is your go-to platform for practicing frontend coding challenges. With curated problems, real-world scenarios, and guidance tailored for all levels, KodeKarma helps you prepare smarter and faster. Start your journey to interview success today!

It’s difficult to live with and without Git — Oh! Shit! Git!

Chirag Goel — Sat, 04 Jan 2020 15:18:43 +0000

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
This standard definition tell you the power of git and most of us have seen it while using it our projects.

But if anyone of you haven’t used it yet, so its a right time to get your hand dirty — https://devdocs.io/git/

“Imagining a life without you is something that is impossible, you make me complete and I want you to say you mean everything to me.-”
— Most of the developers using git

This article will mostly cover the challenges and the solution to our struggles with git. If below problems sounds familiar to you, then this article is for you -

You committed something and immediately realised I want to make one more small change.
You accidentally committed something on another branch (say master)
Nothing shows in diff command
You want to squash multiple commits into one
You did something terribly wrong and want to time travel your git life cycle
You wanted to know who the hell have written this code

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible.
— mSingh

I know most of above problems are very much familiar to you. So let’s dive into their solutions.

1. You committed something and immediately realised I want to make one more small change.

*# make your change*
**git add .** *# or add individual files*
**git commit --amend**
*# follow prompts to change or keep the commit message
# now your last commit contains that change! *

2. Nothing shows in diff command

**git diff --staged**

3. You want to squash multiple commits into one

*#This will squash last 3 commits into single commit*
**git reset --soft HEAD~3 &&
git commit**

4. You did something terribly wrong and want to time travel your git life cycle

**git reflog**
# you will see a list of every thing you've done in git, across all branches!
# each one has an index HEAD@{index}
# find the one before you broke everything
**git reset HEAD@{index}**
# magic time machine

5. You need to change the message on last commit

**git commit --amend**
# follow prompts to change the commit message

6. You wanted to know who the hell have written this code

# last commit by on each line**
git blame -l <filename>**

# last commit by between lines in a file**
git log -L55,60:file.c**

7. You accidentally committed something on another branch (say master)

Solution by creating new branch —

*# create a new branch from the current state of master*
**git branch -b some-new-branch-name**
*# checkout to master and remove the commit from the master branch
***git checkout master***
***git reset HEAD~ --hard**
**git checkout some-new-branch-name**
*# your commit lives in this branch now :)*

Solution using stash

# undo the last commit, but leave the changes available
**git reset HEAD~ --soft**
**git stash**
# move to the correct branch
**git checkout name-of-the-correct-branch
git stash pop**
**git add .** # or add individual files
**git commit -m "your message here"**
# now your changes are on the correct branch

Solution using cherry-pick

# take that commit to another branch and remove it from master 
**git checkout name-of-the-correct-branch**
# grab the last commit to master
**git cherry-pick [master- SHA]**
# delete it from master
**git checkout master**
**git reset HEAD~ --hard**

The last and most important — Fuck this noise, I give up.

*cd ..

sudo rm -r giveup-git-repo-dir

git clone https://some.github.url/giveup-git-repo-dir.git

cd giveup-git-repo-dir

*# Delete the git repo and clone the fresh repo from remote origin

Wrapping up

Woo! That’s all about most popular git problems. Stay tuned to my future articles.

Was this article helpful for you? Let me know in the comments below if you have any questions or thoughts! I’d love to hear them :)

Thanks for reading. Did this article help you in any way? If I did, I hope you consider sharing it you might just help someone who felt the same way you did before reading the article. Thank you.

Sharing makes you bigger than you are. The more you pour out, the more life will be able to pour in.

Setup your personal blogging website from dev.to in 2min

Chirag Goel — Tue, 24 Dec 2019 17:47:56 +0000

Most of us often like to learn and share our knowledge digitally through articles, videos, podcast, live sessions etc.

— Articles are the simplest, easiest and impactful way of doing so.

Among many alternatives for readers like medium, hubPages, dev.to etc. Dev seems to be more popular among software developers. So in this article we will be talking about dev.to.

dev.to (or just Dev) is a platform where software developers write articles, and take part in discussions and build their professional profile. It value supportive and constructive dialogue in the pursuit of great code and career growth of all members.

For whom this article is?

Do you write blogs on dev.to or planning to do so?
Do you want to setup your own identity(website) without investing much time in infra setup?
Do you believe in write once and use at multiple places?

If above questions seems familiar to you, this article is for you.

What are the challenges we face in order to setup our own blog website?

From where to get theme?
How to build my website?
How to update content of my website?
Where to host it?
How to deploy it?
How to keep it up to date with my public blogging profile (dev.to)?
How to maintain it?

Simplest solution to all above problems — **Stackbit.

Stackbit — Combine any Theme, Site Generator and CMS to use git hosting and Netlify for deployment without complicated integrations.

So let’s start with your blogging website setup. Follow below steps to create your website before your Maggie is ready. Your 2min starts now-

Open **Stackbit **and login.
Select your favourite theme.

Select any site generator. Mine favourite is Gatsby.

Enter repo-name, repo with preferred name will be created in your Github account. Github will be used for hosting your website.
Connect with your dev.to and G*ithub* account.

Click on CREATE YOUR PROJECT it will ask you to signup on Netlify, which will be used for deployment.

That’s all. Netlify is deploying your website. Meanwhile check if your Maggie is ready ;).

Yuppie, your website is ready, click on ‘Visit Site’. For me my website was live before my Maggie. Do share your own experience in comments.

From now Netlify will take care of new post in dev.to or change in your repo on Github and will auto build & deploy it for you.

Wrapping up

Woo! That’s all about setting up your personal blog from dev.to, looking forward to hear about your Maggie challenge. Stay tuned to my future articles.

Was this article helpful for you? Let me know in the comments below if you have any questions or thoughts! I’d love to hear them :)

Thanks for reading. Did this article help you in any way? If I did, I hope you consider sharing it you might just help someone who felt the same way you did before reading the article. Thank you.

Sharing makes you bigger than you are. The more you pour out, the more life will be able to pour in.**

Security Vulnerabilities in Web Apps

Chirag Goel — Sun, 22 Dec 2019 19:49:34 +0000

We will be talking about three degrees of security vulnerabilities that affect enterprise and consumer-oriented web applications: high-severity, medium-severity, and low-severity.

I. High-Severity Vulnerabilities

High-severity vulnerabilities are security flaws that enable hackers to take complete control over a targeted application without having direct access to it.

Cross-Site Scripting (XSS)
SQL Injection
Server-side JavaScript Injection (SSJI)
Remote Code Execution
File Inclusion and Directory Traversal

II. Medium-Severity Vulnerabilities

Medium-severity flaws can partially compromise the confidentiality, integrity, and availability (CIA) of a website or web application. These flaws enable hackers to access business data and modify it to prevent your employees and customers from using it when needed.

Cross-Site Request Forgery
Denial of Service (DoS)
Security misconfiguration (Directory Listing)
Transport Layer Security (TLS)/Secure Socket Layer (SSL)

III. Low-Severity Vulnerabilities

Unlike high-severity and medium-severity vulnerabilities, low-severity flaws cannot be exploited over a network and require authorised access or direct user involvement to take control over a web app.

Insufficient protection.
Failure to encrypt sensitive data.
Using components with known vulnerabilities

Details of above Vulnerabilities:

Let’s cover all of them one by one.

1. Cross-Site Scripting (XSS)

Cross-Site Scripting is a commonly used technique that allows running external JavaScript in the context of the attacked website. XSS allows getting access to full Web API. The simplest example of XSS attack implies that a hacker finds a vulnerable input field on the page and creates a link that injects a snipper to another page. After the link is opened by a user, it’s up to the hacker what will be happened next.

XSS is a high-rated security vulnerability since the attacker can get access to LocalStorage, SessionStorage, or cookies. That’s why it’s recommended not to store any sensitive data in these storages.

2. SQL Injection

SQL injection vulnerabilities exist for websites and apps powered by SQL database software( Structured Query Language). SQL software stores and organizes business data like customer records and payment info.

As SQL databases require authentication, so SQL injection is implemented through app level.

Thus, hackers who skip the authentication scheme of a web application to retrieve contents of an entire database. SQL injections accounted for 64% of web app attacks that were registered through 2016.

Injection flaws result from a classic failure to filter untrusted input. It can happen when you pass unfiltered data to the SQL server (SQL injection), to the browser (XSS), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to these entities, resulting in loss of data.

3. Server-side JavaScript Injection (SSJI)

Server-side JavaScript Injection is one of the most widespread web app vulnerabilities on the web nowadays. It’s a pretty common thing when a developer accidentally introduces proneness into his web application by simple misconfiguration. For example, the **eval **function can be pretty open for attacks and can be exploited with ease.

You should avoid the use of the eval function to decrease the risk of such vulnerabilities. It’s used mostly for speed benefits, but it can compile and execute any JavaScript code which significantly increases the risks.

If you use the concatenation of string of unsanctioned dynamic user input, be prepared to meet some unpleasant consequences.

4. Remote Code Execution

Remote code execution allows hackers to trigger code execution over the internet.

These attacks typically originate from one of your employees who clicks on an email link to a 3rd-party website. That website exploits the vulnerabilities of a web browser or the operating system (OS) running on your corporate computers and infects them with malware.

A hacker can then manipulate the malicious program over the Internet to access sensitive data or lock the computers and demand ransom. Ransomware attacks, for example, grew by 250% last year(link is external) and caused over $5 billion in damage.

5. File Inclusion and Directory Traversal

These vulnerabilities allow intruders to read directories and files outside the root directory, the top directory of a web app file system. During a file inclusion attack, access to any data stored “above” the root directory, for example, other websites’ directories, are inaccessible to users but are accessible to hackers.

Eg. http://192.168.80.134/dvwa/vulnerabilities/fi/?page=../../../../../../etc/passwd

The “../” characters used in the example above represent a directory traversal. The number of “../” sequences depends on the configuration and location of the target web server on the victim machine. Some experimentation may be required.

We can see that the contents of /etc/passwd are displayed on the screen. A lot of useful information about the host can be obtained this way.

6. Cross-Site Request Forgery

CSRF is an attack that exploits the mechanism of sending HTTP requests from the browser. If a user’s PC stores some cookies from a particular website, these cookies will be sent with the request, and it doesn’t matter who starts a given request. Thus, if you let things slide and don’t defend your web app against CSRF, a hacker can steal the accounts of your users.

In the case of CSRF, a 3rd party site issues requests to the target site (e.g., your bank) using your browser with your cookies / session. If you are logged in on one tab on your bank’s homepage, for example, and they are vulnerable to this attack, another tab can make your browser misuse its credentials on the attacker’s behalf, resulting in the confused deputy problem. The deputy is the browser that misuses its authority (session cookies) to do something the attacker instructs it to do.

Consider this example:

Attacker Bot wants to lighten target ram’s PayTm wallet by transfering some of his money to her. PayTm bank is vulnerable to CSRF. To send money, Ram has to access the following URL:
http://example.com/app/transferFunds?amount=150000&destinationAccountNumber=4673243243
After this URL is opened, a success page is presented to Ram, and the transfer is done. Bot also knows, that Ram frequently visits a site under her control at https://medium.com/@engineerchirag, where she places the following snippet:

Upon visiting Bot’s website, Ram’s browser thinks that Bot links to an image, and automatically issues an HTTP GET request to fetch the “picture”, but this actually instructs Ram’s bank to transfer $150000 to Alice.

Incidentally, in addition to demonstrating the CSRF vulnerability, this example also demonstrates altering the server state with an idempotent HTTP GET request which is itself a serious vulnerability. HTTP GET requests must be idempotent (safe), meaning that they cannot alter the resource which is accessed. Never, ever, ever use idempotent methods to change the server state.

7. Denial of Service (DoS)

A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt normal traffic of a targeted server, service or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic.

DDoS attacks are popular because of their simplicity. During a DDoS attack, hackers basically generate a very large number of requests to a server in order to overwhelm it. The main purpose of these kind of attacks is to prevent legitimate users from accessing the server. The attack can be initiated through any individual system or group of systems or crawlers and can use any mechanism to flood servers with huge amount of information and choke it.

8. Security misconfiguration (Directory Listing)

In my experience, web servers and applications that have been misconfigured are way more common than those that have been configured properly. Perhaps this because there is no shortage of ways to screw up. Some examples:

Running the application with debug enabled in production.
Having directory listing enabled on the server, which leaks valuable information.
Running outdated software (think WordPress plugins, old PhpMyAdmin).
Having unnecessary services running on the machine.
Not changing default keys and passwords. (Happens way more frequently than you’d believe!)
Revealing error handling information to the attackers, such as stack traces.

9. Transport Layer Security (TLS)/Secure Socket Layer (SSL)

The SSL and TLS protocols enable two parties to identify and authenticate each other and communicate with confidentiality and data integrity.

Vulnerabilities that allow intruders to access data transferred between client and server.

10. Failure to encrypt sensitive data.

This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. Obviously the crypto/hashing algorithm must not be a weak one — when in doubt, web security standards recommend AES (256 bits and up) and RSA (2048 bits and up).

And while it goes without saying that session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important and cannot be over-emphasized.

11. Insufficient protection

This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed. A lot of times, developers rely on the fact that the server side generated the UI and they think that the functionality that is not supplied by the server cannot be accessed by the client. It is not as simple as that, as an attacker can always forge requests to the “hidden” functionality and will not be deterred by the fact that the UI doesn’t make this functionality easily accessible. Imagine there’s an /admin panel, and the button is only present in the UI if the user is actually an admin. Nothing keeps an attacker from discovering this functionality and misusing it if authorization is missing.

12: Using components with known vulnerabilities

The title says it all. I’d again classify this as more of a maintenance/deployment issue. Before incorporating new code, do some research, possibly some auditing. Using code that you got from a random person on GitHub or some forum might be very convenient, but is not without risk of serious web security vulnerability.

I have seen many instances, for example, where sites got owned (i.e., where an outsider gains administrative access to a system), not because the programmers were stupid, but because a 3rd party software remained unpatched for years in production. This is happening all the time with WordPress plugins for example. If you think they will not find your hidden phpmyadmin installation, let me introduce you to dirbuster.

The lesson here is that software development does not end when the application is deployed. There has to be documentation, tests, and plans on how to maintain and keep it updated, especially if it contains 3rd party or open source components.

Prevention over above Vulnerabilities:

Hold on, let’s wait for my next article. Stay tuned @engineerchirag.

Wrapping up

Woo! That’s all about most popular security concern related to web apps. In my next article we will discuss all about it’s prevention and cool techniques.

Was this article helpful for you? Let me know in the comments below if you have any questions or thoughts! I’d love to hear them :)

Thanks for reading. Did this article help you in any way? If I did, I hope you consider sharing it you might just help someone who felt the same way you did before reading the article. Thank you.

Sharing makes you bigger than you are. The more you pour out, the more life will be able to pour in.