To build this, we use an API that runs a recursive query in PostgreSQL. It starts from a user, follows the parent_id links up until it reaches the very first ancestor, and then walks back down through all the children. With millions of records, this becomes heavy work for the database. Even on our powerful servers, the query was taking more than 1.5 seconds to run. The frontend team flagged this as a serious issue, because with thousands of users making the same request, the whole system could slow down.

Time to debug. I figured I must have missed something obvious. Maybe the parent_id column isn’t indexed. But it was a foreign key, and the index was already there, so no luck. Next, maybe the ORM I was using wasn’t generating an efficient query. I rewrote it in raw SQL to see if that helped. It was faster, but only about 72% better. That still fell far short of my target of 500%. At this point, it was clear I needed to change the way the data was structured. Since I was pulling user info by joining multiple tables, I thought of using a materialized view. A materialized view is basically a read-only table that stores the results of a complex query with all the joins, so everything I need is already in one place. The view then gets refreshed every 15 minutes with updated data. When I tried this, the difference was huge. The query dropped to around 200 ms, a 750% improvement. Great! I hit my performance goal and then some. But then I started thinking: is this really the best approach? I was duplicating a lot of data, and every refresh put extra load on the database. It worked, but it didn’t feel clean or sustainable.

I started thinking there has to be a simpler way. What if I just add a root_parent_id column to every record in the users table? That way, each user would always point to their top-level ancestor, no matter where they sit in the family tree. Then, if I need the full bloodline, I can just query all users with the same root_parent_id. I tried it out. After updating the database and running some tests, the response time averaged under 300 ms. That’s fast enough, and it didn’t involve as much data duplication or heavy refreshes on the server. But soon I hit problems. With this setup, I could get the full bloodline, but what if I only needed parents, children, or siblings later in another feature? For that, I’d still have to use the same expensive recursive query I was trying to avoid. Keeping the `root_parent_id` up to date was another issue. Every time a user was added or updated, the system would need to recalculate it. Doing that during a save would slow things down and could cause timeouts, so I’d have to push it into a job queue. It worked, but it felt like too much effort for something that still wasn’t flexible. I knew I needed an even simpler fix.

What if, I just let it run like it was previously running through a time taking, complex CTE and cached a response for the same payload for a given user? It took 1.6 seconds on the first API call and subsequent ones were giving me a response in less than 300 milliseconds. Great, I just need to make sure the response is accurate. I set the cache timeout to one hour only and If a user gets updated, there is a chance that their parent has been changed which could affect not just this user but a lot of others as well. So, I just simply need to invalidate the entire user cache in such a case. The user is not being updated very often so I will be fine.

I communicated to the frontend team that the time taking part has been fixed and to this day, I have’t received a complaint so I guess it is working.

Everything has changed today. Interest rates are at an all-time high, there are many CS graduates and AI has already taken over a few jobs.

How we apply also need to change. There are thousands of applicants and many many more tools that can help us build a better application than there were in 2017.

After spending 5 years in PHP, I wanted to change something, I wanted to go into a cutting edge technology. AI seemed a lot expensive (this was before ChatGPT API). The only viable option was to move to blockchain. But there was a problem. Who would hire me to do the same work as a freshie but for the pay of a 5 years experienced developer. A few interviews gave me the answer, no one.

I had to build a portfolio to land a job and needed a job to build a portfolio. I decided documenting my learning. I made a daily streak of Github commits to a Readme file, I would learn new thing daily and document it. After 4 months, I was hired in Tkxel. The team size was 85, and I was the only blockchain developer among them. I had a big responsibility and the next year was as much challenging as it was fulfilling. Jamal, CEO of that project, later told me that he had interviewed 19-20 people and I was the least experienced but most motivated.

This made me realize that having a hunger to learn and showing that hunger would help my chances of getting a gig.

After a year, the project was ended and I was transferred to the biggest project of Tkxel, as a NodeJS developer. I had no experience with the NodeJs but that wasn’t a problem after a year in blockchain. The past year had given me confidence that I could perform well in unknown territories and the next one confirmed that I was not wrong.

During this time, a lot of recruiters reached out to me in my Linkedin dms and after many interviews, I had a couple of offers in my hand. I was not able to decide which one to pursue, so thought to get help in deciding. I called my former manager and asked her for her advice. She asked if I would be willing to work with her in her new company. I sent my resume over, had a few rounds of interviews and was offered a position which I accepted. Having a recommendation made me bypass all those ATS tools (resume scanners).

A former colleague is an expert in finding remote jobs. I asked him to share his secrets and he told me that all I do is mention their mission and vision in my cover letter. Moral of the story is that personalizing has a better chance of standing out from the crowd.

But it does come with a cost. You would dedicate a few hours daily to apply to a handful of jobs (because personalizing takes time) only to receive automated rejections. In the defence of the recruiters, they are receiving far more applications than they used to. The key is to not be let down. Job applications are a form of sales and sales are a numbers game and good salespersons are not bothered by rejections and even mean replies. They just move on to the next lead.

tldr;

1. Just Apply

2. Build a portfolio yourself if you don’t have any

3. Talk to former colleagues

4. Personalize each application

5. Don’t give up too soon

A couple of months ago, I had a long list of APIs that were to be provided to the mobile and web frontend teams. 9 people were dependent on me to continue their work (and would often stare from across the table) which was anticipated to take about a month. So, I chickened out and provided stub APIs so that they don’t sit idle. It was first for me, and I learned a lot during this process. Here’s a summary of my experience.

Stub APIs are temporary placeholders that provide mock data to frontend teams while backend development is still ongoing. While this technique might seem like a win-win at first glance, it comes with a hidden cost of increased complexity and potential technical debt

1. The URL Format

I was working with NestJS, and circular dependencies between modules are a bit complex. For example, if the "Employee Management" module relies on services from the "Leave Management" module, and there's an endpoint primarily associated with leave management, it might be tempting to place that endpoint in the Leave Management. However, if that endpoint later requires access to employee information, it could lead to complications.

• Including references to "Employee Management" module in the "Leave Management" module would create a circular dependency between the two.

• Moving the endpoint to a different URL would require changes for frontend teams.

This brings me to my next point.

2. Ask Frontend Teams to Store URL Endpoints in env File

All endpoints should be stored in the dotenv file so that the code does not get changed later on.

3. Use a folder to store all the stub responses and use them in your Service File

Even if a lot of endpoints are just returning a simple response like the following

{

“message”: “success”,

“status”: 200
}

Store them separately for each endpoint and require them in the service file (not your controller). This way, you will have a list of APIs that need to get implemented.

4. Conclusion

Don’t do it. I do not see much benefit of this technique. Plan ahead so that the backend and frontend are always in sync.

tldr;

• Think thorough of all the services an endpoint might require later on and use the module that is a super set of these services.

• The frontend teams should be coached to not use endpoints directly in their code. Instead they should use environment variables that hold them so that a change in the API URL does not mean a change in the React code.

• Store all the stub responses in files in a folder dedicated to them. This will serve as a checklist of your technical debt.

• Try as much as possible that the stubbing is not required.