DEV Community: Gaurang Pawar

Why bubbles are good for tech

Gaurang Pawar — Wed, 03 Sep 2025 13:28:29 +0000

Over the years there have been many bubbles in software industry, spreading all the tech domains. Tech bubbles happen when there excessive speculation around a new piece of technology and everyone in the market wants to bet on it.

There is an increase in stock price of companies who are building products using this new technology, other industries supporting this technologies also see substantial gain in investments and stock price.

There will be new startups created everyday getting massive fundings. All the big tech giants will try to get a piece of this pie too. Media and other blogging platforms will publish articles on how this new technology will change the entire world. And this creates a hype, everyone wants to be part a of this new wave of technology.

And if the history is correct, eventually the bubble burst and all comes crashing down. Stock market crashes, layoffs happen and most of these newly formed startups go bankrupt.

So how is this good for tech? Does this mean that the new technology was useless and it was all just a hype?

No, the new technology is not useless, people would still keep using it even after the bubble is burst. There will still be new job openings for that new technology. The Tulips didn't vanish after Tulip Mania, we still use webites 25 years after the Dot Com bubble burst. In fact the usage is now 100x of what it was during the bubble. So why the crash?

The bubble is not about the new technolgy itself but how that technology is supposed to be used. Most of the companies during Dot Com bubble were not creating any customer value. Most of them had unsustainable business models, bad infra and no stable revenue stream. Eventually they all went bankrupt. But few survive to become billion dollar giants.

These billion dollar giants were the ones doing something right. Now there is no playbook on how to successfully navigate through a tech bubble. Its not different than 1 million monkeys with typewriters and eventually one of them writes Hamlet. That's an exaggerated example but thats how tech bubbles are. Bunch of startups doing random shit and eventually most of them fail and few succeede.

But now that bubble is burst we know how to work with this new technology, how its supposed to be used and what specific problems it can solve. This leads to further growth in this technology, and the next startups using this technology has better chance to succeede with it.

Because there was so much investment around this new technology, there was also increase in research. Common problems were identified and new libraries and frameworks are created to fix these problems. Now someone new picking up this technology does not have to worry about the problems that people before him/her faced. See how easy it is to create a website today compared to 2000s.

We have optimized libraries, ready made templates and everything is perfected. Bubbles are more about finding out how we can fail at this thing in 100 different ways.

There is also an invisible flow of knowledge during these bubbles. Becacuse there is so much money flowing in and everyone is getting high salaries, most of the engineers working in bigtech where they have experience working on complex high scale systems, leave those companies to start their own company or join a newly funded startup.

This migration result in flow of knowledge, which before this only small group of engineers working in the big tech had. Now every startup has this one engineer who has years of experties working on complex problems. Even if the startup goes bankrupt the knowledge persists.

The good practices and ideas becomes an industry standard.

Since most of the companies are starting from scratch, they adopt new technologies. They would pick the shiny new database and better security and monitoring tools. This attracts more open-source contributions to these technologies.

Most of the entry level grads joining these startup would get to work on real stuff which impacts customers. They get to wear multiple hats and be part of important decisions. They may not do everything right but they are full of energy allowing them to do more. This real world experience will play huge role in their professional careers.

There is still a lot of damage because of these bubbles. People lose their life savings and jobs. But the tech thrives.

I open-sourced sttrace.com's problemset

Gaurang Pawar — Tue, 02 Sep 2025 20:22:08 +0000

I recently launched sttrace.com. It helps users practice real world Software Development, DevOps and SRE scenarios.

It has multiple problems which heavily revolve around skills required for everyday developer tasks. Up until today I was creating new problem everyday. The process was simple I need to create bunch of files data.json for metadata, description.md for problem statement, init.sh for setting initial task state in container and task_submit.sh to evalute users submittion, and the problem was pretty much ready.

I had a simple CLI tool which will then create the Docker image and parse the data.json and description.md file for additional data and upload everything to backend server.

So why did I open-source it?

The problems on sttrace.com needs to be as close as possible to real world scenarios faced by developers. Having spent only 3 years in the industry as DevOps and SRE engineer, I realised that my experience is very limited. This means that eventually I will run out of good scenarios for these problems.

This will heavily affect the quality of site and turn it into yet another coding platform with 10+ problems which revolves around same data structure or algorithm.

Making it open source allows other experienced engineers around the world to contribute new and fresh challenges. This also creates a community around the project which attracts like-minded people who have same goal.

My motive behind sttrace.com was never to create yet another programming platform where users would mindlessly grind for hours and get nothing out of it. It was to create an upskilling platform where users can learn stuff by solving challenges which would help them in their career.

