DEV Community: Prashant Singh

How I Answer “What’s Your Expected Salary?” as a Software Developer

Prashant Singh — Wed, 19 Aug 2026 10:47:05 +0000

How I Answer “What’s Your Expected Salary?” as a Software Developer

One of the questions that can make even a good interview suddenly uncomfortable is:

“What are your salary expectations?”

You can be asked this during the first HR call, before you've even spoken to the engineering team.

For developers early in their careers, this question can be especially difficult. You don't want to quote a number that's too low and undervalue yourself, but you also don't want to give an unrealistic number before understanding the role.

Over time, I’ve started looking at this question differently.
Instead of treating it as a question that requires an immediate number, I treat it as the beginning of a conversation.

Don't Rush to Give a Number

When a recruiter asks about salary early in the process, my first preference is to understand the company's range.

A simple response can be:

“I’m looking for compensation that is aligned with the role, responsibilities, and current market standards. Could you share the budgeted range for this position?”
I like this approach because it doesn't make the conversation about a random number.
A software developer role can mean very different things depending on the company. A role requiring Java, Spring Boot, SQL, REST APIs and system design will have different expectations from a role focused mainly on frontend development.

So before deciding what I'm worth, I want to understand what the company expects from me.

Research the Market Before the Interview

If the recruiter asks me for a number and the company doesn't provide a range, I wouldn't want to guess.
Before an interview, I would research similar roles based on experience, location, technology stack and company size.

Platforms such as Levels.fyi and Glassdoor can be useful starting points. For the Indian market, sites such as AmbitionBox can also provide additional context.
The important thing is not to take one salary figure as the truth.

Instead, look for a pattern.

If several sources suggest that developers with a particular skill set and experience level are generally being offered within a certain range, that gives you a much stronger foundation for your expectations.

Then I can say something like:

“Based on my research and the requirements of this role, I’m targeting a compensation range of ₹X–₹Y LPA. However, I’d also be interested in understanding the range you have budgeted for the position.”

Now the number has a reason behind it.

Don't Just Look at CTC

There is another important point, especially when interviewing in India.

CTC is not the same as take-home salary.

A package might include fixed salary, variable compensation, employer PF contribution, gratuity, joining bonuses and other components.
So if a company says:

“The package is ₹6 LPA.”

I wouldn't immediately assume that means ₹50,000 per month in hand.

Instead, I'd ask:

“Could you please explain the fixed and variable components of the CTC?”

That one question can make a huge difference when comparing two offers.
A ₹6 LPA package with a high fixed component can be very different from a ₹6 LPA package where a significant portion is variable.

What If They Keep Pushing for a Number?

Sometimes recruiters won't give you their range.
They may simply ask:

“What is your expected CTC?”

If I have researched the market and understand the role, I would give a reasonable range rather than a single rigid number.

For example:

“Considering the responsibilities of the role, my technical skills and the current market range for similar positions, I would be comfortable with something around ₹X–₹Y LPA. Of course, I’m open to discussing the overall compensation depending on the role and responsibilities.”

This keeps the conversation flexible while still showing that you have an expectation.

What I Would Avoid

One answer I would avoid is:

“Anything is fine.”

Being flexible is good, but having absolutely no expectation can sometimes work against you.
I would also avoid giving a completely random number just because I feel that it sounds impressive.
And I definitely wouldn't exaggerate another offer just to negotiate.
Negotiation is important, but credibility is more important.

Salary Is Only One Part of the Decision

Something else I've learned is that compensation shouldn't be the only thing I evaluate.
For an early-career developer, the quality of the engineering team, mentorship, technology stack, learning opportunities and the kind of problems you'll solve can have a huge impact on your career.

A slightly lower-paying role where you work with strong engineers and build real production systems can sometimes provide more long-term value than a higher-paying role where you're not learning or growing.

That doesn't mean you should accept an unfair salary.
It means salary should be considered alongside the career value of the opportunity.

My Simple Approach

If I'm asked about salary during an early interview, my approach is straightforward.
First, I try to understand the company's salary range.

If the range isn't available, I research the market and understand what similar developers are earning.
If I'm required to provide an expectation, I give a realistic range rather than an arbitrary single number.

And when an offer finally comes, I look beyond the headline CTC and understand the fixed salary, variable pay and other components.
The goal isn't simply to get the highest possible number.

The goal is to make sure the compensation is reasonable for the skills, responsibilities, experience and market value involved.

Final Thought

Salary negotiation doesn't have to be aggressive.
You don't need to sound demanding, and you don't need to avoid the question completely.

You just need to be prepared.

Know your skills.

Know the market.

Understand the role.

And most importantly, don't undervalue yourself just because you're early in your career.

How do you handle the “expected salary” question?

