At any time a customer may get upset or angry. That is to be expected.
However, it is not okay for customers to speak to you in an abusive or demeaning manner. Customers should not use inappropriate language when speaking to you in any medium.
If this ever occurs, you are allowed to end the conversation and tell the customer that the conversation will begin again when they can speak to you in a respectful manner. If you are not comfortable with that, I am happy to have the conversation with the customer.
You are a human and you are to be respected. Do not let anyone treat you otherwise.
As most of you know, today is my last day at Recruiterbox.
It has been an incredible experience here; I sincerely feel that working here has made me a better person overall. Joining Rbox is undoubtedly the best decision that I have made so far in my career.
I will really miss you guys.
I wish you all the best for the future, and I hope you guys achieve everything you set your eyes on.
Bye, and thanks for the memories!
For the last month the administering Rbox team has been working hard on api v2 and I felt it is now a good time to share what we have achieved.
Today in Recruiterbox we have the following versions of the api
Some of the problems with the above approach
It is desirable to have a single canonical api for recruiterbox that both our app as well as customers use. This means that you add new features and fix bugs in one place.
Today api v1 has over a hundred endpoints. This is hard to grok for even devs inside Recruiterbox, let only external customers. We need to have a small api surface area and a consistent api, so that is easier for devs to start with and work with. React.js is a very good example of it.
The goal is to totally take out api v1 and have our app use api v2. If an app as complex uses the api, then a lot of our customers can as well. The trick however is to keep the design generic enough and not couple it how our app does certain things. This means we need to have routine discussions on the design of the API.
The admin team has already built a few basic endpoints as a first cut. The idea is that if we build anything new, we should use ApiV2. This isn't as easy as it sounds because you may be enhancing a feature that already has an api, rewriting the api layer can add a lot to your delivery times. This a call that every team needs to take after discussing it with other teams and the admin team. Bigger features like for example the candidate profile page redesign will make sure that we use the new APIs. It has become easier to write and modify the api because of the changes in RIP.
RIP had a few rough edges and issues and it was hard to write resources. The admin team has refactored RIP and fixed the following issues
Kudos to the Black ops team of @vedarth @bhargavvoleti @gauravkumar @anantpal for the performance improvements we have made in the last few weeks. Customers have noticed it and are impressed by pace of implementation. Excited to know this is just the beginning and there's a lot more improvements coming up.