Image
Hey there! Check out how we work at recruiterbox
or  Ask us anything
Ask Us
Ask: I'm happy with my current work. Why should I consider working with Recruiterbox?
Ask: What is a normal day @Recruiterbox look like?
Let our team tell you about a typical day at Recruiterbox

I wake up at 8 or so. Talk to my sister. Get ready for office while gossiping with my roomie for an hour. Rush to office. Eat breakfast. Go through the tasks I have to get done for the day.

List them on a paper and breakdown by time. Work for an hour or so. Lunch time, read something which interests me or stand in lunch time convos. Again back to work. Then probably go for a walk with anyone who is interested for coffee or anything. Back to work and try to wrap up before I go for badminton. After badminton, we have our dinner. Then take a quick standup / marketing call if any. Try to think of what to do for next day. Rush to home. Talk to parents and friends. Before sleep I work on small personal projects, lectures or tv series. SLEEP at 2 or so!

Edit Permalink
Chelsea Stroh
DITL of ChelseaBot
Josh
A day at recruiterbox
Travis Townsend
For a SDR, our day revolves around three main peak hours -

Recent

Forgot to thank @frances for having my back everyday! Thanks @frances !!

Edit Permalink

Screen Shot 2017-01-20 at 6.09.56 AM.png

Kudos to @annette for always WOW-ing our customers!

Edit Permalink

Dear everyone:

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.

❤

  • Chelsea cc Justiceleague Stormdragons
Edit Permalink

Adios!

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!

Edit Permalink

AND Kudos to our newest happiness member @dylan for his constant support on slack as we plowed through the day!

Edit Permalink

Kudos to @anantpal and the ops team for supporting us late late late in to the night! 🚀

Edit Permalink

Kudos to @annette and @amar for rocking a SUPER busy day yesterday. On the 18th we worked more than twice the tickets that we worked on the 17th - for 162 in total. 🚀

Edit Permalink

Thanks @akhil for giving us a quick travel through time 👏 🙌

Edit Permalink

Screen Shot 2017-01-18 at 10.59.41 PM.png

Wait.. Raghu was wearing the exact same t-shirt for his last birthday? 🤔 😛

Edit Permalink

Happy birthday boss

Edit Permalink

Api v2 and the way forward

Folks,

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.

###

Why another version of the api ?

Today in Recruiterbox we have the following versions of the api

  1. v1 (eg. /api/v1/openings ) it is a mix of Tasty pie endpoints and some RIP
  2. public_api/v1 (eg. /public_api/v1/openings ) written in RIP authenticated using an api token
  3. js api ( eg. js_api/v1/openings) written in RIP and unauthenticated because it is supposed to be used for customers' career pages.

Some of the problems with the above approach

  • The same entity has multiple endpoints and different conventions of schema which means when we add a new feature or fix bugs we need to do it in multiple places
  • Some of the design decisions are not consistent with each other and not very popular in the external world eg. sub resources, some resources modelled as CRUD endpoints and some others as commands and View.

There is no public and private

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.

Small API surface

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.

Dogfooding is the best way to VALIDATE THE API's DESIGN

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.

All that is awesome, but where are we right now ?

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.

API Endpoints are now easier to write with 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

  • There are sensible defaults for error messages (there were null responses before)
  • All the logic of a resource resides in one class and by extension one place/file Developers have to extend the CrudResource and all the authentication, authorization, entity actions, serialization hooks etc are on the same class. All exsiting resources have been moved to the new style, so no two ways of doing things.
  • Flattened hierarchy in the RIP codebase means if you want to know how CrudResource works, then it is just about reading the code in one class, most classes don't inherit from anything. This is a decent substitute for documentation until we get there.
  • There is a base class for all apiv2 resources called CrudResourceV2, a lot of common logic like authorization which is common across all api endpoints can go here. Developers don't need to add code or tests for this common logic.
Edit Permalink

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.

Edit Permalink

Whoa! I was included in this article of the best Customer Experience posts! (https://www.kayako.com/blog/customer-experience-articles-2017/) :dance:

Edit Permalink

Kudos to @nivedha for stepping in to help with tickets when things got busy!

Edit Permalink

Kudos to @nivedha for going that extra mile personalizing the message for each user, so well that I would accept the request readily if I were that user 🙂

Edit Permalink

Thank you @ashwin for a great January quiz. We'll miss you buddy.

Edit Permalink

Kudos to @nivedita and @prakash1 for organizing today's event. It was great fun meeting everybody's families.

Edit Permalink

In 2016 we worked 27,835 tickets in Freshdesk. WHOA! Nice job, Justiceleague Stormdragons and @nivedha!!! Does anyone have a guess on how many more this was than 2015? I’ll help out with some choices: A) 1,231 🍎 B) 6,753 🍏 C) 8,612 🍌 D) 10,242 🍋 Vote with your choice (fruit) below!

Edit Permalink

Wishing everyone a Happy and Prosperous New Year! 🎉 :rbox:

Edit Permalink