Do you prefer asking the company for its range first, or do you share your expected range immediately?

I’d love to hear how other developers approach this.

Understanding "Pwn Requests" in GitHub Actions: How to Prevent Repository Compromise

Prashant Singh — Thu, 13 Aug 2026 13:35:18 +0000

Automation through GitHub Actions makes continuous integration effortless, but misconfigured workflows can inadvertently hand full write access or secret keys to malicious actors.

One of the most dangerous patterns in GitHub CI/CD security is known as a "Pwn Request."

📌 Credit & Reference: This article summarizes key insights from the original research published by Jaroslav Lobačevski on the GitHub Security Lab Blog.

🔍 What is a "Pwn Request"?

A Pwn Request occurs when an attacker submits a Pull Request (PR) from a public fork that triggers an automated workflow running with elevated privileges (write permissions or access to repository secrets).

Because build and test automation inherently runs code defined within the repository, untrusted PRs can manipulate that execution context. An attacker can achieve code execution by:

Modifying build scripts (e.g., Makefile, PowerShell, or package.json scripts).
Adding malicious package pre-install/post-install hooks (npm install).
Writing arbitrary payload code within test suites executed during CI.

🚨 The Vulnerable Pattern: `pull_request_target` + Explicit Checkout

To protect repositories, GitHub's default pull_request trigger strips write permissions and secret access from PRs originating from external forks.

However, developers often need workflows to comment on PRs or label them. To allow this, GitHub introduced pull_request_target, which:

Runs with write access to the target repository and access to secrets.
Evaluates in the context of the target repository rather than the untrusted fork.

The Deadly Mistake

The vulnerability happens when developers explicitly check out the untrusted head commit of the incoming PR inside a pull_request_target workflow:

# ❌ INSECURE EXAMPLE
on: pull_request_target

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Explicit checkout of untrusted PR code in a privileged context!
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

      - run: npm install
      - run: npm build

When npm install or npm build executes, it runs scripts provided by the untrusted PR while holding a write-capable GITHUB_TOKEN in memory!

🛡️ The Secure Architecture: `pull_request` + `workflow_run`

To safely process PRs from external forks when elevated actions (like commenting or labeling) are required, separate the unprivileged build step from the privileged reaction step using artifacts.

Step 1: Unprivileged Build (`ReceivePR.yml`)

Runs in an isolated environment without write permissions or secrets access.

name: Receive PR
on:
  pull_request:
    permissions:
      contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: /bin/bash ./build.sh
      - name: Save PR number as artifact
        run: |
          mkdir -p ./pr
          echo ${{ github.event.number }} > ./pr/NR
      - uses: actions/upload-artifact@v4
        with:
          name: pr
          path: pr/

Step 2: Privileged Reaction (`CommentPR.yml`)

Triggers only after the unprivileged workflow completes, running safely in the base repository context.

name: Comment on PR
on:
  workflow_run:
    workflows: ["Receive PR"]
    types: [completed]

jobs:
  comment:
    runs-on: ubuntu-latest
    if: >
      github.event.workflow_run.event == 'pull_request' &&
      github.event.workflow_run.conclusion == 'success'
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v4
        with:
          name: pr
          path: ${{ runner.temp }}/pr
          run-id: ${{ github.event.workflow_run.id }}

      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const issue_number = Number(fs.readFileSync('${{ runner.temp }}/pr/NR', 'utf8').trim());
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'All checks passed successfully! Thank you for your contribution.'
            });

💡 Key Takeaways for Developers

Treat external PRs as untrusted input: Never execute code or scripts from external contributors inside a privileged runner.
Avoid checking out untrusted refs under pull_request_target: Use standard pull_request whenever code compilation or testing is required.
Decouple tasks: Use the workflow_run event pattern to pass safe, passive data (like coverage text or PR numbers) from unprivileged workflows to privileged ones.

*For full technical details, refer to the original research by GitHub Security Lab: Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests*.

If your API key is in your frontend code, it's no longer a secret.

Prashant Singh — Sun, 02 Aug 2026 04:26:07 +0000

🚨 "If your API key is in your frontend code, it's no longer a secret."

That one line completely changed how I think about web security. 🤯

I recently read a security research report by RedHunt Labs, and one statistic stopped me in my tracks...

🔍 Researchers analyzed internet-facing web applications-starting with the top 1 million websites and later expanding to ~500 million domains.

💥 They discovered 1.67 MILLION+ exposed secrets.

But here's the scary part... 😳

⚠️ Nearly 77% of those exposed secrets were found inside JavaScript files running in users' browsers.

That means:
❌ API Keys
❌ Cloud Credentials
❌ Payment Tokens
❌ Authentication Secrets

...were all sitting in frontend code where anyone could inspect them.