This doesn't mean that I've open sourced entire source code. I would still manage the website and hosting myself. This allows me to focus more on the core product and marketing side of things.

The problemset GitHub repository sttrace-com/problemset is now actively accepting contributions. Anyone with professional experience in Software Development, DevOps, SRE and Security is welcome to contribute.

How I put my homelab to use

Gaurang Pawar — Sat, 30 Aug 2025 20:03:32 +0000

I recently launched sttrace.com, it's a site where people can practice real world software engineering problems. When it was finally time to move it from localhost to the internet I had to figure out a way to host it without burning a hole in my pocket.

It's a simple website with a React client, Node.js backend server and a container manager REST API service. If I spin up one medium-sized EC2 instance, I can probably fit all the services along with a Postgres server and a self-hosted image registry in there.

But looking at the cloud costs I realized that this setup would be very expensive. Then I realized I already have 2 servers running in my homelab. It's nothing fancy, 2 Dell Optiplex machines both running Linux. It'd be perfect for hosting. I can run my main monolith service on one server (the smaller one) and put the container manager and database on the other server. The second server is the bigger one since the container manager and DB will require more resources.

The challenge would be to get around CGNAT. I tried some tunneling services which can give me public URLs for the services I was running on my homelab but the paid tier was too costly for me at that time.

So I decided to implement my own SSH tunnel. First I needed something to tunnel to, so I got an elastic IP and a t2.micro EC2 instance on AWS. I started an nginx service on it and routed all the traffic to local ports.

Once the nginx was running I started an SSH tunnel from my homelab to the EC2 instance.

I then shoved all my startup commands for the required services into a bash script and created a systemd service.

The website was then fully live🥳

This setup costs only peanuts, but is quite susceptible to internet or power outages.

How I created sttrace in 1 week

Gaurang Pawar — Fri, 29 Aug 2025 17:14:43 +0000

This was one week before my Meta Production Engineer interview. I was looking for a website to practice my debugging and SRE skills. Meta has these debugging rounds where you are given a real world situation such as a broken server or an unresponsive service, and you have to provide a step by step analysis of what you would do in that situation.

Unlike normal coding interviews where you can simply solve the top 50 DSA/algo questions and clear the interview, debugging interviews do not have many websites where you can tackle simulated production outages.

So, just like any other developer with lots of free time, I decided to create one :)

It started with a very basic webpage: a simple terminal emulated in the browser with the xterm library. The input and output are sent via a socket connection to a backend server, which then routes it to a running container via SSH connection. The container has a very basic structure:

entrypoint.sh sets up sshd and other required processes
init.sh initializes the required state for the problem
submit.sh is triggered after the user clicks the submit button in the browser. It checks the current state of the user directory and echoes success or failure on the stdout stream.

Once I had the backbone set up, I needed to think about scaling. This was not going to be the next ChatGPT receiving millions of users in a week, but I still needed to plan for horizontal scaling in case it grew. The Node.js monolith backend could handle heavy traffic, so I was not worried about that. I also trusted Postgres for performance since most of the required queries were simple reads with little to no joins. The only part that could become a bottleneck was the running containers triggered for each problem.

I needed to spread these containers across multiple nodes for better performance and reliability. I went with a basic master slave architecture. Each node worker, when started, registers itself with a master service, which in this case is the backend monolith. The master then performs a basic health check on the node worker and places it inside a priority queue. I use the priority queue to find the best node worker for an incoming connection request and it also acts as a load balancer.

Another challenge was finding the right container manager. I needed a lightweight container manager with an API to start and stop containers. I could not find one, so like any other unemployed engineer with lots of time on his hands, I decided to create my own. A basic Flask API wrapper around the Docker client took less than an hour.

Once I had all the basic parts, I duct taped together a working website. Next was hosting. Looking at my options, I realized I did not have enough spare money to throw at EC2 boxes, but I did have two powerful Dell Optiplex boxes in my homelab, both running Linux. With a few bash scripts the homelab was all set to run the site. I got an elastic IP and spun up a t2.micro box routing all the traffic via an SSH tunnel to my homelab, and the sttrace.com was live.

The whole thing took around one week to build, and I was able to get around 40 users within the first two days of launch.

So, what is next?

I try to create at least one problem every day, but the website is still incomplete. The idea behind sttrace.com was bridging the gap between recruiters and developers. The next step is to build an internal job board where recruiters can post jobs. I also want this website to be a place where developers come to upskill instead of grinding problems only for job interviews.