🎯 My biggest takeaway?

Everything you send to the browser is public.

If your frontend can read it, an attacker can read it too.

The report also revealed production debug pages exposing sensitive information-not because of advanced hackers, but because of simple development and deployment mistakes. 😬

As someone learning backend development, this is a lesson I'll never forget:

🔒 Secrets belong on the backend.

✅ Store them in environment variables
✅ Use proper authentication & authorization
✅ Protect them with access controls
✅ Follow secure deployment practices

Building software isn't just about making it work.

It's about making it secure. 🛡️

Every day I'm realizing that backend development isn't only about APIs and databases-it's also about protecting the data users trust us with.

💡 What's one security lesson that completely changed the way you write code?

👇 I'd love to hear it.

Fixing Cache Stampede & API Latency Spike in Redis-Backed Dashboards

Prashant Singh — Sun, 26 Jul 2026 07:50:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

This project is a high-traffic financial affiliate dashboard built with Node.js, Express, and Redis. It processes real-time user metrics, rank calculations, and commission statistics across multiple active user tiers. The platform relies heavily on cached endpoints to serve heavy aggregation queries quickly to thousands of simultaneous users.

During peak traffic events, cache invalidation triggered a severe cache stampede (thundering herd problem). When a high-frequency key expired or was invalidated after a data update, hundreds of concurrent incoming requests simultaneously bypassed the cache and hit the primary SQL database.

Impact of the Bug:

Sudden spikes in database CPU utilization (reaching 98%–100%).

API response latency jumped from ~45ms to over 3,200ms.

Frequent HTTP 504 Gateway Timeout errors during leaderboard and payout recalculations.

Code

onecompiler.com

My Improvements:
To resolve the bottleneck and ensure system resilience under high load, I implemented a multi-layered optimization strategy:

Distributed Mutex Locking: Used Redis SET NX EX to guarantee that only a single worker recomputes the expensive query when a cache miss occurs.

Stale-While-Revalidate Strategy: Configured background workers to update hot cache entries prior to expiration, eliminating synchronous blocking for active users.

Benchmarking & Latency Reduction:

p99 Latency: Dropped from 3,200ms to 38ms.

Database Load: Reduced peak database CPU usage by 82%.

Failure

Best Use of Google AI

Google AI (Gemini) was utilized during the post-mortem analysis to evaluate lock contention edge cases and optimize the exponential backoff algorithm for waiting threads. It assisted in identifying a potential deadlock condition when Redis connections dropped during lock release, allowing us to implement proper try/finally cleanup blocks.

Are your GitHub Actions workflows vulnerable to command injection?

Prashant Singh — Sun, 26 Jul 2026 05:58:24 +0000

Are your GitHub Actions workflows vulnerable to command injection?

When writing custom GitHub Workflows, context data like issue titles, PR descriptions, branch names, and commit messages are often treated as safe string values. However, because these fields can be controlled by external users or contributors, they must be treated as untrusted input.

If untrusted expressions (e.g., ${{ github.event.issue.title }}) are used directly inside inline run scripts, an attacker can craft inputs to inject arbitrary shell commands—potentially exposing repository secrets or write tokens.
💡 Key Takeaway & Best Practice: Instead of directly interpolating context expressions into inline scripts, assign them to intermediate environment variables first:

❌ Vulnerable:
By storing the value in memory as an environment variable rather than evaluating it directly during script generation, you prevent command injection.
Automating security checks using tools like CodeQL in your CI/CD pipeline can also help flag these expression injection patterns early.

The Countdown Begins: Preparing for My Next Chapter in Tech!

Prashant Singh — Sun, 12 Jul 2026 10:13:01 +0000

The offer is signed, the dates are set, and the countdown to my first official tech role is officially on! 🎓

I am incredibly excited to announce that I will soon be joining the team as a Software Engineering.

Before day one arrives, I’m spending my time diving deep into the tech stacks and engineering principles that bridge the gap between academic projects and production-scale systems. I'm focusing my preparation on a few core areas:

System Design & Architecture: Shifting my mindset toward scalability, microservices, and understanding how data flows efficiently through high-throughput systems.

Modern Tooling & Frameworks: Sharpening my skills in robust frontend/backend technologies, efficient database management, and cloud infrastructure.

Clean Code & Collaborative Workflows: Practicing writing maintainable, production-grade code and mastering Git strategies for seamless team collaboration.

More than anything, I am eager to learn from experienced engineers, tackle real-world complexities, and see firsthand how a modern tech pipeline operates at scale.

The learning curve ahead is bound to be steep, but I couldn't be more ready for the challenge.

To everyone who has guided, mentored, and supported me up to this point-thank you. Let’s build something great soon!

Between Want and Need: What Economics Gets Wrong

Prashant Singh — Thu, 07 May 2026 10:48:39 +0000

Every morning, 733 million people wake up hungry. They have a need - urgent and real. But in the language of markets, most of them don't exist. Because markets don't respond to need. They respond to demand. And demand requires money.
Alfred Marshall defined it clearly in 1890: demand is not desire. It is desire backed by the power and willingness to pay. A starving person needs food whether they can afford it or not. But only the person who can pay creates a market signal.
This gap between need and demand is not a small detail. It is the central fact of modern economic life.
Abraham Maslow's hierarchy - validated across 123 countries and 60,000 respondents - confirms that human needs are universal. Food, safety, belonging, esteem, and purpose. Every person on earth experiences all five. But markets serve them in proportion to purchasing power, not urgency.
Research makes this painfully visible. Healthcare and food, the things people cannot live without, carry the most inelastic demand. People go into debt for insulin. They skip meals to keep the lights on. The market's harshest pressure falls on those with the least power to resist it.
And behavioral research by Kahneman and Tversky adds another layer: much of what we think we need has been constructed for us. Algorithms don't discover our preferences. They manufacture them.
Markets are not broken. They do exactly what they were designed to do - serve effective demand. The problem is that effective demand and genuine human need are rarely the same thing.
Every business decision, every investment, every policy built without understanding that gap is built on incomplete ground.

The distance between what people need and what economies provide is not a gap. It is a choice.

Why I Started Learning System Design as a Web Developer

Prashant Singh — Thu, 16 Apr 2026 07:35:23 +0000

I was reading a discussion on Reddit the other day that made me wonder whether system design is truly important for backend developers or just something emphasized in interviews. It got me thinking about how I approach my work as a developer.

💡 My Realization

When I first started as a web developer, I thought system design was for:
• Big systems that handle a lot of users
• Complicated architectures
• Preparing for big tech interviews

But the more I worked on real projects, the more I realized that system design is actually part of everyday backend development.

🔍 Where System Design Applies in Practice

System design shows up in things like:
• Designing APIs that are reliable and scalable
• Handling third-party integrations with different behaviors
• Managing performance using caching, queues, and async processing
• Building systems that are flexible and easy to extend

Even small applications benefit from good design.

⁉️ Why I Started Learning It

I realized system design is not about size-it’s about problem-solving and decision-making.
For example:
• Handling services with different response times
• Managing inconsistent data formats
• Designing systems that continue working even when parts fail

These are core engineering skills beyond just writing code.

⬆️ Relevance in Modern Development

With the rise of:
• Microservices
• Distributed systems
• AI-assisted development
The role of a developer is shifting toward:
• Designing systems
• Making informed decisions
• Managing complexity

🎯 Current Focus
I’m currently working on:
• Practical system design thinking
• Understanding architectural trade-offs
• Solving real-world backend problems

💬 Closing Thought
System design is not just an interview topic.
It’s a mindset.
I’m approaching it as a long-term investment to become a better backend engineer-not just a coder.
I’d love to hear how others are approaching system design in their journey.
hashtag#SystemDesign hashtag#BackendDevelopment hashtag#Reddit i posted it

DEV Community: Prashant Singh

How I Answer “What’s Your Expected Salary?” as a Software Developer

How I Answer “What’s Your Expected Salary?” as a Software Developer

Don't Rush to Give a Number

Research the Market Before the Interview

Don't Just Look at CTC

What If They Keep Pushing for a Number?

What I Would Avoid

Salary Is Only One Part of the Decision

My Simple Approach

Final Thought

Understanding "Pwn Requests" in GitHub Actions: How to Prevent Repository Compromise

🔍 What is a "Pwn Request"?

🚨 The Vulnerable Pattern: pull_request_target + Explicit Checkout

The Deadly Mistake

🛡️ The Secure Architecture: pull_request + workflow_run

Step 1: Unprivileged Build (ReceivePR.yml)

Step 2: Privileged Reaction (CommentPR.yml)

💡 Key Takeaways for Developers

If your API key is in your frontend code, it's no longer a secret.

Fixing Cache Stampede & API Latency Spike in Redis-Backed Dashboards

Code

Best Use of Google AI

Are your GitHub Actions workflows vulnerable to command injection?

The Countdown Begins: Preparing for My Next Chapter in Tech!

Between Want and Need: What Economics Gets Wrong

Why I Started Learning System Design as a Web Developer

🚨 The Vulnerable Pattern: `pull_request_target` + Explicit Checkout

🛡️ The Secure Architecture: `pull_request` + `workflow_run`

Step 1: Unprivileged Build (`ReceivePR.yml`)

Step 2: Privileged Reaction (`CommentPR.yml`)