I’m just getting started, and there’s a lot more to build. If you’re a developer looking to sharpen your debugging skills or a recruiter interested in meaningful assessments, check out sttrace.com and be part of this journey. Your feedback and participation can help shape it into a valuable platform for everyone.

Why SRE is not for entry-levels

Gaurang Pawar — Thu, 28 Aug 2025 14:58:31 +0000

So you just learned Docker and Linux, and while exploring potential job opportunities, you see that SRE is a booming field. It has good demand and is not saturated compared to other software domains like web dev and backend. You see the job description and notice that the tech stack is not that overwhelming. You need to know Linux, Docker, and a few backend frameworks. Cool, you are totally competent to do this job.

You apply and never get any response :(

Compared to other software engineering domains, SRE and Production Engineering are the two fields where the Dunning-Kruger effect hits hard. In web dev or backend, all you need to do is learn a few frameworks, make some projects, maybe look at some open-source production-ready code to see what good industry practices are, and you are good to go. You may still not have any industry experience, but you do know most of the tech stack, and it should not take you more than 5 months to start shipping features.

SRE and Production Engineering are like firefighting. You can read all the books you want, but unless you have enough experience barging into a burning house, you are not going to do well.

This is what makes most entry-level developers not fit for SRE. Having worked 3 years in the SRE and Production Engineering field, I can say most production outages can be solved by running 2–3 basic Linux commands, but it takes years of firefighting experience to figure out what to run and where to run it.

When something fails in production, there are 10 different things that could be responsible. Modern software tech stacks consist of 10+ microservices, a cache, monitoring tools, multiple databases, and load balancers. Where do you even start to look for a problem? This is a classic reference to the Old Engineer with a Hammer story!

Most of the really sharp SREs I've met in my career are veteran developers and sysadmins. They've pretty much worked on all the tech stacks needed in modern production systems.

So how does an entry-level dev get into SRE? The answer is you don’t. You get enough development and DevOps experience to pave your path toward an SRE role. You need to know enough about software engineering and architecture to be able to imagine the entire production system in your head.

For anyone who is still keen on learning how they can work on real-world SRE problems and want to try out their Linux skills, sttrace.com is the right place. It has lots of real-world problems simulating production outages and, in general, the operational tasks an SRE would do. It is also a good place to challenge yourself to learn more about Linux.

DSA Won’t Save You in Production

Gaurang Pawar — Thu, 28 Aug 2025 13:15:24 +0000

Recently Meta announced that they will allow the use of AI tools in interviews. This changes the way candidates prepare for these interview. After having solved 700+ Leetcode problems I realized that after a certain point, the learning saturates.

There is also very little you can learn from grinding coding websites that can be translated to real-world SDE tasks. Sure, knowing how to work with heaps is a good skill to know when you want to implement small in-memory priority queue or knowing topological sorting in case you are trying to make a package manager. But honestly, it doesn’t take more than 1 day to learn any of these concepts, also with hundreds of libraries available that let you simply call the required functions, you don’t need to spend days trying to master these concepts.

To be really good generalist software engineer, you need to master The Black Box Method. You don’t need to know how push and pop algorithm for heap works under the hood, but you can simply understand what heap is and how pushing and popping items in heap can help you get items faster in O(log(n)) time. Look the type of problems that you can solve with heap. And when in future you see a probelm your brain will automatically tell you that this is a heap problem.

Cool, but how is this related to software or production engineering interviews?

In real world, nobody cares if you Google an error or simply copy paste the error trace to ChatGPT. What’s important is to solve the problem in front of you. Because of the growing supply of software developers and with rise of LLMs the old DSA+Algo style interviews are becoming useless. Its becoming easier and easier to game or cheat the system. Just solve the top 15 most frequently asked questions for a company and there is a good chance that you will clear the interview.

This is the main reason I created sttrace.com(yes, the name in inspired by linux tool strace, that domain name was costly🥲), having realized that real world software engineering requires you to be decent in a wide range of skills which are very hard to develop if you haven’t faced enough problems or production outages.

It has a wide variety of problems focusing on Debugging, DevOps, SRE, and Security. The good thing is, you can solve the problem however you want. You are not forced to use a certain tech stack or algorithm to solve a problem, the submissions are evaluated based on the final results. I add new problems daily, and I’ll soon be launching an internal job board.

As AI changes the interview landscape, the engineers who thrive won’t be the ones who memorized algorithms, but the ones who’ve practiced solving unpredictable and messy problems. And that’s the vision behind sttrace.com